Message-ID: <20121101130636.GB12489@arwen.pp.htv.fi>
Date:	Thu, 1 Nov 2012 15:06:36 +0200
From:	Felipe Balbi <balbi@...com>
To:	Koen Kooi <koen@...inion.thruhere.net>
CC:	"Cousson, Benoit" <b-cousson@...com>,
	Pantelis Antoniou <panto@...oniou-consulting.com>,
	<balbi@...com>, Tony Lindgren <tony@...mide.com>,
	<linux-kernel@...r.kernel.org>, Matt Porter <mporter@...com>,
	Russ Dill <Russ.Dill@...com>, <linux-omap@...r.kernel.org>,
	Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

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" <b-cousson@...com> 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 ?

> 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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists