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. Regards, -- Alex -- 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
