On Wed, Mar 20, 2013 at 05:32:05PM +0100, Marc Kleine-Budde wrote: > On 03/20/2013 05:02 PM, Felipe Balbi wrote: > > On Wed, Mar 20, 2013 at 04:58:05PM +0100, Marc Kleine-Budde wrote: > >> On 03/20/2013 03:44 PM, Felipe Balbi wrote: > >>> Hi, > >>> > >>> On Wed, Mar 20, 2013 at 04:26:02PM +0200, Alexander Shishkin wrote: > >>>>>>>> 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 > >>>>> > >>>>> that's not entirely true. A manufacturer can decide to skip OTG > >>>>> certification but still support Dual Role. Look at the whole Android > >>>>> Accessory Kit, for example. > >>>> > >>>> Sure, I was just making an example of how device capabilities can differ > >>>> from device's intended function. > >>>> > >>>>>> 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. > >>>>> > >>>>> well, if it's only available in OTG configurations, then you make the > >>>>> same assumption in driver. If driver was compiled with OTG, you check > >>>>> OTGSC; otherwise don't. > >>>> > >>>> I'd kind of like to support different configurations in runtime and have > >>>> as few compilation options as possible. Of course, if it means extra > >>>> spaghetti, there's a trade off right there. > >>> > >>> right, that's what I did with drivers/usb/dwc3/, it helped cut down > >>> ifdeferry to a minimum. But when chromebook with Exynos5 showed up, we > >>> _had_ to allow manufacturers to ship the notebook without the peripheral > >>> side, since they'd never, ever use it. Since the code was already > >>> prepared for that, it was pretty simple and there's no ifdef hell > >>> anywhere. Below you will find original commit. The main idea is that, if > >>> you want a distro-like kernel, then you always build with everything > >>> (DRD), but if you're building a real product, as you said, you may not > >>> want to ship both modes unless you're really going to use them. > >> > >> With the "dr_mode" property in the DT, you can build one kernel that > >> supports host, device and otg at the same time, but still limit a > >> particular hardware to device only mode. > > > > that's alright. We do that with dwc3 as well. But what if you want a > > kernel with host-only ? You don't want to waste precious memory > > initializing data you will never use ;-) > > Sure, even the mainline chipidea driver already allows us to build it > host or device only :D yeah, note what Alex had said his plans were when I replied. -- balbi
Attachment:
signature.asc
Description: Digital signature
