On 03/20/2013 12:23 PM, Alexander Shishkin wrote: > Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> writes: > >> On 03/20/2013 12:04 PM, Alexander Shishkin wrote: >>> Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: >>> >>>> On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote: >>>>> >>>>>> Eg, for tablet or phone, the dr_mode may be "gadget", but the >>>>>> otg_capable = 1. >>>>> >>>>> No, because dr_mode indicates controller's capability, and not the >>>>> "current" mode of operation. Why would anyone want to put *that* in a >>>>> DT? >>>>> >>>> >>>> OK, now I totally understand your mind of this problem. In fact, dr_mode >>>> is NOT controller's capability, even at its original place: >>>> (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia, tegra20-ehci.txt) >>>> dr_mode is the usb working mode. >>>> >>>> When we design USB system, the requirements are differ from products >>>> to products. >>>> The phone/tablet device may only wants itself as gadget >>>> device, it needs to be no-response when there is a usb device plug in >>>> (eg usb keyboard with Micro B-to-A cable). >>>> >>>> The car entertainment system or other Standard-A port system do not want >>>> to be enumerated when it plugs to notebook using Standard A-to-A cable. >>> >>> Bah. Of course, you're right. We're stuck with dr_mode till people learn >>> to design middleware stacks that can handle being both host and >>> peripheral. >>> >>>> So, currently, even most of controllers are otg-capable, still most >>>> of designs are one working mode designed. The reason why we design >>>> the dr_mode is that we want controller working mode to be decided >>>> by DT without re-compile the kernel by build out the host/gadget driver. >>> >>> Ok, so then how about introducing *one* more parameter, something like >>> "dr_cap", which >>> 1) when specified, supersedes DCCPARAMS, so no need to read that >>> register any more; >>> 2) when unspecified, use DCCPARAMS; >>> 3) can be one of "host", "peripheral", "otg", "dual_role": >>> - host, peripheral: initialize one role only, stick to that, no otg; >>> - dual_role: initialize both roles, no otg; >>> - otg: both roles, ci->is_otg == true. >>> >>> Another question now is, do we need "dual_role" variant for the dr_mode >>> parameter? >> >> What's the difference between the newly proposed dr_cap and the dr_mode >> parameter? > > See the discussion above. > > dr_cap is what the device can actually do (host, peripheral, etc). Tells > us which roles to initialize and wether we can access OTGSC on this > device. > dr_mode is what function of the device we'll be using on this particular > board. Sorry, I don't get why the driver needs to know what the chipidea can do in theory (dr_cap). IMHO it should be sufficient to tell the driver what that exact hardware it runs on can do (dr_mode). What the hardware can do depends on the actual chipidea implementation used in that SoC and the board the SoC is soldered on. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Attachment:
signature.asc
Description: OpenPGP digital signature
