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.

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.

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)

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

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

Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" [off-list ref] het volgende geschreven:

quoted

quoted

quoted

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.

quoted

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 ?

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 ? :-)

2) the i2c sensors on the weathercape are registered

that will work with or without capebus.

3) the one-wire bus on the weathercape gets registered

also should work with or without capebus.

4) the LEDs on the lcd cape get registered5

also works with or without capebus.

5) the LED on the geigercape gets registered and adds a custom trigger

also works with or without capebus.

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

driver problem.

7) pinctrl sets the pinmuxes for the above

also works with or without capebus.

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.

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.

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

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

-- 
balbi