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