Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> writes:
> 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.
Again, see the discussion above.
In real world products (that is, phones and tablets as opposed to jolly
fun development boards), vendors will want to limit the usb
functionality to peripheral only or host only or whatever, because the
middleware stack can only do one thing or because they don't want to go
through with otg certification or you name it. Meanwhile, the controller
and the whole device can still support otg. And we need to know that if
we're to try to detect vbus session, because that is done via OTGSC
which is only available in otg configurations.
The alternative is to have N more platform tweaks for
* dccparams_is_borked,
* otgsc_is_borked,
and a lot of luck trying to get that right in the probe(). This is, of
course a preferred approach for anyone who supports phandle creep in
DT.
I don't like either approach, but the former seems a tad less damaging.
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
