Op 1 nov. 2012, om 14:06 heeft Felipe Balbi [off-list ref] het volgende geschreven:

Hi,

On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote:

quoted

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.

quoted

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 ?

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

quoted

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.

quoted

2) the i2c sensors on the weathercape are registered

that will work with or without capebus.

Not in a plug and play way.

quoted

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

also should work with or without capebus.

Not in a plug and play way.

quoted

4) the LEDs on the lcd cape get registered5

also works with or without capebus.

Not in a plug and play way.

quoted

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.

quoted

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.

quoted

7) pinctrl sets the pinmuxes for the above

also works with or without capebus.

Not in a plug and play way.

quoted

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.

quoted

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.

quoted

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.

quoted

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

quoted

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.

quoted

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.