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" <[email protected]> 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

Attachments:

(No filename) (6.41 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2012-11-01 13:22:09

HI,

On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote:
> Hi Alan,
>
> On Nov 1, 2012, at 3:51 PM, Alan Cox wrote:
>
> >> What they want, and what every user wants, is I plug this board in, and
> >> the driver make sure everything is loaded and ready. No, the end users
> >> don't want to see any of the implementation details of how the bitfile
> >> is transported; the driver can handle it.
> >
> > That doesn't necessarily make it a bus merely some kind of hotplug
> > enumeration of devices. That should all work properly both for devices
> > and busses with spi and i?c as the final bits needed for it got fixed
> > some time ago.
> >
> > In an ideal world you don't want to be writing custom drivers for stuff.
> > If your cape routes an i?c serial device to the existing system i?c
> > busses then you want to just create an instance of any existing driver on
> > the existing i?c bus not create a whole new layer of goop.
> >
> > It does need to do the plumbing and resource management for the plumbing
> > but thats not the same as being a bus.
> >
> > Alan
>
>
> Fair enough. But there's no such thing a 'hotplug enumeration
> construct' in Linux yet, and a bus is the closest thing to it. It does
> take advantage of the nice way device code matches drivers and devices
> though.
>
> I'm afraid that having the I2C/SPI drivers doing the detection won't
> work. The capes can have arbitrary I2C/SPI devices (and even more
> weird components). There is no way to assure for example that the I2C
> device responding to address 'foo' in cape A is the same I2C device
> responding to the same address in cape B.

your ->detect() method should take care of that.

--
balbi

Attachments:

(No filename) (1.67 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2012-11-01 23:49:27

by Russ Dill

[permalink] [raw]

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

On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi <[email protected]> wrote:
> HI,
>
> On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote:
>> Hi Alan,
>>
>> On Nov 1, 2012, at 3:51 PM, Alan Cox wrote:
>>
>> >> What they want, and what every user wants, is I plug this board in, and
>> >> the driver make sure everything is loaded and ready. No, the end users
>> >> don't want to see any of the implementation details of how the bitfile
>> >> is transported; the driver can handle it.
>> >
>> > That doesn't necessarily make it a bus merely some kind of hotplug
>> > enumeration of devices. That should all work properly both for devices
>> > and busses with spi and i²c as the final bits needed for it got fixed
>> > some time ago.
>> >
>> > In an ideal world you don't want to be writing custom drivers for stuff.
>> > If your cape routes an i²c serial device to the existing system i²c
>> > busses then you want to just create an instance of any existing driver on
>> > the existing i²c bus not create a whole new layer of goop.
>> >
>> > It does need to do the plumbing and resource management for the plumbing
>> > but thats not the same as being a bus.
>> >
>> > Alan
>>
>>
>> Fair enough. But there's no such thing a 'hotplug enumeration
>> construct' in Linux yet, and a bus is the closest thing to it. It does
>> take advantage of the nice way device code matches drivers and devices
>> though.
>>
>> I'm afraid that having the I2C/SPI drivers doing the detection won't
>> work. The capes can have arbitrary I2C/SPI devices (and even more
>> weird components). There is no way to assure for example that the I2C
>> device responding to address 'foo' in cape A is the same I2C device
>> responding to the same address in cape B.
>
> your ->detect() method should take care of that.

There isn't some magical serial number in I²C devices that a
->detect() method can read and the implementation of I²C is somewhat
flexible. One devices read may be another devices write. A detect
method that only performs reads could easily toggle a gpio that resets
the board, rewrite and eeprom, or set the printer on fire. If you
browse through various detect functions, yes, some of them key off an
ID, but a lot of them just check various registers to see if certain
bits are zero, or certain bits are one. A lot of I²C devices I've
dealt with have no good way of probing them, especially GPIO chips
(you'll notice none of the I²C GPIO expanders have detect functions)

On top of all this the detect routine does not tell you if the alert
pin is connected to some IRQ, or in the case of a GPIO expander, what
those GPIOs are connected to, etc, etc.

2012-11-02 08:16:41

by Benoit Cousson

[permalink] [raw]

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

On 11/1/2012 1:00 PM, 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.
>
> Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" <[email protected]> het volgende geschreven:
>
>> Hi Panto,
>>
>> On 11/1/2012 11:39 AM, Pantelis Antoniou wrote:
>>> Hi Benoit,
>>>
>>> On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote:
>>>
>>>> On 11/1/2012 8:02 AM, Pantelis Antoniou wrote:
>>>>> Hi Felibe,
>>>>>
>>>>> On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote:
>>>>>>>> * Pantelis Antoniou <[email protected]> [121031 13:14]:
>>>>>>>>> On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
>>>>>>>>>>
>>>>>>>>>> Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control
>>>>>>>>>> could have an hwmod and thus must be handled by an omap_device.
>>>>>>>>>>
>>>>>>>>>> Any devices that is created later cannot be omap_device. The DT core
>>>>>>>>>> will create regular platform_device for them.
>>>>>>>>>>
>>>>>>>>>> Since cape is an external board, it should have nothing to do with
>>>>>>>>>> omap_device.
>>>>>>>>>>
>>>>>>>>>> Looking at your patch:
>>>>>>>>>> da8xx-dt: Create da8xx DT adapter device
>>>>>>>>>>
>>>>>>>>>> I understand why you do that, but in fact that patch does not make sense
>>>>>>>>>> to me :-(
>>>>>>>>>>
>>>>>>>>>> Why do you have to create an omap_device from the driver probe?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The problem is that capes are not external boards in the normal sense
>>>>>>>>> as a PCI board is. In the PCI case the hardware that implements the
>>>>>>>>> desired functionality is on the PCI board, while in the cape case the
>>>>>>>>> hardware module is in the SoC. The cape most of the times is quite
>>>>>>>>> simple and contains passive components, leds or some kind of I2C/SPI devices.
>>>>>>>>
>>>>>>>> Ah now I see, you're talking about the beaglebone extension
>>>>>>>> boards :)
>>>>>>>>
>>>>>>>> The way to deal with those properly is to just edit the
>>>>>>>> board .dts entry to include omap-beaglebone-cape-xyz.dtsi
>>>>>>>> whatever.
>>>>>>>>
>>>>>>>
>>>>>>> That is what is being done...
>>>>>>> This is the fallout.
>>>>>>>
>>>>>>>>> You can't instantiate the omap_device early in the boot process like it was done up to
>>>>>>>>> now in the board file. You can only do that later in the boot process (for built-in
>>>>>>>>> cape drivers), or even after user-space has booted and the matching cape driver module
>>>>>>>>> has been loaded.
>>>>>>>>
>>>>>>>> Yes you can, just edit the .dts file for the extension
>>>>>>>> board you have connected. This stuff should be DT
>>>>>>>> only for sure, let's not even start adding platform_data
>>>>>>>> entries for that.
>>>>>>>>
>>>>>>>> The omap_device entries for the omap internal devices
>>>>>>>> will be created automatically during startup based on the
>>>>>>>> .dts. Note that you can set status = "disabled" for the
>>>>>>>> omap internal devices in the .dts file, the devices are
>>>>>>>> there in the hardware.
>>>>>>>>
>>>>>>>> If you are sure the extension boards are safely hot
>>>>>>>> pluggable, then all you need is some interface to enable
>>>>>>>> and disable devices after booting. But that should be
>>>>>>>> done in Linux generic way.
>>>>>>>>
>>>>>>>> So we should not export any omap_hwmod or omap_device
>>>>>>>> things, and want to keep it __init only, and local to
>>>>>>>> arch/arm/mach-omap2.
>>>>>>>>
>>>>>>>
>>>>>>> I disagree. This is not something that is handled by just
>>>>>>> editing the dts. The way it is handled, is in the Linux
>>>>>>> generic way, we have a proper bus, and the drivers as compiled
>>>>>>> as standalone file.
>>>>>>
>>>>>> when you have an actual bus, that'd be correct.
>>>>>
>>>>> What do you think capebus is? It is an actual bus that allows you
>>>>> to do so.
>>>>>
>>>>>>
>>>>>>> We're hitting a use case that wasn't there in omap until now.
>>>>>>>
>>>>>>> There a a whole bunch of conflicting capes. There's no
>>>>>>> way to instantiate them together. They must be instantiated
>>>>>>> only after their EEPROMs are read and they are matched
>>>>>>> to their corresponding cape drivers.
>>>>>>
>>>>>> why this requirement of instantiating them only after reading EEPROMs ?
>>>>>>
>>>>>> It's unnecessary to add that requirement, just do what Tony said
>>>>>> (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices
>>>>>> should be created automatically.
>>>>>>
>>>>>> The thing is that there is no such thing as a cape-device. The cape is
>>>>>> just a collection of I2C, 1-wire and SPI devices anyway. What we should
>>>>>> instantiate is bmp085, tls2550, sht21, instead of instantiating
>>>>>> beagle-bone-weather-cape.
>>>>>>
>>>>>> What's the problem in just instantiating all of those from bone.dts ?
>>>>>> Expose the EEPROMs to userland so whatever SW you guys have running on
>>>>>> the bone can figure out what features to expose to the SDK which the
>>>>>> user sees, but the kernel doesn't need to know that there is a
>>>>>> weather-cape attached to the bone.
>>>>>>
>>>>>
>>>>> The I2C/SPI devices are not a problem at all.
>>>>>
>>>>> Let me try to explain what the problem is, and why it all this
>>>>> is needed.
>>>>>
>>>>> First of all, capes may be relatively simple boards, which may function
>>>>> as a generic device - like the generic capes. They might not necessarily
>>>>> be simple. Some capes, for example the geiger cape have a number of
>>>>> components that perform a specific task; in this instance the driving
>>>>> circuit of the geiger tube and the event detector input. Other capes
>>>>> that are being designed now are even more complex, i.e. there's a
>>>>> radar cape, an fpga cape and so on. So for these kind of boards
>>>>> you will need a specific driver. That driver will probably use some
>>>>> generic-cape bits (like gpios, pwms, keys what-ever).
>>>>> But it will put them to use in the custom in-kernel driver in it's own
>>>>> way. You can't put that task to user-space, if it's ever slightly complex.
>>>>>
>>>>> So for really simple capes, after considerable pain you might, just
>>>>> might, dump the problem to user-space and try to make it work.
>>>>> People have tried that and it's a total pain. There is no way that this will
>>>>> work with anything more complex than a generic cape.
>>>>>
>>>>> Then there's the out of the box experience problem.
>>>>>
>>>>> What a customer that buys one of these boards along with a number of
>>>>> capes wants is to plug them, and have them work. You cannot have
>>>>> the DTS file activating all the drivers for each possible cape since
>>>>> they conflict; the pins that one SPI bus that one cape uses might be a
>>>>> PWM output for another, and so on.
>>>>>
>>>>> Asking the customer to edit the distro supplied kernel's dts and recompiling,
>>>>> while figuring out how to solve conflicts is not going to fly.
>>>>
>>>> Well you do not have to rebuild the kernel if you just want to update the DTS.
>>>> The way DT is done, the best you can do is to rely on the bootloader in your case to select the proper DTB. You should try to merge dynamically AMxx + beaglebone + capeXXX based on some EEPROM id.
>>>>
>>>
>>> That is what the capebus does. It inserts
>>
>> It inserts what?
>>
>>>> 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>

Well, at that time I guess people were not that aware of the DT limitation.
In fact at that time, this kind of stuff were done by bootloader.

But I'm quite sure uEFI will fix that :-)

The point being, there is indeed no proper solution as of today beside
the bootloader hack.

> 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 situation. But it gets a picture on the screen, blinks LEDs and does largely what the user expects.

As I told Panto, it is not like it is a straightforward problem. My
point is still valid, this is a generic issue that should not be fixed
using some capebus hack.

> With capebus we get:
>
> 1) da8xx-fb which lacks DT bindingsp[1] receives plaftorm data to match the LCD
> 2) the i2c sensors on the weathercape are registered
> 3) the one-wire bus on the weathercape gets registered
> 4) the LEDs on the lcd cape get registered5
> 5) the LED on the geigercape gets registered and adds a custom trigger
> 6) the ADC, which again, lacks DT bindings[2], receives plaftorm data and a custom IIO binding
> 7) pinctrl sets the pinmuxes for the above
>
> In other words: plug & play, even for devices with drivers that are still lacking DT support.
>
> 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?

Because, anyway, any new complex capes will require a new DTS to handle
it if it requires some parameters.
The whole issue is the lack of discoverable bus, and there is nothing
you can do to fix that.

> 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. (Cross)compiling a kernel is a bridge too far for 95% of the intended audience.

The whole point of DTS is that you don't have to recompile to describe a
new board. So why do you want to compile a kernel?

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

Fair enough, hacking boot loader sucks.

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

Then make it part of DT core.

If you do want a pure dynamic stuff that minimize rebuild kernel,
potentially loadable module and loadable DTB sub tree makes more sense
than the capebus infrastructure.

The whole point here is to be able to build a DT dynamically.

We can boot with the default one.

beaglebone.dts:
/{
i2c@0 {
status = "disabled";
};

spi@0 {
status = "disabled";
};

gmpc {
status = "disabled";
};
}

And then later load that one using a bone-cape driver that can detect
revision.

super-cape.dts:
{
i2c@0 {
toaster@42 {
blabla...
};
};

gmpc {
mega-fpga@42 {
blabla...
};
};
}

And then use the standard DT support to create later the platform_device
that does represent the new super-cape devices.

Regards,
Benoit

2012-11-02 08:43:45

by Pantelis Antoniou

[permalink] [raw]

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

Hi Benoit,

On Nov 2, 2012, at 10:15 AM, Cousson, Benoit wrote:

> On 11/1/2012 1:00 PM, 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.
>>
>> Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" <[email protected]> het volgende geschreven:
>>
>>> Hi Panto,
>>>
>>> On 11/1/2012 11:39 AM, Pantelis Antoniou wrote:
>>>> Hi Benoit,
>>>>
>>>> On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote:
>>>>
>>>>> On 11/1/2012 8:02 AM, Pantelis Antoniou wrote:
>>>>>> Hi Felibe,
>>>>>>
>>>>>> On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote:
>>>>>>>>> * Pantelis Antoniou <[email protected]> [121031 13:14]:
>>>>>>>>>> On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote:
>>>>>>>>>>>
>>>>>>>>>>> Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control
>>>>>>>>>>> could have an hwmod and thus must be handled by an omap_device.
>>>>>>>>>>>
>>>>>>>>>>> Any devices that is created later cannot be omap_device. The DT core
>>>>>>>>>>> will create regular platform_device for them.
>>>>>>>>>>>
>>>>>>>>>>> Since cape is an external board, it should have nothing to do with
>>>>>>>>>>> omap_device.
>>>>>>>>>>>
>>>>>>>>>>> Looking at your patch:
>>>>>>>>>>> da8xx-dt: Create da8xx DT adapter device
>>>>>>>>>>>
>>>>>>>>>>> I understand why you do that, but in fact that patch does not make sense
>>>>>>>>>>> to me :-(
>>>>>>>>>>>
>>>>>>>>>>> Why do you have to create an omap_device from the driver probe?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The problem is that capes are not external boards in the normal sense
>>>>>>>>>> as a PCI board is. In the PCI case the hardware that implements the
>>>>>>>>>> desired functionality is on the PCI board, while in the cape case the
>>>>>>>>>> hardware module is in the SoC. The cape most of the times is quite
>>>>>>>>>> simple and contains passive components, leds or some kind of I2C/SPI devices.
>>>>>>>>>
>>>>>>>>> Ah now I see, you're talking about the beaglebone extension
>>>>>>>>> boards :)
>>>>>>>>>
>>>>>>>>> The way to deal with those properly is to just edit the
>>>>>>>>> board .dts entry to include omap-beaglebone-cape-xyz.dtsi
>>>>>>>>> whatever.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is what is being done...
>>>>>>>> This is the fallout.
>>>>>>>>
>>>>>>>>>> You can't instantiate the omap_device early in the boot process like it was done up to
>>>>>>>>>> now in the board file. You can only do that later in the boot process (for built-in
>>>>>>>>>> cape drivers), or even after user-space has booted and the matching cape driver module
>>>>>>>>>> has been loaded.
>>>>>>>>>
>>>>>>>>> Yes you can, just edit the .dts file for the extension
>>>>>>>>> board you have connected. This stuff should be DT
>>>>>>>>> only for sure, let's not even start adding platform_data
>>>>>>>>> entries for that.
>>>>>>>>>
>>>>>>>>> The omap_device entries for the omap internal devices
>>>>>>>>> will be created automatically during startup based on the
>>>>>>>>> .dts. Note that you can set status = "disabled" for the
>>>>>>>>> omap internal devices in the .dts file, the devices are
>>>>>>>>> there in the hardware.
>>>>>>>>>
>>>>>>>>> If you are sure the extension boards are safely hot
>>>>>>>>> pluggable, then all you need is some interface to enable
>>>>>>>>> and disable devices after booting. But that should be
>>>>>>>>> done in Linux generic way.
>>>>>>>>>
>>>>>>>>> So we should not export any omap_hwmod or omap_device
>>>>>>>>> things, and want to keep it __init only, and local to
>>>>>>>>> arch/arm/mach-omap2.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I disagree. This is not something that is handled by just
>>>>>>>> editing the dts. The way it is handled, is in the Linux
>>>>>>>> generic way, we have a proper bus, and the drivers as compiled
>>>>>>>> as standalone file.
>>>>>>>
>>>>>>> when you have an actual bus, that'd be correct.
>>>>>>
>>>>>> What do you think capebus is? It is an actual bus that allows you
>>>>>> to do so.
>>>>>>
>>>>>>>
>>>>>>>> We're hitting a use case that wasn't there in omap until now.
>>>>>>>>
>>>>>>>> There a a whole bunch of conflicting capes. There's no
>>>>>>>> way to instantiate them together. They must be instantiated
>>>>>>>> only after their EEPROMs are read and they are matched
>>>>>>>> to their corresponding cape drivers.
>>>>>>>
>>>>>>> why this requirement of instantiating them only after reading EEPROMs ?
>>>>>>>
>>>>>>> It's unnecessary to add that requirement, just do what Tony said
>>>>>>> (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices
>>>>>>> should be created automatically.
>>>>>>>
>>>>>>> The thing is that there is no such thing as a cape-device. The cape is
>>>>>>> just a collection of I2C, 1-wire and SPI devices anyway. What we should
>>>>>>> instantiate is bmp085, tls2550, sht21, instead of instantiating
>>>>>>> beagle-bone-weather-cape.
>>>>>>>
>>>>>>> What's the problem in just instantiating all of those from bone.dts ?
>>>>>>> Expose the EEPROMs to userland so whatever SW you guys have running on
>>>>>>> the bone can figure out what features to expose to the SDK which the
>>>>>>> user sees, but the kernel doesn't need to know that there is a
>>>>>>> weather-cape attached to the bone.
>>>>>>>
>>>>>>
>>>>>> The I2C/SPI devices are not a problem at all.
>>>>>>
>>>>>> Let me try to explain what the problem is, and why it all this
>>>>>> is needed.
>>>>>>
>>>>>> First of all, capes may be relatively simple boards, which may function
>>>>>> as a generic device - like the generic capes. They might not necessarily
>>>>>> be simple. Some capes, for example the geiger cape have a number of
>>>>>> components that perform a specific task; in this instance the driving
>>>>>> circuit of the geiger tube and the event detector input. Other capes
>>>>>> that are being designed now are even more complex, i.e. there's a
>>>>>> radar cape, an fpga cape and so on. So for these kind of boards
>>>>>> you will need a specific driver. That driver will probably use some
>>>>>> generic-cape bits (like gpios, pwms, keys what-ever).
>>>>>> But it will put them to use in the custom in-kernel driver in it's own
>>>>>> way. You can't put that task to user-space, if it's ever slightly complex.
>>>>>>
>>>>>> So for really simple capes, after considerable pain you might, just
>>>>>> might, dump the problem to user-space and try to make it work.
>>>>>> People have tried that and it's a total pain. There is no way that this will
>>>>>> work with anything more complex than a generic cape.
>>>>>>
>>>>>> Then there's the out of the box experience problem.
>>>>>>
>>>>>> What a customer that buys one of these boards along with a number of
>>>>>> capes wants is to plug them, and have them work. You cannot have
>>>>>> the DTS file activating all the drivers for each possible cape since
>>>>>> they conflict; the pins that one SPI bus that one cape uses might be a
>>>>>> PWM output for another, and so on.
>>>>>>
>>>>>> Asking the customer to edit the distro supplied kernel's dts and recompiling,
>>>>>> while figuring out how to solve conflicts is not going to fly.
>>>>>
>>>>> Well you do not have to rebuild the kernel if you just want to update the DTS.
>>>>> The way DT is done, the best you can do is to rely on the bootloader in your case to select the proper DTB. You should try to merge dynamically AMxx + beaglebone + capeXXX based on some EEPROM id.
>>>>>
>>>>
>>>> That is what the capebus does. It inserts
>>>
>>> It inserts what?
>>>
>>>>> 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>
>
> Well, at that time I guess people were not that aware of the DT limitation.
> In fact at that time, this kind of stuff were done by bootloader.
>
> But I'm quite sure uEFI will fix that :-)
>
> The point being, there is indeed no proper solution as of today beside the bootloader hack.
>
>> 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 situation. But it gets a picture on the screen, blinks LEDs and does largely what the user expects.
>
> As I told Panto, it is not like it is a straightforward problem. My point is still valid, this is a generic issue that should not be fixed using some capebus hack.
>
>> With capebus we get:
>>
>> 1) da8xx-fb which lacks DT bindingsp[1] receives plaftorm data to match the LCD
>> 2) the i2c sensors on the weathercape are registered
>> 3) the one-wire bus on the weathercape gets registered
>> 4) the LEDs on the lcd cape get registered5
>> 5) the LED on the geigercape gets registered and adds a custom trigger
>> 6) the ADC, which again, lacks DT bindings[2], receives plaftorm data and a custom IIO binding
>> 7) pinctrl sets the pinmuxes for the above
>>
>> In other words: plug & play, even for devices with drivers that are still lacking DT support.
>>
>> 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?
>
> Because, anyway, any new complex capes will require a new DTS to handle it if it requires some parameters.
> The whole issue is the lack of discoverable bus, and there is nothing you can do to fix that.
>
>> 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. (Cross)compiling a kernel is a bridge too far for 95% of the intended audience.
>
> The whole point of DTS is that you don't have to recompile to describe a new board. So why do you want to compile a kernel?
>
>> 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.
>
> Fair enough, hacking boot loader sucks.
>
>> 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.
>
> Then make it part of DT core.
>
> If you do want a pure dynamic stuff that minimize rebuild kernel, potentially loadable module and loadable DTB sub tree makes more sense than the capebus infrastructure.
>
> The whole point here is to be able to build a DT dynamically.
>
> We can boot with the default one.
>
> beaglebone.dts:
> /{
> i2c@0 {
> status = "disabled";
> };
>
> spi@0 {
> status = "disabled";
> };
>
> gmpc {
> status = "disabled";
> };
> }
>
>
> And then later load that one using a bone-cape driver that can detect revision.
>
> super-cape.dts:
> {
> i2c@0 {
> toaster@42 {
> blabla...
> };
> };
>
> gmpc {
> mega-fpga@42 {
> blabla...
> };
> };
> }
>
> And then use the standard DT support to create later the platform_device that does represent the new super-cape devices.
>

We know this is the ideal case. In fact that's the long term goal and we had internal discussions about it.

DT is nowhere near being able to do it.

That would require the introduction of a DT object file format with aliases being capable to be
resolved dynamically. We're talking about major changes here in the way DT files are being compiled and
used in practice.

So yes, in an ideal world that would be great. We're nowhere near close today unfortunately.

Assuming that we do work on a DT object format, and that the runtime resolution mechanism is approved,
then I agree that this part of the capebus patches can be dropped and the functionality assumed by generic
DT core.

The question is that this will take time, with no guarantees that this would be acceptable from
the device tree maintainers. So I am putting them in the CC list, to see what they think about it.

> Regards,
> Benoit
>

Regards

-- Pantelis

2012-11-02 09:03:31

[permalink] [raw]

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

On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou
<[email protected]> wrote:
> On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:
>> Sure, so if we add data type supplementary properties to the tree to
>> indicate the data type as "indirect phandle", then kernel could refer
>> to the index in the got-like table to fetch the actual phandle address
>> (1-level of indirection), instead of directly using the address in the
>> data field.
>>
>
> I'm fine with this.

But if the data about phandles is already in the tree, then the need
for a GOT simply goes away. The phandles can be fixed up directly and
it is so much better because it works with existing parsing code after
the merge is applied.

g.

2012-11-06 13:55:12

by Pantelis Antoniou

[permalink] [raw]

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

Από το iPhone μου

6 Νοε 2012, 12:16, ο/η Grant Likely <[email protected]> έγραψε:

> On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou
> <[email protected]> wrote:
>> On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:
>>> Sure, so if we add data type supplementary properties to the tree to
>>> indicate the data type as "indirect phandle", then kernel could refer
>>> to the index in the got-like table to fetch the actual phandle address
>>> (1-level of indirection), instead of directly using the address in the
>>> data field.
>>
>> I'm fine with this.
>
> But if the data about phandles is already in the tree, then the need
> for a GOT simply goes away. The phandles can be fixed up directly and
> it is so much better because it works with existing parsing code after
> the merge is applied.
>

Either way works. It is your call after all.
I agree that your method is simpler.
> g.

Regards

-- Pantelis-