Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

[Koen Kooi]

Op 1 nov. 2012, om 14:06 heeft Felipe Balbi <balbi@xxxxxx> het volgende geschreven:

> Hi,
> 
> On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote:
>> tl;dr: please suggest an actual solution that allows plug&play when
>> plugging in multiple capes and applying power after that. Preferably
>> one that doesn't pass the buck to u-boot.
> 
> I can think of a few ways:
> 
> 1) ship your distribution with all necessary drivers and let udev handle
> 	driver probing.
> 
> 	clearly this will require constant updates for the distribution
> 	as new capes are developed. But IIUC, that's the same with
> 	Arduino where new "libraries" are added to the Arduino OS.

And how are you going to handle pinmuxing and conflict resolution? You're basically saying that people should just use /dev/mem to write drivers, since you don't consider their use case valid.

> 
> 2) ship with drivers for EEPROMs only and setup a repository of drivers
> 
> 	this would require every driver to be packaged separately, then
> 	you create a setup where bone's userland will use EEPROMs data
> 	to figure out which drivers it needs, pass that information to
> 	SDK via USB, then SDK downloads all necessary/missing packages,
> 	sends them to bone via USB and all packages are installed on the
> 	bone.
> 
> 	Note that since packages would be 'installed', this would be a
> 	one-time-only thing.

I lack the words to describe my emotions after reading this. Let's leave it at that.

> 3) realize that if your user can build an FPGA cape, s/he can most
> 	likely write code and adding/recompiling kernel shouldn't be the
> 	biggest of his/her worries
> 
> 	(no comments to this one, I understand it's not feasible)

You'd be surprised.

> in any case, capebus sounds like something which is hugely unnecessary.

On tablets and phones, yes. But TI chips are use for different use-cases, bone + capes being one of those.

> ps: at least for the I2C subsystem, i2c-core can detect for you if your
> driver provides ->detect() method.

So I just need to patch all i2c drivers and force people to use the "standard" address for the i2c chip when designing a board.

>> Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" <b-cousson@xxxxxx> het volgende geschreven:
>>>>> FWIW, we do have a similar, but simpler, problem with the beagle /
>>>>> beagle-xm and panda / panda-es. But for the moment we are just
>>>>> using a different DTS for each board.
>>>> 
>>>> A different DTS for each board combination... There alot more capes
>>>> for the bone that they are for the beagle & the panda.  And more
>>>> are going to come, but not necessarily from people that have any
>>>> connection to TI or CCO.
>>> 
>>> Sure, but my point is that your solution will not solve our problem
>>> :-)
>>> This is a generic problem that you address with a very custom /
>>> specific approach.
>>> 
>>>> You still haven't described how I could solve the issue of
>>>> conflicting capes using a single DTS.
>>> 
>>> Well I don't have the solution otherwise I will have done it already
>>> :-)
>>> My point is that the solution has to be in the DT core if not in the
>>> bootloader.
>> 
>> <snarky comment>So when we at beagleboard.org handled the beagleboard
>> and beagleboard xM expansionboards in the bootloader (detection,
>> muxing, etc) we were told it was wrong and we should handle it in the
>> kernel and if we waited a bit, DT would solve everything. And now that
>> we actually handle it in the kernel you are saying that it is wrong
>> and we should handle it in the bootloader and that DT won't solve
>> everything. I guess someone will now tell us that uEFI will fix
>> everything.</snarky comment>
>> 
>> Apart from that, you and others still fail to tell us how you want to
>> handle a user (or customer) that buys a beaglebone, an LCD cape, a
>> weatherstation cape and a geiger counter cape and plugs those together
>> and powers them on. With the evil TI vendor tree and extra patches the
>> boardfile reads the eeproms and tries its best to instantiate all the
>> platform data. One of the capes won't have working LEDs since
>> appending to the leds-gpio struct is pretty much impossible in this
> 
> couldn't you just instantiate multiple leds-gpio device ?

No, and that is a problem in the driver core, see earlier discussions about similar problems.

>> situation. But it gets a picture on the screen, blinks LEDs and does
>> largely what the user expects.
>> 
>> With capebus we get:
>> 
>> 1) da8xx-fb which lacks DT bindingsp[1] receives plaftorm data to
>> match the LCD
> 
> this is something which could be fixed at the driver level, right ? :-)

You'd have to tell your coworkers that.

>> 2) the i2c sensors on the weathercape are registered
> 
> that will work with or without capebus.

Not in a plug and play way.

>> 3) the one-wire bus on the weathercape gets registered
> 
> also should work with or without capebus.

Not in a plug and play way.

>> 4) the LEDs on the lcd cape get registered5
> 
> also works with or without capebus.

Not in a plug and play way.

>> 5) the LED on the geigercape gets registered and adds a custom trigger
> 
> also works with or without capebus.

Not in a plug and play way.

> 
>> 6) the ADC, which again, lacks DT bindings[2], receives plaftorm data
>> and a custom IIO binding
> 
> driver problem.

Yes, beat up your coworkers, I can't.

> 
>> 7) pinctrl sets the pinmuxes for the above
> 
> also works with or without capebus.

Not in a plug and play way.

> 
>> In other words: plug & play, even for devices with drivers that are
>> still lacking DT support. 
> 
> I _do_ agree with you that we could have a "grace period" where DT and
> non-DT would boot together, but apparently that's not something which
> isn't trivial to do.
> 
> I guess Benoit might also be concerned that if we add such an
> infrastructure than conversion to DT will never finish heh.

Like I said, take that up with your coworkers. I want DT support for all TI IP blocks, apparently TI disagrees.

>> Now please explain to me why you think it's such an awesome idea that
>> the users will need to find the right dtsi files (multiple revisions
>> of the lcd cape exist), include them in the dts, run dtc, add a few
>> missing semicolons, run dtc again, copy it over to /boot and reboot to
>> have a change of making it work?
> 
> that shouldn't be necessary. At least for all the I2C devices, you can
> just implement ->detect() and it will just work. Maybe similar tricks
> can be done for 1-wire and SPI, I haven't looked into the details of
> those buses to be sure, though.
> 
>> I know you can't escape that for new or custom capes, but I do want
>> all the capes my company assembles work out of the box.
> 
> then push all drivers to mainline and start shipping your boards with
> those drivers enabled.

So how do you solve conflicts? The PRU pins are mixed with the LCD pins. So how can I enable both drivers? Same deal with mcasp and SPI.

> 
>> (Cross)compiling a kernel is a bridge too far for 95% of the intended
>> audience.
> 
> Agreed, but that doesn't prevent you from either shipping distribution
> with drivers enabled or providing pre-compiled modules.
> 
>> With capebus most capes can be supported by editing the DTS, your
>> bootloader proposal involves updating u-boot for every new cape as
>> well. That is downright scary. The RMA department will get flooded.
> 
> that's not true at all. If capebus can do all that from within kernel,
> it surely can do the same (with a few changes here and there) from
> within bootloader.

Yes, and then I have 2 places to add support for capes instead of one. And I seriously question why anyone thinks that having users replace their bootloader everytime they add a new i2c device or LED to their board is a good idea.

> 
>> More importantly: capebus is generic enough to work on beagleboard,
>> beagleboard xm, panda, panda es and even raspberry-pi. Basically on
>> any DT capable platform.
> 
> that doesn't matter much I guess. MTP is so cool that works on Exynos,
> OMAP, Tegra, x86, Cris, AVR, etc etc etc and we still don't have an MTP
> stack inside the kernel (ok a bit sarcastic... but you get the drift,
> hopefully).

Yes, I agree, we still don't have a working MUSB driver in the kernel either. But that shouldn't stop capebus from being considered.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/