Hi,
recently I have been working on mainlining a simple bus glue driver
for the USB EHCI for the Allwinner family of the ARM SoCs aka sunxi.
The patches are almost ready and can be found at [1] and will be
submitted once completely ready. The most interesting patch is [2]
which is a driver itself.
Currently everything works. Recently Maxime Ripard brought the reset
framework to my attention which I am going to use, since each of the
PHYs has a reset bit. Right now those bits are treated as clocks.
Later I am going to add the OHCI support. OHCI and EHCI will be
different drivers in different modules but they will share the same
PHY. I do not quite understand how can I correctly use reset framework
in the case of the common PHY. Imagine a situation if EHCI and OHCI
drivers got loaded and deassert the (same) reset bit. Then a user
decides to rmmod one of the drivers. This will cause it to assert the
reset bit, which will make the other driver to fail. So it is clear
there is a need for some central manager for the reset bit which is
going to be poked by both EHCI and OHCI.
Maxime Ripard also brought to my attention the new USB phy framework
which was merged into usb-next. However I'm not sure it should be used
in my driver since as far as I understand a PHY of a USB Host
Controller I'm dealing with is built into the controller itself. The
only parts of the driver that touche a PHY are reset bits (different
for each controller) and some initialization bits [3]. In addition the
in the doc file phy.txt I read
"This framework will be of use only to devices that use external PHY
(PHY functionality is not embedded within the controller)."
So can you please give me some hints about the possibilities to share
single reset bit? Should I use PHY framework, or create some kind of a
common module that is going to be used by EHCI and OHCI. In addition I
wanted to ask where I should normally put a common code like [4].
Thank you in advance,
Arokux
[1] https://github.com/arokux/linux/commits/sunxi-next-usb
[2] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be
[3] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be#diff-2fdea331a4331eca7c86f18cd2d87e72R89
[4] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be#diff-2fdea331a4331eca7c86f18cd2d87e72R104
On Thu, Oct 10, 2013 at 09:21:36PM +0200, Arokux X wrote:
> Hi,
>
> recently I have been working on mainlining a simple bus glue driver
> for the USB EHCI for the Allwinner family of the ARM SoCs aka sunxi.
> The patches are almost ready and can be found at [1] and will be
> submitted once completely ready. The most interesting patch is [2]
> which is a driver itself.
>
> Currently everything works. Recently Maxime Ripard brought the reset
> framework to my attention which I am going to use, since each of the
> PHYs has a reset bit. Right now those bits are treated as clocks.
>
> Later I am going to add the OHCI support. OHCI and EHCI will be
> different drivers in different modules but they will share the same
> PHY. I do not quite understand how can I correctly use reset framework
> in the case of the common PHY. Imagine a situation if EHCI and OHCI
> drivers got loaded and deassert the (same) reset bit. Then a user
> decides to rmmod one of the drivers. This will cause it to assert the
> reset bit, which will make the other driver to fail. So it is clear
> there is a need for some central manager for the reset bit which is
> going to be poked by both EHCI and OHCI.
>
> Maxime Ripard also brought to my attention the new USB phy framework
> which was merged into usb-next. However I'm not sure it should be used
> in my driver since as far as I understand a PHY of a USB Host
> Controller I'm dealing with is built into the controller itself. The
> only parts of the driver that touche a PHY are reset bits (different
> for each controller) and some initialization bits [3]. In addition the
> in the doc file phy.txt I read
>
> "This framework will be of use only to devices that use external PHY
> (PHY functionality is not embedded within the controller)."
More exactly, it your PHY is not the same register mapping with controller's
you can use it.
>
> So can you please give me some hints about the possibilities to share
> single reset bit? Should I use PHY framework, or create some kind of a
> common module that is going to be used by EHCI and OHCI. In addition I
> wanted to ask where I should normally put a common code like [4].
For your situation, you may need to create a controller driver, and call
ehci, ohci, and phy init at this probe routine, in that way, your ohci
and ehci controller will need to be unloaded together.
--
Best Regards,
Peter Chen
On Friday 11 October 2013 12:51 AM, Arokux X wrote:
> Hi,
>
> recently I have been working on mainlining a simple bus glue driver
> for the USB EHCI for the Allwinner family of the ARM SoCs aka sunxi.
> The patches are almost ready and can be found at [1] and will be
> submitted once completely ready. The most interesting patch is [2]
> which is a driver itself.
>
> Currently everything works. Recently Maxime Ripard brought the reset
> framework to my attention which I am going to use, since each of the
> PHYs has a reset bit. Right now those bits are treated as clocks.
>
> Later I am going to add the OHCI support. OHCI and EHCI will be
> different drivers in different modules but they will share the same
> PHY. I do not quite understand how can I correctly use reset framework
> in the case of the common PHY. Imagine a situation if EHCI and OHCI
> drivers got loaded and deassert the (same) reset bit. Then a user
> decides to rmmod one of the drivers. This will cause it to assert the
> reset bit, which will make the other driver to fail. So it is clear
> there is a need for some central manager for the reset bit which is
> going to be poked by both EHCI and OHCI.
Looks like the reset should be done in a wrapper driver. Do you have a wrapper
driver for EHCI/OHCI?
>
> Maxime Ripard also brought to my attention the new USB phy framework
> which was merged into usb-next. However I'm not sure it should be used
> in my driver since as far as I understand a PHY of a USB Host
> Controller I'm dealing with is built into the controller itself. The
> only parts of the driver that touche a PHY are reset bits (different
> for each controller) and some initialization bits [3]. In addition the
> in the doc file phy.txt I read
>
> "This framework will be of use only to devices that use external PHY
> (PHY functionality is not embedded within the controller)."
right. PHY framework is used when you have a separate IP for PHY. Generally in
cases where you have the PHY built in the controller, you can handle the PHY
programming in your controller driver itself.
>
> So can you please give me some hints about the possibilities to share
> single reset bit? Should I use PHY framework, or create some kind of a
> common module that is going to be used by EHCI and OHCI. In addition I
I think you should have a wrapper driver to EHCI/OHCI to handle this reset.
Thanks
Kishon
> wanted to ask where I should normally put a common code like [4].
>
> Thank you in advance,
> Arokux
>
>
>
>
> [1] https://github.com/arokux/linux/commits/sunxi-next-usb
> [2] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be
> [3] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be#diff-2fdea331a4331eca7c86f18cd2d87e72R89
> [4] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be#diff-2fdea331a4331eca7c86f18cd2d87e72R104
>
> I think you should have a wrapper driver to EHCI/OHCI to handle this reset.
Thank you Kishon and Peter for the quick replies. Is there any good
example of such a wrapper driver in the kernel already?
Thanks
Arokux
>
> > I think you should have a wrapper driver to EHCI/OHCI to handle this
> reset.
>
> Thank you Kishon and Peter for the quick replies. Is there any good
> example of such a wrapper driver in the kernel already?
>
chipidea, dwc3, etc.
Hi,
On Friday 11 October 2013 10:52 PM, Arokux X wrote:
>> I think you should have a wrapper driver to EHCI/OHCI to handle this reset.
>
> Thank you Kishon and Peter for the quick replies. Is there any good
> example of such a wrapper driver in the kernel already?
can you explain how your IP actually looks like? Do you have separate address
space for EHCI and OHCI? Do you have any common address space for doing some
configuration (USB host in OMAP used to have it)? Where does PHY registers
reside exactly?
Thanks
Kishon
Dear Kishon,
On Sat, Oct 12, 2013 at 12:07 PM, Kishon Vijay Abraham I <[email protected]> wrote:
> Hi,
>
> On Friday 11 October 2013 10:52 PM, Arokux X wrote:
>>> I think you should have a wrapper driver to EHCI/OHCI to handle this reset.
>>
>> Thank you Kishon and Peter for the quick replies. Is there any good
>> example of such a wrapper driver in the kernel already?
>
> can you explain how your IP actually looks like? Do you have separate address
> space for EHCI and OHCI? Do you have any common address space for doing some
> configuration (USB host in OMAP used to have it)? Where does PHY registers
> reside exactly?
The knowledge I have about the IP is derived from the source code of
the different kernel trees some of which were leaked and the others
released by Allwinner. I cannot really see similarities to the other
USB IPs supported by the mainline kernel since I have zero experience
with kernel development and this simple bus glue driver is going to be
my first contribution.
USB Host Controller as available in Allwinner SoCs supports EHCI and
OHCI. The address spaces of EHCI and OHCI are separate. Let the
address of the host controller be X, then EHCI is at X and OHCI is at
X+OHCI_OFFSET, where OHCI_OFFSET = 0x100.
The driver in the vendor's tree also touches the address X + 0x800 and
enables DMA burst, similar to the SAMSUNG S5P USB HOST EHCI Controller
[1].
In addition another memory location is touched to configure the PHY.
At that place two things occur [2]: "adjust PHY's magnitude and rate"
and adjusting the threshold of the disconnect. (Both are translated
from Chinese and I'm not sure whether the former is correct).
There are either two or one USB Host Controllers in a SoC. For each
controller there are EHCI and OHCI gatable clocks, one common clock
for all the PHYs and one reset bit for each PHY.
I think this is pretty much it. As you see the EHCI and OHCI parts are
almost independent from each other. The only problem is the common
reset bit which I do not know how to manage. Any help is highly
appreciated.
Best regards,
Arokux
[1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-s5p.c#L34
[2] https://github.com/arokux/linux/commit/1f271d01b8138d5a593df18a80b4129a08eac1be#diff-2fdea331a4331eca7c86f18cd2d87e72R89
Dear all,
may I please draw your attention to this thread?
Thank you,
Arokux
+Roman
Hi,
Sorry for the late reply..
On Monday 14 October 2013 11:47 PM, Arokux X wrote:
> Dear Kishon,
>
> On Sat, Oct 12, 2013 at 12:07 PM, Kishon Vijay Abraham I <[email protected]> wrote:
>> Hi,
>>
>> On Friday 11 October 2013 10:52 PM, Arokux X wrote:
>>>> I think you should have a wrapper driver to EHCI/OHCI to handle this reset.
>>>
>>> Thank you Kishon and Peter for the quick replies. Is there any good
>>> example of such a wrapper driver in the kernel already?
>>
>> can you explain how your IP actually looks like? Do you have separate address
>> space for EHCI and OHCI? Do you have any common address space for doing some
>> configuration (USB host in OMAP used to have it)? Where does PHY registers
>> reside exactly?
>
> The knowledge I have about the IP is derived from the source code of
> the different kernel trees some of which were leaked and the others
> released by Allwinner. I cannot really see similarities to the other
> USB IPs supported by the mainline kernel since I have zero experience
> with kernel development and this simple bus glue driver is going to be
> my first contribution.
>
> USB Host Controller as available in Allwinner SoCs supports EHCI and
> OHCI. The address spaces of EHCI and OHCI are separate. Let the
> address of the host controller be X, then EHCI is at X and OHCI is at
> X+OHCI_OFFSET, where OHCI_OFFSET = 0x100.
>
> The driver in the vendor's tree also touches the address X + 0x800 and
> enables DMA burst, similar to the SAMSUNG S5P USB HOST EHCI Controller
> [1].
>
> In addition another memory location is touched to configure the PHY.
> At that place two things occur [2]: "adjust PHY's magnitude and rate"
> and adjusting the threshold of the disconnect. (Both are translated
> from Chinese and I'm not sure whether the former is correct).
>
> There are either two or one USB Host Controllers in a SoC. For each
> controller there are EHCI and OHCI gatable clocks, one common clock
> for all the PHYs and one reset bit for each PHY.
>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.
And when you have a second USB HOST controller, you have a new instance of the
same thing as before?
Thanks
Kishon
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
Hi,
On Monday 21 October 2013 04:49 PM, Arokux X wrote:
> 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?
Probably you can have a look at drivers/mfd/omap-usb-host.c in mainline kernel.
Thanks
Kishon
On Mon, Oct 21, 2013 at 01:19:46PM +0200, Arokux X wrote:
> 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?
It looks to me like all of these are just different registers of the
same controller. So to me, you should have a single driver for it, that
manages both the reset, regulators and clocks, and loads both the ohci
and ehci layers. bcma-hcd seems to be doing exactly that for example.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com