On 14/02/14 05:40, Magnus Damm wrote:
On Thu, Feb 13, 2014 at 9:34 PM, Ben Dooks <ben.do...@codethink.co.uk> wrote:
On 13/02/14 03:03, Magnus Damm wrote:
PCI: rcar: Recent driver patches from Ben Dooks and me
[PATCH 01/08] PCI: rcar: check platform_get_irq() return code
[PATCH v2 02/08] PCI: rcar: add error interrupt handling
[PATCH 03/08] PCI: rcar: fix bridge logic configuration accesses
[PATCH v2 04/08] PCI: rcar: Register each instance independently
[PATCH v2 05/08] PCI: rcar: Break out window size handling
[PATCH v2 06/08] PCI: rcar: Add DMABOUNCE support
[PATCH 07/08] PCI: rcar: Enable BOUNCE in case of HIGHMEM
[PATCH 08/08] PCI: rcar: Make the Kconfig dependencies more generic
These patches update the pci-rcar-gen2.c driver with patches from
Ben Dooks and me. The first 3 are written by Ben (thanks!) and are
included here to show what I would like to have merged and what I
rebased my patches on. The following 4 are updated versions of
[PATCH 00/04] PCI: rcar: Driver model and physical address space update
The final patch is a new one that fixes up the Kconfig dependencies.
Thanks. Is there any chance of getting this driver device-tree
enabled too?
I think so! The DT bindings proposed by you looked good for this device.
The only question is how to handle the PHY hardware in a sane way. The
PHY is the central problematic point so to say, since it ties these
PCI USB2.0 devices together with USBHS and for some SoCs USB 3.0 as
well.
I'm thinking of something along these lines:
1) To use DT to describe the full hardware topology
2) Enable all or some device drivers in the kernel configuration
3) Have a sane default but use the bind interface to reassign
driver-to-port configuration.
What is your intended use case?
I think we can describe this all from the PHY node or links to
the PHY node. I was going to look at sorting out the bindings
next week, due to this week being mostly consumed by chasing
bugs.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
