RE: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

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

 



Hi Geert-san,

> -----Original Message-----
> From: Geert Uytterhoeven
> Sent: Thursday, May 18, 2017 5:46 PM
> 
> On Thu, May 18, 2017 at 4:53 AM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
> >> From: Petre Pircalabu
> >> The USB30PHY of a RCAR-Gen3 XHCI device can select the reference clock
> >> source. The 2 available options are the differential input clock pair
> >> supplied on pins USB3S0_CLK_P / USB3S0_CLK_M (default) and the on-chip
> >> clock source supplied through USB_XTAL/USB_EXTAL.
> >>
> >> The device can be configured to use the on-chip source by adding the
> >> "renesas,use-on-chip-clk" option in the corresponding device tree node.
> >>
> >> Signed-off-by: Petre Pircalabu <Petre_Pircalabu@xxxxxxxxxx>
> 
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
> >> @@ -0,0 +1,22 @@
> >> +* Renesas R-Car generation 3 USB 3.0 PHY
> >> +
> >> +This file provides information on what the device node for the R-Car generation
> >> +3 USB 3.0 PHY contains.
> >> +
> >> +Required properties:
> >> +- compatible: "renesas,rcar-gen3-usb3-phy" for a generic R-Car Gen3 compatible device.
> >
> > I would like to add "renesas,usb3-phy-r8a7795" and "renesas,usb3-phy-r8a7796".
> 
> "renesas,r8a7795-usb3-phy" etc.?
> 
> (I know all other Renesas PHY drivers use the old scheme)

Oops! Yes, we should be "renesas,<soc>-<driver name>".
(However, "renesas,rcar-gen3-usb3-phy" is OK.)

> >> +- reg: offset and length of the partial USB 3.0 Host PHY register block.
> >> +- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
> >
> > I think we should add "clocks" property as required.
> >
> >> +Optional properties:
> >
> > You should add "renesas,use-on-chip-clk" here.
> > And, the name of "use-on-chip-clk" is not good to me.
> > FYI, my developing patch names "renesas,usb-extal".
> 
> Can this be decided at runtime, e.g. by looking at the rates of the clocks
> to see which one is available/best suited?

According to the HW manual, this module cannot see which one is available/best suited.
So, I don't think this can be decided at runtime.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux