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 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
