Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role
Hi,
On Thu, Mar 29, 2018 at 01:57:24PM +0200, Paul Kocialkowski wrote:
> On Thu, 2018-03-29 at 11:23 +0200, Maxime Ripard wrote:
> > On Wed, Mar 28, 2018 at 11:52:13PM +0200, Paul Kocialkowski wrote:
> > > This allows dual-role ports to be reported as having gadget mode by
> > > the
> > > musb_has_gadget helper. This is required to enable MUSB at all with
> > > MUSB
> > > glue layers that set the port mode to MUSB_PORT_MODE_DUAL_ROLE at
> > > init.
> > >
> > > Most notably, this allows calling musb_start when needed in the
> > > virtual
> > > MUSB root HUB, regardless of whether the current mode should be
> > > gadget
> > > or host.
> > >
> > > This fixes USB OTG on Allwinner devices that I could test it with,
> > > mainly A20 devices.
> > >
> > > Signed-off-by: Paul Kocialkowski <cont...@paulk.fr>
> >
> > Surely there's more to it than that. The gadget mode of A20 boards
> > have been working in the past, including when compiling with mUSB
> > setup as dual role.
> >
> > Is this a regression since a particular commit? Or is there another,
> > deeper issue overlooked in the commit log?
>
> The root of the issue here is that musb_start is not called at any point
> without this patch. My understanding of the flow is the following: when
> the PHY detects that there was a VBUS/ID change, it will notify its
> listeners (mainly the musb sunxi glue layer). This will then schedule
> the driver's work (sunxi_musb_work), which does nothing since the
> SUNXI_MUSB_FL_ENABLED bit was never set. This bit is only set after
> calling sunxi_musb_enable, which is called from musb_platform_enable,
> that originates from musb_start.
>
> Currently I see two places where musb_start is called:
> * musb_virthub
> * musb_gadget
>
> In the latter case, it is in turn called from udc_start, which should
> probably (correct me if I'm wrong) happen later in the call chain than
> ID/VBUS change notification time.
>
> In the former case, musb_start is called in the root controller hub
> control, when setting the USB_PORT_FEAT_POWER feature. This looks
> perfectly legit and IMO this is where it should be initially calling
> musb_start in the dual role case. The kernel is indeed setting the
> feature, only that it fails to enable musb without this patch.
>
> First, I'd like to make sure that this understanding of the flow is
> correct as I may have missed something here. Does it make sense?
>
> Then, it seems that the offending commit is: be9d39881fc4f
> ("usb: musb: host: rely on port_mode to call musb_start()")
>
> That itself fixed: ae44df2e21b5
> ("usb: musb: call musb_start() only once in OTG mode")
>
> Still, this commit was authored in June 2015, so almost 3 years ago.
> In the meantime, the sunxi driver has received feature improvements, so
> it seems hard to believe that it was broken all this time...
I'm not that knowlegdeable about the musb driver, so I can't really
comment on whether what you're saying actually makes sense, but from
what you seem to say, the issue is just happening upon VBUS / ID
notification.
Have you tested without the role switching? For example, trying to
boot while acting as a gadget?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role
On Wed, Mar 28, 2018 at 11:52:13PM +0200, Paul Kocialkowski wrote: > This allows dual-role ports to be reported as having gadget mode by the > musb_has_gadget helper. This is required to enable MUSB at all with MUSB > glue layers that set the port mode to MUSB_PORT_MODE_DUAL_ROLE at init. > > Most notably, this allows calling musb_start when needed in the virtual > MUSB root HUB, regardless of whether the current mode should be gadget > or host. > > This fixes USB OTG on Allwinner devices that I could test it with, > mainly A20 devices. > > Signed-off-by: Paul Kocialkowski <cont...@paulk.fr> Surely there's more to it than that. The gadget mode of A20 boards have been working in the past, including when compiling with mUSB setup as dual role. Is this a regression since a particular commit? Or is there another, deeper issue overlooked in the commit log? Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode
Hi, On Thu, May 11, 2017 at 02:45:11PM -0700, Bim Overbohm wrote: > Hi All, > > I had a similar problem running a mainline 4.11 kernel on an A33 tablet > (marked "Q8-2.4G 20140918". It came from a company called Trimeo and is > simply called 7". It contains an APX223 power controller, RTL8189ETV WiFi > controller, 2x Nanya NT5CB128M15FP-DY DRAM chips (2x256MB), a Hynix > H27UCG8T2BTR-BC NAND-flash chip and a Goodix GT818 touch controller. > Display resolution is 1024x600). The self-compiled u-boot dtb would > initialize the USB, but the kernel dtb would not work. U-Boot doesn't use the DT for this USB setup. > The kernel messages were something along the lines of "[ 9.366994] > sun4i-usb-phy 1c19400.phy: could not find pctldev for node > /soc@01c0/pinctrl@01c20800/usb0_id_detect_pin@0, deferring > probe". That's not likely to be your issue. The probe should be deferred, and reattempted later. > I found no way to activate the pinctrl devices, so I fixed this by > decompiling the dts, removing all the USB id detect pin and vbus > settings and recompiling the dts (diff at end of message). The > device boots into LXDE now and I can use an USB keyboard and > mouse. I still have no WiFi though... > > Pastebin of unpatched dts file: https://pastebin.com/kL6WELuC > > A couple of questions: > > - Is there a proper way to make the pinctrls and OTG dual mode work > on the device?! I suspect they are needed to activate WiFi too... As I said, that's probably not your issue. Are you sure of your micro-USB cable? Is it setting the ID pin to the ground as it's supposed to? > - Is this a bug I should report for sunxi-next? sunxi-next is just a merge of various upstream branches. It doesn't make sense to report bugs there. You've found the right place already. > - Is there a driver for the GT818 in the mainline kernel or a way to > make that device work? It doesn't look like there is. > - Is there a driver for the RTL8189ETV in the mainline kernel or a way to > make that device work? https://linux-sunxi.org/Wifi#RTL8189ES_.2F_RTL8189ETV Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
On Wed, Jan 18, 2017 at 04:09:32AM +0800, Chen-Yu Tsai wrote: > Hi, > > On Wed, Jan 18, 2017 at 4:06 AM, Maxime Ripard > <maxime.rip...@free-electrons.com> wrote: > > On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote: > >> > >> > >> 17.01.2017, 16:06, "Maxime Ripard" <maxime.rip...@free-electrons.com>: > >> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote: > >> >> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI > >> >> controller. > >> >> > >> >> The original driver wired it to OHCI/EHCI controller; however, as the > >> >> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully > >> >> unusable. > >> >> > >> >> Rename the register (according to its function and the name in BSP > >> >> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB > >> >> can support both peripheral and host mode (although the host mode of > >> >> MUSB is buggy). > >> > > >> > Can you elaborate on that? What's wrong with it? > >> > >> The configuration is at bit 0 of register 0x20 in PHY. > >> > >> When the PHY is reseted, it defaults as MUSB mode. > >> > >> However, the original author of the H3 PHY code seems to be lack of > >> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI > >> mode. > >> > >> I just removed the code that wires it to HCI mode, thus it will work > >> in MUSB mode, with my sun8i-h3-musb patch. > > > > I have no idea what you mean by MUSB mode. > > > > Do you mean that the previous code was only working in host mode, and > > now it only works in peripheral? > > From what I understand, with the H3, Allwinner has put a mux > in front of the MUSB controller. The mux can send the USB data > to/from the MUSB controller, or a standard EHCI/OHCI pair. > This register controls said mux. > > This means we can use a proper USB host for host mode, > instead of the limited support in MUSB. But musb can still operate as a host, right? Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote: > > > 17.01.2017, 16:06, "Maxime Ripard" <maxime.rip...@free-electrons.com>: > > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote: > >> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI > >> controller. > >> > >> The original driver wired it to OHCI/EHCI controller; however, as the > >> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully > >> unusable. > >> > >> Rename the register (according to its function and the name in BSP > >> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB > >> can support both peripheral and host mode (although the host mode of > >> MUSB is buggy). > > > > Can you elaborate on that? What's wrong with it? > > The configuration is at bit 0 of register 0x20 in PHY. > > When the PHY is reseted, it defaults as MUSB mode. > > However, the original author of the H3 PHY code seems to be lack of > this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI > mode. > > I just removed the code that wires it to HCI mode, thus it will work > in MUSB mode, with my sun8i-h3-musb patch. I have no idea what you mean by MUSB mode. Do you mean that the previous code was only working in host mode, and now it only works in peripheral? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote: > The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI > controller. > > The original driver wired it to OHCI/EHCI controller; however, as the > code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully > unusable. > > Rename the register (according to its function and the name in BSP > driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB > can support both peripheral and host mode (although the host mode of > MUSB is buggy). Can you elaborate on that? What's wrong with it? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
Hi Bin,
On Thu, Jan 12, 2017 at 08:50:14AM -0600, Bin Liu wrote:
> On Wed, Jan 11, 2017 at 10:06:38PM +0100, Maxime Ripard wrote:
> > On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> > > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> > > >
> > > >
> > > > 11.01.2017, 04:24, "Bin Liu" <b-...@ti.com>:
> > > > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> > > > >> Lichee Pi Zero features a USB OTG port.
> > > > >>
> > > > >> Add support for it.
> > > > >>
> > > > >> Note: in order to use the Host mode, the board must be powered via
> > > > >> the
> > > > >> +5V and GND pins.
> > > > >>
> > > > >> Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
> > > > >> ---
> > > > >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++
> > > > >> 1 file changed, 10 insertions(+)
> > > > >>
> > > > >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > > > >> b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > > > >> index 0099affc6ce3..3d9168cbaeca 100644
> > > > >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > > > >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > > > >> @@ -71,3 +71,13 @@
> > > > >> pinctrl-names = "default";
> > > > >> status = "okay";
> > > > >> };
> > > > >> +
> > > > >> +_otg {
> > > > >> + dr_mode = "otg";
> > > > >
> > > > > Why not set this default mode in dtsi instead?
> > > > >
> > > > > Regards,
> > > > > -Bin.
> > > >
> > > > There's possibly boards which do not have OTG functions.
> > >
> > > That is board specific.
> >
> > Exactly, and this is why it should be done in the board DT.
>
> I am just suggesting based on the common practice. If a .dtsi exists for
> a family, the .dtsi describes the device and common properties for all
> possible boards, and each board .dts adds or overrides its specific
> implementation. Kernel has many devices/boards done in this way - define
> the default dr_mode in .dtsi.
>
> In this case, I suggest to set the common dr_mode in .dtsi, then each
> board .dts only overrides it if the implementation is different.
>
> >
> > The controller in the Allwinner SoCs do not handle directly the ID pin
> > and VBUS, but rather rely on a GPIO to do so.
> >
> > So boards with OTG will need setup anyway, at least to tell which
> > GPIOs are used. There's no point in enforcing a default if it doesn't
> > work by default.
>
> Then define a default which supposes to work for most boards.
>
> Why I suggest this, is because defining a default dr_mode which works
> for most cases in dtsi could prevent a little surprise in MUSB function.
> If someone designs a new board but forgets to define dr_mode in the new
> board DT, the MUSB driver will default to org mode, which might not be
> intended.
The point is that there is no sensible default. Some boards don't have
an ID pin and no VBUS (peripheral), some don't have an ID pin but VBUS
(host), and some have an ID pin but no controllable VBUS, some have an
ID pin and a controllable VBUS, but we have no idea which GPIOs are
used.
There's no way we can have something that works on most cases.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >
> >
> > 11.01.2017, 04:24, "Bin Liu" <b-...@ti.com>:
> > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> > >> Lichee Pi Zero features a USB OTG port.
> > >>
> > >> Add support for it.
> > >>
> > >> Note: in order to use the Host mode, the board must be powered via the
> > >> +5V and GND pins.
> > >>
> > >> Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
> > >> ---
> > >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++
> > >> 1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> index 0099affc6ce3..3d9168cbaeca 100644
> > >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> @@ -71,3 +71,13 @@
> > >> pinctrl-names = "default";
> > >> status = "okay";
> > >> };
> > >> +
> > >> +_otg {
> > >> + dr_mode = "otg";
> > >
> > > Why not set this default mode in dtsi instead?
> > >
> > > Regards,
> > > -Bin.
> >
> > There's possibly boards which do not have OTG functions.
>
> That is board specific.
Exactly, and this is why it should be done in the board DT.
The controller in the Allwinner SoCs do not handle directly the ID pin
and VBUS, but rather rely on a GPIO to do so.
So boards with OTG will need setup anyway, at least to tell which
GPIOs are used. There's no point in enforcing a default if it doesn't
work by default.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 1/4] phy: sun4i-usb: add support for V3s USB PHY
On Tue, Jan 03, 2017 at 11:25:31PM +0800, Icenowy Zheng wrote: > Allwinner V3s come with a USB PHY controller slightly different to other > SoCs, with only one PHY. > > Add support for it. > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz> Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 2/4] musb: sunxi: add support for the variant in H3/V3s SoC
On Tue, Jan 03, 2017 at 11:25:32PM +0800, Icenowy Zheng wrote: > Allwinner H3/V3s features a variant of MUSB controller, which lacks one > endpoint. > > Add support for it. > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz> Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 3/4] ARM: dts: sunxi: add usb_otg and usbphy node for V3s SoC
On Tue, Jan 03, 2017 at 11:25:33PM +0800, Icenowy Zheng wrote: > V3s SoC features a USB PHY controller and a MUSB OTG controller. > > Add device nodes for them. > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz> This can be merged in your other DTSI patch. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote: > This patch just uses the resource-managed extcon API when registering > the extcon notifier. > > Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com> Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v3 4/4] musb: sunxi: Simplify dr_mode handling
Hi, On Wed, Jun 08, 2016 at 12:30:20PM +0200, Hans de Goede wrote: > Hi, > > On 08-06-16 12:23, Maxime Ripard wrote: > >Hi, > > > >On Sun, Jun 05, 2016 at 04:59:36PM +0200, Hans de Goede wrote: > >>phy-sun4i-usb now has proper dr_mode handling, it always registers an > >>extcon, and sends a notify with the mode (even when in peripheral- / > >>host-only mode) at least once. > >> > >>So we can simply the sunxi musb glue by always registering its extcon > >>notifier and relying on sunxi_musb_work() to enable vbus when in > >>host-only mode. > >> > >>This also enables host- and peripheral-only mode with vbus monitoring. > >> > >>Signed-off-by: Hans de Goede <hdego...@redhat.com> > > > >It's been a bit painful to track all the patches needed so that it > >applies properly, but I've finally been able to test it on a Sinlinx > >SinA33 with peripheral-only mUSB, and it works like a charm. > > > >You can add my Tested-by. > > Great, thanks for testing. > > This is the board which has an otg connector with vbus not connected, > right? Yet it does have a functional id-pin, right ? It's that one, yes. > In that case you should be able to put it in dual-role mode (only > specify the id-pin in the phy dts node, no vbus / vbus-monitoring) > and then it _should_ work in host mode if you use a powered hub. > > I'm fine with putting in peripheral-only mode, but as said > dual-role might work with a powered hub. Good point, I'll test that. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v3 4/4] musb: sunxi: Simplify dr_mode handling
Hi, On Sun, Jun 05, 2016 at 04:59:36PM +0200, Hans de Goede wrote: > phy-sun4i-usb now has proper dr_mode handling, it always registers an > extcon, and sends a notify with the mode (even when in peripheral- / > host-only mode) at least once. > > So we can simply the sunxi musb glue by always registering its extcon > notifier and relying on sunxi_musb_work() to enable vbus when in > host-only mode. > > This also enables host- and peripheral-only mode with vbus monitoring. > > Signed-off-by: Hans de Goede <hdego...@redhat.com> It's been a bit painful to track all the patches needed so that it applies properly, but I've finally been able to test it on a Sinlinx SinA33 with peripheral-only mUSB, and it works like a charm. You can add my Tested-by. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 1/2] phy: Group vendor specific phy drivers
Hi,
On Fri, Apr 01, 2016 at 04:59:15PM +0530, Vivek Gautam wrote:
> create mode 100644 drivers/phy/sunxi/Kconfig
> create mode 100644 drivers/phy/sunxi/Makefile
> rename drivers/phy/{ => sunxi}/phy-sun4i-usb.c (100%)
> rename drivers/phy/{ => sunxi}/phy-sun9i-usb.c (100%)
That would be allwinner in this case, sunxi is the SoC family
Allwinner produces.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants
On Wed, Dec 16, 2015 at 12:21:48PM +0100, Philipp Zabel wrote:
> Hi Maxime,
>
> Am Mittwoch, den 16.12.2015, 11:29 +0100 schrieb Maxime Ripard:
> > On Mon, Dec 14, 2015 at 10:50:55AM +0100, Philipp Zabel wrote:
> > > Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard:
> > > > Hi,
> > > >
> > > > On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote:
> > > > > diff --git a/include/linux/reset.h b/include/linux/reset.h
> > > > > index c4c097d..1cca8ce 100644
> > > > > --- a/include/linux/reset.h
> > > > > +++ b/include/linux/reset.h
> > > > > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc);
> > > > > int reset_control_assert(struct reset_control *rstc);
> > > > > int reset_control_deassert(struct reset_control *rstc);
> > > > > int reset_control_status(struct reset_control *rstc);
> > > > > +int reset_control_assert_shared(struct reset_control *rstc);
> > > > > +int reset_control_deassert_shared(struct reset_control *rstc);
> > > >
> > > > Shouldn't that be handled in reset_control_get directly?
>
> I think I see your point now. Maybe we should add a flags parameter to
> reset_control_get and/or wrap it in two versions,
> reset_control_get_exclusive and reset_control_get_shared (or just add
> the _shared variant). Then reset_control_get(_exclusive) could return
> -EBUSY if a reset line is already in use.
I guess the current assumption was that reset_control_get was
exclusive.
So we could have something like:
reset_control_get (..) {
return __reset_control_get(.., 0);
}
reset_control_get_shared (..) {
return __reset_control_get(.., RESET_SHARED);
}
And all the logic shared between the two, without exposing any flag
(that would change the prototype and require to fix every callers).
>
> > > This is about different expectations of the caller.
> > > A driver calling reset_control_assert expects the reset line to be
> > > asserted after the call.
> >
> > Is that behaviour documented explicitly somewhere?
>
> /**
>
> * reset_control_assert - asserts the reset line
> * @rstc: reset controller
> */
Yeah, but it's not said when it would happen, or if it happens
synchronously.
> Also, that expected behavior matches the function name, which I like.
> So I still welcome adding new API calls for the shared/refcounting
> variant.
>
> > > A driver calling reset_control_assert_shared
> > > just signals that it doesn't care about the state of the reset line
> > > anymore.
> > > We could just as well call the two new functions
> > > reset_control_deassert_get and reset_control_deassert_put.
> >
> > What happens if you mix them? What happens if you have several drivers
> > ignoring this API?
>
> The core should give useful error messages and disallow non-shared reset
> calls on shared lines.
I guess we could also have something like this:
* The driver gets the reference to the reset line using
reset_control_get or its shared variant.
- If you call reset_control_get on a free line, it succeeds, and
marks the line in exclusive use.
- If you call reset_control_get on a busy line, it fails with
EBUSY
- If you call the shared variant on a free line, it succeeds
- If you call the shared variant on a busy exclusive line, it
fails with EBUSY
- If you call the shared variant on a busy !exclusive line, it
succeeds.
* The customer driver can then call reset_control_assert / deassert:
- If the reset line is in exclusive use, the assertion happens
right away, it succeeds and returns 0.
- If the reset line is in a !exclusive use, but with a single
user, the assertion happens right away, it succeeds and returns
0.
- If the reset line is in a !exclusive use with more than 1 user,
the refcount is modified and an error is returned to notify that
it didn't happen.
What do you think? That would work fine in both the case where you
care about the fact that the device has really been asserted (to
recover from an error for example) and the one when you don't really
care and you just want to give away your reset line (in a remove for
example).
I'd really like to avoid having shared variants of assert and
de-assert, since it will only spread out and end up being used in
drivers where most users don't have a shared reset line.
And if we want to avoid that, we'll end up in something like
if (struct->shared_reset)
reset_control_assert_shared
else
reset_control_assert
around *all* the calls in your driver.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants
On Mon, Dec 14, 2015 at 10:50:55AM +0100, Philipp Zabel wrote: > Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard: > > Hi, > > > > On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote: > > > diff --git a/include/linux/reset.h b/include/linux/reset.h > > > index c4c097d..1cca8ce 100644 > > > --- a/include/linux/reset.h > > > +++ b/include/linux/reset.h > > > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc); > > > int reset_control_assert(struct reset_control *rstc); > > > int reset_control_deassert(struct reset_control *rstc); > > > int reset_control_status(struct reset_control *rstc); > > > +int reset_control_assert_shared(struct reset_control *rstc); > > > +int reset_control_deassert_shared(struct reset_control *rstc); > > > > Shouldn't that be handled in reset_control_get directly? > > This is about different expectations of the caller. > A driver calling reset_control_assert expects the reset line to be > asserted after the call. Is that behaviour documented explicitly somewhere? > A driver calling reset_control_assert_shared > just signals that it doesn't care about the state of the reset line > anymore. > We could just as well call the two new functions > reset_control_deassert_get and reset_control_deassert_put. What happens if you mix them? What happens if you have several drivers ignoring this API? The current default API totally allows to have several drivers getting the same reset line, and happily poking that reset line without any way for the others to A) know they're not the single users B) let them know their device has been reset. And not being able to tell at the consumer level if and when our device is going to be reset behind our back is a big issue. Because then, we simply have to expect it can be reset at any point in time, good luck writing a driver with that expectation. The reset framework should make sure that the shared case is an exception, and not the default case (and make sure that it cannot happen in the default case). Just like for any other framework with similar resources constraints. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants
Hi, On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote: > diff --git a/include/linux/reset.h b/include/linux/reset.h > index c4c097d..1cca8ce 100644 > --- a/include/linux/reset.h > +++ b/include/linux/reset.h > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc); > int reset_control_assert(struct reset_control *rstc); > int reset_control_deassert(struct reset_control *rstc); > int reset_control_status(struct reset_control *rstc); > +int reset_control_assert_shared(struct reset_control *rstc); > +int reset_control_deassert_shared(struct reset_control *rstc); Shouldn't that be handled in reset_control_get directly? That would allow to share more code between the implementations, since it would just be a flag to test in the get and not duplicate the function definitions, and we could simply rely on the refcount to know if we have to actually assert / deassert the device, in all the cases (shared or not). That would also allow us to catch easily if we're going to be able a shared reset line or not, with the regular reset_control_get being exclusive, and reset_control_get_shared or reset_control_get(.., RESET_SHARED) being shared. It would also avoid ending up with the shared variant used in every generic driver eventually. We could just use the variant to see if we have to use the shared get or not, and the rest of the driver is left untouched, which is way less intrusive. Moreover, it's also pretty much the pattern used everywhere else (irqs, regulator, clocks, etc.), so it's going to be easier to review as well. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH v3 1/2] phy-sun4i-usb: Use of_match_node to get model specific config data
On Thu, Nov 26, 2015 at 01:11:32PM +0100, Hans de Goede wrote:
> >>+enum sun4i_usb_phy_type {
> >>+ sun4i_a10_phy,
> >>+ sun8i_a33_phy,
> >>+};
> >>+
> >>+struct sun4i_usb_phy_cfg {
> >>+ int num_phys;
> >>+ u32 disc_thresh;
> >>+ enum sun4i_usb_phy_type type;
> >>+ bool dedicated_clocks;
> >>+};
> >>+
> >> struct sun4i_usb_phy_data {
> >> void __iomem *base;
> >>+ const struct sun4i_usb_phy_cfg *cfg;
> >> struct mutex mutex;
> >>- int num_phys;
> >>- u32 disc_thresh;
> >>- bool has_a33_phyctl;
> >> struct sun4i_usb_phy {
> >> struct phy *phy;
> >> void __iomem *pmu;
> >>@@ -164,12 +174,15 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy
> >>*phy, u32 addr, u32 data,
> >>
> >> mutex_lock(_data->mutex);
> >>
> >>- if (phy_data->has_a33_phyctl) {
> >>+ switch (phy_data->cfg->type) {
> >>+ case sun4i_a10_phy:
> >>+ phyctl = phy_data->base + REG_PHYCTL_A10;
> >
> >Any reason why this offset isn't incorporated into phy_data?
>
> You mean in phy_data->cfg I assume, the difference needed for
> the "sun4i_usb_phy_write" functionality are not just the phyctl
> register offset...
>
> >
> >>+ break;
> >>+ case sun8i_a33_phy:
> >> phyctl = phy_data->base + REG_PHYCTL_A33;
> >> /* A33 needs us to set phyctl to 0 explicitly */
> >> writel(0, phyctl);
>
> e.g. the A33 needs this extra write, and on the H3 we need to do
> similar bitbanging, but slightly different, see:
>
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/usb/host/sunxi_hci.c#L899
>
> Notice how it uses different addr and write register addresses
> their through the usb_phy_csr_add and usb_phy_csr_write helper
> functions as well as directly poking offset 0x20.
Then it easy to support: one u8 for each register that changes, one
bool to tell if you need to clear the phyctl register or not, And you
don't have to duplicate the switch everywhere, and basically just
reimplement of_device_is_compatible without an actual compatible to
workaround the review ;)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: sun8i-h3-orangepi-plus: Enable USB host controllers
Hi, On Fri, Nov 20, 2015 at 03:38:47PM +0100, Hans de Goede wrote: > Hi, > > On 17-11-15 17:12, Jens Kuske wrote: > >Enable the 2 USB host controllers used on the Orange Pi Plus > >and add the necessary regulators. > > > >Signed-off-by: Reinder de Haan <patches...@mveas.com> > >Signed-off-by: Hans de Goede <hdego...@redhat.com> > >Signed-off-by: Jens Kuske <jensku...@gmail.com> > >--- > > > >Hi Hans, > > > >with these regulators USB works on the Orange Pi Plus too. > >I don't know if adding the regulators in the dts is okay, since most > >regulators are defined in the sunxi-common-regulators.dtsi, but > >we use different pins. > > Thanks, I've added this to my sunxi-wip branch for now. > > Regards, > > Hans > > p.s. > > Any progress on getting the "core" H3 kernel support upstream ? > > Given Arnd's remarks about how we should not hard-code the > indices in the clk driver + the very KISS nature of the > change to 1 parent-clk per gate setup I still believe > that that one is best. > > Maxime ? Chen-Yu ? It would be really good to be able to > move forward with this, how do you want to proceed ? Yeah, sorry, Chen-Yu and I were busy because of $LIFE the past weeks, we're getting back to speed. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 1/5] clk: sunxi: Add support for the H3 usb phy clocks
On Mon, Nov 16, 2015 at 10:36:02AM +0800, Chen-Yu Tsai wrote: > On Mon, Nov 16, 2015 at 3:46 AM, Hans de Goede <hdego...@redhat.com> wrote: > > From: Reinder de Haan <patches...@mveas.com> > > > > The H3 has a usb-phy clk register which is similar to that of earlier > > SoCs, but with support for a larger number of phys. So we can simply add > > a new set of clk-data and a new compatible and be done with it. > > > > Signed-off-by: Reinder de Haan <patches...@mveas.com> > > Signed-off-by: Hans de Goede <hdego...@redhat.com> > > Acked-by: Chen-Yu Tsai <w...@csie.org> Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines
On Wed, Nov 18, 2015 at 11:38:17AM +0100, Hans de Goede wrote: > Hi, > > On 18-11-15 10:46, Philipp Zabel wrote: > >Hi Hans, > > > >Am Montag, den 16.11.2015, 18:13 +0100 schrieb Hans de Goede: > >>On 16-11-15 18:01, Philipp Zabel wrote: > >>>If there are two devices sharing the same reset line that is initially > >>>held asserted, do the two drivers somehow have to synchronize before > >>>releasing the reset together? > >> > >>Not to my knowledge, I suggest that we simply treat this same as > >>regulators / clocks where the first one to enable it actually gets > >>it enabled (de-asserted in case of a reset), and the last one > >>to disable (assert) it (so dropping the usage counter back to 0) leads > >>to it being asserted again. > >> > >>This seems to work well enough for clocks / regulators and phys, and > >>at least for my use-case it should work fine for the shared reset too > >>(I will test to make sure of course). > >> > >>So from my pov a simple counter should suffice, does that work for you ? > > > >I don't quite understand what counting will help with, then. The first > >driver to call reset_control_deassert will deassert the reset, whether > >you count or not. > >But if the two drivers have deasserted an initially asserted reset, a > >reset_control_assert for one of them will silently fail. > > Correct, which is what we want, although I would not call it silently > fail I would call it a nop as it is intended. > > >I fear the deassertion count maps well to the case where resets are used > >just like clocks (when inactive modules are kept in reset), but I'm not > >sure this is useful in the case of resets that are kept deasserted most > >of the time, only to be asserted for a short pulse. Maybe we have to > >differentiate between the two cases? > > Ack. I think that the "just like clocks" case is the more common one, and > it seems to me that the short-pulse case should use reset_control_reset. > > Maybe we need to provide a default implementation of reset_control_reset which > does the pulse when no implementation is provided by the driver ? > > Although that brings the question with it what to do with the deassert_count > in > that case, as some drivers may also use that for the initial deassert... I > guess > we could document to not do that if you want to assure that no other drivers > muck with the reset-line ... > > Hmm, this is getting messy pretty quickly. New proposal: > > 1) Add a concept of shared resets, adding: reset_control_get_shared and >devm_reset_control_get_shared functions, which set a shared bool >in struct reset_control Maybe we can simply be a bit more generic and add a version taking flags as an argument, the fact that the reset line is shared being one of these flags. I guess both these versions have the issue that eventually every driver might use the shared variant (since we'd need to use it if one board or SoC is using a shared reset line, pretty much the same situation than for the interrupts), which would reduce the effectiveness of reset_control_get would not be able to catch exclusive use of the reset line. > 2) Add int refcnt to struct reset_controller_dev, which gets >incremented/decremented on reset_control_get/reset_control_put >do a BUG_ON on refcnt == 1 in the get functions when the non-shared >variant gets called (this is optional but probably a good extra >check) > > 3) Do the whole deassert_count thingy only when the shared bool is true > > 4) Make reset_control_reset fail (BUG_ON) if the shared bool is true I don't think silently failing (at least from the driver point of view) is the right approach. You've used clocks as an example, but there's a quite significant difference between clocks and reset lines: you never really care if the clock is actually disabled or not while when you want to put the device in reset, you usually expect it to be actually reset when the function returns (to deal with unrecoverable hardware errors for example). And drivers can always ignore the return code if they don't care. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines
On Wed, Nov 18, 2015 at 10:46:52AM +0100, Philipp Zabel wrote: > Hi Hans, > > Am Montag, den 16.11.2015, 18:13 +0100 schrieb Hans de Goede: > > On 16-11-15 18:01, Philipp Zabel wrote: > > > If there are two devices sharing the same reset line that is initially > > > held asserted, do the two drivers somehow have to synchronize before > > > releasing the reset together? > > > > Not to my knowledge, I suggest that we simply treat this same as > > regulators / clocks where the first one to enable it actually gets > > it enabled (de-asserted in case of a reset), and the last one > > to disable (assert) it (so dropping the usage counter back to 0) leads > > to it being asserted again. > > > > This seems to work well enough for clocks / regulators and phys, and > > at least for my use-case it should work fine for the shared reset too > > (I will test to make sure of course). > > > > So from my pov a simple counter should suffice, does that work for you ? > > I don't quite understand what counting will help with, then. The first > driver to call reset_control_deassert will deassert the reset, whether > you count or not. > But if the two drivers have deasserted an initially asserted reset, a > reset_control_assert for one of them will silently fail. Then maybe we can just make it return an error when someone calls _assert or _reset on a reset line that has more than one user? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v5 0/5] usb/gadget: independent registration of gadgets and gadget drivers
Hi Ruslan, On Mon, Nov 02, 2015 at 06:44:00PM +0200, Ruslan Bilovol wrote: > >> This patchset adds independent registration of gadgets > >> and gadget drivers to udc-core. This is very useful for > >> built-in modules into kernel case since it's possible > >> situation that gadget driver is probing at a time > >> when no gadgets are registered in udc-core. > >> In this case instead of silently failing without > >> of any attempt to recover, with independent registration > >> of gadgets and gadget drivers there is no matter > >> in which order gadgets and gadget drivers are > >> probed/registered. > >> > >> This patch has side-effect on gadget drivers that had > >> __init/__exit attributes on some paths like bind/unbind > >> and (since bind/unbind may happen at any time) should > >> not use them now. This is covered by forth patch > >> > > > > Has there been any progress on these patches? They're fixing some real > > issue that we're seeing, and it seems to both work quite well and not > > generate a lot of pushback. > > This patch series has stack on review due to different views > on checking input parameters of externally visible function. > > I see there is no any way to get these patches accepted other > than skip checking validity of some input parameters as > was pointed by Alan, although I disagree with it. > > I will post updated patch series later Great, thanks a lot! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v5 0/5] usb/gadget: independent registration of gadgets and gadget drivers
Hi, On Tue, Jun 23, 2015 at 01:01:09AM +0300, Ruslan Bilovol wrote: > This patchset adds independent registration of gadgets > and gadget drivers to udc-core. This is very useful for > built-in modules into kernel case since it's possible > situation that gadget driver is probing at a time > when no gadgets are registered in udc-core. > In this case instead of silently failing without > of any attempt to recover, with independent registration > of gadgets and gadget drivers there is no matter > in which order gadgets and gadget drivers are > probed/registered. > > This patch has side-effect on gadget drivers that had > __init/__exit attributes on some paths like bind/unbind > and (since bind/unbind may happen at any time) should > not use them now. This is covered by forth patch > Has there been any progress on these patches? They're fixing some real issue that we're seeing, and it seems to both work quite well and not generate a lot of pushback. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode
On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote: > Hi, > > On 10-09-15 20:30, Maxime Ripard wrote: > >On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote: > >>Hi, > >> > >>On 04-09-15 08:43, Olliver Schinagl wrote: > >>>Hey Hans, > >>> > >>>On 07-08-15 10:45, Olliver Schinagl wrote: > >>>> > >>>>>If you change the dr_mode to host then you _must_ also remove any id_det > >>>>>and vbus_det > >>>>>gpio settings from the usb_phy node in the dts, as the sun4i phy code > >>>>>detects > >>>>>host vs otg mode by checking for the presence of these. > >>>>Yes, this fixes it and makes it work. Thanks. > >>>> > >>>I've been going back to this and am wondering if this is something I can > >>>look into to fix properly? E.g. if the dts sets dr_mode = host, can we > >>>simply ignore the pins and treat them as unset? > >> > >>AFAIK you cannot unset something in dts. The only solution I > >>can comeup with is to add a dr_mode argument to the phy like > >>we already have for the otg controller itself. > >> > >>This is something which we likely need to do anyways to add > >>support for peripheral only mode, which we seem to need for > >>some "hdmi sticks". > > > >I haven't really followed the rest of the discussion, so sorry if you > >already talked about that, but why can't you just set the dr_mode to > >peripheral in such a case? > > This is about the usbphy code not the musb-controller code, which are > 2 different dts nodes, atm only the musb-controller node has a > dr_mode property, and the phy code decides between host-only > and otg mode based on whether an id pin is assigned or not. > > My proposal is to get rid of the id-pin hack to determine the mode > and add a dr_mode property to the usbphy dts node. I agree that we should get rid of that hack, especially since a lack of an ID pin might also be used on a peripheral-only device. However, we already have that information in the musb node, and duplicating the info seems error prone. We already have a custom function, maybe that's a case for another one, and that would allow to handle "hard" cases more easily (like CONFIG_USB_MUSB_HOST selected, with the otg node set to otg). Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode
On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote: > Hi, > > On 04-09-15 08:43, Olliver Schinagl wrote: > >Hey Hans, > > > >On 07-08-15 10:45, Olliver Schinagl wrote: > >> > >>>If you change the dr_mode to host then you _must_ also remove any id_det > >>>and vbus_det > >>>gpio settings from the usb_phy node in the dts, as the sun4i phy code > >>>detects > >>>host vs otg mode by checking for the presence of these. > >>Yes, this fixes it and makes it work. Thanks. > >> > >I've been going back to this and am wondering if this is something I can > >look into to fix properly? E.g. if the dts sets dr_mode = host, can we > >simply ignore the pins and treat them as unset? > > AFAIK you cannot unset something in dts. The only solution I > can comeup with is to add a dr_mode argument to the phy like > we already have for the otg controller itself. > > This is something which we likely need to do anyways to add > support for peripheral only mode, which we seem to need for > some "hdmi sticks". I haven't really followed the rest of the discussion, so sorry if you already talked about that, but why can't you just set the dr_mode to peripheral in such a case? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v4 1/2] phy-sun4i-usb: Add full support for usb0 phy / OTG
Hi,
On Mon, Jun 01, 2015 at 11:28:23AM +0200, Hans de Goede wrote:
On 01-06-15 11:22, Maxime Ripard wrote:
On Sun, May 31, 2015 at 06:10:25PM +0200, Hans de Goede wrote:
+ /* We either want both gpio pins or neither (when in host mode) */
+ if (!data-id_det_gpio != !data-vbus_det_gpio) {
+ dev_err(dev, failed to get id or vbus detect pin\n);
+ return -ENODEV;
+ }
The fact that the driver expects both to be set if one is should be in
the binding documentation.
That would be behavior description, and I've always been told that the
binding should only document the hardware description, not the behavior.
Yes, that's true, but here it looks more like there's no point of
having one without the other.
Pretty much like interrupt-parent and interrupt. A single one doesn't
really make much sense without the other.
And I don't think saying that you would need some additional
properties when in device mode rather than in host mode is really
documenting a behaviour. It does change things at a hardware level
too.
Also this may change in the future as we add support for more boards,
e.g. the cubieboard seems to be unable to turn vbus off ever, so vbus-det
will always read as 1 / high, making it rather useless. This is something
which I still need to figure out how to deal with.
We can always figure it out in due time.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v4 1/2] phy-sun4i-usb: Add full support for usb0 phy / OTG
On Sun, May 31, 2015 at 06:10:25PM +0200, Hans de Goede wrote:
+ /* We either want both gpio pins or neither (when in host mode) */
+ if (!data-id_det_gpio != !data-vbus_det_gpio) {
+ dev_err(dev, failed to get id or vbus detect pin\n);
+ return -ENODEV;
+ }
The fact that the driver expects both to be set if one is should be in
the binding documentation.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 2/5] usb: xhci: plat: Create both HCDs before adding them
On Tue, Apr 21, 2015 at 01:46:36PM +0300, Roger Quadros wrote: On 21/04/15 11:08, Maxime Ripard wrote: On Tue, Apr 21, 2015 at 12:49:54PM +0300, Roger Quadros wrote: On 20/04/15 15:35, Mathias Nyman wrote: Hi On 02.04.2015 15:23, Roger Quadros wrote: As xhci_hcd is now allocated by usb_create_hcd(), we don't need to add the primary HCD before creating the shared HCD. Creating the shared HCD before adding the primary HCD is particularly useful for the OTG use case so that we know at the OTG core if the HCD is in single configuration or dual (primary + shared) configuration. This doesn't apply as commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 usb: xhci: plat: Add USB phy support changed xhci-plat.c since. I rebased it, and the changed version is sitting in the for-usb-next branch in: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git But it appeared to me that usb_add_hcd() and usb_remove_hcd() will also call phy init and remove functions. As the order how hcds are created and added would change I'd need some more eyes on this to see if it will cause regression. Or maybe in the best case we could get rid of the Add USB phy support patch as we will call xhci_add_hcd() for the first hcd much later, and it could maybe init the phy for us? I thought usb_phy_*() stuff would be deprecated and we should use phy framework instead i.e. phy_init() and friends. Except that all drivers have not been converted yet... So it's not really an option until then. In fact usb_add_hcd() is already handling the phy for us. If it handles USB phy, then I don't really have an issue with it. It handles usb_phy as well. It just expects hcd-usb_phy to be set. Ok, perfect then. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 2/5] usb: xhci: plat: Create both HCDs before adding them
On Tue, Apr 21, 2015 at 12:49:54PM +0300, Roger Quadros wrote: On 20/04/15 15:35, Mathias Nyman wrote: Hi On 02.04.2015 15:23, Roger Quadros wrote: As xhci_hcd is now allocated by usb_create_hcd(), we don't need to add the primary HCD before creating the shared HCD. Creating the shared HCD before adding the primary HCD is particularly useful for the OTG use case so that we know at the OTG core if the HCD is in single configuration or dual (primary + shared) configuration. This doesn't apply as commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 usb: xhci: plat: Add USB phy support changed xhci-plat.c since. I rebased it, and the changed version is sitting in the for-usb-next branch in: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git But it appeared to me that usb_add_hcd() and usb_remove_hcd() will also call phy init and remove functions. As the order how hcds are created and added would change I'd need some more eyes on this to see if it will cause regression. Or maybe in the best case we could get rid of the Add USB phy support patch as we will call xhci_add_hcd() for the first hcd much later, and it could maybe init the phy for us? I thought usb_phy_*() stuff would be deprecated and we should use phy framework instead i.e. phy_init() and friends. Except that all drivers have not been converted yet... So it's not really an option until then. In fact usb_add_hcd() is already handling the phy for us. If it handles USB phy, then I don't really have an issue with it. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: Hi, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 it seems to be broken. Still had no time to bisect this. I've been giving a few versions (from v3.15 to Tuesday's linux-next) a try, and I always see the same behaviour now: - Booting as a gadget (ie, with a USB cable plugged in), and swapping the cable for a (real, this time) USB OTG cable with a USB key never works. When the device is plugged, all I get is [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 278.064748] usb 1-1: device descriptor read/64, error -110 Putting in back in gadget results with a load of continuous: [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active - Booting as a host, or with nothing connected to it actually work, up to a few plug-a-device-then-plug-a-host cycles, where you end up with the following logs when disconnecting the device (somehow, it always happens when it is set in host mode). [ 12.969075] CAUTION: musb: Babble Interrupt Occurred [ 12.974445] CAUTION: musb: Babble Interrupt Occurred [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) [ 12.988498] usb 1-1: USB disconnect, device number 2 [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble Plugging back our USB cable, with the AM335x acting as a device work once. Then, when it switches to the host mode, we end up with the same scenario than in the coldplug as gadget case: USB read error, before then having all the a_wait_vfall messages. I gave it some more testing these two days, with next-20150410, with pretty much the same results. Dumping the DSPS glue registers doesn't get anywhere, in both cases (booting as peripheral and then switching to host, or booting as host) they are identical. However, the musb registers vary greatly. In the first case, we boot as host, switch to peripheral, and then switch back to host, repeatedly until it fails: http://code.bulix.org/p0d964-88211?raw We can see that while it still works, value comes back to their original state when switching back to host, which makes sense. However, when it fails, some registers are not set back to their initial values, including TxMaxPp, TxCSRp, RxMaxPp, ConfigData, DevCtl, TxFIFOadd and RxFIFOadd. Some registers that were not changing while it was working also now have a different value: TxMaxPp, RxMaxPp, MISC, TxFIFOsz and RxFIFOsz. Starting with the device as peripheral, and then switching to host fails instantly, once again with exotic values for the registers compared to the configuration set whenever the host mode is working: http://code.bulix.org/uo8fmu-88210?raw However, the registers values are quite similar to the one we got previously when the host mode was failing after a while, which might indicate that we end up in the same case somehow. Since I've not been able to find the musb datasheet, I'm unfortunately unable to make any deduction from these besides that something looks fishy. I've also did some runs with the musb glue and core compiled with debug options: Booted as host: http://code.bulix.org/97jz3i-88207?raw Booted as peripheral: http://code.bulix.org/vqdqt6-88208?raw I hope it helps... Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 00/13] musb: Add support for the Allwinner sunxi musb controller
Hi Hans, On Fri, Mar 20, 2015 at 08:11:09PM +0100, Hans de Goede wrote: Hi All, Here is v2 of my patch-set to add support for the musb variant found on Allwinner sunxi SoCs. Changes since the original posting: -Removed the sunxi specific phy functions, instead the id / vbus gpio polling has been moved to the phy-sun4i-usb driver and their status is exported through extcon for the sunxi-musb glue -Stop using syscon, instead Maxime Ripard's sunxi SRAM controller driver is now used This should address all review remarks against v1 of this patch-set, so hopefully we can start merging this upstream. The musb: Add support for the Allwinner sunxi musb commit relies on Maxime's SRAM controller patches, so those need to get merged first, but the phy-sun4i-usb and musb preparation patches can be merged already (assuming there are no objections). And then once the SRAM controller patches are in next we can also merge the musb: Add support for the Allwinner sunxi musb commit and the dts changes. All the DT bits look fine to me. I'll wait for Felipe and Kishon comments before merging those. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 00/15] musb: Add support for the Allwinner sunxi musb controller
On Mon, Mar 09, 2015 at 09:40:13PM +0100, Hans de Goede wrote: Hi All, This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it. Before talking about merging this there are 2 things which I would like to point out: a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC. I know that Maxime is not 100% in favor of using syscon: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html But I disagree with his arguments for writing a special driver for the SRAM controller: And I disagree with your disagreement :) 1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here No. Syscon has been designed for being lazy. This is a huge abstraction non-sense. You have to put all the logic of dealing with some external register layout in clients drivers, including dealing with the different revisions/SoC that are different from that aspect, and duplicating that code across all client drivers. 2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this. Actually, I already wrote some prototype for this. I'll clean this up and send it tonight/tomorrow. 3) I actually believe that having a specific driver for this is a bad idea, because that means inventing a whole new cross driver API for this, and getting those right is, hard, a lot of work, and even then one is still likely to get it wrong. We can avoid all this by going with the proven syscon solution. Except that modifying an in-kernel API, especially when we have two users, is easy. Moving back from syscon is not. Maxime, can we please have your ack for moving forward with this using syscon? (see above for my arguments why) If you can address my objections above, sure. Thanks for your awesome work on this, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 12/15] ARM: dts: sun4i: Enable USB DRC on Chuwi V7 CW0825
Hi Hans,
On Mon, Mar 09, 2015 at 09:40:25PM +0100, Hans de Goede wrote:
Enable the otg/drc usb controller on the Chuwi V7 CW0825 tablet.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 31
+
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index 97fca89..034396c 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -111,6 +111,26 @@
status = okay;
};
+pio {
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = PH4;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ allwinner,pins = PH5;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_DOWN;
+ };
+};
+
+reg_usb0_vbus {
+ status = okay;
+};
+
reg_usb2_vbus {
status = okay;
};
@@ -121,7 +141,18 @@
status = okay;
};
+usb_otg {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin
+ usb0_vbus_detect_pin;
+ id_det-gpio = pio 7 4 GPIO_ACTIVE_HIGH; /* PH4 */
+ vbus_det-gpio = pio 7 5 GPIO_ACTIVE_HIGH; /* PH5 */
+ dr_mode = otg;
Is there a reason to not put that in the DTSI?
All the users seem to be wiring it as OTG.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 12/15] ARM: dts: sun4i: Enable USB DRC on Chuwi V7 CW0825
On Tue, Mar 10, 2015 at 04:23:09PM +0100, Hans de Goede wrote:
Hi,
On 03/10/2015 04:07 PM, Maxime Ripard wrote:
Hi Hans,
On Mon, Mar 09, 2015 at 09:40:25PM +0100, Hans de Goede wrote:
Enable the otg/drc usb controller on the Chuwi V7 CW0825 tablet.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 31
+
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index 97fca89..034396c 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -111,6 +111,26 @@
status = okay;
};
+pio {
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = PH4;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ allwinner,pins = PH5;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_DOWN;
+ };
+};
+
+reg_usb0_vbus {
+ status = okay;
+};
+
reg_usb2_vbus {
status = okay;
};
@@ -121,7 +141,18 @@
status = okay;
};
+usb_otg {
+ pinctrl-names = default;
+ pinctrl-0 = usb0_id_detect_pin
+usb0_vbus_detect_pin;
+ id_det-gpio = pio 7 4 GPIO_ACTIVE_HIGH; /* PH4 */
+ vbus_det-gpio = pio 7 5 GPIO_ACTIVE_HIGH; /* PH5 */
+ dr_mode = otg;
Is there a reason to not put that in the DTSI?
This is not in the dtsi because it is board specific.
All the users seem to be wiring it as OTG.
Sofar I've only enabled the otg on a handful of boards,
the otg on the Mele-M9 for example is connected to a usb-sata
bridge and as such should be brought up in host only mode.
And on the wobo-i5 (which I still need to create a dts file for)
the otg is connected to an usb wifi module.
Ok, that seems like a good reason :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port
Hi Matthias, On Tue, Mar 03, 2015 at 06:12:44PM +0200, Mathias Nyman wrote: On 03.03.2015 11:59, Maxime Ripard wrote: On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote: Hi Maxime, On 19/01/2015 14:01, Maxime Ripard wrote: The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this. it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2? IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window. It still didn't happen though. Maxime Hi I understood that you wanted the first fix patch in as soon as possible so I sent it forward to Greg, and it's now in his usb-linus branch. Ah, so you were talking only about the first patch. My bad. The other two patches, 2/3 and 3/3 you said were regual patches (for usb-next?), Indeed, at least for patch 2. Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together? Patch 3 doesn't need to be merged through the same tree, so I guess it's totally fine if 2 goes through USB and 3 through arm-soc. It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone with more USB PHY insight could ack it first. ACK. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port
On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote: Hi Maxime, On 19/01/2015 14:01, Maxime Ripard wrote: The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this. it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2? IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window. It still didn't happen though. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
On Tue, Feb 24, 2015 at 11:33:57AM -0600, Felipe Balbi wrote: Hi, On Tue, Feb 24, 2015 at 05:50:50PM +0100, Maxime Ripard wrote: Hi Felipe, On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote: Hi, On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: Hi, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 since 3.16 ? That's what Yegor said. I never saw it working with 3.15 either. it seems to be broken. Still had no time to bisect this. I've been giving a few versions (from v3.15 to Tuesday's linux-next) a try, and I always see the same behaviour now: - Booting as a gadget (ie, with a USB cable plugged in), and swapping the cable for a (real, this time) USB OTG cable with a USB key never works. When the device is plugged, all I get is [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 278.064748] usb 1-1: device descriptor read/64, error -110 Putting in back in gadget results with a load of continuous: [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active - Booting as a host, or with nothing connected to it actually work, up to a few plug-a-device-then-plug-a-host cycles, where you end up with the following logs when disconnecting the device (somehow, it always happens when it is set in host mode). [ 12.969075] CAUTION: musb: Babble Interrupt Occurred [ 12.974445] CAUTION: musb: Babble Interrupt Occurred [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) [ 12.988498] usb 1-1: USB disconnect, device number 2 [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble Plugging back our USB cable, with the AM335x acting as a device work once. Then, when it switches to the host mode, we end up with the same scenario than in the coldplug as gadget case: USB read error, before then having all the a_wait_vfall messages. Guys, any ideas/hints? which platform are you using ? I guess the only way to move here would be to bisect between 3.15 and 3.16 to find the offending commit. 3.15 didn't work either unfortunately. I had the behaviour described above on all kernel between 3.15 and a 4.0-rc1-ish. This is on an custom design based on the am335x. has it ever worked ? I don't have a board here which can do dual role. BBB has a mini-B only on the peripheral port. I don't know if it ever worked. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: Hi, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 it seems to be broken. Still had no time to bisect this. I've been giving a few versions (from v3.15 to Tuesday's linux-next) a try, and I always see the same behaviour now: - Booting as a gadget (ie, with a USB cable plugged in), and swapping the cable for a (real, this time) USB OTG cable with a USB key never works. When the device is plugged, all I get is [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 278.064748] usb 1-1: device descriptor read/64, error -110 Putting in back in gadget results with a load of continuous: [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active - Booting as a host, or with nothing connected to it actually work, up to a few plug-a-device-then-plug-a-host cycles, where you end up with the following logs when disconnecting the device (somehow, it always happens when it is set in host mode). [ 12.969075] CAUTION: musb: Babble Interrupt Occurred [ 12.974445] CAUTION: musb: Babble Interrupt Occurred [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) [ 12.988498] usb 1-1: USB disconnect, device number 2 [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble Plugging back our USB cable, with the AM335x acting as a device work once. Then, when it switches to the host mode, we end up with the same scenario than in the coldplug as gadget case: USB read error, before then having all the a_wait_vfall messages. Guys, any ideas/hints? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi Felipe, On Tue, Feb 24, 2015 at 08:54:01AM -0600, Felipe Balbi wrote: Hi, On Tue, Feb 24, 2015 at 11:39:11AM +0100, Maxime Ripard wrote: On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: Hi, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 it seems to be broken. Still had no time to bisect this. I've been giving a few versions (from v3.15 to Tuesday's linux-next) a try, and I always see the same behaviour now: - Booting as a gadget (ie, with a USB cable plugged in), and swapping the cable for a (real, this time) USB OTG cable with a USB key never works. When the device is plugged, all I get is [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 278.064748] usb 1-1: device descriptor read/64, error -110 Putting in back in gadget results with a load of continuous: [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active - Booting as a host, or with nothing connected to it actually work, up to a few plug-a-device-then-plug-a-host cycles, where you end up with the following logs when disconnecting the device (somehow, it always happens when it is set in host mode). [ 12.969075] CAUTION: musb: Babble Interrupt Occurred [ 12.974445] CAUTION: musb: Babble Interrupt Occurred [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) [ 12.988498] usb 1-1: USB disconnect, device number 2 [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble Plugging back our USB cable, with the AM335x acting as a device work once. Then, when it switches to the host mode, we end up with the same scenario than in the coldplug as gadget case: USB read error, before then having all the a_wait_vfall messages. Guys, any ideas/hints? which platform are you using ? I guess the only way to move here would be to bisect between 3.15 and 3.16 to find the offending commit. 3.15 didn't work either unfortunately. I had the behaviour described above on all kernel between 3.15 and a 4.0-rc1-ish. This is on an custom design based on the am335x. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
On Wed, Feb 04, 2015 at 05:04:18AM -0800, Greg Kroah-Hartman wrote: On Wed, Feb 04, 2015 at 10:35:22AM +0100, Maxime Ripard wrote: Hi Mathias, Greg, On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote: The commit 973747928514 (usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers) extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window. However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock. Things get messy when EPROBE_DEFER is involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever. Fix this by running the quirks after the clock has been enabled by the driver. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Cc: sta...@vger.kernel.org # v3.16+ Any chance for this to go in 3.19? For 3.19? It's too late, I'm not sending anything else to Linus as 3.19 will be out in a few days. Ok. I'll resend it when 3.20-rc1 is out then. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 it seems to be broken. Still had no time to bisect this. I've been giving a few versions (from v3.15 to Tuesday's linux-next) a try, and I always see the same behaviour now: - Booting as a gadget (ie, with a USB cable plugged in), and swapping the cable for a (real, this time) USB OTG cable with a USB key never works. When the device is plugged, all I get is [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 278.064748] usb 1-1: device descriptor read/64, error -110 Putting in back in gadget results with a load of continuous: [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active - Booting as a host, or with nothing connected to it actually work, up to a few plug-a-device-then-plug-a-host cycles, where you end up with the following logs when disconnecting the device (somehow, it always happens when it is set in host mode). [ 12.969075] CAUTION: musb: Babble Interrupt Occurred [ 12.974445] CAUTION: musb: Babble Interrupt Occurred [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) [ 12.988498] usb 1-1: USB disconnect, device number 2 [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble Plugging back our USB cable, with the AM335x acting as a device work once. Then, when it switches to the host mode, we end up with the same scenario than in the coldplug as gadget case: USB read error, before then having all the a_wait_vfall messages. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
Hi Mathias, Greg, On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote: The commit 973747928514 (usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers) extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window. However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock. Things get messy when EPROBE_DEFER is involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever. Fix this by running the quirks after the clock has been enabled by the driver. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Cc: sta...@vger.kernel.org # v3.16+ Any chance for this to go in 3.19? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi Markus, On Thu, Jan 22, 2015 at 12:01:13PM +0100, Markus Pargmann wrote: Hi, On Thu, Jan 22, 2015 at 11:43:30AM +0100, Maxime Ripard wrote: Hi Yegor, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: On 21.01.2015 19:53, Bin Liu wrote: Hi, On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Felipe, I'm currently working on a custom AM335x-based board, that has a OTG connector wired to one of the musb controlers, and Linux 3.17 This OTG connector seems to behave in a weird way when it comes to switching from one role to another: - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if the dr_mode is set to host in the DT, and only if we plug the USB device after the kernel has booted. Otherwise, even though the controller seems to be set up as host in the kernel logs, it doesn't work. When DR-mode is set to otg, DRVVBUS is not high which surely doesn't help, but there might be some other issues. - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode is set to otg and not host (obviously), and only if we plug the USB cable after the kernel has booted. - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with dr_mode set to otg, even if we cold plug the device. - As you might expect from the two first items, the runtime switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode is set in otg doesn't work either. It looks like it's only waiting for an interrupt to occur to read the ID pin state, without reading its initial value, which would explain why both the host and gadget enumerate only when a device/cable is hotplugged, and that there's some configuration bits that differ whenever dr_mode changes, but I couldn't really see anything standing out in the driver nor the datasheet. Have you already experienced something alike with that driver? I don't use vanilla mainline kernel very often, but I don't have such hotplug issues with TI 3.12/14 kernels [1]. I only use CONFIG_USB_MUSB_DUAL_ROLE though. [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch remote/origin/linux-3.14.y I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 it seems to be broken. Still had no time to bisect this. I just gave 3.15 a quick try, and it looks like it can now detect when the device is acting as a gadget, but the host mode is not working at all. That's a good lead though, I'll dig more into the older versions and see if some are working better than others. This issue may be related to the fact that the musb controller does not have an ID pin interrupt. Last year I sent a RFC for a soft detection in OTG mode. It has a poll loop which toggles the SESSION bit of the controller to detect devices as host and drops back to device otherwise. This is far away from a good solution. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204519.html I guess it was a combination of two issues: after giving your patch a try, I found out that (even without your patch), in OTG mode, the gadget device is properly attached even if plugged before the kernel boots. I don't really know how I missed that, but anyway... I also tested to force the ID pin to the ground when a USB device was plugged in, and it then enumerates properly, both when cold and hot plugging. It's a bit weird because the adapter I'm using is working fine on other boards, but maybe the AM335x controller is a bit more picky with the ID pin, or that the other SoC I was testing it on (Atmel's sama5d4) is quite relaxed about it. I'm guessing that when forced in the host mode, the driver ignores completely the ID pin, hence why it was working properly with that setup. Thanks a lot, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
Hi Yegor, On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: On 21.01.2015 19:53, Bin Liu wrote: Hi, On Wed, Jan 21, 2015 at 10:06 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Felipe, I'm currently working on a custom AM335x-based board, that has a OTG connector wired to one of the musb controlers, and Linux 3.17 This OTG connector seems to behave in a weird way when it comes to switching from one role to another: - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if the dr_mode is set to host in the DT, and only if we plug the USB device after the kernel has booted. Otherwise, even though the controller seems to be set up as host in the kernel logs, it doesn't work. When DR-mode is set to otg, DRVVBUS is not high which surely doesn't help, but there might be some other issues. - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode is set to otg and not host (obviously), and only if we plug the USB cable after the kernel has booted. - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with dr_mode set to otg, even if we cold plug the device. - As you might expect from the two first items, the runtime switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode is set in otg doesn't work either. It looks like it's only waiting for an interrupt to occur to read the ID pin state, without reading its initial value, which would explain why both the host and gadget enumerate only when a device/cable is hotplugged, and that there's some configuration bits that differ whenever dr_mode changes, but I couldn't really see anything standing out in the driver nor the datasheet. Have you already experienced something alike with that driver? I don't use vanilla mainline kernel very often, but I don't have such hotplug issues with TI 3.12/14 kernels [1]. I only use CONFIG_USB_MUSB_DUAL_ROLE though. [1] git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, branch remote/origin/linux-3.14.y I have the same experience with 3.15. The switching is working when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = otg. But since 3.16 it seems to be broken. Still had no time to bisect this. I just gave 3.15 a quick try, and it looks like it can now detect when the device is acting as a gadget, but the host mode is not working at all. That's a good lead though, I'll dig more into the older versions and see if some are working better than others. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
MUSB dual-role on AM335x behaving weirdly
Hi Felipe, I'm currently working on a custom AM335x-based board, that has a OTG connector wired to one of the musb controlers, and Linux 3.17 This OTG connector seems to behave in a weird way when it comes to switching from one role to another: - The host mode works with CONFIG_USB_MUSB_DUAL_ROLE set, only if the dr_mode is set to host in the DT, and only if we plug the USB device after the kernel has booted. Otherwise, even though the controller seems to be set up as host in the kernel logs, it doesn't work. When DR-mode is set to otg, DRVVBUS is not high which surely doesn't help, but there might be some other issues. - The gadget mode works with CONFIG_USB_MUSB_DUAL_ROLE, if dr_mode is set to otg and not host (obviously), and only if we plug the USB cable after the kernel has booted. - The gadget mode works with CONFIG_USB_MUSB_GADGET, and with dr_mode set to otg, even if we cold plug the device. - As you might expect from the two first items, the runtime switching from gadget to host when CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode is set in otg doesn't work either. It looks like it's only waiting for an interrupt to occur to read the ID pin state, without reading its initial value, which would explain why both the host and gadget enumerate only when a device/cable is hotplugged, and that there's some configuration bits that differ whenever dr_mode changes, but I couldn't really see anything standing out in the driver nor the datasheet. Have you already experienced something alike with that driver? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
On Tue, Jan 20, 2015 at 09:43:07PM +0100, Andrew Lunn wrote: On Tue, Jan 20, 2015 at 09:30:28PM +0100, Maxime Ripard wrote: Hi Andrew, On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote: On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy. Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval. Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+. The two patches remaining are regular patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board. Hi Maxime I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc. What route do you think the other patches will take? There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree. Hi Maxime Humm, maybe i'm wrong, but i think arch/arm/boot/dts/armada-385-db-ap.dts only exists in the mvebu tree? At least, i don't see it here: https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next Yeah, but my point was that if you merge the DT bits, without having the PHY driver quirks fix in your tree, you'll result in a kernel that doesn't boot at all on that board. But again, since this is a new board, I don't really see why you would want to bisect that. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
Hi Andrew, On Mon, Jan 19, 2015 at 10:35:07PM +0100, Andrew Lunn wrote: On Mon, Jan 19, 2015 at 02:01:11PM +0100, Maxime Ripard wrote: Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy. Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval. Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+. The two patches remaining are regular patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board. Hi Maxime I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc. What route do you think the other patches will take? There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
The commit 973747928514 (usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers) extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.
Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.
Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Cc: sta...@vger.kernel.org # v3.16+
---
drivers/usb/host/xhci-plat.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b15482..0e11d61408ff 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -83,16 +83,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq 0)
return -ENODEV;
-
- if (of_device_is_compatible(pdev-dev.of_node,
- marvell,armada-375-xhci) ||
- of_device_is_compatible(pdev-dev.of_node,
- marvell,armada-380-xhci)) {
- ret = xhci_mvebu_mbus_init_quirk(pdev);
- if (ret)
- return ret;
- }
-
/* Initialize dma_mask and coherent_dma_mask to 32-bits */
ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
if (ret)
@@ -127,6 +117,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ if (of_device_is_compatible(pdev-dev.of_node,
+ marvell,armada-375-xhci) ||
+ of_device_is_compatible(pdev-dev.of_node,
+ marvell,armada-380-xhci)) {
+ ret = xhci_mvebu_mbus_init_quirk(pdev);
+ if (ret)
+ goto disable_clk;
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] usb: xhci: plat: Add USB phy support
The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
drivers/usb/host/xhci-plat.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 0e11d61408ff..783e819139a7 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
@@ -155,12 +156,27 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci-hcc_params) = 4)
xhci-shared_hcd-can_do_streams = 1;
+ hcd-usb_phy = devm_usb_get_phy_by_phandle(pdev-dev, usb-phy, 0);
+ if (IS_ERR(hcd-usb_phy)) {
+ ret = PTR_ERR(hcd-usb_phy);
+ if (ret == -EPROBE_DEFER)
+ goto put_usb3_hcd;
+ hcd-usb_phy = NULL;
+ } else {
+ ret = usb_phy_init(hcd-usb_phy);
+ if (ret)
+ goto put_usb3_hcd;
+ }
+
ret = usb_add_hcd(xhci-shared_hcd, irq, IRQF_SHARED);
if (ret)
- goto put_usb3_hcd;
+ goto disable_usb_phy;
return 0;
+disable_usb_phy:
+ usb_phy_shutdown(hcd-usb_phy);
+
put_usb3_hcd:
usb_put_hcd(xhci-shared_hcd);
@@ -184,6 +200,7 @@ static int xhci_plat_remove(struct platform_device *dev)
struct clk *clk = xhci-clk;
usb_remove_hcd(xhci-shared_hcd);
+ usb_phy_shutdown(hcd-usb_phy);
usb_put_hcd(xhci-shared_hcd);
usb_remove_hcd(hcd);
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
VBUS line. Enable the needed drivers to support this.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
arch/arm/boot/dts/armada-385-db-ap.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts
b/arch/arm/boot/dts/armada-385-db-ap.dts
index 3a51531eb37b..b891b4c897f5 100644
--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -98,6 +98,13 @@
status = okay;
};
+ pinctrl@18000 {
+ xhci0_vbus_pins: xhci0-vbus-pins {
+ marvell,pins = mpp44;
+ marvell,function = gpio;
+ };
+ };
+
ethernet@3 {
status = okay;
phy = phy2;
@@ -122,6 +129,11 @@
phy = phy0;
phy-mode = rgmii-id;
};
+
+ usb3@f {
+ status = okay;
+ usb-phy = usb3_phy;
+ };
};
pcie-controller {
@@ -147,4 +159,20 @@
};
};
};
+
+ usb3_phy: usb3_phy {
+ compatible = usb-nop-xceiv;
+ vcc-supply = reg_xhci0_vbus;
+ };
+
+ reg_xhci0_vbus: xhci0-vbus {
+ compatible = regulator-fixed;
+ pinctrl-names = default;
+ pinctrl-0 = xhci0_vbus_pins;
+ regulator-name = xhci0-vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ enable-active-high;
+ gpio = gpio1 12 GPIO_ACTIVE_HIGH;
+ };
};
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: mvebu: armada-385-ap: Enable USB3 port
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
VBUS line. Enable the needed drivers to support this.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
arch/arm/boot/dts/armada-385-ap.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/armada-385-ap.dts
b/arch/arm/boot/dts/armada-385-ap.dts
index ab88dc4be636..a9dea82ef34b 100644
--- a/arch/arm/boot/dts/armada-385-ap.dts
+++ b/arch/arm/boot/dts/armada-385-ap.dts
@@ -88,6 +88,13 @@
status = okay;
};
+ pinctrl@18000 {
+ xhci0_vbus_pins: xhci0-vbus-pins {
+ marvell,pins = mpp44;
+ marvell,function = gpio;
+ };
+ };
+
ethernet@3 {
status = okay;
phy = phy1;
@@ -112,6 +119,11 @@
phy = phy0;
phy-mode = rgmii-id;
};
+
+ usb3@f {
+ status = okay;
+ usb-phy = usb3_phy;
+ };
};
pcie-controller {
@@ -137,4 +149,20 @@
};
};
};
+
+ usb3_phy: usb3_phy {
+ compatible = usb-nop-xceiv;
+ vcc-supply = reg_xhci0_vbus;
+ };
+
+ reg_xhci0_vbus: xhci0-vbus {
+ compatible = regulator-fixed;
+ pinctrl-names = default;
+ pinctrl-0 = xhci0_vbus_pins;
+ regulator-name = xhci0-vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ enable-active-high;
+ gpio = gpio1 12 GPIO_ACTIVE_HIGH;
+ };
};
--
2.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] usb: xhci: plat: Add USB phy support
The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
drivers/usb/host/xhci-plat.c | 13 +
drivers/usb/host/xhci.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 34c2f6d3e5d0..284ab70f13a3 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
@@ -155,6 +156,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci-hcc_params) = 4)
xhci-shared_hcd-can_do_streams = 1;
+ xhci-phy = devm_usb_get_phy_by_phandle(pdev-dev, usb-phy, 0);
+ if (IS_ERR(xhci-phy)) {
+ ret = PTR_ERR(xhci-phy);
+ if (ret == -EPROBE_DEFER)
+ goto put_usb3_hcd;
+ xhci-phy = NULL;
+ } else {
+ ret = usb_phy_init(xhci-phy);
+ if (ret)
+ goto put_usb3_hcd;
+ }
+
ret = usb_add_hcd(xhci-shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index cc7c5bb7cbcf..d9468af2a8e4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1474,6 +1474,8 @@ struct xhci_hcd {
struct msix_entry *msix_entries;
/* optional clock */
struct clk *clk;
+ /* optional phy */
+ struct usb_phy *phy;
/* data structures */
struct xhci_device_context_array *dcbaa;
struct xhci_ring*cmd_ring;
--
2.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
The commit 973747928514 (usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers) extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.
Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.
Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Cc: sta...@vger.kernel.org # v3.16+
---
drivers/usb/host/xhci-plat.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b15482..34c2f6d3e5d0 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -83,16 +83,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq 0)
return -ENODEV;
-
- if (of_device_is_compatible(pdev-dev.of_node,
- marvell,armada-375-xhci) ||
- of_device_is_compatible(pdev-dev.of_node,
- marvell,armada-380-xhci)) {
- ret = xhci_mvebu_mbus_init_quirk(pdev);
- if (ret)
- return ret;
- }
-
/* Initialize dma_mask and coherent_dma_mask to 32-bits */
ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
if (ret)
@@ -127,6 +117,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ if (of_device_is_compatible(pdev-dev.of_node,
+ marvell,armada-375-xhci) ||
+ of_device_is_compatible(pdev-dev.of_node,
+ marvell,armada-380-xhci)) {
+ ret = xhci_mvebu_mbus_init_quirk(pdev);
+ if (ret)
+ return ret;
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
--
2.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: phy: Fix deferred probing
Commit 1290a958d48e (usb: phy: propagate __of_usb_find_phy()'s error on
failure) actually broke the deferred probing mechanism, since it now returns
EPROBE_DEFER only when the try_module_get call fails, but not when the phy
lookup does.
All the other similar functions seem to return ENODEV when try_module_get
fails, and the error code of either __usb_find_phy or __of_usb_find_phy
otherwise.
In order to have a consistent behaviour, and a meaningful EPROBE_DEFER, always
return EPROBE_DEFER when __(of_)usb_find_phy fails to look up the requested
phy, that will be propagated by the caller, and ENODEV if try_module_get fails.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
drivers/usb/phy/phy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index b4066a001ba0..353c686498d4 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -34,7 +34,7 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return phy;
}
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(-EPROBE_DEFER);
}
static struct usb_phy *__usb_find_phy_dev(struct device *dev,
@@ -66,7 +66,7 @@ static struct usb_phy *__of_usb_find_phy(struct device_node
*node)
return phy;
}
- return ERR_PTR(-ENODEV);
+ return ERR_PTR(-EPROBE_DEFER);
}
static void devm_usb_phy_release(struct device *dev, void *res)
@@ -192,7 +192,7 @@ struct usb_phy *devm_usb_get_phy_by_phandle(struct device
*dev,
phy = __of_usb_find_phy(node);
if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
if (!IS_ERR(phy))
- phy = ERR_PTR(-EPROBE_DEFER);
+ phy = ERR_PTR(-ENODEV);
devres_free(ptr);
goto err1;
--
2.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: mvebu: Enable XHCI on the A385-AP
Hi all, This serie enables the Armada 385 AP XHCI controller. Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy. Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval. First, the commit 1290a958d48e (usb: phy: propagate __of_usb_find_phy()'s error on failure) introduced in 3.19 broke the deferred probing for consumer drivers. The first patch attempts at fixing this while keeping the original intention of the author, and should probably go in as a fix for 3.19. Then, since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19 as well, and any stable kernel for 3.16+. The two patches remaining are regular patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board. Thanks, Maxime Maxime Ripard (4): usb: phy: Fix deferred probing usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks usb: xhci: plat: Add USB phy support ARM: mvebu: armada-385-ap: Enable USB3 port arch/arm/boot/dts/armada-385-ap.dts | 28 drivers/usb/host/xhci-plat.c| 32 ++-- drivers/usb/host/xhci.h | 2 ++ drivers/usb/phy/phy.c | 6 +++--- 4 files changed, 55 insertions(+), 13 deletions(-) -- 2.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v4 0/8] Add Allwinner A31 USB support
On Tue, May 27, 2014 at 03:53:18PM -0700, Greg Kroah-Hartman wrote: On Thu, May 15, 2014 at 11:14:38AM +0200, Maxime Ripard wrote: Hi Greg, On Wed, May 14, 2014 at 06:05:20PM +0200, Greg Kroah-Hartman wrote: On Wed, May 14, 2014 at 02:34:19PM +0200, Maxime Ripard wrote: On Tue, May 13, 2014 at 05:44:14PM +0200, Maxime Ripard wrote: Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Resent adding Alan Stern's Acked-by and puting Greg KH in the recipients this time... Applied patches 2, 7 and 8. Feel free to apply patches 5 and 6 to your tree, as your branch needs these, with my: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Or, if you want me to take them, just let me know and I will. You can merge them, I don't need them in any of my branch. Now applied, thanks. Great, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND v4 0/8] Add Allwinner A31 USB support
On Sat, May 24, 2014 at 07:19:40AM +0900, Greg Kroah-Hartman wrote: On Fri, May 23, 2014 at 08:33:39PM +0200, Maxime Ripard wrote: Hi Greg, On Wed, May 14, 2014 at 06:05:20PM +0200, Greg Kroah-Hartman wrote: On Wed, May 14, 2014 at 02:34:19PM +0200, Maxime Ripard wrote: On Tue, May 13, 2014 at 05:44:14PM +0200, Maxime Ripard wrote: Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Resent adding Alan Stern's Acked-by and puting Greg KH in the recipients this time... Applied patches 2, 7 and 8. Feel free to apply patches 5 and 6 to your tree, as your branch needs these, with my: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Or, if you want me to take them, just let me know and I will. It looks like it's still not in your tree (or at least, I haven't received the usual mail notifications). Is this expected? Given that I haven't applied any USB patches in a week or so, yes, it is expected... Give me a week or so to catch up, I've been on the road for a month now, and am finally home. Ok, thanks, I was just trying to make sure they weren't lost/forgotten. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND v4 0/8] Add Allwinner A31 USB support
Hi Greg, On Wed, May 14, 2014 at 06:05:20PM +0200, Greg Kroah-Hartman wrote: On Wed, May 14, 2014 at 02:34:19PM +0200, Maxime Ripard wrote: On Tue, May 13, 2014 at 05:44:14PM +0200, Maxime Ripard wrote: Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Resent adding Alan Stern's Acked-by and puting Greg KH in the recipients this time... Applied patches 2, 7 and 8. Feel free to apply patches 5 and 6 to your tree, as your branch needs these, with my: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Or, if you want me to take them, just let me know and I will. It looks like it's still not in your tree (or at least, I haven't received the usual mail notifications). Is this expected? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND v4 0/8] Add Allwinner A31 USB support
Hi Greg, On Wed, May 14, 2014 at 06:05:20PM +0200, Greg Kroah-Hartman wrote: On Wed, May 14, 2014 at 02:34:19PM +0200, Maxime Ripard wrote: On Tue, May 13, 2014 at 05:44:14PM +0200, Maxime Ripard wrote: Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Resent adding Alan Stern's Acked-by and puting Greg KH in the recipients this time... Applied patches 2, 7 and 8. Feel free to apply patches 5 and 6 to your tree, as your branch needs these, with my: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Or, if you want me to take them, just let me know and I will. You can merge them, I don't need them in any of my branch. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND v4 3/8] phy: sunxi: Rework phy initialization
On Wed, May 14, 2014 at 11:18:51AM +0530, Kishon Vijay Abraham I wrote: Hi, On Tuesday 13 May 2014 09:14 PM, Maxime Ripard wrote: Move the phy initialization and variables declaration to the loop itself, since it is where it really belongs. Also remove all the temporary variables, we can use the structure members directly. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Reviewed-by: Hans de Goede hdego...@redhat.com let me know if I have to queue this and the next patch in my PHY tree. Yes, that would be great Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH RESEND v4 4/8] phy: usb: sunxi: Introduce Allwinner A31 USB PHY support
Hi,
On Wed, May 14, 2014 at 02:09:37PM +0530, Kishon Vijay Abraham I wrote:
@@ -305,6 +315,7 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = allwinner,sun4i-a10-usb-phy },
{ .compatible = allwinner,sun5i-a13-usb-phy },
+ { .compatible = allwinner,sun6i-a31-usb-phy },
Do you have Documentation for this comptible binding? Would be good to mention
that in the commit log.
Ah right. I forgot.
I'm sending you a followup patch.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH RESEND v4 0/8] Add Allwinner A31 USB support
On Tue, May 13, 2014 at 05:44:14PM +0200, Maxime Ripard wrote: Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Resent adding Alan Stern's Acked-by and puting Greg KH in the recipients this time... Applied patches 2, 7 and 8. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v3 5/8] usb: ehci-platform: add optional reset controller retrieval
On Mon, May 12, 2014 at 04:06:16PM -0400, Alan Stern wrote:
On Mon, 12 May 2014, Maxime Ripard wrote:
From: Boris BREZILLON boris.brezil...@free-electrons.com
On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
be deasserted for the EHCI block to be usable.
Add support for an optional reset controller that will be deasserted on
power off and asserted on power on.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
...
@@ -208,6 +210,18 @@ static int ehci_platform_probe(struct platform_device
*dev)
}
}
+ priv-rst = devm_reset_control_get_optional(dev-dev, NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
+ }
+
if (pdata-big_endian_desc)
ehci-big_endian_desc = 1;
if (pdata-big_endian_mmio)
You don't re-assert the reset control if an error happens later on
during probe. Was that intentional?
No, it wasn't. I'll resubmit another version.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH v4 8/8] ARM: sunxi: dt: add APP4-EVB1 board support
From: Boris BREZILLON boris.brezil...@free-electrons.com
The APP4 EVB1 development boards embeds an A31, together with some NAND, one SD
card slot, and one SDIO + UART WiFi and Bluetooth chip, a few I2C buses, USB,
and a LCD display.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 +++
2 files changed, 58 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8bc808cb7ce2..1d9c50dda655 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -344,6 +344,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
sun5i-a10s-r7-tv-dongle.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
+ sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
sun6i-a31-m9.dtb \
sun7i-a20-cubieboard2.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
new file mode 100644
index ..2bbf8867362b
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
@@ -0,0 +1,57 @@
+/*
+ * Copyright 2014 Boris Brezillon
+ *
+ * Boris Brezillon boris.brezil...@free-electrons.com
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ sun6i-a31.dtsi
+/include/ sunxi-common-regulators.dtsi
+
+/ {
+ model = Allwinner A31 APP4 EVB1 Evaluation Board;
+ compatible = allwinner,app4-evb1, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
+ };
+
+ soc@01c0 {
+ pio: pinctrl@01c20800 {
+ usb1_vbus_pin_a: usb1_vbus_pin@0 {
+ allwinner,pins = PH27;
+ allwinner,function = gpio_out;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+ };
+
+ usbphy: phy@01c19400 {
+ usb1_vbus-supply = reg_usb1_vbus;
+ status = okay;
+ };
+
+ ehci0: usb@01c1a000 {
+ status = okay;
+ };
+
+ uart0: serial@01c28000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins_a;
+ status = okay;
+ };
+ };
+
+ reg_usb1_vbus: usb1-vbus {
+ pinctrl-0 = usb1_vbus_pin_a;
+ gpio = pio 7 27 0;
+ status = okay;
+ };
+};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 7/8] ARM: sun6i: dt: Add support for the USB controllers
The A31 has two ECHI/OHCI controllers, and one OHCI-only phy-less controller.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 13aa56ed5858..5e9f01af6d99 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -341,6 +341,83 @@
status = disabled;
};
+ usbphy: phy@01c19400 {
+ compatible = allwinner,sun6i-a31-usb-phy;
+ reg = 0x01c19400 0x10,
+ 0x01c1a800 0x4,
+ 0x01c1b800 0x4;
+ reg-names = phy_ctrl,
+ pmu1,
+ pmu2;
+ clocks = usb_clk 8,
+usb_clk 9,
+usb_clk 10;
+ clock-names = usb0_phy,
+ usb1_phy,
+ usb2_phy;
+ resets = usb_clk 0,
+usb_clk 1,
+usb_clk 2;
+ reset-names = usb0_reset,
+ usb1_reset,
+ usb2_reset;
+ status = disabled;
+ #phy-cells = 1;
+ };
+
+ ehci0: usb@01c1a000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1a000 0x100;
+ interrupts = 0 72 4;
+ clocks = ahb1_gates 26;
+ resets = ahb1_rst 26;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci0: usb@01c1a400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1a400 0x100;
+ interrupts = 0 73 4;
+ clocks = ahb1_gates 29, usb_clk 16;
+ resets = ahb1_rst 29;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ehci1: usb@01c1b000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1b000 0x100;
+ interrupts = 0 74 4;
+ clocks = ahb1_gates 27;
+ resets = ahb1_rst 27;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci1: usb@01c1b400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1b400 0x100;
+ interrupts = 0 75 4;
+ clocks = ahb1_gates 30, usb_clk 17;
+ resets = ahb1_rst 30;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci2: usb@01c1c000 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1c400 0x100;
+ interrupts = 0 77 4;
+ clocks = ahb1_gates 31, usb_clk 18;
+ resets = ahb1_rst 31;
+ status = disabled;
+ };
+
pio: pinctrl@01c20800 {
compatible = allwinner,sun6i-a31-pinctrl;
reg = 0x01c20800 0x400;
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/8] Add Allwinner A31 USB support
Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Thanks, Maxime Changes from v3: - Asserted back the ECHI/OHCI in reset if probe fails - Drop of the redundant NULL assignent for the PMU in the PHY rework Changes from v2: - Fixed indentation and used the reset framework in all case and not just in DT case - Added a default value to the dedicated_clocks variable. Setting it actually started triggering a gcc warning for no reason. Ended up reworking a bit the code to avoid it. Changes from v1: - Moved the reset assertion/deassertion to probe/remove - Moved the dedicated_clocks to the probe function instead of the private structure since it was the only user Boris BREZILLON (2): usb: ehci-platform: add optional reset controller retrieval ARM: sunxi: dt: add APP4-EVB1 board support Maxime Ripard (6): clk: sunxi: Implement A31 USB clock ARM: sun6i: Add the USB clocks to the DTSI phy: sunxi: Rework phy initialization phy: usb: sunxi: Introduce Allwinner A31 USB PHY support usb: ohci-platform: Enable optional use of reset controller ARM: sun6i: dt: Add support for the USB controllers Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 + Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 ++ arch/arm/boot/dts/sun6i-a31.dtsi | 88 ++ drivers/clk/sunxi/clk-sunxi.c | 6 ++ drivers/phy/phy-sun4i-usb.c| 75 +- drivers/usb/host/ehci-platform.c | 26 ++- drivers/usb/host/ohci-platform.c | 27 ++- 9 files changed, 241 insertions(+), 41 deletions(-) create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 6/8] usb: ohci-platform: Enable optional use of reset controller
The OHCI controllers used in the Allwinner A31 are asserted in reset using a
global reset controller.
Add optional support for such a controller in the OHCI platform driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
drivers/usb/host/ohci-platform.c | 27 +++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 45f67d91e888..b968a1aea995 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -12,6 +12,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : usb
+- resets : phandle + reset specifier pair
Example:
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index b6002c951c5c..4369299064c7 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
#include linux/err.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/usb/ohci_pdriver.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -36,6 +37,7 @@
struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -191,6 +193,19 @@ static int ohci_platform_probe(struct platform_device *dev)
break;
}
}
+
+ }
+
+ priv-rst = devm_reset_control_get_optional(dev-dev, NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
}
if (pdata-big_endian_desc)
@@ -203,7 +218,7 @@ static int ohci_platform_probe(struct platform_device *dev)
dev_err(dev-dev,
Error: CONFIG_USB_OHCI_BIG_ENDIAN_MMIO not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
#ifndef CONFIG_USB_OHCI_BIG_ENDIAN_DESC
@@ -211,14 +226,14 @@ static int ohci_platform_probe(struct platform_device
*dev)
dev_err(dev-dev,
Error: CONFIG_USB_OHCI_BIG_ENDIAN_DESC not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
if (pdata-power_on) {
err = pdata-power_on(dev);
if (err 0)
- goto err_put_clks;
+ goto err_reset;
}
hcd-rsrc_start = res_mem-start;
@@ -242,6 +257,9 @@ static int ohci_platform_probe(struct platform_device *dev)
err_power:
if (pdata-power_off)
pdata-power_off(dev);
+err_reset:
+ if (priv-rst)
+ reset_control_assert(priv-rst);
err_put_clks:
while (--clk = 0)
clk_put(priv-clks[clk]);
@@ -266,6 +284,9 @@ static int ohci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (priv-rst)
+ reset_control_assert(priv-rst);
+
for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++)
clk_put(priv-clks[clk]);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/8] clk: sunxi: Implement A31 USB clock
The A31 USB clock slightly differ from its older counterparts, mostly because
it has a different gate for each PHY, while the older one had a single gate for
all the phy.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Acked-by: Mike Turquette mturque...@linaro.org
---
drivers/clk/sunxi/clk-sunxi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index bd7dc733c1ca..d9bab75f128b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -972,6 +972,11 @@ static const struct gates_data sun5i_a13_usb_gates_data
__initconst = {
.reset_mask = 0x03,
};
+static const struct gates_data sun6i_a31_usb_gates_data __initconst = {
+ .mask = { BIT(18) | BIT(17) | BIT(16) | BIT(10) | BIT(9) | BIT(8) },
+ .reset_mask = BIT(2) | BIT(1) | BIT(0),
+};
+
static void __init sunxi_gates_clk_setup(struct device_node *node,
struct gates_data *data)
{
@@ -1267,6 +1272,7 @@ static const struct of_device_id clk_gates_match[]
__initconst = {
{.compatible = allwinner,sun6i-a31-apb2-gates-clk, .data =
sun6i_a31_apb2_gates_data,},
{.compatible = allwinner,sun4i-a10-usb-clk, .data =
sun4i_a10_usb_gates_data,},
{.compatible = allwinner,sun5i-a13-usb-clk, .data =
sun5i_a13_usb_gates_data,},
+ {.compatible = allwinner,sun6i-a31-usb-clk, .data =
sun6i_a31_usb_gates_data,},
{}
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/8] usb: ehci-platform: add optional reset controller retrieval
From: Boris BREZILLON boris.brezil...@free-electrons.com
On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
be deasserted for the EHCI block to be usable.
Add support for an optional reset controller that will be deasserted on
power off and asserted on power on.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 +
drivers/usb/host/ehci-platform.c | 26 +++---
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index ff151ec084c4..43c1a4e06767 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -15,6 +15,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : usb
+ - resets : phandle + reset specifier pair
Example (Sequoia 440EPx):
ehci@e300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index c7dd93aad20c..2f5b9ce3e042 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/ehci_pdriver.h
@@ -41,6 +42,7 @@
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -208,6 +210,18 @@ static int ehci_platform_probe(struct platform_device *dev)
}
}
+ priv-rst = devm_reset_control_get_optional(dev-dev, NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
+ }
+
if (pdata-big_endian_desc)
ehci-big_endian_desc = 1;
if (pdata-big_endian_mmio)
@@ -218,7 +232,7 @@ static int ehci_platform_probe(struct platform_device *dev)
dev_err(dev-dev,
Error: CONFIG_USB_EHCI_BIG_ENDIAN_MMIO not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
#ifndef CONFIG_USB_EHCI_BIG_ENDIAN_DESC
@@ -226,14 +240,14 @@ static int ehci_platform_probe(struct platform_device
*dev)
dev_err(dev-dev,
Error: CONFIG_USB_EHCI_BIG_ENDIAN_DESC not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
if (pdata-power_on) {
err = pdata-power_on(dev);
if (err 0)
- goto err_put_clks;
+ goto err_reset;
}
hcd-rsrc_start = res_mem-start;
@@ -256,6 +270,9 @@ static int ehci_platform_probe(struct platform_device *dev)
err_power:
if (pdata-power_off)
pdata-power_off(dev);
+err_reset:
+ if (priv-rst)
+ reset_control_assert(priv-rst);
err_put_clks:
while (--clk = 0)
clk_put(priv-clks[clk]);
@@ -280,6 +297,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (priv-rst)
+ reset_control_assert(priv-rst);
+
for (clk = 0; clk EHCI_MAX_CLKS priv-clks[clk]; clk++)
clk_put(priv-clks[clk]);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/8] phy: sunxi: Rework phy initialization
Move the phy initialization and variables declaration to the loop itself, since
it is where it really belongs. Also remove all the temporary variables, we can
use the structure members directly.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 42 ++
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e6e6c4ba7145..66a87d50512b 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -224,13 +224,8 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
struct sun4i_usb_phy_data *data;
struct device *dev = pdev-dev;
struct device_node *np = dev-of_node;
- void __iomem *pmu = NULL;
struct phy_provider *phy_provider;
- struct reset_control *reset;
- struct regulator *vbus;
struct resource *res;
- struct phy *phy;
- char name[16];
int i;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
@@ -262,42 +257,41 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
/* Skip 0, 0 is the phy for otg which is not yet supported. */
for (i = 1; i data-num_phys; i++) {
+ struct sun4i_usb_phy *phy = data-phys + i;
+ char name[16];
+
snprintf(name, sizeof(name), usb%d_vbus, i);
- vbus = devm_regulator_get_optional(dev, name);
- if (IS_ERR(vbus)) {
- if (PTR_ERR(vbus) == -EPROBE_DEFER)
+ phy-vbus = devm_regulator_get_optional(dev, name);
+ if (IS_ERR(phy-vbus)) {
+ if (PTR_ERR(phy-vbus) == -EPROBE_DEFER)
return -EPROBE_DEFER;
- vbus = NULL;
+ phy-vbus = NULL;
}
snprintf(name, sizeof(name), usb%d_reset, i);
- reset = devm_reset_control_get(dev, name);
- if (IS_ERR(reset)) {
+ phy-reset = devm_reset_control_get(dev, name);
+ if (IS_ERR(phy-reset)) {
dev_err(dev, failed to get reset %s\n, name);
- return PTR_ERR(reset);
+ return PTR_ERR(phy-reset);
}
if (i) { /* No pmu for usbc0 */
snprintf(name, sizeof(name), pmu%d, i);
res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
- pmu = devm_ioremap_resource(dev, res);
- if (IS_ERR(pmu))
- return PTR_ERR(pmu);
+ phy-pmu = devm_ioremap_resource(dev, res);
+ if (IS_ERR(phy-pmu))
+ return PTR_ERR(phy-pmu);
}
- phy = devm_phy_create(dev, sun4i_usb_phy_ops, NULL);
- if (IS_ERR(phy)) {
+ phy-phy = devm_phy_create(dev, sun4i_usb_phy_ops, NULL);
+ if (IS_ERR(phy-phy)) {
dev_err(dev, failed to create PHY %d\n, i);
- return PTR_ERR(phy);
+ return PTR_ERR(phy-phy);
}
- data-phys[i].phy = phy;
- data-phys[i].pmu = pmu;
- data-phys[i].vbus = vbus;
- data-phys[i].reset = reset;
- data-phys[i].index = i;
- phy_set_drvdata(phy, data-phys[i]);
+ phy-index = i;
+ phy_set_drvdata(phy-phy, data-phys[i]);
}
dev_set_drvdata(dev, data);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/8] ARM: sun6i: Add the USB clocks to the DTSI
The USB clocks of the A31 seems to be parented to the 24MHz oscillator, and
handle the clocks for the USB phys and OHCI devices.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index eec1afa257a5..13aa56ed5858 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -269,6 +269,17 @@
clocks = osc24M, pll6;
clock-output-names = spi3;
};
+
+ usb_clk: clk@01c200cc {
+ #clock-cells = 1;
+ #reset-cells = 1;
+ compatible = allwinner,sun6i-a31-usb-clk;
+ reg = 0x01c200cc 0x4;
+ clocks = osc24M;
+ clock-output-names = usb_phy0, usb_phy1, usb_phy2,
+usb_ohci0, usb_ohci1,
+usb_ohci2;
+ };
};
soc@01c0 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/8] phy: usb: sunxi: Introduce Allwinner A31 USB PHY support
The USB phy controller in the A31 differs mostly from the older controllers
because it has a clock dedicated for each phy, while the older ones were having
a single clock for all the phys.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 66a87d50512b..115d8d5190d5 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -61,7 +61,6 @@
#define MAX_PHYS 3
struct sun4i_usb_phy_data {
- struct clk *clk;
void __iomem *base;
struct mutex mutex;
int num_phys;
@@ -71,6 +70,7 @@ struct sun4i_usb_phy_data {
void __iomem *pmu;
struct regulator *vbus;
struct reset_control *reset;
+ struct clk *clk;
int index;
} phys[MAX_PHYS];
};
@@ -146,13 +146,13 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
- ret = clk_prepare_enable(data-clk);
+ ret = clk_prepare_enable(phy-clk);
if (ret)
return ret;
ret = reset_control_deassert(phy-reset);
if (ret) {
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return ret;
}
@@ -170,11 +170,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
static int sun4i_usb_phy_exit(struct phy *_phy)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
- struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
sun4i_usb_phy_passby(phy, 0);
reset_control_assert(phy-reset);
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return 0;
}
@@ -225,6 +224,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
struct device_node *np = dev-of_node;
struct phy_provider *phy_provider;
+ bool dedicated_clocks;
struct resource *res;
int i;
@@ -244,17 +244,16 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
else
data-disc_thresh = 2;
+ if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy))
+ dedicated_clocks = true;
+ else
+ dedicated_clocks = false;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, phy_ctrl);
data-base = devm_ioremap_resource(dev, res);
if (IS_ERR(data-base))
return PTR_ERR(data-base);
- data-clk = devm_clk_get(dev, usb_phy);
- if (IS_ERR(data-clk)) {
- dev_err(dev, could not get usb_phy clock\n);
- return PTR_ERR(data-clk);
- }
-
/* Skip 0, 0 is the phy for otg which is not yet supported. */
for (i = 1; i data-num_phys; i++) {
struct sun4i_usb_phy *phy = data-phys + i;
@@ -268,6 +267,17 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
phy-vbus = NULL;
}
+ if (dedicated_clocks)
+ snprintf(name, sizeof(name), usb%d_phy, i);
+ else
+ strlcpy(name, usb_phy, sizeof(name));
+
+ phy-clk = devm_clk_get(dev, name);
+ if (IS_ERR(phy-clk)) {
+ dev_err(dev, failed to get clock %s\n, name);
+ return PTR_ERR(phy-clk);
+ }
+
snprintf(name, sizeof(name), usb%d_reset, i);
phy-reset = devm_reset_control_get(dev, name);
if (IS_ERR(phy-reset)) {
@@ -305,6 +315,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = allwinner,sun4i-a10-usb-phy },
{ .compatible = allwinner,sun5i-a13-usb-phy },
+ { .compatible = allwinner,sun6i-a31-usb-phy },
{ .compatible = allwinner,sun7i-a20-usb-phy },
{ },
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 1/8] clk: sunxi: Implement A31 USB clock
The A31 USB clock slightly differ from its older counterparts, mostly because
it has a different gate for each PHY, while the older one had a single gate for
all the phy.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Acked-by: Mike Turquette mturque...@linaro.org
---
drivers/clk/sunxi/clk-sunxi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index bd7dc733c1ca..d9bab75f128b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -972,6 +972,11 @@ static const struct gates_data sun5i_a13_usb_gates_data
__initconst = {
.reset_mask = 0x03,
};
+static const struct gates_data sun6i_a31_usb_gates_data __initconst = {
+ .mask = { BIT(18) | BIT(17) | BIT(16) | BIT(10) | BIT(9) | BIT(8) },
+ .reset_mask = BIT(2) | BIT(1) | BIT(0),
+};
+
static void __init sunxi_gates_clk_setup(struct device_node *node,
struct gates_data *data)
{
@@ -1267,6 +1272,7 @@ static const struct of_device_id clk_gates_match[]
__initconst = {
{.compatible = allwinner,sun6i-a31-apb2-gates-clk, .data =
sun6i_a31_apb2_gates_data,},
{.compatible = allwinner,sun4i-a10-usb-clk, .data =
sun4i_a10_usb_gates_data,},
{.compatible = allwinner,sun5i-a13-usb-clk, .data =
sun5i_a13_usb_gates_data,},
+ {.compatible = allwinner,sun6i-a31-usb-clk, .data =
sun6i_a31_usb_gates_data,},
{}
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 6/8] usb: ohci-platform: Enable optional use of reset controller
The OHCI controllers used in the Allwinner A31 are asserted in reset using a
global reset controller.
Add optional support for such a controller in the OHCI platform driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
drivers/usb/host/ohci-platform.c | 27 +++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 45f67d91e888..b968a1aea995 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -12,6 +12,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : usb
+- resets : phandle + reset specifier pair
Example:
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index b6002c951c5c..4369299064c7 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
#include linux/err.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/usb/ohci_pdriver.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -36,6 +37,7 @@
struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -191,6 +193,19 @@ static int ohci_platform_probe(struct platform_device *dev)
break;
}
}
+
+ }
+
+ priv-rst = devm_reset_control_get_optional(dev-dev, NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
}
if (pdata-big_endian_desc)
@@ -203,7 +218,7 @@ static int ohci_platform_probe(struct platform_device *dev)
dev_err(dev-dev,
Error: CONFIG_USB_OHCI_BIG_ENDIAN_MMIO not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
#ifndef CONFIG_USB_OHCI_BIG_ENDIAN_DESC
@@ -211,14 +226,14 @@ static int ohci_platform_probe(struct platform_device
*dev)
dev_err(dev-dev,
Error: CONFIG_USB_OHCI_BIG_ENDIAN_DESC not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
if (pdata-power_on) {
err = pdata-power_on(dev);
if (err 0)
- goto err_put_clks;
+ goto err_reset;
}
hcd-rsrc_start = res_mem-start;
@@ -242,6 +257,9 @@ static int ohci_platform_probe(struct platform_device *dev)
err_power:
if (pdata-power_off)
pdata-power_off(dev);
+err_reset:
+ if (priv-rst)
+ reset_control_assert(priv-rst);
err_put_clks:
while (--clk = 0)
clk_put(priv-clks[clk]);
@@ -266,6 +284,9 @@ static int ohci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (priv-rst)
+ reset_control_assert(priv-rst);
+
for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++)
clk_put(priv-clks[clk]);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 2/8] ARM: sun6i: Add the USB clocks to the DTSI
The USB clocks of the A31 seems to be parented to the 24MHz oscillator, and
handle the clocks for the USB phys and OHCI devices.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index eec1afa257a5..13aa56ed5858 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -269,6 +269,17 @@
clocks = osc24M, pll6;
clock-output-names = spi3;
};
+
+ usb_clk: clk@01c200cc {
+ #clock-cells = 1;
+ #reset-cells = 1;
+ compatible = allwinner,sun6i-a31-usb-clk;
+ reg = 0x01c200cc 0x4;
+ clocks = osc24M;
+ clock-output-names = usb_phy0, usb_phy1, usb_phy2,
+usb_ohci0, usb_ohci1,
+usb_ohci2;
+ };
};
soc@01c0 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 7/8] ARM: sun6i: dt: Add support for the USB controllers
The A31 has two ECHI/OHCI controllers, and one OHCI-only phy-less controller.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 13aa56ed5858..5e9f01af6d99 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -341,6 +341,83 @@
status = disabled;
};
+ usbphy: phy@01c19400 {
+ compatible = allwinner,sun6i-a31-usb-phy;
+ reg = 0x01c19400 0x10,
+ 0x01c1a800 0x4,
+ 0x01c1b800 0x4;
+ reg-names = phy_ctrl,
+ pmu1,
+ pmu2;
+ clocks = usb_clk 8,
+usb_clk 9,
+usb_clk 10;
+ clock-names = usb0_phy,
+ usb1_phy,
+ usb2_phy;
+ resets = usb_clk 0,
+usb_clk 1,
+usb_clk 2;
+ reset-names = usb0_reset,
+ usb1_reset,
+ usb2_reset;
+ status = disabled;
+ #phy-cells = 1;
+ };
+
+ ehci0: usb@01c1a000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1a000 0x100;
+ interrupts = 0 72 4;
+ clocks = ahb1_gates 26;
+ resets = ahb1_rst 26;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci0: usb@01c1a400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1a400 0x100;
+ interrupts = 0 73 4;
+ clocks = ahb1_gates 29, usb_clk 16;
+ resets = ahb1_rst 29;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ehci1: usb@01c1b000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1b000 0x100;
+ interrupts = 0 74 4;
+ clocks = ahb1_gates 27;
+ resets = ahb1_rst 27;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci1: usb@01c1b400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1b400 0x100;
+ interrupts = 0 75 4;
+ clocks = ahb1_gates 30, usb_clk 17;
+ resets = ahb1_rst 30;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci2: usb@01c1c000 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1c400 0x100;
+ interrupts = 0 77 4;
+ clocks = ahb1_gates 31, usb_clk 18;
+ resets = ahb1_rst 31;
+ status = disabled;
+ };
+
pio: pinctrl@01c20800 {
compatible = allwinner,sun6i-a31-pinctrl;
reg = 0x01c20800 0x400;
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 5/8] usb: ehci-platform: add optional reset controller retrieval
From: Boris BREZILLON boris.brezil...@free-electrons.com
On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
be deasserted for the EHCI block to be usable.
Add support for an optional reset controller that will be deasserted on
power off and asserted on power on.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 +
drivers/usb/host/ehci-platform.c | 26 +++---
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index ff151ec084c4..43c1a4e06767 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -15,6 +15,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : usb
+ - resets : phandle + reset specifier pair
Example (Sequoia 440EPx):
ehci@e300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index c7dd93aad20c..2f5b9ce3e042 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/ehci_pdriver.h
@@ -41,6 +42,7 @@
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -208,6 +210,18 @@ static int ehci_platform_probe(struct platform_device *dev)
}
}
+ priv-rst = devm_reset_control_get_optional(dev-dev, NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
+ }
+
if (pdata-big_endian_desc)
ehci-big_endian_desc = 1;
if (pdata-big_endian_mmio)
@@ -218,7 +232,7 @@ static int ehci_platform_probe(struct platform_device *dev)
dev_err(dev-dev,
Error: CONFIG_USB_EHCI_BIG_ENDIAN_MMIO not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
#ifndef CONFIG_USB_EHCI_BIG_ENDIAN_DESC
@@ -226,14 +240,14 @@ static int ehci_platform_probe(struct platform_device
*dev)
dev_err(dev-dev,
Error: CONFIG_USB_EHCI_BIG_ENDIAN_DESC not set\n);
err = -EINVAL;
- goto err_put_clks;
+ goto err_reset;
}
#endif
if (pdata-power_on) {
err = pdata-power_on(dev);
if (err 0)
- goto err_put_clks;
+ goto err_reset;
}
hcd-rsrc_start = res_mem-start;
@@ -256,6 +270,9 @@ static int ehci_platform_probe(struct platform_device *dev)
err_power:
if (pdata-power_off)
pdata-power_off(dev);
+err_reset:
+ if (priv-rst)
+ reset_control_assert(priv-rst);
err_put_clks:
while (--clk = 0)
clk_put(priv-clks[clk]);
@@ -280,6 +297,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (priv-rst)
+ reset_control_assert(priv-rst);
+
for (clk = 0; clk EHCI_MAX_CLKS priv-clks[clk]; clk++)
clk_put(priv-clks[clk]);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 0/8] Add Allwinner A31 USB support
Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Resent adding Alan Stern's Acked-by and puting Greg KH in the recipients this time... Thanks, Maxime Changes from v3: - Asserted back the ECHI/OHCI in reset if probe fails - Drop of the redundant NULL assignent for the PMU in the PHY rework Changes from v2: - Fixed indentation and used the reset framework in all case and not just in DT case - Added a default value to the dedicated_clocks variable. Setting it actually started triggering a gcc warning for no reason. Ended up reworking a bit the code to avoid it. Changes from v1: - Moved the reset assertion/deassertion to probe/remove - Moved the dedicated_clocks to the probe function instead of the private structure since it was the only user Boris BREZILLON (2): usb: ehci-platform: add optional reset controller retrieval ARM: sunxi: dt: add APP4-EVB1 board support Maxime Ripard (6): clk: sunxi: Implement A31 USB clock ARM: sun6i: Add the USB clocks to the DTSI phy: sunxi: Rework phy initialization phy: usb: sunxi: Introduce Allwinner A31 USB PHY support usb: ohci-platform: Enable optional use of reset controller ARM: sun6i: dt: Add support for the USB controllers Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 + Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 ++ arch/arm/boot/dts/sun6i-a31.dtsi | 88 ++ drivers/clk/sunxi/clk-sunxi.c | 6 ++ drivers/phy/phy-sun4i-usb.c| 75 +- drivers/usb/host/ehci-platform.c | 26 ++- drivers/usb/host/ohci-platform.c | 27 ++- 9 files changed, 241 insertions(+), 41 deletions(-) create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 8/8] ARM: sunxi: dt: add APP4-EVB1 board support
From: Boris BREZILLON boris.brezil...@free-electrons.com
The APP4 EVB1 development boards embeds an A31, together with some NAND, one SD
card slot, and one SDIO + UART WiFi and Bluetooth chip, a few I2C buses, USB,
and a LCD display.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 +++
2 files changed, 58 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8bc808cb7ce2..1d9c50dda655 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -344,6 +344,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
sun5i-a10s-r7-tv-dongle.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
+ sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
sun6i-a31-m9.dtb \
sun7i-a20-cubieboard2.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
new file mode 100644
index ..2bbf8867362b
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
@@ -0,0 +1,57 @@
+/*
+ * Copyright 2014 Boris Brezillon
+ *
+ * Boris Brezillon boris.brezil...@free-electrons.com
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ sun6i-a31.dtsi
+/include/ sunxi-common-regulators.dtsi
+
+/ {
+ model = Allwinner A31 APP4 EVB1 Evaluation Board;
+ compatible = allwinner,app4-evb1, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
+ };
+
+ soc@01c0 {
+ pio: pinctrl@01c20800 {
+ usb1_vbus_pin_a: usb1_vbus_pin@0 {
+ allwinner,pins = PH27;
+ allwinner,function = gpio_out;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+ };
+
+ usbphy: phy@01c19400 {
+ usb1_vbus-supply = reg_usb1_vbus;
+ status = okay;
+ };
+
+ ehci0: usb@01c1a000 {
+ status = okay;
+ };
+
+ uart0: serial@01c28000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins_a;
+ status = okay;
+ };
+ };
+
+ reg_usb1_vbus: usb1-vbus {
+ pinctrl-0 = usb1_vbus_pin_a;
+ gpio = pio 7 27 0;
+ status = okay;
+ };
+};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 4/8] phy: usb: sunxi: Introduce Allwinner A31 USB PHY support
The USB phy controller in the A31 differs mostly from the older controllers
because it has a clock dedicated for each phy, while the older ones were having
a single clock for all the phys.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 66a87d50512b..115d8d5190d5 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -61,7 +61,6 @@
#define MAX_PHYS 3
struct sun4i_usb_phy_data {
- struct clk *clk;
void __iomem *base;
struct mutex mutex;
int num_phys;
@@ -71,6 +70,7 @@ struct sun4i_usb_phy_data {
void __iomem *pmu;
struct regulator *vbus;
struct reset_control *reset;
+ struct clk *clk;
int index;
} phys[MAX_PHYS];
};
@@ -146,13 +146,13 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
- ret = clk_prepare_enable(data-clk);
+ ret = clk_prepare_enable(phy-clk);
if (ret)
return ret;
ret = reset_control_deassert(phy-reset);
if (ret) {
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return ret;
}
@@ -170,11 +170,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
static int sun4i_usb_phy_exit(struct phy *_phy)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
- struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
sun4i_usb_phy_passby(phy, 0);
reset_control_assert(phy-reset);
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return 0;
}
@@ -225,6 +224,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
struct device_node *np = dev-of_node;
struct phy_provider *phy_provider;
+ bool dedicated_clocks;
struct resource *res;
int i;
@@ -244,17 +244,16 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
else
data-disc_thresh = 2;
+ if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy))
+ dedicated_clocks = true;
+ else
+ dedicated_clocks = false;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, phy_ctrl);
data-base = devm_ioremap_resource(dev, res);
if (IS_ERR(data-base))
return PTR_ERR(data-base);
- data-clk = devm_clk_get(dev, usb_phy);
- if (IS_ERR(data-clk)) {
- dev_err(dev, could not get usb_phy clock\n);
- return PTR_ERR(data-clk);
- }
-
/* Skip 0, 0 is the phy for otg which is not yet supported. */
for (i = 1; i data-num_phys; i++) {
struct sun4i_usb_phy *phy = data-phys + i;
@@ -268,6 +267,17 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
phy-vbus = NULL;
}
+ if (dedicated_clocks)
+ snprintf(name, sizeof(name), usb%d_phy, i);
+ else
+ strlcpy(name, usb_phy, sizeof(name));
+
+ phy-clk = devm_clk_get(dev, name);
+ if (IS_ERR(phy-clk)) {
+ dev_err(dev, failed to get clock %s\n, name);
+ return PTR_ERR(phy-clk);
+ }
+
snprintf(name, sizeof(name), usb%d_reset, i);
phy-reset = devm_reset_control_get(dev, name);
if (IS_ERR(phy-reset)) {
@@ -305,6 +315,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = allwinner,sun4i-a10-usb-phy },
{ .compatible = allwinner,sun5i-a13-usb-phy },
+ { .compatible = allwinner,sun6i-a31-usb-phy },
{ .compatible = allwinner,sun7i-a20-usb-phy },
{ },
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v4 3/8] phy: sunxi: Rework phy initialization
Move the phy initialization and variables declaration to the loop itself, since
it is where it really belongs. Also remove all the temporary variables, we can
use the structure members directly.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 42 ++
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e6e6c4ba7145..66a87d50512b 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -224,13 +224,8 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
struct sun4i_usb_phy_data *data;
struct device *dev = pdev-dev;
struct device_node *np = dev-of_node;
- void __iomem *pmu = NULL;
struct phy_provider *phy_provider;
- struct reset_control *reset;
- struct regulator *vbus;
struct resource *res;
- struct phy *phy;
- char name[16];
int i;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
@@ -262,42 +257,41 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
/* Skip 0, 0 is the phy for otg which is not yet supported. */
for (i = 1; i data-num_phys; i++) {
+ struct sun4i_usb_phy *phy = data-phys + i;
+ char name[16];
+
snprintf(name, sizeof(name), usb%d_vbus, i);
- vbus = devm_regulator_get_optional(dev, name);
- if (IS_ERR(vbus)) {
- if (PTR_ERR(vbus) == -EPROBE_DEFER)
+ phy-vbus = devm_regulator_get_optional(dev, name);
+ if (IS_ERR(phy-vbus)) {
+ if (PTR_ERR(phy-vbus) == -EPROBE_DEFER)
return -EPROBE_DEFER;
- vbus = NULL;
+ phy-vbus = NULL;
}
snprintf(name, sizeof(name), usb%d_reset, i);
- reset = devm_reset_control_get(dev, name);
- if (IS_ERR(reset)) {
+ phy-reset = devm_reset_control_get(dev, name);
+ if (IS_ERR(phy-reset)) {
dev_err(dev, failed to get reset %s\n, name);
- return PTR_ERR(reset);
+ return PTR_ERR(phy-reset);
}
if (i) { /* No pmu for usbc0 */
snprintf(name, sizeof(name), pmu%d, i);
res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
- pmu = devm_ioremap_resource(dev, res);
- if (IS_ERR(pmu))
- return PTR_ERR(pmu);
+ phy-pmu = devm_ioremap_resource(dev, res);
+ if (IS_ERR(phy-pmu))
+ return PTR_ERR(phy-pmu);
}
- phy = devm_phy_create(dev, sun4i_usb_phy_ops, NULL);
- if (IS_ERR(phy)) {
+ phy-phy = devm_phy_create(dev, sun4i_usb_phy_ops, NULL);
+ if (IS_ERR(phy-phy)) {
dev_err(dev, failed to create PHY %d\n, i);
- return PTR_ERR(phy);
+ return PTR_ERR(phy-phy);
}
- data-phys[i].phy = phy;
- data-phys[i].pmu = pmu;
- data-phys[i].vbus = vbus;
- data-phys[i].reset = reset;
- data-phys[i].index = i;
- phy_set_drvdata(phy, data-phys[i]);
+ phy-index = i;
+ phy_set_drvdata(phy-phy, data-phys[i]);
}
dev_set_drvdata(dev, data);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] usb: ehci-platform: add optional reset controller retrieval
Hi Alan,
On Sat, May 10, 2014 at 10:35:49AM -0400, Alan Stern wrote:
@@ -206,6 +208,19 @@ static int ehci_platform_probe(struct platform_device
*dev)
break;
}
}
+
+ priv-rst = devm_reset_control_get_optional(dev-dev,
+ NULL);
I hate the style that matches arguments on a continuation line with the
opening paren of the function call, for a couple of reasons. Instead I
simply indent continuation lines by two or more tab stops. But some
people seem to be incurably attached to it.
Ok, I'll change it.
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
+ }
}
if (pdata-big_endian_desc)
The new code was added inside an if statement, which will cause it to
apply only to OF devices. Is there any reason not to put the new code
outside the if statement, so it applies to all devices?
Hmmm, I did this because so far, the reset framework only handles the
DT case. But that's right that it can be extended in the future, I'll
update it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [linux-sunxi] [PATCH v2 3/7] phy: usb: sunxi: Introduce Allwinner A31 USB PHY support
On Mon, May 12, 2014 at 05:14:26PM +0800, Chen-Yu Tsai wrote:
Hi,
On Sat, May 10, 2014 at 8:56 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
The USB phy controller in the A31 differs mostly from the older controllers
because it has a clock dedicated for each phy, while the older ones were
having
a single clock for all the phys.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e6e6c4ba7145..8bd89430d945 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -61,7 +61,6 @@
#define MAX_PHYS 3
struct sun4i_usb_phy_data {
- struct clk *clk;
void __iomem *base;
struct mutex mutex;
int num_phys;
@@ -71,6 +70,7 @@ struct sun4i_usb_phy_data {
void __iomem *pmu;
struct regulator *vbus;
struct reset_control *reset;
+ struct clk *clk;
int index;
} phys[MAX_PHYS];
};
@@ -146,13 +146,13 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
- ret = clk_prepare_enable(data-clk);
+ ret = clk_prepare_enable(phy-clk);
if (ret)
return ret;
ret = reset_control_deassert(phy-reset);
if (ret) {
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return ret;
}
@@ -170,11 +170,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
static int sun4i_usb_phy_exit(struct phy *_phy)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
- struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
sun4i_usb_phy_passby(phy, 0);
reset_control_assert(phy-reset);
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return 0;
}
@@ -228,8 +227,10 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
struct phy_provider *phy_provider;
struct reset_control *reset;
struct regulator *vbus;
+ bool dedicated_clocks;
No default?
struct resource *res;
struct phy *phy;
+ struct clk *clk;
char name[16];
int i;
@@ -249,15 +250,20 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
else
data-disc_thresh = 2;
+ if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy))
+ dedicated_clocks = true;
+
dedicated_clocks is more than likely to be true from leftover data
on the stack. This results in the usb phy driver probe failing, and
the usb host drivers left in perpetual probe deferral on my Cubietruck.
Adding an else section fixes this.
Oh, yes. Stupid me. It used to be in a kzalloc'd section, so I didn't
have the error, and didn't properly test it because it was trivial.
Thanks for catching this, I'll submit a v3.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH v3 4/8] phy: usb: sunxi: Introduce Allwinner A31 USB PHY support
The USB phy controller in the A31 differs mostly from the older controllers
because it has a clock dedicated for each phy, while the older ones were having
a single clock for all the phys.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 81896409c4bd..e15715aeec24 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -61,7 +61,6 @@
#define MAX_PHYS 3
struct sun4i_usb_phy_data {
- struct clk *clk;
void __iomem *base;
struct mutex mutex;
int num_phys;
@@ -71,6 +70,7 @@ struct sun4i_usb_phy_data {
void __iomem *pmu;
struct regulator *vbus;
struct reset_control *reset;
+ struct clk *clk;
int index;
} phys[MAX_PHYS];
};
@@ -146,13 +146,13 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
- ret = clk_prepare_enable(data-clk);
+ ret = clk_prepare_enable(phy-clk);
if (ret)
return ret;
ret = reset_control_deassert(phy-reset);
if (ret) {
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return ret;
}
@@ -170,11 +170,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
static int sun4i_usb_phy_exit(struct phy *_phy)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
- struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
sun4i_usb_phy_passby(phy, 0);
reset_control_assert(phy-reset);
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return 0;
}
@@ -225,6 +224,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
struct device_node *np = dev-of_node;
struct phy_provider *phy_provider;
+ bool dedicated_clocks;
struct resource *res;
int i;
@@ -244,17 +244,16 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
else
data-disc_thresh = 2;
+ if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy))
+ dedicated_clocks = true;
+ else
+ dedicated_clocks = false;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, phy_ctrl);
data-base = devm_ioremap_resource(dev, res);
if (IS_ERR(data-base))
return PTR_ERR(data-base);
- data-clk = devm_clk_get(dev, usb_phy);
- if (IS_ERR(data-clk)) {
- dev_err(dev, could not get usb_phy clock\n);
- return PTR_ERR(data-clk);
- }
-
/* Skip 0, 0 is the phy for otg which is not yet supported. */
for (i = 1; i data-num_phys; i++) {
struct sun4i_usb_phy *phy = data-phys + i;
@@ -268,6 +267,17 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
phy-vbus = NULL;
}
+ if (dedicated_clocks)
+ snprintf(name, sizeof(name), usb%d_phy, i);
+ else
+ strlcpy(name, usb_phy, sizeof(name));
+
+ phy-clk = devm_clk_get(dev, name);
+ if (IS_ERR(phy-clk)) {
+ dev_err(dev, failed to get clock %s\n, name);
+ return PTR_ERR(phy-clk);
+ }
+
snprintf(name, sizeof(name), usb%d_reset, i);
phy-reset = devm_reset_control_get(dev, name);
if (IS_ERR(phy-reset)) {
@@ -307,6 +317,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = allwinner,sun4i-a10-usb-phy },
{ .compatible = allwinner,sun5i-a13-usb-phy },
+ { .compatible = allwinner,sun6i-a31-usb-phy },
{ .compatible = allwinner,sun7i-a20-usb-phy },
{ },
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/8] usb: ohci-platform: Enable optional use of reset controller
The OHCI controllers used in the Allwinner A31 are asserted in reset using a
global reset controller.
Add optional support for such a controller in the OHCI platform driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
drivers/usb/host/ohci-platform.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 45f67d91e888..b968a1aea995 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -12,6 +12,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : usb
+- resets : phandle + reset specifier pair
Example:
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index b6002c951c5c..806dbebdc1d4 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
#include linux/err.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/usb/ohci_pdriver.h
#include linux/usb.h
#include linux/usb/hcd.h
@@ -36,6 +37,7 @@
struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -191,6 +193,19 @@ static int ohci_platform_probe(struct platform_device *dev)
break;
}
}
+
+ }
+
+ priv-rst = devm_reset_control_get_optional(dev-dev, NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
}
if (pdata-big_endian_desc)
@@ -266,6 +281,9 @@ static int ohci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (priv-rst)
+ reset_control_assert(priv-rst);
+
for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++)
clk_put(priv-clks[clk]);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/8] Add Allwinner A31 USB support
Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Thanks, Maxime Changes from v2: - Fixed indentation and used the reset framework in all case and not just in DT case - Added a default value to the dedicated_clocks variable. Setting it actually started triggering a gcc warning for no reason. Ended up reworking a bit the code to avoid it. Changes from v1: - Moved the reset assertion/deassertion to probe/remove - Moved the dedicated_clocks to the probe function instead of the private structure since it was the only user Boris BREZILLON (2): usb: ehci-platform: add optional reset controller retrieval ARM: sunxi: dt: add APP4-EVB1 board support Maxime Ripard (6): clk: sunxi: Implement A31 USB clock ARM: sun6i: Add the USB clocks to the DTSI. phy: sunxi: Rework phy initialization phy: usb: sunxi: Introduce Allwinner A31 USB PHY support usb: ohci-platform: Enable optional use of reset controller ARM: sun6i: dt: Add support for the USB controllers Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 + Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 ++ arch/arm/boot/dts/sun6i-a31.dtsi | 88 ++ drivers/clk/sunxi/clk-sunxi.c | 6 ++ drivers/phy/phy-sun4i-usb.c| 77 ++- drivers/usb/host/ehci-platform.c | 17 + drivers/usb/host/ohci-platform.c | 18 + 9 files changed, 231 insertions(+), 35 deletions(-) create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/8] ARM: sunxi: dt: add APP4-EVB1 board support
From: Boris BREZILLON boris.brezil...@free-electrons.com
The APP4 EVB1 development boards embeds an A31, together with some NAND, one SD
card slot, and one SDIO + UART WiFi and Bluetooth chip, a few I2C buses, USB,
and a LCD display.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 +++
2 files changed, 58 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8bc808cb7ce2..1d9c50dda655 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -344,6 +344,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
sun5i-a10s-r7-tv-dongle.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
+ sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
sun6i-a31-m9.dtb \
sun7i-a20-cubieboard2.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
new file mode 100644
index ..2bbf8867362b
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
@@ -0,0 +1,57 @@
+/*
+ * Copyright 2014 Boris Brezillon
+ *
+ * Boris Brezillon boris.brezil...@free-electrons.com
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ sun6i-a31.dtsi
+/include/ sunxi-common-regulators.dtsi
+
+/ {
+ model = Allwinner A31 APP4 EVB1 Evaluation Board;
+ compatible = allwinner,app4-evb1, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
+ };
+
+ soc@01c0 {
+ pio: pinctrl@01c20800 {
+ usb1_vbus_pin_a: usb1_vbus_pin@0 {
+ allwinner,pins = PH27;
+ allwinner,function = gpio_out;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+ };
+
+ usbphy: phy@01c19400 {
+ usb1_vbus-supply = reg_usb1_vbus;
+ status = okay;
+ };
+
+ ehci0: usb@01c1a000 {
+ status = okay;
+ };
+
+ uart0: serial@01c28000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins_a;
+ status = okay;
+ };
+ };
+
+ reg_usb1_vbus: usb1-vbus {
+ pinctrl-0 = usb1_vbus_pin_a;
+ gpio = pio 7 27 0;
+ status = okay;
+ };
+};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/8] usb: ehci-platform: add optional reset controller retrieval
From: Boris BREZILLON boris.brezil...@free-electrons.com
On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
be deasserted for the EHCI block to be usable.
Add support for an optional reset controller that will be deasserted on
power off and asserted on power on.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 +
drivers/usb/host/ehci-platform.c | 17 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index ff151ec084c4..43c1a4e06767 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -15,6 +15,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : usb
+ - resets : phandle + reset specifier pair
Example (Sequoia 440EPx):
ehci@e300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index c7dd93aad20c..8bb15eda9713 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/ehci_pdriver.h
@@ -41,6 +42,7 @@
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -208,6 +210,18 @@ static int ehci_platform_probe(struct platform_device *dev)
}
}
+ priv-rst = devm_reset_control_get_optional(dev-dev, NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
+ }
+
if (pdata-big_endian_desc)
ehci-big_endian_desc = 1;
if (pdata-big_endian_mmio)
@@ -280,6 +294,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (priv-rst)
+ reset_control_assert(priv-rst);
+
for (clk = 0; clk EHCI_MAX_CLKS priv-clks[clk]; clk++)
clk_put(priv-clks[clk]);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/8] ARM: sun6i: dt: Add support for the USB controllers
The A31 has two ECHI/OHCI controllers, and one OHCI-only phy-less controller.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 13aa56ed5858..5e9f01af6d99 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -341,6 +341,83 @@
status = disabled;
};
+ usbphy: phy@01c19400 {
+ compatible = allwinner,sun6i-a31-usb-phy;
+ reg = 0x01c19400 0x10,
+ 0x01c1a800 0x4,
+ 0x01c1b800 0x4;
+ reg-names = phy_ctrl,
+ pmu1,
+ pmu2;
+ clocks = usb_clk 8,
+usb_clk 9,
+usb_clk 10;
+ clock-names = usb0_phy,
+ usb1_phy,
+ usb2_phy;
+ resets = usb_clk 0,
+usb_clk 1,
+usb_clk 2;
+ reset-names = usb0_reset,
+ usb1_reset,
+ usb2_reset;
+ status = disabled;
+ #phy-cells = 1;
+ };
+
+ ehci0: usb@01c1a000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1a000 0x100;
+ interrupts = 0 72 4;
+ clocks = ahb1_gates 26;
+ resets = ahb1_rst 26;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci0: usb@01c1a400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1a400 0x100;
+ interrupts = 0 73 4;
+ clocks = ahb1_gates 29, usb_clk 16;
+ resets = ahb1_rst 29;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ehci1: usb@01c1b000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1b000 0x100;
+ interrupts = 0 74 4;
+ clocks = ahb1_gates 27;
+ resets = ahb1_rst 27;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci1: usb@01c1b400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1b400 0x100;
+ interrupts = 0 75 4;
+ clocks = ahb1_gates 30, usb_clk 17;
+ resets = ahb1_rst 30;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci2: usb@01c1c000 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1c400 0x100;
+ interrupts = 0 77 4;
+ clocks = ahb1_gates 31, usb_clk 18;
+ resets = ahb1_rst 31;
+ status = disabled;
+ };
+
pio: pinctrl@01c20800 {
compatible = allwinner,sun6i-a31-pinctrl;
reg = 0x01c20800 0x400;
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/8] phy: sunxi: Rework phy initialization
Move the phy initialization and variables declaration to the loop itself, since
it is where it really belongs. Also remove all the temporary variables, we can
use the structure members directly.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
drivers/phy/phy-sun4i-usb.c | 44
1 file changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e6e6c4ba7145..81896409c4bd 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -224,13 +224,8 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
struct sun4i_usb_phy_data *data;
struct device *dev = pdev-dev;
struct device_node *np = dev-of_node;
- void __iomem *pmu = NULL;
struct phy_provider *phy_provider;
- struct reset_control *reset;
- struct regulator *vbus;
struct resource *res;
- struct phy *phy;
- char name[16];
int i;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
@@ -262,42 +257,43 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
/* Skip 0, 0 is the phy for otg which is not yet supported. */
for (i = 1; i data-num_phys; i++) {
+ struct sun4i_usb_phy *phy = data-phys + i;
+ char name[16];
+
snprintf(name, sizeof(name), usb%d_vbus, i);
- vbus = devm_regulator_get_optional(dev, name);
- if (IS_ERR(vbus)) {
- if (PTR_ERR(vbus) == -EPROBE_DEFER)
+ phy-vbus = devm_regulator_get_optional(dev, name);
+ if (IS_ERR(phy-vbus)) {
+ if (PTR_ERR(phy-vbus) == -EPROBE_DEFER)
return -EPROBE_DEFER;
- vbus = NULL;
+ phy-vbus = NULL;
}
snprintf(name, sizeof(name), usb%d_reset, i);
- reset = devm_reset_control_get(dev, name);
- if (IS_ERR(reset)) {
+ phy-reset = devm_reset_control_get(dev, name);
+ if (IS_ERR(phy-reset)) {
dev_err(dev, failed to get reset %s\n, name);
- return PTR_ERR(reset);
+ return PTR_ERR(phy-reset);
}
if (i) { /* No pmu for usbc0 */
snprintf(name, sizeof(name), pmu%d, i);
res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
- pmu = devm_ioremap_resource(dev, res);
- if (IS_ERR(pmu))
- return PTR_ERR(pmu);
+ phy-pmu = devm_ioremap_resource(dev, res);
+ if (IS_ERR(phy-pmu))
+ return PTR_ERR(phy-pmu);
+ } else {
+ phy-pmu = NULL;
}
- phy = devm_phy_create(dev, sun4i_usb_phy_ops, NULL);
- if (IS_ERR(phy)) {
+ phy-phy = devm_phy_create(dev, sun4i_usb_phy_ops, NULL);
+ if (IS_ERR(phy-phy)) {
dev_err(dev, failed to create PHY %d\n, i);
- return PTR_ERR(phy);
+ return PTR_ERR(phy-phy);
}
- data-phys[i].phy = phy;
- data-phys[i].pmu = pmu;
- data-phys[i].vbus = vbus;
- data-phys[i].reset = reset;
- data-phys[i].index = i;
- phy_set_drvdata(phy, data-phys[i]);
+ phy-index = i;
+ phy_set_drvdata(phy-phy, data-phys[i]);
}
dev_set_drvdata(dev, data);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/8] ARM: sun6i: Add the USB clocks to the DTSI.
The USB clocks of the A31 seems to be parented to the 24MHz oscillator, and
handle the clocks for the USB phys and OHCI devices.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index eec1afa257a5..13aa56ed5858 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -269,6 +269,17 @@
clocks = osc24M, pll6;
clock-output-names = spi3;
};
+
+ usb_clk: clk@01c200cc {
+ #clock-cells = 1;
+ #reset-cells = 1;
+ compatible = allwinner,sun6i-a31-usb-clk;
+ reg = 0x01c200cc 0x4;
+ clocks = osc24M;
+ clock-output-names = usb_phy0, usb_phy1, usb_phy2,
+usb_ohci0, usb_ohci1,
+usb_ohci2;
+ };
};
soc@01c0 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/8] clk: sunxi: Implement A31 USB clock
The A31 USB clock slightly differ from its older counterparts, mostly because
it has a different gate for each PHY, while the older one had a single gate for
all the phy.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/clk/sunxi/clk-sunxi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index bd7dc733c1ca..d9bab75f128b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -972,6 +972,11 @@ static const struct gates_data sun5i_a13_usb_gates_data
__initconst = {
.reset_mask = 0x03,
};
+static const struct gates_data sun6i_a31_usb_gates_data __initconst = {
+ .mask = { BIT(18) | BIT(17) | BIT(16) | BIT(10) | BIT(9) | BIT(8) },
+ .reset_mask = BIT(2) | BIT(1) | BIT(0),
+};
+
static void __init sunxi_gates_clk_setup(struct device_node *node,
struct gates_data *data)
{
@@ -1267,6 +1272,7 @@ static const struct of_device_id clk_gates_match[]
__initconst = {
{.compatible = allwinner,sun6i-a31-apb2-gates-clk, .data =
sun6i_a31_apb2_gates_data,},
{.compatible = allwinner,sun4i-a10-usb-clk, .data =
sun4i_a10_usb_gates_data,},
{.compatible = allwinner,sun5i-a13-usb-clk, .data =
sun5i_a13_usb_gates_data,},
+ {.compatible = allwinner,sun6i-a31-usb-clk, .data =
sun6i_a31_usb_gates_data,},
{}
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] ARM: sunxi: dt: add APP4-EVB1 board support
From: Boris BREZILLON boris.brezil...@free-electrons.com
The APP4 EVB1 development boards embeds an A31, together with some NAND, one SD
card slot, and one SDIO + UART WiFi and Bluetooth chip, a few I2C buses, USB,
and a LCD display.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 +++
2 files changed, 58 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ffa3f5ef27d3..d50c0895a9d5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -343,6 +343,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
sun5i-a10s-olinuxino-micro.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
+ sun6i-a31-app4-evb1.dtb \
sun6i-a31-colombus.dtb \
sun6i-a31-m9.dtb \
sun7i-a20-cubieboard2.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
new file mode 100644
index ..2bbf8867362b
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31-app4-evb1.dts
@@ -0,0 +1,57 @@
+/*
+ * Copyright 2014 Boris Brezillon
+ *
+ * Boris Brezillon boris.brezil...@free-electrons.com
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ sun6i-a31.dtsi
+/include/ sunxi-common-regulators.dtsi
+
+/ {
+ model = Allwinner A31 APP4 EVB1 Evaluation Board;
+ compatible = allwinner,app4-evb1, allwinner,sun6i-a31;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
+ };
+
+ soc@01c0 {
+ pio: pinctrl@01c20800 {
+ usb1_vbus_pin_a: usb1_vbus_pin@0 {
+ allwinner,pins = PH27;
+ allwinner,function = gpio_out;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+ };
+
+ usbphy: phy@01c19400 {
+ usb1_vbus-supply = reg_usb1_vbus;
+ status = okay;
+ };
+
+ ehci0: usb@01c1a000 {
+ status = okay;
+ };
+
+ uart0: serial@01c28000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins_a;
+ status = okay;
+ };
+ };
+
+ reg_usb1_vbus: usb1-vbus {
+ pinctrl-0 = usb1_vbus_pin_a;
+ gpio = pio 7 27 0;
+ status = okay;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] ARM: sun6i: dt: Add support for the USB controllers
The A31 has two ECHI/OHCI controllers, and one OHCI-only phy-less controller.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 13aa56ed5858..5e9f01af6d99 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -341,6 +341,83 @@
status = disabled;
};
+ usbphy: phy@01c19400 {
+ compatible = allwinner,sun6i-a31-usb-phy;
+ reg = 0x01c19400 0x10,
+ 0x01c1a800 0x4,
+ 0x01c1b800 0x4;
+ reg-names = phy_ctrl,
+ pmu1,
+ pmu2;
+ clocks = usb_clk 8,
+usb_clk 9,
+usb_clk 10;
+ clock-names = usb0_phy,
+ usb1_phy,
+ usb2_phy;
+ resets = usb_clk 0,
+usb_clk 1,
+usb_clk 2;
+ reset-names = usb0_reset,
+ usb1_reset,
+ usb2_reset;
+ status = disabled;
+ #phy-cells = 1;
+ };
+
+ ehci0: usb@01c1a000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1a000 0x100;
+ interrupts = 0 72 4;
+ clocks = ahb1_gates 26;
+ resets = ahb1_rst 26;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci0: usb@01c1a400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1a400 0x100;
+ interrupts = 0 73 4;
+ clocks = ahb1_gates 29, usb_clk 16;
+ resets = ahb1_rst 29;
+ phys = usbphy 1;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ehci1: usb@01c1b000 {
+ compatible = allwinner,sun6i-a31-ehci, generic-ehci;
+ reg = 0x01c1b000 0x100;
+ interrupts = 0 74 4;
+ clocks = ahb1_gates 27;
+ resets = ahb1_rst 27;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci1: usb@01c1b400 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1b400 0x100;
+ interrupts = 0 75 4;
+ clocks = ahb1_gates 30, usb_clk 17;
+ resets = ahb1_rst 30;
+ phys = usbphy 2;
+ phy-names = usb;
+ status = disabled;
+ };
+
+ ohci2: usb@01c1c000 {
+ compatible = allwinner,sun6i-a31-ohci, generic-ohci;
+ reg = 0x01c1c400 0x100;
+ interrupts = 0 77 4;
+ clocks = ahb1_gates 31, usb_clk 18;
+ resets = ahb1_rst 31;
+ status = disabled;
+ };
+
pio: pinctrl@01c20800 {
compatible = allwinner,sun6i-a31-pinctrl;
reg = 0x01c20800 0x400;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] usb: ehci-platform: add optional reset controller retrieval
From: Boris BREZILLON boris.brezil...@free-electrons.com
On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
be deasserted for the EHCI block to be usable.
Add support for an optional reset controller that will be deasserted on
power off and asserted on power on.
Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 +
drivers/usb/host/ehci-platform.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index ff151ec084c4..43c1a4e06767 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -15,6 +15,7 @@ Optional properties:
- clocks : a list of phandle + clock specifier pairs
- phys : phandle + phy specifier pair
- phy-names : usb
+ - resets : phandle + reset specifier pair
Example (Sequoia 440EPx):
ehci@e300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index c7dd93aad20c..da89f274aa76 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -29,6 +29,7 @@
#include linux/of.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/usb.h
#include linux/usb/hcd.h
#include linux/usb/ehci_pdriver.h
@@ -41,6 +42,7 @@
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
+ struct reset_control *rst;
struct phy *phy;
};
@@ -206,6 +208,19 @@ static int ehci_platform_probe(struct platform_device *dev)
break;
}
}
+
+ priv-rst = devm_reset_control_get_optional(dev-dev,
+ NULL);
+ if (IS_ERR(priv-rst)) {
+ err = PTR_ERR(priv-rst);
+ if (err == -EPROBE_DEFER)
+ goto err_put_clks;
+ priv-rst = NULL;
+ } else {
+ err = reset_control_deassert(priv-rst);
+ if (err)
+ goto err_put_clks;
+ }
}
if (pdata-big_endian_desc)
@@ -280,6 +295,9 @@ static int ehci_platform_remove(struct platform_device *dev)
if (pdata-power_off)
pdata-power_off(dev);
+ if (priv-rst)
+ reset_control_assert(priv-rst);
+
for (clk = 0; clk EHCI_MAX_CLKS priv-clks[clk]; clk++)
clk_put(priv-clks[clk]);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Add Allwinner A31 USB support
Hi everyone, This patchset adds support for the USB controllers found in the Allwinner A31. While the design is similar to the earlier Allwinner SoCs that are already supported, a few details here and there change, like the fact that the PHYs now have one clock per phy, while it used to be only one for all the PHYs. Thanks, Maxime Changes from v1: - Moved the reset assertion/deassertion to probe/remove - Moved the dedicated_clocks to the probe function instead of the private structure since it was the only user Boris BREZILLON (2): usb: ehci-platform: add optional reset controller retrieval ARM: sunxi: dt: add APP4-EVB1 board support Maxime Ripard (5): clk: sunxi: Implement A31 USB clock ARM: sun6i: Add the USB clocks to the DTSI. phy: usb: sunxi: Introduce Allwinner A31 USB PHY support usb: ohci-platform: Enable optional use of reset controller ARM: sun6i: dt: Add support for the USB controllers Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 + Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 57 ++ arch/arm/boot/dts/sun6i-a31.dtsi | 88 ++ drivers/clk/sunxi/clk-sunxi.c | 6 ++ drivers/phy/phy-sun4i-usb.c| 35 ++--- drivers/usb/host/ehci-platform.c | 18 + drivers/usb/host/ohci-platform.c | 18 + 9 files changed, 216 insertions(+), 9 deletions(-) create mode 100644 arch/arm/boot/dts/sun6i-a31-app4-evb1.dts -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] ARM: sun6i: Add the USB clocks to the DTSI.
The USB clocks of the A31 seems to be parented to the 24MHz oscillator, and
handle the clocks for the USB phys and OHCI devices.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index eec1afa257a5..13aa56ed5858 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -269,6 +269,17 @@
clocks = osc24M, pll6;
clock-output-names = spi3;
};
+
+ usb_clk: clk@01c200cc {
+ #clock-cells = 1;
+ #reset-cells = 1;
+ compatible = allwinner,sun6i-a31-usb-clk;
+ reg = 0x01c200cc 0x4;
+ clocks = osc24M;
+ clock-output-names = usb_phy0, usb_phy1, usb_phy2,
+usb_ohci0, usb_ohci1,
+usb_ohci2;
+ };
};
soc@01c0 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] phy: usb: sunxi: Introduce Allwinner A31 USB PHY support
The USB phy controller in the A31 differs mostly from the older controllers
because it has a clock dedicated for each phy, while the older ones were having
a single clock for all the phys.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
---
drivers/phy/phy-sun4i-usb.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e6e6c4ba7145..8bd89430d945 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -61,7 +61,6 @@
#define MAX_PHYS 3
struct sun4i_usb_phy_data {
- struct clk *clk;
void __iomem *base;
struct mutex mutex;
int num_phys;
@@ -71,6 +70,7 @@ struct sun4i_usb_phy_data {
void __iomem *pmu;
struct regulator *vbus;
struct reset_control *reset;
+ struct clk *clk;
int index;
} phys[MAX_PHYS];
};
@@ -146,13 +146,13 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
- ret = clk_prepare_enable(data-clk);
+ ret = clk_prepare_enable(phy-clk);
if (ret)
return ret;
ret = reset_control_deassert(phy-reset);
if (ret) {
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return ret;
}
@@ -170,11 +170,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
static int sun4i_usb_phy_exit(struct phy *_phy)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
- struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
sun4i_usb_phy_passby(phy, 0);
reset_control_assert(phy-reset);
- clk_disable_unprepare(data-clk);
+ clk_disable_unprepare(phy-clk);
return 0;
}
@@ -228,8 +227,10 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
struct phy_provider *phy_provider;
struct reset_control *reset;
struct regulator *vbus;
+ bool dedicated_clocks;
struct resource *res;
struct phy *phy;
+ struct clk *clk;
char name[16];
int i;
@@ -249,15 +250,20 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
else
data-disc_thresh = 2;
+ if (of_device_is_compatible(np, allwinner,sun6i-a31-usb-phy))
+ dedicated_clocks = true;
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, phy_ctrl);
data-base = devm_ioremap_resource(dev, res);
if (IS_ERR(data-base))
return PTR_ERR(data-base);
- data-clk = devm_clk_get(dev, usb_phy);
- if (IS_ERR(data-clk)) {
- dev_err(dev, could not get usb_phy clock\n);
- return PTR_ERR(data-clk);
+ if (!dedicated_clocks) {
+ clk = devm_clk_get(dev, usb_phy);
+ if (IS_ERR(clk)) {
+ dev_err(dev, could not get usb_phy clock\n);
+ return PTR_ERR(clk);
+ }
}
/* Skip 0, 0 is the phy for otg which is not yet supported. */
@@ -270,6 +276,15 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
vbus = NULL;
}
+ if (dedicated_clocks) {
+ snprintf(name, sizeof(name), usb%d_phy, i);
+ clk = devm_clk_get(dev, name);
+ if (IS_ERR(clk)) {
+ dev_err(dev, failed to get clock %s\n, name);
+ return PTR_ERR(clk);
+ }
+ }
+
snprintf(name, sizeof(name), usb%d_reset, i);
reset = devm_reset_control_get(dev, name);
if (IS_ERR(reset)) {
@@ -296,6 +311,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
data-phys[i].pmu = pmu;
data-phys[i].vbus = vbus;
data-phys[i].reset = reset;
+ data-phys[i].clk = clk;
data-phys[i].index = i;
phy_set_drvdata(phy, data-phys[i]);
}
@@ -311,6 +327,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = allwinner,sun4i-a10-usb-phy },
{ .compatible = allwinner,sun5i-a13-usb-phy },
+ { .compatible = allwinner,sun6i-a31-usb-phy },
{ .compatible = allwinner,sun7i-a20-usb-phy },
{ },
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
