Marc Kleine-Budde <m...@pengutronix.de> writes:

> On 03/20/2013 12:04 PM, Alexander Shishkin wrote:
>> Peter Chen <peter.c...@freescale.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to