Re: [PATCH] PCI: keystone: update to support multiple pci ports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/05/2014 05:11 PM, Arnd Bergmann wrote:
On Friday 05 September 2014 16:37:25 Murali Karicheri wrote:
On 09/05/2014 03:00 PM, Arnd Bergmann wrote:
On Friday 05 September 2014 14:33:54 Murali Karicheri wrote:
This looks like it's a shared register of some sort that doesn't
really belong into the registers of a particular port. Could it
be that it's actually for the PHY?

This a shared device configuration register between the two ports the
desciption states it is bootstrap configuration of the PCIe module as
Endpoint or Root complex and Not Phy. Hope below text will help.

Ok. Why do you want to have this user-selectable though? Can't it
just be set by the boot loader before starting Linux?

Arnd,

As the driver is responsible for configuring the device to support the
device functionality, it make sense to do this in the device driver. The
driver enables clock to the IP and this is an addition thing to be
configured so that when the device is powered up, it should function as
RC. The IP can be configured to work as Root Complex or Endpoint. So not
sure why you want to me to move this functionality to boot loader.

But the driver can only do root complex mode, and we would probably
want a completely different driver if we were to start supporting
endpoint mode.

Arnd,

Good point! I will drop index#2 handling in the driver code and will handle the same in boot loader. But I have a question though. The original driver which is queued up for merge to v3.18 has index #2 for this reg offset and is documented in the DT documentation as

	index 2 is the base address and length of PCI mode configuration
	register.
	index 3 is the base address and length of PCI device ID register.


Will this create any issue in terms of backward compatibility if I remove it and move index3 to index2 and update the code for the same? I assume since this patch also will likely be on the next branch soon, and gets merged together with original driver to v3.18, this should be fine. But for some reason, if this patch doesn't make to v3.18, then won't this break the backward compatibility?

I think the other option is document index2 as obsolete and update the document and remove the code for handling it. Any suggestion?

Thanks

Murali

This also implies that the firmware has to pass a different DT for
endpoint mode, so it should be responsible for setting up the hardware
to match the DT.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux