[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPNxggbs6hJtPA+2kqg34D8kV73BdNft2kZdMhUKtsAD=SsCnA@mail.gmail.com>
Date: Mon, 21 Oct 2013 13:19:46 +0200
From: Arokux X <arokux@...il.com>
To: Kishon Vijay Abraham I <kishon@...com>
Cc: peter.chen@...escale.com, Felipe Balbi <balbi@...com>,
Alan Stern <stern@...land.harvard.edu>,
Greg KH <gregkh@...uxfoundation.org>,
linux-usb@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: When USB PHY framework should be used?
Dear Kishon,
thank you for the answer, no problem it was late! Your understanding
is almost correct.
> From whatever I could understand, you have a USB HOST controller (each HOST
> controller has an EHCI controller and a companion OHCI controller?). There are
> separate clocks for each of EHCI and OHCI controller. EHCI and OHCI has
> separate PHYs. Both these PHYs are fed by the same common clock. And you have a
> separate reset bits for each of the PHYs.
EHCI and OHCI have the same PHY. And this PHY has a reset bit. This is
exactly what bothers me. Because there should be something central to
both EHCI and OHCI which manages this reset bit, i.e. the bit should
be cleared if and only if both EHCI and OHCI controllers are unloaded
(as modules). I have done a nice picture of the hardware here, please
take a look at it:
http://linux-sunxi.org/User:Arokux#USB_Host_Hardware
I've just realized that there is another commo thing for EHCI and OHCI
- a GPIO which turns on the power to the USB_VBUS. The power should be
supplied if at least one of the EHCI or OHCI is loaded. This again
needs some central management.
So to summarize, I have two things (reset bit and GPIO for the
USB_VBUS) which are common to EHCI and OHCI and need to be managed
outside of the EHCI/OHCI bus glue drivers. My exact question is: where
this management should be done? Are there good examples in the kernel
already?
Thank you in advance for the answer!
Best regards,
Arokux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists