lkml.org 
[lkml]   [2012]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/3] capebus moving omap_devices to mach-omap2
    From
    Date

    Op 1 nov. 2012, om 14:06 heeft Felipe Balbi <balbi@ti.com> 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@ti.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 ?

    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.

    \
     
     \ /
      Last update: 2012-11-01 15:01    [W:4.934 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site