On 03/20/2013 02:37 PM, Alexander Shishkin wrote: > 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 It's very tempting to describe the software capabilities by the device tree. But the device tree is supposed to describe the hardware only. > 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. Do we need to access the OTGSC register on a OTG capable SoC which is limited to device-only by other hardware constraints (like no ID Pin)? In other words, is Svetoslav's patch[1] "usb: chipidea: Don't access OTG related registers" sufficient? [1] http://patchwork.linux-mips.org/patch/4940/ This patch restricts the access to the OTGSC register to the dr_mode=otg case, which of course is only valid, if the hardware (SoC, board, etc) really supports otg. > 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. 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
