Hello.
On 03/07/2014 05:27 PM, Sergei Shtylyov wrote:
Add support of the device tree probing for the Renesas R-Car generation 2 SoCs
documenting the device tree binding as necessary.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx>
---
This patch is against the 'next' branch of Felipe Balbi's 'usb.git' repo.
Changes in version 2:
- restored devm_clk_get() call and the error handling logic in the probe()
method, removed clk_put() call in the remove() method.
Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt | 29 +++++++++++
drivers/usb/phy/phy-rcar-gen2-usb.c | 42
++++++++++++++--
2 files changed, 68 insertions(+), 3 deletions(-)
Index: usb/Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt
===================================================================
--- /dev/null
+++ usb/Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt
@@ -0,0 +1,29 @@
+* Renesas R-Car generation 2 USB PHY
+
+This file provides information on what the device node for the R-Car
generation
+2 USB PHY contains.
+
+Required properties:
+- compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790
SoC.
+ "renesas,usb-phy-r8a7791" if the device is a part of R8A7791
SoC.
+- reg: offset and length of the register block.
+- clocks: clock phandle and specifier pair.
+- clock-names: string, clock input name, must be "usbhs".
+
+Optional properties:
+- renesas,channel0-pci: boolean, specify when USB channel 0 should be
connected
+ to PCI EHCI/OHCI; otherwise, it will be connected
to the
+ USBHS controller.
+- renesas,channel2-pci: boolean, specify when USB channel 2 should be
connected
+ to PCI EHCI/OHCI; otherwise, it will be connected
to the
+ USBSS controller (xHCI).
Thanks for your efforts here, but this DT binding looks like a mix of
software configuration and hardware description.
I disagree. I have already explained to Mark Rutland how selecting a
particular controller for a particular USB port should depend on the kind of
the USB connector used, i.e. the board hardware.
+Example (Lager board):
+
+ usb-phy@e6590100 {
+ compatible = "renesas,usb-phy-r8a7790";
+ reg = <0 0xe6590100 0 0x100>;
+ clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
+ clock-names = "usbhs";
+ renesas,channel2-pci;
+ };
As an example, instead of relying on "renesas,channel0-pci" or
"renesas,channel2-pci" to specify which hard coded software
configuration you want please rework this to expose 3 separate
channels and use DT to point each host controller to the right
channel.
So you want to expose the channels as "virtual devices"? Or what do you
want?
OK, let's assume you want either "virtual" PHYs or channel subnodes in the
PHY node we have now. Now what the PHY driver should do with all these
phandles pointing from the controller nodes to the PHY nodes or the channel
subnodes? Scan all device tree in search of the nodes having certain prop and
get info from such nodes on how to program the channel MUXing register using
their "compatible" props? Sorry, that doesn't appeal to me at all.
Now if we got the phandles pointing from the PHY node back to the selected
controllers, things would look somewhat better. Yet it still looks like an
unnecessary complication of what I'm proposing and so doesn't appeal to me
much either.
So, what's your intent here (other than to make my life harder :-)?
Also, it seems almost impossible to represent some USB controllers in DT
-- such as USBHS in particular.
I've spent several days staring at the various USBHS code and I'm going to
send you a more detailed report on USBHS vs DT issues.
[...]
So this is a NAK on my side. I expect better.
Thanks for your long awaited feedback.
I'm not convinced that what you're proposing is indeed better though.
Thanks,
/ magnus
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
