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 ;-) -- balbi
Attachment:
signature.asc
Description: Digital signature
