[PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Ping 

> Subject: RE: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
> PCIe Host Controller
> 
>  > On Mon, Dec 21, 2015 at 05:23:47AM +0000, Bharat Kumar Gogada wrote:
> > > Hi Bjorn, can you comment on this. Marc has also replied for query
> > > on
> > irq_dispose_mapping().
> >
> > I'm not sure exactly what you want me to comment on.
> I wanted you to check for Marc's reply.
> >
> > > > Subject: RE: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for
> > > > Xilinx NWL PCIe Host Controller
> > > >
> > > > > Subject: Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for
> > > > > Xilinx NWL PCIe Host Controller
> > > > >
> > > > > [+cc Marc for irq_dispose_mapping() question]
> > > > >
> > > > > On Thu, Dec 10, 2015 at 02:10:34PM +0000, Bharat Kumar Gogada
> > wrote:
> > > > > I'm trying to figure out what the difference is between these
> > > > > two checks and why you have both of them:
> > > > >
> > > > > > +	if (bus->number == pcie->root_busno && devfn > 0)
> > > > > > +	if (bus->primary == pcie->root_busno && devfn > 0)
> > > > >
> > > > > If I understand correctly, pcie->root_busno is the bus number of
> > > > > the Root Port device (likely 00).  I think the "bus->number ==
> > > > > pcie->root_busno && devfn > 0" check means that the Root Port,
> > > > > pcie->e.g.,
> > > > > 00:00.0, is the only device allowed on bus 00.  Often a Root
> > > > > Complex contains several Root Ports and other integrated devices
> > > > > that typically are
> > > > on bus 00.
> > > > > But in your case, I think you're saying there is only the single
> > > > > Root Port and no other devices.
> > > > >
> > > > > I think that first check takes care of everything on bus 00, so
> > > > > I'm trying to figure out what the second check is for.  Assume
> > > > > your Root Port is device
> > > > > 00:00.0 and it is a bridge to [bus 01-ff].  Then we have two
> > > > > pci_bus structs with these values:
> > > > >
> > > > >   bus->number = 00
> > > > >   bus->primary = 00
> > > > >   bus->busn_res = [bus 00-ff]
> > > > >
> > > > >   bus->number = 01
> > > > >   bus->primary = 00
> > > > >   bus->busn_res = [bus 01-ff]
> > > > >
> > > > > Because of the first check, 00:00.0 is the only possible device
> > > > > on bus 00, and because of the second check, 01:00.0 is the only
> > > > > possible device on
> > > > bus 01.
> > > > > Therefore, you don't support a multifunction device connected to
> > > > > the Root Port.  Right?
> > > > >
> > > > We support multifunction devices also, so this check should not be
> > > > there, will remove this check in next patch.
> >
> > It looks like you're planning to change this.
> No, our core supports multifunction devices it was my misunderstanding,
> due to which this condition was present.
> > > > > > > > +		return false;
> > > > > > > > +
> > > > > > > > +	return true;
> > > > > > > > +}
> > > > > > > > + * nwl_setup_sspl - Set Slot Power limit
> > > > > > > > + *
> > > > > > > > + * @pcie: PCIe port information  */ static int
> > > > > > > > +nwl_setup_sspl(struct nwl_pcie *pcie)
> > > > > > >
> > > > > > The Set_Slot_Power_Limit Message includes a one DW data
> payload.
> > > > > > The data payload is copied from the Slot Capabilities register
> > > > > > of the Downstream Port and is written into the Device
> > > > > > Capabilities register of the Upstream Port on the other side
> > > > > > of the Link. Bits 9:8 of the data payload map to the Slot
> > > > > > Power Limit Scale field and bits 7:0 map to the Slot Power
> > > > > > Limit Value field. Bits 31:10 of the data payload must be set
> > > > > > to all 0's by the Transmitter and ignored by the
> > > > Receiver.
> > > > >
> > > > > > This Message is sent automatically by the Downstream Port (of
> > > > > > a Root Complex or a Switch) when one of the following events
> occurs:
> > > > > > -> On a Configuration Write to the Slot Capabilities register
> > > > > > -> (see
> > > > > > Section 7.8.9) when the Data Link Layer reports DL_Up status.
> > > > >
> > > > > I interpret this as meaning "the *hardware* automatically sends
> > > > > a Set_Slot_Power_Limit Message."  There's no mention of software
> > > > > doing anything other than the configuration write.
> > > > >
> > > > > If your hardware doesn't do that, I think it's a defect.  It's
> > > > > fine to work around it, but we should have a comment to that
> > > > > effect so people don't copy the code to new drivers that don't need
> it.
> > > >
> > > > Our hardware is not capable of doing it, so we are doing it
> > > > software. Yes I will add some comments.
> >
> > And add a comment here.
> >
> You meant to add comments for the function clearly mentioning that
> hardware doesn't support this so doing it software ?
> 
> > > > > It's a little strange that 7.8.9 talks about writing to this
> > > > > register when all of its fields are HwInit and supposedly
> > > > > read-only.  I had assumed devices would use strapping or
> > > > > implementation-specific registers to set the Slot Power values,
> > > > > but maybe some devices use direct
> > > > writes to Slot Capabilities instead.
> > > > >
> > > > > BTW, I noticed a related lspci bug: it didn't decode the Capture
> > > > > Slot Power Limit in Device Capabilities of Endpoints.  I posted
> > > > > a fix for that
> > > > separately.
> > > > >
> > > > > The Slot Power Limit (in Slot Capabilities) indicates how much
> > > > > power the slot can supply to a downstream device.  That's a
> > > > > function of the platform design, so it seems like this is
> > > > > something you want to set via DT or some other mechanism that
> > > > > knows
> > about the platform.
> > > > > Intercepting all config writes and updating it with whatever the
> > > > > caller supplies doesn't sound wise.  The value might be coming
> > > > > from setpci or some other source with no knowledge of the platform.
> > > >
> > > > Agreed, but this is what can be done, it is difficult to determine
> > > > who does what.
> >
> > Your driver is based on DT.  What prevents you from adding a DT
> > property that shows the slot power capability?
> >
> You meant to add a DT property, Example: xlnx,slot_power_cap; as required
> property, and use this property to call nwl_setup_sspl function. Currently
> this function is being invoked in config write function if the condition meets a
> write to slot power capabilities register.
> > > > > > > > +			status = nwl_bridge_readl(pcie,
> > > > TX_PCIE_MSG)
> > > > > > > > +						  & MSG_DONE_BIT;
> > > > > > > > +			if (status) {
> > > > > > > > +				status = nwl_bridge_readl(pcie,
> > > > > > > TX_PCIE_MSG)
> > > > > > > > +						  &
> > > > MSG_DONE_STATUS_BIT;
> > > > >
> > > > > > > It's not clear to me whether you need to re-read TX_PCIE_MSG
> > here.
> > > > > >
> > > > > > MSG_DONE_BIT qualifies MSG_DONE_STATUS_BIT; so value of
> > > > > > MSG_DONE_STATUS_BIT is valid only when MSG_DONE_BIT = 1
> > > > >
> > > > > That doesn't answer the question of whether another read is
> required.
> > > > > In fact, I would argue that if MSG_DONE_STATUS_BIT is only valid
> > > > > when MSG_DONE_BIT = 1, you *should* only do one read, because
> > you
> > > > > want to capture both bits simultaneously so you know they're
> > > > > consistent, e.g.,
> > > > >
> > > > >   status = nwl_bridge_readl(pcie, TX_PCIE_MSG);
> > > > >   if (status & MSG_DONE_BIT) {
> > > > >     if (status & MSG_DONE_STATUS_BIT)
> > > > >       ...
> > > > >   }
> > > > >
> > > > > If you read the register twice, you always have to worry about
> > > > > what changes MSG_DONE_BIT, and how you guarantee that the
> > second
> > > > > read happens before MSG_DONE_BIT changes.
> > > > >
> > > > Agreed, will do it in this way, once will also confirm with IP
> > > > owner regarding both bits being updated parallel.
> >
> > It sounds like you're working on resolving this.
> >
> > Did I miss a question for me?
> 
> Since IP owner is different, we don't have exact information by that time we
> commented, now we got Information from owner that both buts
> simultaneously.
> 
> Bharat