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 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
