diff mbox

[1/5] capemgr: Beaglebone DT overlay based cape manager

Message ID 1357584666-17374-2-git-send-email-panto@antoniou-consulting.com (mailing list archive)
State New, archived
Headers show

Commit Message

Pantelis Antoniou Jan. 7, 2013, 6:51 p.m. UTC
A cape loader based on DT overlays and DT objects.

Beaglebone cape manager implementation.

Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
---
 arch/arm/mach-omap2/Kconfig            |    2 +
 drivers/misc/Kconfig                   |    2 +
 drivers/misc/Makefile                  |    1 +
 drivers/misc/cape/Kconfig              |    5 +
 drivers/misc/cape/Makefile             |    5 +
 drivers/misc/cape/beaglebone/Kconfig   |   11 +
 drivers/misc/cape/beaglebone/Makefile  |    5 +
 drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
 8 files changed, 1866 insertions(+)
 create mode 100644 drivers/misc/cape/Kconfig
 create mode 100644 drivers/misc/cape/Makefile
 create mode 100644 drivers/misc/cape/beaglebone/Kconfig
 create mode 100644 drivers/misc/cape/beaglebone/Makefile
 create mode 100644 drivers/misc/cape/beaglebone/capemgr.c

Comments

Tony Lindgren Jan. 7, 2013, 8:09 p.m. UTC | #1
* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
> A cape loader based on DT overlays and DT objects.
> 
> Beaglebone cape manager implementation.
> 
> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> ---
>  arch/arm/mach-omap2/Kconfig            |    2 +
>  drivers/misc/Kconfig                   |    2 +
>  drivers/misc/Makefile                  |    1 +
>  drivers/misc/cape/Kconfig              |    5 +
>  drivers/misc/cape/Makefile             |    5 +
>  drivers/misc/cape/beaglebone/Kconfig   |   11 +
>  drivers/misc/cape/beaglebone/Makefile  |    5 +
>  drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++

The driver should probably be in drivers/bus?

>  8 files changed, 1866 insertions(+)
>  create mode 100644 drivers/misc/cape/Kconfig
>  create mode 100644 drivers/misc/cape/Makefile
>  create mode 100644 drivers/misc/cape/beaglebone/Kconfig
>  create mode 100644 drivers/misc/cape/beaglebone/Makefile
>  create mode 100644 drivers/misc/cape/beaglebone/capemgr.c
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 41b581f..f0c2eab 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -18,6 +18,8 @@ config ARCH_OMAP2PLUS_TYPICAL
>  	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
>  	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
>  	select VFP
> +	select OF_OVERLAY
> +	select OF_RESOLVE
>  	help
>  	  Compile a kernel suitable for booting most boards

You should just make the driver depend on OF_OVERLAY and
OF_RESOLVE as most SoCs won't need this. Then we can select
it in the omap2plus_defconfig.

Regards,

Tony  
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pantelis Antoniou Jan. 7, 2013, 8:13 p.m. UTC | #2
Hi Tony,

On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
>> A cape loader based on DT overlays and DT objects.
>> 
>> Beaglebone cape manager implementation.
>> 
>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
>> ---
>> arch/arm/mach-omap2/Kconfig            |    2 +
>> drivers/misc/Kconfig                   |    2 +
>> drivers/misc/Makefile                  |    1 +
>> drivers/misc/cape/Kconfig              |    5 +
>> drivers/misc/cape/Makefile             |    5 +
>> drivers/misc/cape/beaglebone/Kconfig   |   11 +
>> drivers/misc/cape/beaglebone/Makefile  |    5 +
>> drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
> 
> The driver should probably be in drivers/bus?
> 

It was a bus on the previous iteration and there was a flame storm of epic proportions.

It is not a bus at all now, it's just a device loader; there are no
bus constructs at all. I am at a loss to classify it really, so drivers/misc
where every misfit ends up sounded OK.

I'm open to suggestions though.

>> 8 files changed, 1866 insertions(+)
>> create mode 100644 drivers/misc/cape/Kconfig
>> create mode 100644 drivers/misc/cape/Makefile
>> create mode 100644 drivers/misc/cape/beaglebone/Kconfig
>> create mode 100644 drivers/misc/cape/beaglebone/Makefile
>> create mode 100644 drivers/misc/cape/beaglebone/capemgr.c
>> 
>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> index 41b581f..f0c2eab 100644
>> --- a/arch/arm/mach-omap2/Kconfig
>> +++ b/arch/arm/mach-omap2/Kconfig
>> @@ -18,6 +18,8 @@ config ARCH_OMAP2PLUS_TYPICAL
>> 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
>> 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
>> 	select VFP
>> +	select OF_OVERLAY
>> +	select OF_RESOLVE
>> 	help
>> 	  Compile a kernel suitable for booting most boards
> 
> You should just make the driver depend on OF_OVERLAY and
> OF_RESOLVE as most SoCs won't need this. Then we can select
> it in the omap2plus_defconfig.
> 

OK

> Regards,
> 
> Tony  

Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Jan. 7, 2013, 8:23 p.m. UTC | #3
* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:16]:
> Hi Tony,
> 
> On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote:
> 
> > * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
> >> A cape loader based on DT overlays and DT objects.
> >> 
> >> Beaglebone cape manager implementation.
> >> 
> >> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> >> ---
> >> arch/arm/mach-omap2/Kconfig            |    2 +
> >> drivers/misc/Kconfig                   |    2 +
> >> drivers/misc/Makefile                  |    1 +
> >> drivers/misc/cape/Kconfig              |    5 +
> >> drivers/misc/cape/Makefile             |    5 +
> >> drivers/misc/cape/beaglebone/Kconfig   |   11 +
> >> drivers/misc/cape/beaglebone/Makefile  |    5 +
> >> drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
> > 
> > The driver should probably be in drivers/bus?
> > 
> 
> It was a bus on the previous iteration and there was a flame storm of epic proportions.

Heh :)
 
> It is not a bus at all now, it's just a device loader; there are no
> bus constructs at all. I am at a loss to classify it really, so drivers/misc
> where every misfit ends up sounded OK.

Right..

> I'm open to suggestions though.

Well how about split it to an eeprom driver, and Linux generic
device loader parts?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pantelis Antoniou Jan. 7, 2013, 8:26 p.m. UTC | #4
Hi Tony,

On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:16]:
>> Hi Tony,
>> 
>> On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote:
>> 
>>> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 10:54]:
>>>> A cape loader based on DT overlays and DT objects.
>>>> 
>>>> Beaglebone cape manager implementation.
>>>> 
>>>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
>>>> ---
>>>> arch/arm/mach-omap2/Kconfig            |    2 +
>>>> drivers/misc/Kconfig                   |    2 +
>>>> drivers/misc/Makefile                  |    1 +
>>>> drivers/misc/cape/Kconfig              |    5 +
>>>> drivers/misc/cape/Makefile             |    5 +
>>>> drivers/misc/cape/beaglebone/Kconfig   |   11 +
>>>> drivers/misc/cape/beaglebone/Makefile  |    5 +
>>>> drivers/misc/cape/beaglebone/capemgr.c | 1835 ++++++++++++++++++++++++++++++++
>>> 
>>> The driver should probably be in drivers/bus?
>>> 
>> 
>> It was a bus on the previous iteration and there was a flame storm of epic proportions.
> 
> Heh :)
> 
>> It is not a bus at all now, it's just a device loader; there are no
>> bus constructs at all. I am at a loss to classify it really, so drivers/misc
>> where every misfit ends up sounded OK.
> 
> Right..
> 
>> I'm open to suggestions though.
> 
> Well how about split it to an eeprom driver, and Linux generic
> device loader parts?
> 

All that's left is the eeprom driver (accessor) and calls to the 
generic DT overlay constructs. 

If you caught on the previous patchset about DT overlays it should be
clear.

So it is split along those lines already.


> Regards,
> 
> Tony

Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Jan. 7, 2013, 8:35 p.m. UTC | #5
* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:29]:
> On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:
> > 
> > Well how about split it to an eeprom driver, and Linux generic
> > device loader parts?
> > 
> 
> All that's left is the eeprom driver (accessor) and calls to the 
> generic DT overlay constructs. 
>
> If you caught on the previous patchset about DT overlays it should be
> clear.
> 
> So it is split along those lines already.

Hmm I was thinking something like this:

drivers/base/device-loader.c
drivers/misc/eeprom/beaglebone-cape.c

Then you may be able to just load the configuration for it
from a .dts file and maybe no hardware specific glue is even
needed.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pantelis Antoniou Jan. 7, 2013, 8:40 p.m. UTC | #6
Hi Tony,

On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote:

> * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:29]:
>> On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:
>>> 
>>> Well how about split it to an eeprom driver, and Linux generic
>>> device loader parts?
>>> 
>> 
>> All that's left is the eeprom driver (accessor) and calls to the 
>> generic DT overlay constructs. 
>> 
>> If you caught on the previous patchset about DT overlays it should be
>> clear.
>> 
>> So it is split along those lines already.
> 
> Hmm I was thinking something like this:
> 
> drivers/base/device-loader.c
> drivers/misc/eeprom/beaglebone-cape.c
> 
> Then you may be able to just load the configuration for it
> from a .dts file and maybe no hardware specific glue is even
> needed.
> 

At the end of the line, some kind of hardware glue is going to be needed.

I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
in the beagleboard), it is a bit premature to think about making it overly
general, besides the part that are obviously part of the infrastructure 
(like the DT overlay stuff).

What I'm getting at, is that we need some user experience about this, before
going away and creating structure out of possible misconception about the uses. 

> Regards,
> 
> Tony

Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Jan. 7, 2013, 9:05 p.m. UTC | #7
* Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:43]:
> Hi Tony,
> 
> On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote:
> 
> > * Pantelis Antoniou <panto@antoniou-consulting.com> [130107 12:29]:
> >> On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote:
> >>> 
> >>> Well how about split it to an eeprom driver, and Linux generic
> >>> device loader parts?
> >>> 
> >> 
> >> All that's left is the eeprom driver (accessor) and calls to the 
> >> generic DT overlay constructs. 
> >> 
> >> If you caught on the previous patchset about DT overlays it should be
> >> clear.
> >> 
> >> So it is split along those lines already.
> > 
> > Hmm I was thinking something like this:
> > 
> > drivers/base/device-loader.c
> > drivers/misc/eeprom/beaglebone-cape.c
> > 
> > Then you may be able to just load the configuration for it
> > from a .dts file and maybe no hardware specific glue is even
> > needed.
> > 
> 
> At the end of the line, some kind of hardware glue is going to be needed.
> 
> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> in the beagleboard), it is a bit premature to think about making it overly
> general, besides the part that are obviously part of the infrastructure 
> (like the DT overlay stuff).
> 
> What I'm getting at, is that we need some user experience about this, before
> going away and creating structure out of possible misconception about the uses. 

IMHO stuff like this will be needed by many SoCs. Some examples of similar
things for omaps that have eventually become generic frameworks have been
the clock framework, USB OTG support, runtime PM, pinmux framework and
so on.

So I suggest a minimal generic API from the start as that will make things
a lot easier in the long run.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Jan. 7, 2013, 9:35 p.m. UTC | #8
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)

On Monday 07 January 2013, Tony Lindgren wrote:
> > 
> > At the end of the line, some kind of hardware glue is going to be needed.
> > 
> > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > in the beagleboard), it is a bit premature to think about making it overly
> > general, besides the part that are obviously part of the infrastructure 
> > (like the DT overlay stuff).
> > 
> > What I'm getting at, is that we need some user experience about this, before
> > going away and creating structure out of possible misconception about the uses. 
> 
> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> things for omaps that have eventually become generic frameworks have been
> the clock framework, USB OTG support, runtime PM, pinmux framework and
> so on.
> 
> So I suggest a minimal generic API from the start as that will make things
> a lot easier in the long run.

I agree. The ux500 platform already has the concept of "user interface boards",
which currently is not well integrated into devicetree. I believe Sascha
mentioned that Pengutronix had been shipping some other systems with add-on
boards and generating device tree binaries from source for each combination.

Ideally, both of the above should be able to use the same DT overlay logic
as BeagleBone, and I'm sure there are more of those.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pantelis Antoniou Jan. 8, 2013, 9:15 a.m. UTC | #9
Hi Arnd,

On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:

> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
>>> 
>>> At the end of the line, some kind of hardware glue is going to be needed.
>>> 
>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>> in the beagleboard), it is a bit premature to think about making it overly
>>> general, besides the part that are obviously part of the infrastructure 
>>> (like the DT overlay stuff).
>>> 
>>> What I'm getting at, is that we need some user experience about this, before
>>> going away and creating structure out of possible misconception about the uses. 
>> 
>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>> things for omaps that have eventually become generic frameworks have been
>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>> so on.
>> 
>> So I suggest a minimal generic API from the start as that will make things
>> a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.
> 
> Ideally, both of the above should be able to use the same DT overlay logic
> as BeagleBone, and I'm sure there are more of those.
> 
> 	Arnd

Hmm, I see. 

I will need some more information about the interface of the 'user interface boards'.
I.e. how is the board identified, what is typically present on those boards, etc.

Can we get some input by the owner of other similar hardware? I know the FPGA
people have similar requirements for example. There are other people that are hitting
problems getting DT to work with their systems, like the V4L people with the order
of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
cleanly solved by the overlay being contained in the V4L device node and applied just before
the device is probed.

In the meantime it would be better to wait until we have some ack from the maintainers
of the core subsystems about what they think.
 
Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Guennadi Liakhovetski Jan. 8, 2013, 9:51 a.m. UTC | #10
(adding linux-media ML to cc)

Hi Pantelis

On Tue, 8 Jan 2013, Pantelis Antoniou wrote:

> Hi Arnd,
> 
> On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
> 
> > (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> > 
> > On Monday 07 January 2013, Tony Lindgren wrote:
> >>> 
> >>> At the end of the line, some kind of hardware glue is going to be needed.
> >>> 
> >>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>> in the beagleboard), it is a bit premature to think about making it overly
> >>> general, besides the part that are obviously part of the infrastructure 
> >>> (like the DT overlay stuff).
> >>> 
> >>> What I'm getting at, is that we need some user experience about this, before
> >>> going away and creating structure out of possible misconception about the uses. 
> >> 
> >> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >> things for omaps that have eventually become generic frameworks have been
> >> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >> so on.
> >> 
> >> So I suggest a minimal generic API from the start as that will make things
> >> a lot easier in the long run.
> > 
> > I agree. The ux500 platform already has the concept of "user interface boards",
> > which currently is not well integrated into devicetree. I believe Sascha
> > mentioned that Pengutronix had been shipping some other systems with add-on
> > boards and generating device tree binaries from source for each combination.
> > 
> > Ideally, both of the above should be able to use the same DT overlay logic
> > as BeagleBone, and I'm sure there are more of those.
> > 
> > 	Arnd
> 
> Hmm, I see. 
> 
> I will need some more information about the interface of the 'user interface boards'.
> I.e. how is the board identified, what is typically present on those boards, etc.
> 
> Can we get some input by the owner of other similar hardware? I know the FPGA
> people have similar requirements for example. There are other people that are hitting
> problems getting DT to work with their systems, like the V4L people with the order
> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> cleanly solved by the overlay being contained in the V4L device node and applied just before
> the device is probed.

You probably mean these related V4L patches: 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 
that base upon of asynchronous V4L2 subdevice probing, referenced above. 
Yes, V4L DT nodes, as documented in 
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 
contain "port" and "endpoint" nodes, that describe the configuration of 
the hardware port and link to devices, connected to it. Not sure how well 
this would work with DT overlays, because endpoint nodes on both sides of 
the video data bus contain references to the other side and I don't know 
whether and how these can be created and / or updated at run-time. 
Otherwise, yes, the approach that we're currently developing on V4L allows 
us to build video data pipelines independent of (sub)device driver probing 
order.

Thanks
Guennadi

> In the meantime it would be better to wait until we have some ack from the maintainers
> of the core subsystems about what they think.
>  
> Regards
> 
> -- Pantelis

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Jan. 8, 2013, 10 a.m. UTC | #11
> >>> At the end of the line, some kind of hardware glue is going to be needed.
> >>> 
> >>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>> in the beagleboard), it is a bit premature to think about making it overly
> >>> general, besides the part that are obviously part of the infrastructure 
> >>> (like the DT overlay stuff).
> >>> 
> >>> What I'm getting at, is that we need some user experience about this, before
> >>> going away and creating structure out of possible misconception about the uses. 
> >> 
> >> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >> things for omaps that have eventually become generic frameworks have been
> >> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >> so on.
> >> 
> >> So I suggest a minimal generic API from the start as that will make things
> >> a lot easier in the long run.
> > 
> > I agree. The ux500 platform already has the concept of "user interface boards",
> > which currently is not well integrated into devicetree. I believe Sascha
> > mentioned that Pengutronix had been shipping some other systems with add-on
> > boards and generating device tree binaries from source for each combination.
> > 
> > Ideally, both of the above should be able to use the same DT overlay logic
> > as BeagleBone, and I'm sure there are more of those.
> 
> Hmm, I see. 
> 
> I will need some more information about the interface of the 'user interface boards'.
> I.e. how is the board identified, what is typically present on those boards, etc.

User Interface Boards are mearly removable PCBs which are interchangeable
amongst various hardware platforms. They are connected via numerous
connectors which carry all sorts of different data links; i2c, spi, rs232,
etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
pad, leds, jumpers, switches and a bunch of sensors.

You can find a small example of how we interface to these by viewing
'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
currently include it as a *.dtsi from a platform's dts file.

> Can we get some input by the owner of other similar hardware? I know the FPGA
> people have similar requirements for example. There are other people that are hitting
> problems getting DT to work with their systems, like the V4L people with the order
> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> cleanly solved by the overlay being contained in the V4L device node and applied just before
> the device is probed.
> 
> In the meantime it would be better to wait until we have some ack from the maintainers
> of the core subsystems about what they think.
>  
> Regards
> 
> -- Pantelis
>
Pantelis Antoniou Jan. 8, 2013, 10:07 a.m. UTC | #12
Hi Guennadi,

On Jan 8, 2013, at 11:51 AM, Guennadi Liakhovetski wrote:

> (adding linux-media ML to cc)
> 
> Hi Pantelis
> 
> On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
> 
>> Hi Arnd,
>> 
>> On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
>> 
>>> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
>>> 
>>> On Monday 07 January 2013, Tony Lindgren wrote:
>>>>> 
>>>>> At the end of the line, some kind of hardware glue is going to be needed.
>>>>> 
>>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>>>> in the beagleboard), it is a bit premature to think about making it overly
>>>>> general, besides the part that are obviously part of the infrastructure 
>>>>> (like the DT overlay stuff).
>>>>> 
>>>>> What I'm getting at, is that we need some user experience about this, before
>>>>> going away and creating structure out of possible misconception about the uses. 
>>>> 
>>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>>>> things for omaps that have eventually become generic frameworks have been
>>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>>>> so on.
>>>> 
>>>> So I suggest a minimal generic API from the start as that will make things
>>>> a lot easier in the long run.
>>> 
>>> I agree. The ux500 platform already has the concept of "user interface boards",
>>> which currently is not well integrated into devicetree. I believe Sascha
>>> mentioned that Pengutronix had been shipping some other systems with add-on
>>> boards and generating device tree binaries from source for each combination.
>>> 
>>> Ideally, both of the above should be able to use the same DT overlay logic
>>> as BeagleBone, and I'm sure there are more of those.
>>> 
>>> 	Arnd
>> 
>> Hmm, I see. 
>> 
>> I will need some more information about the interface of the 'user interface boards'.
>> I.e. how is the board identified, what is typically present on those boards, etc.
>> 
>> Can we get some input by the owner of other similar hardware? I know the FPGA
>> people have similar requirements for example. There are other people that are hitting
>> problems getting DT to work with their systems, like the V4L people with the order
>> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
>> cleanly solved by the overlay being contained in the V4L device node and applied just before
>> the device is probed.
> 
> You probably mean these related V4L patches: 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 
> that base upon of asynchronous V4L2 subdevice probing, referenced above. 
> Yes, V4L DT nodes, as documented in 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 
> contain "port" and "endpoint" nodes, that describe the configuration of 
> the hardware port and link to devices, connected to it. Not sure how well 
> this would work with DT overlays, because endpoint nodes on both sides of 
> the video data bus contain references to the other side and I don't know 
> whether and how these can be created and / or updated at run-time. 
> Otherwise, yes, the approach that we're currently developing on V4L allows 
> us to build video data pipelines independent of (sub)device driver probing 
> order.
> 

I'm not very well versed at the V4L intricacies, and correct me if I got it wrong,
but it seems like you have the  problem on needing to probe a bunch of devices only after 
the parent device has been probed successfully. 
Your async subdevice probing method seems to be doing this.

It might be simpler to do something like this:

v4ldevice {
	compatible = "foo,v4ldev";
	...
	overlay {
		fragment@0 {
			target = <&i2c0>;
			__overlay__ {
				...
				/* i2c devices */
			};
		};
		fragment@0 {
			target = <&ocp>;
			__overlay__ {
				..
				/* platform devices */
			};
		};
		...
	}:
};

And in the probe of the v4ldev apply the overlay. The i2c devices will end up in the
i2c node, the platform devices to the ocp node, etc, and will be registered.

There is nothing preventing the overlay being in a part of the board dts file. 
You will need to do a resolve pass for the phandles, but it's not insurmountable IMO.

Regards

-- Pantelis

> Thanks
> Guennadi
> 
>> In the meantime it would be better to wait until we have some ack from the maintainers
>> of the core subsystems about what they think.
>> 
>> Regards
>> 
>> -- Pantelis
> 
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pantelis Antoniou Jan. 8, 2013, 10:10 a.m. UTC | #13
Hi Lee,

On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:

>>>>> At the end of the line, some kind of hardware glue is going to be needed.
>>>>> 
>>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
>>>>> in the beagleboard), it is a bit premature to think about making it overly
>>>>> general, besides the part that are obviously part of the infrastructure 
>>>>> (like the DT overlay stuff).
>>>>> 
>>>>> What I'm getting at, is that we need some user experience about this, before
>>>>> going away and creating structure out of possible misconception about the uses. 
>>>> 
>>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
>>>> things for omaps that have eventually become generic frameworks have been
>>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
>>>> so on.
>>>> 
>>>> So I suggest a minimal generic API from the start as that will make things
>>>> a lot easier in the long run.
>>> 
>>> I agree. The ux500 platform already has the concept of "user interface boards",
>>> which currently is not well integrated into devicetree. I believe Sascha
>>> mentioned that Pengutronix had been shipping some other systems with add-on
>>> boards and generating device tree binaries from source for each combination.
>>> 
>>> Ideally, both of the above should be able to use the same DT overlay logic
>>> as BeagleBone, and I'm sure there are more of those.
>> 
>> Hmm, I see. 
>> 
>> I will need some more information about the interface of the 'user interface boards'.
>> I.e. how is the board identified, what is typically present on those boards, etc.
> 
> User Interface Boards are mearly removable PCBs which are interchangeable
> amongst various hardware platforms. They are connected via numerous
> connectors which carry all sorts of different data links; i2c, spi, rs232,
> etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> pad, leds, jumpers, switches and a bunch of sensors.
> 
> You can find a small example of how we interface to these by viewing
> 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> currently include it as a *.dtsi from a platform's dts file.

I see. What I'm asking about is whether there's a method where you can read
an EEPROM, or some GPIO code combination where I can find out what kind of board
is plugged each time.

If there is not, there is no way to automatically load the overlays; you can always
use the kernel command line, or have the a user space application to request the loading
of a specific board's overlay.

Regards

-- Pantelis

> 
>> Can we get some input by the owner of other similar hardware? I know the FPGA
>> people have similar requirements for example. There are other people that are hitting
>> problems getting DT to work with their systems, like the V4L people with the order
>> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
>> cleanly solved by the overlay being contained in the V4L device node and applied just before
>> the device is probed.
>> 
>> In the meantime it would be better to wait until we have some ack from the maintainers
>> of the core subsystems about what they think.
>> 
>> Regards
>> 
>> -- Pantelis
>> 
> 
> -- 
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Jan. 8, 2013, 10:48 a.m. UTC | #14
On Tue, 08 Jan 2013, Pantelis Antoniou wrote:

> Hi Lee,
> 
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> 
> >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> >>>>> 
> >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>>>> in the beagleboard), it is a bit premature to think about making it overly
> >>>>> general, besides the part that are obviously part of the infrastructure 
> >>>>> (like the DT overlay stuff).
> >>>>> 
> >>>>> What I'm getting at, is that we need some user experience about this, before
> >>>>> going away and creating structure out of possible misconception about the uses. 
> >>>> 
> >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >>>> things for omaps that have eventually become generic frameworks have been
> >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >>>> so on.
> >>>> 
> >>>> So I suggest a minimal generic API from the start as that will make things
> >>>> a lot easier in the long run.
> >>> 
> >>> I agree. The ux500 platform already has the concept of "user interface boards",
> >>> which currently is not well integrated into devicetree. I believe Sascha
> >>> mentioned that Pengutronix had been shipping some other systems with add-on
> >>> boards and generating device tree binaries from source for each combination.
> >>> 
> >>> Ideally, both of the above should be able to use the same DT overlay logic
> >>> as BeagleBone, and I'm sure there are more of those.
> >> 
> >> Hmm, I see. 
> >> 
> >> I will need some more information about the interface of the 'user interface boards'.
> >> I.e. how is the board identified, what is typically present on those boards, etc.
> > 
> > User Interface Boards are mearly removable PCBs which are interchangeable
> > amongst various hardware platforms. They are connected via numerous
> > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > pad, leds, jumpers, switches and a bunch of sensors.
> > 
> > You can find a small example of how we interface to these by viewing
> > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > currently include it as a *.dtsi from a platform's dts file.
> 
> I see. What I'm asking about is whether there's a method where you can read
> an EEPROM, or some GPIO code combination where I can find out what kind of board
> is plugged each time.
> 
> If there is not, there is no way to automatically load the overlays; you can always
> use the kernel command line, or have the a user space application to request the loading
> of a specific board's overlay.

Unfortunately, there is no way to probe the UIBs. :(

> >> Can we get some input by the owner of other similar hardware? I know the FPGA
> >> people have similar requirements for example. There are other people that are hitting
> >> problems getting DT to work with their systems, like the V4L people with the order
> >> of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is
> >> cleanly solved by the overlay being contained in the V4L device node and applied just before
> >> the device is probed.
> >> 
> >> In the meantime it would be better to wait until we have some ack from the maintainers
> >> of the core subsystems about what they think.
Sascha Hauer Jan. 8, 2013, 11:14 a.m. UTC | #15
On Mon, Jan 07, 2013 at 09:35:04PM +0000, Arnd Bergmann wrote:
> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
> > > 
> > > At the end of the line, some kind of hardware glue is going to be needed.
> > > 
> > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > > in the beagleboard), it is a bit premature to think about making it overly
> > > general, besides the part that are obviously part of the infrastructure 
> > > (like the DT overlay stuff).
> > > 
> > > What I'm getting at, is that we need some user experience about this, before
> > > going away and creating structure out of possible misconception about the uses. 
> > 
> > IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > things for omaps that have eventually become generic frameworks have been
> > the clock framework, USB OTG support, runtime PM, pinmux framework and
> > so on.
> > 
> > So I suggest a minimal generic API from the start as that will make things
> > a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.

What we have is usually CPU modules which can have different base
boards. Usually they are not detectable by software. Right now we
normally use a baseboard dts which includes a board dtd which then
includes the SoC dtsi. This works quite well on dtc level.

For us overlay dts become interesting when it comes to all the little
variants of the boards, like for example different displays, different
touchscreens,...

Sascha
Arnd Bergmann Jan. 8, 2013, 12:12 p.m. UTC | #16
On Tuesday 08 January 2013, Lee Jones wrote:
> > If there is not, there is no way to automatically load the overlays; you can always
> > use the kernel command line, or have the a user space application to request the loading
> > of a specific board's overlay.
> 
> Unfortunately, there is no way to probe the UIBs. :(

I thought that some of the newer UIBs had it, just not the old ones.
As Pantelis says, we could at least detect the ones that have an EEPROM
on them, and use a command line option or device tree attribute for the others.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pantelis Antoniou Jan. 8, 2013, 1:26 p.m. UTC | #17
Hi Arnd,

On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:

> On Tuesday 08 January 2013, Lee Jones wrote:
>>> If there is not, there is no way to automatically load the overlays; you can always
>>> use the kernel command line, or have the a user space application to request the loading
>>> of a specific board's overlay.
>> 
>> Unfortunately, there is no way to probe the UIBs. :(
> 
> I thought that some of the newer UIBs had it, just not the old ones.
> As Pantelis says, we could at least detect the ones that have an EEPROM
> on them, and use a command line option or device tree attribute for the others.
> 
> 	Arnd

So I gather the new ones have an eeprom?

Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Jan. 8, 2013, 4:12 p.m. UTC | #18
On Tuesday 08 January 2013, Pantelis Antoniou wrote:
> On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
> 
> > On Tuesday 08 January 2013, Lee Jones wrote:
> >>> If there is not, there is no way to automatically load the overlays; you can always
> >>> use the kernel command line, or have the a user space application to request the loading
> >>> of a specific board's overlay.
> >> 
> >> Unfortunately, there is no way to probe the UIBs. :(
> > 
> > I thought that some of the newer UIBs had it, just not the old ones.
> > As Pantelis says, we could at least detect the ones that have an EEPROM
> > on them, and use a command line option or device tree attribute for the others.
> > 
> >       Arnd
> 
> So I gather the new ones have an eeprom?

I don't remember the details unfortunately. Lee should be the one who can find out.
IIRC there was at least a single integeger number on them.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Jan. 9, 2013, 8:11 a.m. UTC | #19
On Tue, 08 Jan 2013, Arnd Bergmann wrote:

> On Tuesday 08 January 2013, Pantelis Antoniou wrote:
> > On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
> > 
> > > On Tuesday 08 January 2013, Lee Jones wrote:
> > >>> If there is not, there is no way to automatically load the overlays; you can always
> > >>> use the kernel command line, or have the a user space application to request the loading
> > >>> of a specific board's overlay.
> > >> 
> > >> Unfortunately, there is no way to probe the UIBs. :(
> > > 
> > > I thought that some of the newer UIBs had it, just not the old ones.
> > > As Pantelis says, we could at least detect the ones that have an EEPROM
> > > on them, and use a command line option or device tree attribute for the others.
> > > 
> > >       Arnd
> > 
> > So I gather the new ones have an eeprom?
> 
> I don't remember the details unfortunately. Lee should be the one who can find out.
> IIRC there was at least a single integeger number on them.

Not as far as I can remember. There was (is?) a crude method of
identifying UIBs, but attempting to obtain certain I2C lines and
testing which ones were accessible. However, if there is an issue
with I2C, the wrong UIB was 'probed'.
Linus Walleij Jan. 9, 2013, 8:29 a.m. UTC | #20
On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 08 Jan 2013, Arnd Bergmann wrote:
>
>> On Tuesday 08 January 2013, Pantelis Antoniou wrote:
>> > On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
>> >
>> > > On Tuesday 08 January 2013, Lee Jones wrote:
>> > >>> If there is not, there is no way to automatically load the overlays; you can always
>> > >>> use the kernel command line, or have the a user space application to request the loading
>> > >>> of a specific board's overlay.
>> > >>
>> > >> Unfortunately, there is no way to probe the UIBs. :(
>> > >
>> > > I thought that some of the newer UIBs had it, just not the old ones.
>> > > As Pantelis says, we could at least detect the ones that have an EEPROM
>> > > on them, and use a command line option or device tree attribute for the others.
>> > >
>> > >       Arnd
>> >
>> > So I gather the new ones have an eeprom?
>>
>> I don't remember the details unfortunately. Lee should be the one who can find out.
>> IIRC there was at least a single integeger number on them.
>
> Not as far as I can remember. There was (is?) a crude method of
> identifying UIBs, but attempting to obtain certain I2C lines and
> testing which ones were accessible. However, if there is an issue
> with I2C, the wrong UIB was 'probed'.

Right, so the UIBs had different GPIO expanders on some I2C addresses,
so we attempt to communicate with the expander to see if it's board type A,
and if it doesn't respond it's deemed to be board type B.

This is the code:
arch/arm/mach-ux500/board-mop500-uib.c

/*
 * Detect the UIB attached based on the presence or absence of i2c devices.
 */
int __init mop500_uib_init(void)
{
        struct uib *uib = mop500_uib;
        struct i2c_adapter *i2c0;
        int ret;

        if (!cpu_is_u8500_family())
                return -ENODEV;

        if (uib) {
                __mop500_uib_init(uib, "from uib= boot argument");
                return 0;
        }

        i2c0 = i2c_get_adapter(0);
        if (!i2c0) {
                __mop500_uib_init(&mop500_uibs[STUIB],
                                "fallback, could not get i2c0");
                return -ENODEV;
        }

        /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */
        ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0,
                        I2C_SMBUS_QUICK, NULL);
        i2c_put_adapter(i2c0);

        if (ret == 0)
                uib = &mop500_uibs[U8500UIB];
        else
                uib = &mop500_uibs[STUIB];

        __mop500_uib_init(uib, "detected");

        return 0;
}

Not elegant but better than e.g. passing a kernel command line option.

As you say it has the downside of detecting the wrong UIB if there is
some (other) problem with the I2C block. But in that case the system is
likely borked anyway so I wonder if it matters...

Even with the device tree approach we'd be into trouble if say, the UIB
was unplugged (which is perfectly possible). The device tree cannot
detect that.

The larger question is how to handle, at runtime, hardware that may
or may not be present, in a device tree world.

Compare this other case: the Integrator has pluggable daughterboards,
(called LMs, logic modules) and in that case we have specific registers
to detect them, and register the daughter board on this specific bus
that Russell came up with in arch/arm/mach-integrator/lm.c,
the actual board detection is in arch/arm/mach-integrator/integrator_ap.c:

static void __init ap_init(void)
{
        unsigned long sc_dec;
        int i;

        platform_device_register(&cfi_flash_device);

        sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
        for (i = 0; i < 4; i++) {
                struct lm_device *lmdev;

                if ((sc_dec & (16 << i)) == 0)
                        continue;

                lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
                if (!lmdev)
                        continue;

                lmdev->resource.start = 0xc0000000 + 0x10000000 * i;
                lmdev->resource.end = lmdev->resource.start + 0x0fffffff;
                lmdev->resource.flags = IORESOURCE_MEM;
                lmdev->irq = IRQ_AP_EXPINT0 + i;
                lmdev->id = i;

                lm_device_register(lmdev);
        }

        integrator_init(false);
}

In this case I think the autodetect is so nice that device tree probing
is mostly pointless. If it wasn't for the fact that we get a
cross-depenency to defined interrupts and clocks and whatever that
are coming from the device tree. Which is where DT shows its
all-or-nothing face.

So to get an elegant DT probing in this case I *guess* the right thing
to do is to dynamically add nodes to the device tree from the board
code, or have all alternatives inside the DT marked "disable" and then
mark them as "okay" from the board code by modifying the DT at
runtime.

Ideas welcome.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Grant Likely March 26, 2013, 4:16 p.m. UTC | #21
On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
> Hi Lee,
> 
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> 
> >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> >>>>> 
> >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> >>>>> in the beagleboard), it is a bit premature to think about making it overly
> >>>>> general, besides the part that are obviously part of the infrastructure 
> >>>>> (like the DT overlay stuff).
> >>>>> 
> >>>>> What I'm getting at, is that we need some user experience about this, before
> >>>>> going away and creating structure out of possible misconception about the uses. 
> >>>> 
> >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> >>>> things for omaps that have eventually become generic frameworks have been
> >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> >>>> so on.
> >>>> 
> >>>> So I suggest a minimal generic API from the start as that will make things
> >>>> a lot easier in the long run.
> >>> 
> >>> I agree. The ux500 platform already has the concept of "user interface boards",
> >>> which currently is not well integrated into devicetree. I believe Sascha
> >>> mentioned that Pengutronix had been shipping some other systems with add-on
> >>> boards and generating device tree binaries from source for each combination.
> >>> 
> >>> Ideally, both of the above should be able to use the same DT overlay logic
> >>> as BeagleBone, and I'm sure there are more of those.
> >> 
> >> Hmm, I see. 
> >> 
> >> I will need some more information about the interface of the 'user interface boards'.
> >> I.e. how is the board identified, what is typically present on those boards, etc.
> > 
> > User Interface Boards are mearly removable PCBs which are interchangeable
> > amongst various hardware platforms. They are connected via numerous
> > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > pad, leds, jumpers, switches and a bunch of sensors.
> > 
> > You can find a small example of how we interface to these by viewing
> > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > currently include it as a *.dtsi from a platform's dts file.
> 
> I see. What I'm asking about is whether there's a method where you can read
> an EEPROM, or some GPIO code combination where I can find out what kind of board
> is plugged each time.
> 
> If there is not, there is no way to automatically load the overlays; you can always
> use the kernel command line, or have the a user space application to request the loading
> of a specific board's overlay.
> 

In this case the best thing to do is announce the availability of the
expansion via a request_firmware() call and let udev handle supplying
the correct overlay file.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Greg Kroah-Hartman March 26, 2013, 6:40 p.m. UTC | #22
On Tue, Mar 26, 2013 at 04:16:10PM +0000, Grant Likely wrote:
> On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou <panto@antoniou-consulting.com> wrote:
> > Hi Lee,
> > 
> > On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
> > 
> > >>>>> At the end of the line, some kind of hardware glue is going to be needed.
> > >>>>> 
> > >>>>> I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > >>>>> in the beagleboard), it is a bit premature to think about making it overly
> > >>>>> general, besides the part that are obviously part of the infrastructure 
> > >>>>> (like the DT overlay stuff).
> > >>>>> 
> > >>>>> What I'm getting at, is that we need some user experience about this, before
> > >>>>> going away and creating structure out of possible misconception about the uses. 
> > >>>> 
> > >>>> IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > >>>> things for omaps that have eventually become generic frameworks have been
> > >>>> the clock framework, USB OTG support, runtime PM, pinmux framework and
> > >>>> so on.
> > >>>> 
> > >>>> So I suggest a minimal generic API from the start as that will make things
> > >>>> a lot easier in the long run.
> > >>> 
> > >>> I agree. The ux500 platform already has the concept of "user interface boards",
> > >>> which currently is not well integrated into devicetree. I believe Sascha
> > >>> mentioned that Pengutronix had been shipping some other systems with add-on
> > >>> boards and generating device tree binaries from source for each combination.
> > >>> 
> > >>> Ideally, both of the above should be able to use the same DT overlay logic
> > >>> as BeagleBone, and I'm sure there are more of those.
> > >> 
> > >> Hmm, I see. 
> > >> 
> > >> I will need some more information about the interface of the 'user interface boards'.
> > >> I.e. how is the board identified, what is typically present on those boards, etc.
> > > 
> > > User Interface Boards are mearly removable PCBs which are interchangeable
> > > amongst various hardware platforms. They are connected via numerous
> > > connectors which carry all sorts of different data links; i2c, spi, rs232,
> > > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key
> > > pad, leds, jumpers, switches and a bunch of sensors.
> > > 
> > > You can find a small example of how we interface to these by viewing
> > > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we
> > > currently include it as a *.dtsi from a platform's dts file.
> > 
> > I see. What I'm asking about is whether there's a method where you can read
> > an EEPROM, or some GPIO code combination where I can find out what kind of board
> > is plugged each time.
> > 
> > If there is not, there is no way to automatically load the overlays; you can always
> > use the kernel command line, or have the a user space application to request the loading
> > of a specific board's overlay.
> > 
> 
> In this case the best thing to do is announce the availability of the
> expansion via a request_firmware() call and let udev handle supplying
> the correct overlay file.

The code to load firmware files was recently removed from udev, now that
the kernel handles this automatically itself :)

But yes, the same call still applies, request_firmware() should work
fine here.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jean-Christophe PLAGNIOL-VILLARD April 15, 2013, 10:14 a.m. UTC | #23
On 21:35 Mon 07 Jan     , Arnd Bergmann wrote:
> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
> > > 
> > > At the end of the line, some kind of hardware glue is going to be needed.
> > > 
> > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > > in the beagleboard), it is a bit premature to think about making it overly
> > > general, besides the part that are obviously part of the infrastructure 
> > > (like the DT overlay stuff).
> > > 
> > > What I'm getting at, is that we need some user experience about this, before
> > > going away and creating structure out of possible misconception about the uses. 
> > 
> > IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > things for omaps that have eventually become generic frameworks have been
> > the clock framework, USB OTG support, runtime PM, pinmux framework and
> > so on.
> > 
> > So I suggest a minimal generic API from the start as that will make things
> > a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.
> 
> Ideally, both of the above should be able to use the same DT overlay logic
> as BeagleBone, and I'm sure there are more of those.
I'm looking for this also as on at91 sama9x5ek and sam9cn12ek and the
sama5d3xek, we have 1 wire eeproms to detect the boards (motherboards and
daugther boards)
where we have 1 1-wire per board and cpu boards so we can detect everything
and have it's revision and more information

we already have barebox that detect the 1-wire but we need the same handling
in the kernel

Best Regards,
J.
> 
> 	Arnd
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..f0c2eab 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -18,6 +18,8 @@  config ARCH_OMAP2PLUS_TYPICAL
 	select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
 	select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
 	select VFP
+	select OF_OVERLAY
+	select OF_RESOLVE
 	help
 	  Compile a kernel suitable for booting most boards
 
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b151b7c..45558a3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -507,4 +507,6 @@  source "drivers/misc/lis3lv02d/Kconfig"
 source "drivers/misc/carma/Kconfig"
 source "drivers/misc/altera-stapl/Kconfig"
 source "drivers/misc/mei/Kconfig"
+source "drivers/misc/cape/Kconfig"
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2129377..c06d457 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,3 +49,4 @@  obj-y				+= carma/
 obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
 obj-$(CONFIG_ALTERA_STAPL)	+=altera-stapl/
 obj-$(CONFIG_INTEL_MEI)		+= mei/
+obj-y				+= cape/
diff --git a/drivers/misc/cape/Kconfig b/drivers/misc/cape/Kconfig
new file mode 100644
index 0000000..a2ef85e
--- /dev/null
+++ b/drivers/misc/cape/Kconfig
@@ -0,0 +1,5 @@ 
+#
+# Capes
+#
+
+source "drivers/misc/cape/beaglebone/Kconfig"
diff --git a/drivers/misc/cape/Makefile b/drivers/misc/cape/Makefile
new file mode 100644
index 0000000..7c4eb96
--- /dev/null
+++ b/drivers/misc/cape/Makefile
@@ -0,0 +1,5 @@ 
+#
+# Makefile for cape like devices
+#
+
+obj-y				+= beaglebone/
diff --git a/drivers/misc/cape/beaglebone/Kconfig b/drivers/misc/cape/beaglebone/Kconfig
new file mode 100644
index 0000000..99a31ec
--- /dev/null
+++ b/drivers/misc/cape/beaglebone/Kconfig
@@ -0,0 +1,11 @@ 
+#
+# Beaglebone capes
+#
+
+config CAPE_BEAGLEBONE
+	tristate "Beaglebone cape support"
+	depends on ARCH_OMAP2PLUS && OF && I2C
+	default n
+	select OF_PLUGIN
+	help
+	  Say Y here to include support for beaglebone capes
diff --git a/drivers/misc/cape/beaglebone/Makefile b/drivers/misc/cape/beaglebone/Makefile
new file mode 100644
index 0000000..5b4549f
--- /dev/null
+++ b/drivers/misc/cape/beaglebone/Makefile
@@ -0,0 +1,5 @@ 
+#
+# Makefile for beaglebone capes
+#
+
+obj-$(CONFIG_CAPE_BEAGLEBONE)		+= capemgr.o
diff --git a/drivers/misc/cape/beaglebone/capemgr.c b/drivers/misc/cape/beaglebone/capemgr.c
new file mode 100644
index 0000000..651f48d
--- /dev/null
+++ b/drivers/misc/cape/beaglebone/capemgr.c
@@ -0,0 +1,1835 @@ 
+/*
+ * TI Beaglebone cape controller
+ *
+ * Copyright (C) 2012 Pantelis Antoniou <panto@antoniou-consulting.com>
+ * Copyright (C) 2012 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/completion.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
+#include <linux/of_fdt.h>
+#include <linux/slab.h>
+#include <linux/pm_runtime.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/firmware.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+#include <linux/string.h>
+#include <linux/memory.h>
+#include <linux/i2c.h>
+#include <linux/i2c/eeprom.h>
+#include <linux/kthread.h>
+
+/* extra command line overrides */
+static char *extra_override = NULL;
+module_param(extra_override, charp, 0444);
+
+struct bone_capemgr_info;
+
+struct slot_ee_attribute {
+	struct device_attribute devattr;
+	unsigned int field;
+	struct bone_cape_slot *slot;	/* this is filled when instantiated */
+};
+#define to_slot_ee_attribute(x) \
+	container_of((x), struct slot_ee_attribute, devattr)
+
+struct bbrd_ee_attribute {
+	struct device_attribute devattr;
+	unsigned int field;
+};
+#define to_bbrd_ee_attribute(x) \
+	container_of((x), struct bbrd_ee_attribute, devattr)
+
+struct bone_cape_slot {
+	struct list_head	node;
+	struct bone_capemgr_info *info;
+	int			slotno;
+	u32			eeprom_handle;
+	int			eeprom_addr;
+	struct i2c_client	*client;
+	struct memory_accessor	*macc;
+	unsigned int		probed : 1;
+	unsigned int		probe_failed : 1;
+	unsigned int		override : 1;
+	char			text_id[256];
+	char			signature[256];
+	/* quick access */
+	char			board_name[32+1];
+	char 			version[4+1];
+	char 			manufacturer[16+1];
+	char 			part_number[16+1];
+
+	/* attribute group */
+	char			*ee_attr_name;
+	int			ee_attrs_count;
+	struct slot_ee_attribute *ee_attrs;
+	struct attribute	**ee_attrs_tab;
+	struct attribute_group	attrgroup;
+
+	unsigned int		loading : 1;
+	unsigned int		loaded : 1;
+	char			*dtbo;
+	const struct firmware	*fw;
+	struct device_node	*overlay;
+	int			ovinfo_cnt;
+	struct of_overlay_info	*ovinfo;
+
+	/* loader thread */
+	struct task_struct	*loader_thread;
+};
+
+struct bone_capemap {
+	struct list_head node;
+	char *part_number;
+	struct device_node *map_node;
+};
+
+struct bone_baseboard {
+
+	/* from the matched boardmap node */
+	char			*compatible_name;
+
+	/* filled in by reading the eeprom */
+	char			signature[256];
+	char			text_id[64+1];
+
+	/* quick access */
+	char			board_name[8+1];
+	char 			revision[4+1];
+	char 			serial_number[12+1];
+
+	/* access to the eeprom */
+	u32			eeprom_handle;
+	int			eeprom_addr;
+	struct i2c_client	*client;
+	struct memory_accessor	*macc;
+	unsigned int		probed : 1;
+	unsigned int		probe_failed : 1;
+	unsigned int		override : 1;
+};
+
+struct bone_capemgr_info {
+	struct platform_device	*pdev;
+
+	atomic_t next_slot_nr;
+	struct list_head	slot_list;
+	struct mutex		slots_list_mutex;
+
+	int capemaps_nr;
+	struct list_head	capemap_list;
+	struct mutex		capemap_mutex;
+
+	/* baseboard EEPROM data */
+	struct bone_baseboard	baseboard;
+};
+
+static int bone_slot_fill_override(struct bone_cape_slot *slot,
+		struct device_node *node,
+		const char *part_number, const char *version);
+static struct bone_cape_slot *bone_capemgr_add_slot(
+		struct bone_capemgr_info *info, struct device_node *node,
+		const char *part_number, const char *version);
+static int bone_capemgr_load(struct bone_cape_slot *slot);
+static int bone_capemgr_unload(struct bone_cape_slot *slot);
+
+/* baseboard EEPROM field definition */
+#define BBRD_EE_FIELD_HEADER		0
+#define BBRD_EE_FIELD_BOARD_NAME	1
+#define BBRD_EE_FIELD_REVISION		2
+#define BBRD_EE_FIELD_SERIAL_NUMBER	3
+#define BBRD_EE_FIELD_CONFIG_OPTION	4
+#define BBRD_EE_FILED_RSVD1		5
+#define BBRD_EE_FILED_RSVD2		6
+#define BBRD_EE_FILED_RSVD3		7
+
+/* cape EEPROM field definitions */
+#define CAPE_EE_FIELD_HEADER		0
+#define CAPE_EE_FIELD_EEPROM_REV	1
+#define CAPE_EE_FIELD_BOARD_NAME	2
+#define CAPE_EE_FIELD_VERSION		3
+#define CAPE_EE_FIELD_MANUFACTURER	4
+#define CAPE_EE_FIELD_PART_NUMBER	5
+#define CAPE_EE_FIELD_NUMBER_OF_PINS	6
+#define CAPE_EE_FIELD_SERIAL_NUMBER	7
+#define CAPE_EE_FIELD_PIN_USAGE		8
+#define CAPE_EE_FIELD_VDD_3V3EXP	9
+#define CAPE_EE_FIELD_VDD_5V		10
+#define CAPE_EE_FIELD_SYS_5V		11
+#define CAPE_EE_FIELD_DC_SUPPLIED	12
+#define CAPE_EE_FIELD_FIELDS_NR		13
+
+#define EE_FIELD_MAKE_HEADER(p)	\
+	({ \
+		const u8 *_p = (p); \
+		(((u32)_p[0] << 24) | ((u32)_p[1] << 16) | \
+		( (u32)_p[2] <<  8) |  (u32)_p[3]      ); \
+	})
+
+#define EE_FIELD_HEADER_VALID	0xaa5533ee
+
+struct ee_field {
+	const char 	*name;
+	int 		start;
+	int		size;
+	unsigned int	ascii : 1;
+	unsigned int	strip_trailing_dots : 1;
+	const char	*override;
+};
+
+/* baseboard EEPROM definitions */
+static const struct ee_field bbrd_sig_fields[] = {
+	[BBRD_EE_FIELD_HEADER] = {
+		.name		= "header",
+		.start		= 0,
+		.size		= 4,
+		.ascii		= 0,
+		.override	= "\xaa\x55\x33\xee",	/* AA 55 33 EE */
+	},
+	[BBRD_EE_FIELD_BOARD_NAME] = {
+		.name		= "board-name",
+		.start		= 4,
+		.size		= 8,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Board Name",
+	},
+	[BBRD_EE_FIELD_REVISION] = {
+		.name		= "revision",
+		.start		= 12,
+		.size		= 4,
+		.ascii		= 1,
+		.override	= "00A0",
+	},
+	[BBRD_EE_FIELD_SERIAL_NUMBER] = {
+		.name		= "serial-number",
+		.start		= 16,
+		.size		= 12,
+		.ascii		= 1,
+		.override	= "0000000000",
+	},
+	[BBRD_EE_FIELD_CONFIG_OPTION] = {
+		.name		= "config-option",
+		.start		= 28,
+		.size		= 32,
+	},
+};
+
+/* cape EEPROM definitions */
+static const struct ee_field cape_sig_fields[] = {
+	[CAPE_EE_FIELD_HEADER] = {
+		.name		= "header",
+		.start		= 0,
+		.size		= 4,
+		.ascii		= 0,
+		.override	= "\xaa\x55\x33\xee",	/* AA 55 33 EE */
+	},
+	[CAPE_EE_FIELD_EEPROM_REV] = {
+		.name		= "eeprom-format-revision",
+		.start		= 4,
+		.size		= 2,
+		.ascii		= 1,
+		.override	= "A0",
+	},
+	[CAPE_EE_FIELD_BOARD_NAME] = {
+		.name		= "board-name",
+		.start		= 6,
+		.size		= 32,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Override Board Name",
+	},
+	[CAPE_EE_FIELD_VERSION] = {
+		.name		= "version",
+		.start		= 38,
+		.size		= 4,
+		.ascii		= 1,
+		.override	= "00A0",
+	},
+	[CAPE_EE_FIELD_MANUFACTURER] = {
+		.name		= "manufacturer",
+		.start		= 42,
+		.size		= 16,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Override Manuf",
+	},
+	[CAPE_EE_FIELD_PART_NUMBER] = {
+		.name		= "part-number",
+		.start		= 58,
+		.size		= 16,
+		.ascii		= 1,
+		.strip_trailing_dots = 1,
+		.override	= "Override Part#",
+	},
+	[CAPE_EE_FIELD_NUMBER_OF_PINS] = {
+		.name		= "number-of-pins",
+		.start		= 74,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_SERIAL_NUMBER] = {
+		.name		= "serial-number",
+		.start		= 76,
+		.size		= 12,
+		.ascii		= 1,
+		.override	= "0000000000",
+	},
+	[CAPE_EE_FIELD_PIN_USAGE] = {
+		.name		= "pin-usage",
+		.start		= 88,
+		.size		= 140,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_VDD_3V3EXP] = {
+		.name		= "vdd-3v3exp",
+		.start		= 228,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_VDD_5V] = {
+		.name		= "vdd-5v",
+		.start		= 230,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_SYS_5V] = {
+		.name		= "sys-5v",
+		.start		= 232,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+	[CAPE_EE_FIELD_DC_SUPPLIED] = {
+		.name		= "dc-supplied",
+		.start		= 234,
+		.size		= 2,
+		.ascii		= 0,
+		.override	= NULL,
+	},
+};
+
+static char *ee_field_get(const struct ee_field *sig_field,
+		const void *data, int field, char *buf, int bufsz)
+{
+	int len;
+
+	/* enough space? */
+	if (bufsz < sig_field->size + sig_field->ascii)
+		return NULL;
+
+	memcpy(buf, (char *)data + sig_field->start, sig_field->size);
+
+	/* terminate ascii field */
+	if (sig_field->ascii)
+		buf[sig_field->size] = '\0';;
+
+	if (sig_field->strip_trailing_dots) {
+		len = strlen(buf);
+		while (len > 1 && buf[len - 1] == '.')
+			buf[--len] = '\0';
+	}
+
+	return buf;
+}
+
+char *bbrd_ee_field_get(const void *data,
+		int field, char *buf, int bufsz)
+{
+	if ((unsigned int)field >= ARRAY_SIZE(bbrd_sig_fields))
+		return NULL;
+
+	return ee_field_get(&bbrd_sig_fields[field], data, field, buf, bufsz);
+}
+
+char *cape_ee_field_get(const void *data,
+		int field, char *buf, int bufsz)
+{
+	if ((unsigned int)field >= ARRAY_SIZE(cape_sig_fields))
+		return NULL;
+
+	return ee_field_get(&cape_sig_fields[field], data, field, buf, bufsz);
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id bone_capemgr_of_match[] = {
+	{
+		.compatible = "ti,bone-capemgr",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, bone_capemgr_of_match);
+
+#endif
+
+static int bone_baseboard_scan(struct bone_baseboard *bbrd)
+{
+	struct bone_capemgr_info *info = container_of(bbrd,
+			struct bone_capemgr_info, baseboard);
+	struct memory_accessor *macc = bbrd->macc;
+	const u8 *p;
+	int i, r;
+
+	/* need to read EEPROM? */
+	if (bbrd->probed)
+		goto bbrd_fail_check;
+
+	bbrd->probed = 1;
+
+	if (!bbrd->override) {
+
+		if (macc == NULL || macc->read == NULL) {
+			dev_err(&info->pdev->dev,
+				"bone: No memory accessor for baseboard\n");
+			return -ENODEV;
+		}
+
+		for (i = 0; i < 10; i++) {
+
+			/* perform read */
+			r = macc->read(macc, bbrd->signature,
+					0, sizeof(bbrd->signature));
+
+			if (r == sizeof(bbrd->signature))
+				break;
+
+			dev_info(&info->pdev->dev,
+				"bone: scan failed (%d time)\n", i + 1);
+
+			msleep(500);
+		}
+
+		if (i >= 10) {
+			bbrd->probe_failed = 1;
+			return r >= 0 ? -EINVAL : r;
+		}
+
+	} else
+		dev_info(&info->pdev->dev,
+			"bone: Using override eeprom data for baseboard\n");
+
+	p = bbrd->signature;
+	if (EE_FIELD_MAKE_HEADER(p) != EE_FIELD_HEADER_VALID) {
+		dev_err(&info->pdev->dev, "bone: Invalid signature "
+			"'%08x' at baseboard\n",
+			EE_FIELD_MAKE_HEADER(p));
+		bbrd->probe_failed = 1;
+		return -ENODEV;
+	}
+
+	bbrd_ee_field_get(bbrd->signature,
+			BBRD_EE_FIELD_BOARD_NAME,
+			bbrd->board_name, sizeof(bbrd->board_name));
+	bbrd_ee_field_get(bbrd->signature,
+			BBRD_EE_FIELD_REVISION,
+			bbrd->revision, sizeof(bbrd->revision));
+	bbrd_ee_field_get(bbrd->signature,
+			BBRD_EE_FIELD_SERIAL_NUMBER,
+			bbrd->serial_number, sizeof(bbrd->serial_number));
+
+	/* board_name,version,manufacturer,part_number */
+	snprintf(bbrd->text_id, sizeof(bbrd->text_id) - 1,
+			"%s,%s,%s", bbrd->board_name, bbrd->revision,
+			bbrd->serial_number);
+
+	/* terminate always */
+	bbrd->text_id[sizeof(bbrd->text_id) - 1] = '\0';
+
+bbrd_fail_check:
+	/* bbrd has failed and we don't support hotpluging */
+	if (bbrd->probe_failed)
+		return -ENODEV;
+
+	return 0;
+}
+
+static int bone_slot_scan(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct memory_accessor *macc = slot->macc;
+	const u8 *p;
+	int r;
+
+	/* need to read EEPROM? */
+	if (slot->probed)
+		goto slot_fail_check;
+
+	slot->probed = 1;
+
+	if (!slot->override) {
+
+		if (macc == NULL || macc->read == NULL) {
+			dev_err(&info->pdev->dev,
+				"bone: No memory accessor for slot %d\n",
+				slot->slotno);
+			return -ENODEV;
+		}
+
+		/* perform read */
+		r = macc->read(macc, slot->signature,
+				0, sizeof(slot->signature));
+
+		if (r != sizeof(slot->signature)) {
+			slot->probe_failed = 1;
+			return r >= 0 ? -EINVAL : r;
+		}
+	} else
+		dev_info(&info->pdev->dev,
+			"bone: Using override eeprom data at slot %d\n",
+			slot->slotno);
+
+	p = slot->signature;
+	if (EE_FIELD_MAKE_HEADER(p) != EE_FIELD_HEADER_VALID) {
+		dev_err(&info->pdev->dev, "bone: Invalid signature "
+			"'%08x' at slot %d\n",
+			EE_FIELD_MAKE_HEADER(p),
+			slot->slotno);
+		slot->probe_failed = 1;
+		return -ENODEV;
+	}
+
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_BOARD_NAME,
+			slot->board_name, sizeof(slot->board_name));
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_VERSION,
+			slot->version, sizeof(slot->version));
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_MANUFACTURER,
+			slot->manufacturer, sizeof(slot->manufacturer));
+	cape_ee_field_get(slot->signature,
+			CAPE_EE_FIELD_PART_NUMBER,
+			slot->part_number, sizeof(slot->part_number));
+
+	/* board_name,version,manufacturer,part_number */
+	snprintf(slot->text_id, sizeof(slot->text_id) - 1,
+			"%s,%s,%s,%s", slot->board_name, slot->version,
+			slot->manufacturer, slot->part_number);
+
+	/* terminate always */
+	slot->text_id[sizeof(slot->text_id) - 1] = '\0';
+
+slot_fail_check:
+	/* slot has failed and we don't support hotpluging */
+	if (slot->probe_failed)
+		return -ENODEV;
+
+	return 0;
+}
+
+/* check an override slot node if it's compatible */
+static int bone_is_compatible_override(struct device_node *node,
+		const char *compatible_name)
+{
+	struct property *prop;
+	char *buf, *s, *e, *sn;
+	const char *part_number;
+	const char *version;
+	char *tmp_part_number, *tmp_version;
+	int found;
+
+	/* check if the slot is compatible with the board */
+	prop = of_find_property(node, "compatible", NULL);
+
+	/* no prop, it's something that's compatible with everything */
+	if (prop == NULL)
+		return 1;
+
+	/* check if it's directly compatible with the baseboard */
+	if (of_multi_prop_cmp(prop, compatible_name) == 0)
+		return 1;
+
+	/* final try, check if it's specified in the kernel command line */
+	if (extra_override == NULL)
+		return 0;
+
+	/* the compatible name should have kernel-command-line in it */
+	if (of_multi_prop_cmp(prop, "kernel-command-line") != 0)
+		return 0;
+
+	/* we must have at least the part-name */
+	if (of_property_read_string(node, "part-number",
+				&part_number) != 0)
+		return 0;
+
+	/* read the version (if it exists) */
+	if (of_property_read_string(node, "version", &version) != 0)
+		version = NULL;
+
+	/* copy the argument to work on it */
+	buf = kstrdup(extra_override, GFP_KERNEL);
+
+	/* no memory, too bad... */
+	if (buf == NULL)
+		return 0;
+
+	found = 0;
+	s = buf;
+	e = s + strlen(s);
+	while (s < e) {
+		/* find comma separator */
+		sn = strchr(s, ',');
+		if (sn != NULL)
+			*sn++ = '\0';
+		else
+			sn = e;
+		tmp_part_number = s;
+		tmp_version = strchr(tmp_part_number, ':');
+		if (tmp_version != NULL)
+			*tmp_version++ = '\0';
+		s = sn;
+
+		/* the part names must match */
+		if (strcmp(tmp_part_number, part_number) != 0)
+			continue;
+
+		pr_info("override: part-number='%s' version='%s' "
+				"tmp_version='%s'\n",
+				part_number,
+				version ? version : "N/A",
+				tmp_version ? tmp_version : "N/A");
+
+		/* if there's no version, match any */
+		if (version == NULL || tmp_version == NULL ||
+			strcmp(version, tmp_version) == 0) {
+			found = 1;
+			break;
+		}
+	}
+
+	kfree(buf);
+
+	return found;
+}
+
+static int bone_is_compatible_runtime_override(struct device_node *node,
+		const char *req_part_number, const char *req_version)
+{
+	struct property *prop;
+	const char *part_number;
+	const char *version;
+
+	/* only check overrides */
+	if (!of_property_read_bool(node, "ti,cape-override"))
+		return 0;
+
+	/* check if the slot is compatible with the board */
+	prop = of_find_property(node, "compatible", NULL);
+
+	/* no prop, it's something that's compatible with everything */
+	if (prop == NULL)
+		return 1;
+
+	/* the compatible name should have runtime in it */
+	if (of_multi_prop_cmp(prop, "runtime") != 0)
+		return 0;
+
+	/* we must have at least the part-name */
+	if (of_property_read_string(node, "part-number",
+				&part_number) != 0)
+		return 0;
+
+	/* read the version (if it exists) */
+	if (of_property_read_string(node, "version", &version) != 0)
+		version = NULL;
+
+	/* the part names must match */
+	if (strcmp(req_part_number, part_number) != 0)
+		return 0;
+
+	/* if any version is null, any version matches */
+	if (version == NULL || req_version == NULL)
+		return 1;
+
+	/* finally versions must match */
+	return strcmp(req_version, version) == 0;
+}
+
+
+static ssize_t slot_ee_attr_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct slot_ee_attribute *ee_attr = to_slot_ee_attribute(attr);
+	struct bone_cape_slot *slot = ee_attr->slot;
+	const struct ee_field *sig_field;
+	int i, len;
+	char *p, *s;
+	u16 val;
+
+	/* add newline for ascii fields */
+	sig_field = &cape_sig_fields[ee_attr->field];
+
+	len = sig_field->size + sig_field->ascii;
+	p = kmalloc(len, GFP_KERNEL);
+	if (p == NULL)
+		return -ENOMEM;
+
+	s = cape_ee_field_get(slot->signature, ee_attr->field, p, len);
+	if (s == NULL)
+		return -EINVAL;
+
+	/* add newline for ascii fields and return */
+	if (sig_field->ascii) {
+		len = sprintf(buf, "%s\n", s);
+		goto out;
+	}
+
+	/* case by case handling */
+	switch (ee_attr->field) {
+		case CAPE_EE_FIELD_HEADER:
+			len = sprintf(buf, "%02x %02x %02x %02x\n",
+					s[0], s[1], s[2], s[3]);
+			break;
+
+			/* 2 bytes */
+		case CAPE_EE_FIELD_NUMBER_OF_PINS:
+		case CAPE_EE_FIELD_VDD_3V3EXP:
+		case CAPE_EE_FIELD_VDD_5V:
+		case CAPE_EE_FIELD_SYS_5V:
+		case CAPE_EE_FIELD_DC_SUPPLIED:
+			/* the bone is LE */
+			val = s[0] & (s[1] << 8);
+			len = sprintf(buf, "%u\n", (unsigned int)val & 0xffff);
+			break;
+
+		case CAPE_EE_FIELD_PIN_USAGE:
+
+			len = 0;
+			for (i = 0; i < sig_field->size / 2; i++) {
+				/* the bone is LE */
+				val = s[0] & (s[1] << 8);
+				sprintf(buf, "%04x\n", val);
+				buf += 5;
+				len += 5;
+				s += 2;
+			}
+
+			break;
+
+		default:
+			*buf = '\0';
+			len = 0;
+			break;
+	}
+
+out:
+	kfree(p);
+
+	return len;
+}
+
+#define SLOT_EE_ATTR(_name, _field) \
+	{ \
+		.devattr = __ATTR(_name, 0440, slot_ee_attr_show, NULL), \
+		.field = CAPE_EE_FIELD_##_field , \
+		.slot = NULL, \
+	}
+
+static const struct slot_ee_attribute slot_ee_attrs[] = {
+	SLOT_EE_ATTR(header, HEADER),
+	SLOT_EE_ATTR(eeprom-format-revision, EEPROM_REV),
+	SLOT_EE_ATTR(board-name, BOARD_NAME),
+	SLOT_EE_ATTR(version, VERSION),
+	SLOT_EE_ATTR(manufacturer, MANUFACTURER),
+	SLOT_EE_ATTR(part-number, PART_NUMBER),
+	SLOT_EE_ATTR(number-of-pins, NUMBER_OF_PINS),
+	SLOT_EE_ATTR(serial-number, SERIAL_NUMBER),
+	SLOT_EE_ATTR(pin-usage, PIN_USAGE),
+	SLOT_EE_ATTR(vdd-3v3exp, VDD_3V3EXP),
+	SLOT_EE_ATTR(vdd-5v, VDD_5V),
+	SLOT_EE_ATTR(sys-5v, SYS_5V),
+	SLOT_EE_ATTR(dc-supplied, DC_SUPPLIED),
+};
+
+static int bone_cape_slot_sysfs_register(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct device *dev = &info->pdev->dev;
+	struct slot_ee_attribute *ee_attr;
+	struct attribute_group *attrgroup;
+	int i, err, sz;
+
+	slot->ee_attr_name = kasprintf(GFP_KERNEL, "slot-%d", slot->slotno);
+	if (slot->ee_attr_name == NULL) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attr_name\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attr_name;
+	}
+
+	slot->ee_attrs_count = ARRAY_SIZE(slot_ee_attrs);
+
+	sz = slot->ee_attrs_count * sizeof(*slot->ee_attrs);
+	slot->ee_attrs = kmalloc(sz, GFP_KERNEL);
+	if (slot->ee_attrs == NULL) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attrs\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attrs;
+	}
+
+	attrgroup = &slot->attrgroup;
+	memset(attrgroup, 0, sizeof(*attrgroup));
+	attrgroup->name = slot->ee_attr_name;
+
+	sz = sizeof(*slot->ee_attrs_tab) * (slot->ee_attrs_count + 1);
+	attrgroup->attrs = kmalloc(sz, GFP_KERNEL);
+	if (attrgroup->attrs == NULL) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attrs_tab\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attrs_tab;
+	}
+	/* copy everything over */
+	memcpy(slot->ee_attrs, slot_ee_attrs, sizeof(slot_ee_attrs));
+
+	/* bind this attr to the slot */
+	for (i = 0; i < slot->ee_attrs_count; i++) {
+		ee_attr = &slot->ee_attrs[i];
+		ee_attr->slot = slot;
+		attrgroup->attrs[i] = &ee_attr->devattr.attr;
+	}
+	attrgroup->attrs[i] = NULL;
+
+	err = sysfs_create_group(&dev->kobj, attrgroup);
+	if (err != 0) {
+		dev_err(dev, "slot #%d: Failed to allocate ee_attrs_tab\n",
+				slot->slotno);
+		err = -ENOMEM;
+		goto err_fail_no_ee_attrs_group;
+	}
+
+	return 0;
+
+err_fail_no_ee_attrs_group:
+	kfree(slot->ee_attrs_tab);
+err_fail_no_ee_attrs_tab:
+	kfree(slot->ee_attrs);
+err_fail_no_ee_attrs:
+	kfree(slot->ee_attr_name);
+err_fail_no_ee_attr_name:
+	return err;
+}
+
+static void bone_cape_slot_sysfs_unregister(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct device *dev = &info->pdev->dev;
+
+	sysfs_remove_group(&dev->kobj, &slot->attrgroup);
+	kfree(slot->ee_attrs_tab);
+	kfree(slot->ee_attrs);
+	kfree(slot->ee_attr_name);
+}
+
+static ssize_t bbrd_ee_attr_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct bbrd_ee_attribute *ee_attr = to_bbrd_ee_attribute(attr);
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_baseboard *bbrd = &info->baseboard;
+	const struct ee_field *sig_field;
+	u16 val;
+	int i, len;
+	char *p, *s;
+
+	/* add newline for ascii fields */
+	sig_field = &bbrd_sig_fields[ee_attr->field];
+
+	len = sig_field->size + sig_field->ascii;
+	p = kmalloc(len, GFP_KERNEL);
+	if (p == NULL)
+		return -ENOMEM;
+
+	s = bbrd_ee_field_get(bbrd->signature, ee_attr->field, p, len);
+	if (s == NULL)
+		return -EINVAL;
+
+	/* add newline for ascii fields and return */
+	if (sig_field->ascii) {
+		len = sprintf(buf, "%s\n", s);
+		goto out;
+	}
+
+	/* case by case handling */
+	switch (ee_attr->field) {
+		case BBRD_EE_FIELD_HEADER:
+			len = sprintf(buf, "%02x %02x %02x %02x\n",
+					s[0], s[1], s[2], s[3]);
+			break;
+
+		case BBRD_EE_FIELD_CONFIG_OPTION:
+			len = 0;
+			for (i = 0; i < sig_field->size / 2; i++) {
+				/* the bone is LE */
+				val = s[0] & (s[1] << 8);
+				sprintf(buf, "%04x\n", val);
+				buf += 5;
+				len += 5;
+				s += 2;
+			}
+			break;
+
+		default:
+			*buf = '\0';
+			len = 0;
+			break;
+	}
+
+out:
+	kfree(p);
+
+	return len;
+}
+
+#define BBRD_EE_ATTR(_name, _field) \
+	{ \
+		.devattr = __ATTR(_name, 0440, bbrd_ee_attr_show, NULL), \
+		.field = BBRD_EE_FIELD_##_field , \
+	}
+
+static struct bbrd_ee_attribute bbrd_ee_attrs[] = {
+	BBRD_EE_ATTR(header, HEADER),
+	BBRD_EE_ATTR(board-name, BOARD_NAME),
+	BBRD_EE_ATTR(revision, REVISION),
+	BBRD_EE_ATTR(serial-number, SERIAL_NUMBER),
+	BBRD_EE_ATTR(config-option, CONFIG_OPTION),
+};
+
+static struct attribute *bbrd_attrs_flat[] = {
+	&bbrd_ee_attrs[BBRD_EE_FIELD_HEADER	 	].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_BOARD_NAME	 	].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_REVISION		].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_SERIAL_NUMBER	].devattr.attr,
+	&bbrd_ee_attrs[BBRD_EE_FIELD_CONFIG_OPTION	].devattr.attr,
+	NULL,
+};
+
+static const struct attribute_group bbrd_attr_group = {
+	.name	= "baseboard",
+	.attrs	= bbrd_attrs_flat,
+};
+
+static ssize_t slots_show(struct device *dev, struct device_attribute *attr,
+		char *buf)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_cape_slot *slot;
+	ssize_t len, sz;
+
+	mutex_lock(&info->slots_list_mutex);
+	sz = 0;
+	list_for_each_entry(slot, &info->slot_list, node) {
+
+		len = sprintf(buf, "%2d: %02x:%c%c%c%c%c %s\n",
+				slot->slotno,
+				(int)slot->client ?
+					slot->client->addr & 0x7f : 0xff,
+				slot->probed       ? 'P' : '-',
+				slot->probe_failed ? 'F' : '-',
+				slot->override     ? 'O' : '-',
+				slot->loading	   ? 'l' : '-',
+				slot->loaded	   ? 'L' : '-',
+				slot->text_id);
+
+		buf += len;
+		sz += len;
+	}
+	mutex_unlock(&info->slots_list_mutex);
+
+	return sz;
+}
+
+static ssize_t slots_store(struct device *dev, struct device_attribute *attr,
+		 const char *buf, size_t count)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_cape_slot *slot;
+	struct device_node *pnode, *node, *slots_node;
+	char *s, *part_number, *version;
+	int ret;
+	int slotno;
+
+	/* check for remove slot */
+	if (strlen(buf) > 0 && buf[0] == '-') {
+		slotno = simple_strtoul(buf + 1, NULL, 10);
+
+		/* now load each (take lock to be sure */
+		mutex_lock(&info->slots_list_mutex);
+		list_for_each_entry(slot, &info->slot_list, node) {
+			if (slotno == slot->slotno)
+				break;
+		}
+		mutex_unlock(&info->slots_list_mutex);
+
+		if (slot == NULL)
+			return -ENODEV;
+
+		bone_capemgr_unload(slot);
+
+		return strlen(buf);
+	}
+
+	part_number = kstrdup(buf, GFP_KERNEL);
+	if (part_number == NULL)
+		return -ENOMEM;
+
+	/* remove trailing spaces dots and newlines */
+	s = part_number + strlen(part_number);
+	while (s > part_number &&
+			(isspace(s[-1]) || s[-1] == '\n' || s[-1] == '.'))
+		*--s = '\0';
+
+	version = strchr(part_number, ':');
+	if (version != NULL)
+		*version++ = '\0';
+
+	dev_info(&pdev->dev, "part_number '%s', version '%s'\n",
+			part_number, version ? version : "N/A");
+
+	pnode = pdev->dev.of_node;
+	node = NULL;
+	slot = NULL;
+	ret = 0;
+
+	/* iterate over any slots */
+	slots_node = of_get_child_by_name(pnode, "slots");
+	if (slots_node != NULL) {
+		for_each_child_of_node(slots_node, node) {
+
+			/* check if the override is compatible */
+			if (!bone_is_compatible_runtime_override(node,
+						part_number, version))
+				continue;
+
+			slot = bone_capemgr_add_slot(info, node,
+					part_number, version);
+			if (IS_ERR(slot)) {
+				dev_err(&pdev->dev, "Failed to add slot #%d\n",
+					atomic_read(&info->next_slot_nr) - 1);
+				ret = PTR_ERR(slot);
+				slot = NULL;
+				goto err_fail;
+			}
+			break;
+		}
+		of_node_put(node);
+		of_node_put(slots_node);
+	}
+	slots_node = NULL;
+
+	/* no specific slot found, try immediate */
+	if (!slot)
+		slot = bone_capemgr_add_slot(info, NULL,
+				part_number, version);
+
+	if (IS_ERR_OR_NULL(slot)) {
+		dev_err(&pdev->dev, "Failed to add slot #%d\n",
+			atomic_read(&info->next_slot_nr) - 1);
+		ret = slot ? PTR_ERR(slot) : -ENODEV;
+		slot = NULL;
+		goto err_fail;
+	}
+
+	kfree(part_number);
+
+	ret = bone_capemgr_load(slot);
+
+	return ret == 0 ? strlen(buf) : ret;
+err_fail:
+	of_node_put(node);
+	of_node_put(slots_node);
+	kfree(part_number);
+	return ret;
+}
+
+static DEVICE_ATTR(slots, 0644, slots_show, slots_store);
+
+static int bone_capemgr_info_sysfs_register(struct bone_capemgr_info *info)
+{
+	struct device *dev = &info->pdev->dev;
+	int ret;
+
+	ret = device_create_file(dev, &dev_attr_slots);
+	if (ret != 0)
+		goto err_fail_no_slots;
+
+	ret = sysfs_create_group(&dev->kobj, &bbrd_attr_group);
+	if (ret != 0)
+		goto err_fail_no_bbrd_grp;
+
+	return 0;
+err_fail_no_bbrd_grp:
+	device_remove_file(dev, &dev_attr_slots);
+err_fail_no_slots:
+	return ret;
+}
+
+static void bone_capemgr_info_sysfs_unregister(struct bone_capemgr_info *info)
+{
+	struct device *dev = &info->pdev->dev;
+
+	sysfs_remove_group(&dev->kobj, &bbrd_attr_group);
+	device_remove_file(dev, &dev_attr_slots);
+}
+
+static int bone_capemgr_load(struct bone_cape_slot *slot)
+{
+	struct bone_capemgr_info *info = slot->info;
+	struct device *dev = &info->pdev->dev;
+	struct device_node *node;
+	struct property *prop;
+	const char *dtbo;
+	int found, err;
+	struct bone_capemap *capemap;
+
+	if (slot->probe_failed)
+		return -ENODEV;
+
+	if (slot->loaded)
+		return -EAGAIN;
+
+	mutex_lock(&info->capemap_mutex);
+	found = 0;
+	list_for_each_entry(capemap, &info->capemap_list, node) {
+		if (strcmp(capemap->part_number, slot->part_number) == 0) {
+			found = 1;
+			break;
+		}
+	}
+
+	/* found? */
+	if (found) {
+		if (capemap->map_node == NULL) {
+			mutex_unlock(&info->capemap_mutex);
+			/* need to match programatically; not supported yet */
+			dev_err(dev, "slot #%d: Failed to find capemap "
+					"for '%s'\n",
+					slot->slotno, slot->part_number);
+			return -ENODEV;
+		}
+
+		/* locate first match */
+		dtbo = NULL;
+		for_each_child_of_node(capemap->map_node, node) {
+
+			/* dtbo must exist */
+			if (of_property_read_string(node, "dtbo", &dtbo) != 0)
+				continue;
+
+			/* get version property (if any) */
+			prop = of_find_property(node, "version", NULL);
+
+			/* if no version node exists, we match */
+			if (prop == NULL)
+				break;
+
+			if (of_multi_prop_cmp(prop, slot->version) == 0)
+				break;
+		}
+
+		if (node == NULL) {
+			/* can't find dtbo version node? try the default */
+			if (of_property_read_string(capemap->map_node,
+						"dtbo", &dtbo) != 0) {
+				mutex_unlock(&info->capemap_mutex);
+				dev_err(dev, "slot #%d: Failed to find dtbo "
+						"for '%s'\n",
+						slot->slotno,
+						slot->part_number);
+				return -ENODEV;
+			}
+		}
+
+		slot->dtbo = kstrdup(dtbo, GFP_KERNEL);
+		of_node_put(node);	/* handles NULL */
+	} else {
+		dev_info(dev, "slot #%d: Requesting part number/version based "
+				"'%s-%s.dtbo\n",
+				slot->slotno,
+				slot->part_number, slot->version);
+
+		/* no specific capemap node; request the part number + .dtbo*/
+		slot->dtbo = kasprintf(GFP_KERNEL, "%s-%s.dtbo",
+				slot->part_number, slot->version);
+	}
+
+	if (slot->dtbo == NULL) {
+		mutex_unlock(&info->capemap_mutex);
+		dev_err(dev, "slot #%d: Failed to get dtbo '%s'\n",
+				slot->slotno, dtbo);
+		return -ENOMEM;
+	}
+
+	dev_info(dev, "slot #%d: Requesting firmware '%s' for board-name '%s'"
+			", version '%s'\n",
+			slot->slotno,
+			slot->dtbo, slot->board_name, slot->version);
+
+	err = request_firmware(&slot->fw, slot->dtbo, dev);
+	if (err != 0) {
+		dev_err(dev, "failed to load firmware '%s'\n", slot->dtbo);
+		mutex_unlock(&info->capemap_mutex);
+		goto err_fail_no_fw;
+	}
+
+	dev_info(dev, "slot #%d: dtbo '%s' loaded; converting to live tree\n",
+			slot->slotno, slot->dtbo);
+
+	mutex_unlock(&info->capemap_mutex);
+
+	of_fdt_unflatten_tree((void *)slot->fw->data, &slot->overlay);
+	if (slot->overlay == NULL) {
+		dev_err(dev, "slot #%d: Failed to unflatten\n",
+				slot->slotno);
+		err = -EINVAL;
+		goto err_fail;
+	}
+
+	/* mark it as detached */
+	of_node_set_flag(slot->overlay, OF_DETACHED);
+
+	/* perform resolution */
+	err = of_resolve(slot->overlay);
+	if (err != 0) {
+		dev_err(dev, "slot #%d: Failed to resolve tree\n",
+				slot->slotno);
+		goto err_fail;
+	}
+
+	/* now build an overlay info array */
+	err = of_build_overlay_info(slot->overlay,
+			&slot->ovinfo_cnt, &slot->ovinfo);
+	if (err != 0) {
+		dev_err(dev, "slot #%d: Failed to build overlay info\n",
+				slot->slotno);
+		goto err_fail;
+	}
+
+	dev_info(dev, "slot #%d: #%d overlays\n",
+			slot->slotno, slot->ovinfo_cnt);
+
+	err = of_overlay(slot->ovinfo_cnt, slot->ovinfo);
+	if (err != 0) {
+		if (err != 0) {
+			dev_err(dev, "slot #%d: Failed to overlay\n",
+					slot->slotno);
+			goto err_fail_overlay;
+		}
+	}
+
+	dev_info(dev, "slot #%d: Applied #%d overlays.\n",
+			slot->slotno, slot->ovinfo_cnt);
+
+	slot->loading = 0;
+	slot->loaded = 1;
+
+	return 0;
+
+err_fail_overlay:
+
+	of_free_overlay_info(slot->ovinfo_cnt, slot->ovinfo);
+	slot->ovinfo_cnt = 0;
+	slot->ovinfo = NULL;
+
+err_fail:
+
+	/* we can't free the overlay, because the unflatten method is a mess */
+	/* __of_free_tree(slot->overlay); */
+	slot->overlay = NULL;
+
+	release_firmware(slot->fw);
+	slot->fw = NULL;
+
+err_fail_no_fw:
+	return err;
+}
+
+static int bone_capemgr_unload(struct bone_cape_slot *slot)
+{
+	if (!slot->loaded || slot->ovinfo == NULL)
+		return -EINVAL;
+
+	of_overlay_revert(slot->ovinfo_cnt, slot->ovinfo);
+
+	slot->ovinfo_cnt = 0;
+	kfree(slot->ovinfo);
+
+	slot->loaded = 0;
+
+	return 0;
+
+}
+
+static int bone_slot_fill_override(struct bone_cape_slot *slot,
+		struct device_node *node,
+		const char *part_number, const char *version)
+{
+	const struct ee_field *sig_field;
+	struct property *prop;
+	int i, len, has_part_number;
+	char *p;
+
+	slot->probe_failed = 0;
+	slot->probed = 0;
+
+	/* zero out signature */
+	memset(slot->signature, 0,
+			sizeof(slot->signature));
+
+	/* first, fill in all with override defaults */
+	for (i = 0; i < ARRAY_SIZE(cape_sig_fields); i++) {
+
+		sig_field = &cape_sig_fields[i];
+
+		/* point to the entry */
+		p = slot->signature + sig_field->start;
+
+		if (sig_field->override)
+			memcpy(p, sig_field->override,
+					sig_field->size);
+		else
+			memset(p, 0, sig_field->size);
+	}
+
+	/* and now, fill any override data from the node */
+	has_part_number = 0;
+	if (node != NULL) {
+		for (i = 0; i < ARRAY_SIZE(cape_sig_fields); i++) {
+
+			sig_field = &cape_sig_fields[i];
+
+			/* find property with the same name (if any) */
+			prop = of_find_property(node, sig_field->name, NULL);
+			if (prop == NULL)
+				continue;
+
+			/* point to the entry */
+			p = slot->signature + sig_field->start;
+
+			/* copy and zero out any remainder */
+			len = prop->length;
+			if (prop->length > sig_field->size)
+				len = sig_field->size;
+			memcpy(p, prop->value, len);
+			if (len < sig_field->size)
+				memset(p + len, 0, sig_field->size - len);
+
+			/* remember if we got a part number which is required */
+			if (i == CAPE_EE_FIELD_PART_NUMBER && len > 0)
+				has_part_number = 1;
+		}
+	}
+
+	/* if a part_number is supplied use it */
+	if (part_number && (len = strlen(part_number)) > 0) {
+		sig_field = &cape_sig_fields[CAPE_EE_FIELD_PART_NUMBER];
+
+		/* point to the entry */
+		p = slot->signature + sig_field->start;
+
+		/* copy and zero out any remainder */
+		if (len > sig_field->size)
+			len = sig_field->size;
+		memcpy(p, part_number, len);
+		if (len < sig_field->size)
+			memset(p + len, 0, sig_field->size - len);
+
+		has_part_number = 1;
+	}
+
+	/* if a version is supplied use it */
+	if (version && (len = strlen(version)) > 0) {
+		sig_field = &cape_sig_fields[CAPE_EE_FIELD_VERSION];
+
+		/* point to the entry */
+		p = slot->signature + sig_field->start;
+
+		/* copy and zero out any remainder */
+		if (len > sig_field->size)
+			len = sig_field->size;
+		memcpy(p, version, len);
+		if (len < sig_field->size)
+			memset(p + len, 0, sig_field->size - len);
+	}
+
+	/* we must have a part number */
+	if (!has_part_number)
+		return -EINVAL;
+
+	slot->override = 1;
+
+	return 0;
+}
+
+static struct bone_cape_slot *
+bone_capemgr_add_slot(struct bone_capemgr_info *info, struct device_node *node,
+		const char *part_number, const char *version)
+{
+	struct device_node *eeprom_node;
+	struct bone_cape_slot *slot;
+	struct device *dev = &info->pdev->dev;
+	int slotno;
+	int ret;
+
+	eeprom_node = NULL;
+
+	slotno = atomic_inc_return(&info->next_slot_nr) - 1;
+
+	slot = devm_kzalloc(dev, sizeof(*slot), GFP_KERNEL);
+	if (slot == NULL) {
+		ret = -ENOMEM;
+		goto err_no_mem;
+	}
+	slot->info = info;
+	slot->slotno = slotno;
+
+	if (node && !of_property_read_bool(node, "ti,cape-override")) {
+		ret = of_property_read_u32(node, "eeprom",
+				&slot->eeprom_handle);
+		if (ret != 0) {
+			dev_err(dev, "slot #%d: failed to locate eeprom\n",
+					slotno);
+			goto err_no_eeprom;
+		}
+		eeprom_node = of_find_node_by_phandle(slot->eeprom_handle);
+		if (eeprom_node == NULL) {
+			dev_err(dev, "slot #%d: failed to find eeprom node\n",
+					slotno);
+			ret = -ENODEV;
+			goto err_no_eeprom_node;
+		}
+		slot->client = of_find_i2c_device_by_node(eeprom_node);
+		if (slot->client == NULL) {
+			dev_err(dev, "slot #%d: failed to find i2c client\n",
+					slotno);
+			ret = -ENODEV;
+			goto err_no_eeprom_client;
+		}
+		/* release ref to the node & get ref of the i2c client */
+		of_node_put(eeprom_node);
+		eeprom_node = NULL;
+		i2c_use_client(slot->client);
+
+		/* grab the memory accessor of the eeprom */
+		slot->macc = i2c_eeprom_get_memory_accessor(slot->client);
+		if (IS_ERR_OR_NULL(slot->macc)) {
+			dev_err(dev, "slot #%d: failed to get "
+					"memory accessor\n", slotno);
+			ret = slot->macc == NULL ? -ENODEV :
+				PTR_ERR(slot->macc);
+			slot->macc = NULL;
+			goto err_no_eeprom_macc;
+		}
+
+	} else {
+		if (node)
+			dev_info(dev, "slot #%d: specific override\n", slotno);
+		else
+			dev_info(dev, "slot #%d: generic override\n", slotno);
+
+		/* fill in everything with defaults first */
+		ret = bone_slot_fill_override(slot, node, part_number, version);
+		if (ret != 0) {
+			dev_err(dev, "slot #%d: override failed\n",
+					slotno);
+			goto err_no_eeprom;
+		}
+	}
+
+	ret = bone_slot_scan(slot);
+	if (ret != 0) {
+
+		if (!slot->probe_failed) {
+			dev_err(dev, "slot #%d: scan failed\n",
+					slotno);
+			goto err_bad_scan;
+		}
+
+		dev_err(dev, "slot #%d: No cape found\n",
+				slotno);
+		/* but all is fine */
+	} else {
+		dev_info(dev, "slot #%d: '%s'\n",
+				slotno, slot->text_id);
+
+		ret = bone_cape_slot_sysfs_register(slot);
+		if (ret != 0) {
+			dev_err(dev, "slot #%d: sysfs register failed\n",
+					slotno);
+			goto err_no_sysfs;
+		}
+
+	}
+
+	/* add to the slot list */
+	mutex_lock(&info->slots_list_mutex);
+	list_add_tail(&slot->node, &info->slot_list);
+	mutex_unlock(&info->slots_list_mutex);
+
+	return slot;
+
+err_no_sysfs:
+err_bad_scan:
+err_no_eeprom_macc:
+	i2c_release_client(slot->client);
+err_no_eeprom_client:
+	of_node_put(eeprom_node);	/* handles NULL */
+err_no_eeprom_node:
+	/* nothing */
+err_no_eeprom:
+	devm_kfree(dev, slot);
+
+err_no_mem:
+	return ERR_PTR(ret);
+}
+
+static int bone_capemgr_loader(void *data)
+{
+	struct bone_cape_slot *slot = data;
+
+	return bone_capemgr_load(slot);
+}
+
+static int __devinit
+bone_capemgr_probe(struct platform_device *pdev)
+{
+	struct bone_capemgr_info *info;
+	struct bone_baseboard *bbrd;
+	struct bone_cape_slot *slot;
+	struct device_node *pnode = pdev->dev.of_node;
+	struct device_node *baseboardmaps_node;
+	struct device_node *slots_node, *capemaps_node, *node;
+	struct device_node *eeprom_node;
+	const char *part_number;
+	const char *board_name;
+	const char *compatible_name;
+	struct bone_capemap *capemap;
+	int ret, len;
+
+	/* we don't use platform_data at all; we require OF */
+	if (pnode == NULL)
+		return -ENOTSUPP;
+
+	info = devm_kzalloc(&pdev->dev,
+			sizeof(struct bone_capemgr_info), GFP_KERNEL);
+	if (!info) {
+		dev_err(&pdev->dev, "Failed to allocate device structure\n");
+		return -ENOMEM;
+	}
+
+	info->pdev = pdev;
+	platform_set_drvdata(pdev, info);
+
+	atomic_set(&info->next_slot_nr, 0);
+	INIT_LIST_HEAD(&info->slot_list);
+	mutex_init(&info->slots_list_mutex);
+
+	INIT_LIST_HEAD(&info->capemap_list);
+	mutex_init(&info->capemap_mutex);
+
+	baseboardmaps_node = NULL;
+	capemaps_node = NULL;
+
+	/* find the baseboard */
+	bbrd = &info->baseboard;
+
+	baseboardmaps_node = of_get_child_by_name(pnode, "baseboardmaps");
+	if (baseboardmaps_node == NULL) {
+		dev_err(&pdev->dev, "Failed to get baseboardmaps node");
+		ret = -ENODEV;
+		goto err_exit;
+	}
+
+	/* get eeprom of the baseboard */
+	ret = of_property_read_u32(pnode, "eeprom",
+			&bbrd->eeprom_handle);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to locate baseboard eeprom\n");
+		goto err_exit;
+	}
+	eeprom_node = of_find_node_by_phandle(bbrd->eeprom_handle);
+	if (eeprom_node == NULL) {
+		dev_err(&pdev->dev, "Failed to find baseboard eeprom node\n");
+		ret = -ENODEV;
+		goto err_exit;
+	}
+	bbrd->client = of_find_i2c_device_by_node(eeprom_node);
+	of_node_put(eeprom_node);
+	eeprom_node = NULL;
+	if (bbrd->client == NULL) {
+		dev_err(&pdev->dev, "Failed to find baseboard i2c client\n");
+		ret = -ENODEV;
+		goto err_exit;
+	}
+
+	/* release ref to the node & get ref of the i2c client */
+	i2c_use_client(bbrd->client);
+
+	/* grab the memory accessor of the eeprom */
+	bbrd->macc = i2c_eeprom_get_memory_accessor(bbrd->client);
+	if (IS_ERR_OR_NULL(bbrd->macc)) {
+		dev_err(&pdev->dev, "Failed to get "
+				"baseboard memory accessor\n");
+		ret = bbrd->macc == NULL ? -ENODEV :
+			PTR_ERR(bbrd->macc);
+		bbrd->macc = NULL;
+		goto err_exit;
+	}
+
+	ret = bone_baseboard_scan(bbrd);
+	if (ret != 0) {
+		dev_err(&pdev->dev, "Failed to scan baseboard eeprom\n");
+		goto err_exit;
+	}
+
+	dev_info(&pdev->dev, "Baseboard: '%s'\n", bbrd->text_id);
+
+	board_name = NULL;
+	compatible_name = NULL;
+	for_each_child_of_node(baseboardmaps_node, node) {
+		/* there must be board-name */
+		if (of_property_read_string(node, "board-name",
+					&board_name) != 0 ||
+		    of_property_read_string(node, "compatible-name",
+					&compatible_name) != 0)
+			continue;
+
+		if (strcmp(bbrd->board_name, board_name) == 0)
+			break;
+	}
+	of_node_put(baseboardmaps_node);
+	baseboardmaps_node = NULL;
+
+	if (node == NULL) {
+		dev_err(&pdev->dev, "Failed to find compatible map for %s\n",
+				bbrd->board_name);
+		ret = -ENODEV;
+		goto err_exit;
+	}
+	bbrd->compatible_name = kstrdup(compatible_name, GFP_KERNEL);
+	if (bbrd->compatible_name == NULL) {
+		dev_err(&pdev->dev, "Failed to allocate compatible name\n");
+		ret = -ENOMEM;
+		goto err_exit;
+	}
+	of_node_put(node);
+
+	dev_info(&pdev->dev, "compatible-baseboard=%s\n",
+			bbrd->compatible_name);
+
+	/* iterate over any capemaps */
+	capemaps_node = of_get_child_by_name(pnode, "capemaps");
+	if (capemaps_node != NULL) {
+
+		for_each_child_of_node(capemaps_node, node) {
+
+			/* there must be part-number */
+			if (of_property_read_string(node, "part-number",
+						&part_number) != 0)
+				continue;
+
+			len = sizeof(*capemap) + strlen(part_number) + 1;
+			capemap = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
+			if (capemap == NULL) {
+				dev_err(&pdev->dev, "Failed to allocate "
+						"capemap\n");
+				ret = -ENOMEM;
+				goto err_exit;
+			}
+			capemap->part_number = (char *)(capemap + 1);
+			capemap->map_node = of_node_get(node);
+			strcpy(capemap->part_number, part_number);
+
+			/* add to the slot list */
+			mutex_lock(&info->capemap_mutex);
+			list_add_tail(&capemap->node, &info->capemap_list);
+			info->capemaps_nr++;
+			mutex_unlock(&info->capemap_mutex);
+		}
+		of_node_put(capemaps_node);
+		capemaps_node = NULL;
+	}
+
+	/* iterate over any slots */
+	slots_node = of_get_child_by_name(pnode, "slots");
+	if (slots_node != NULL) {
+		for_each_child_of_node(slots_node, node) {
+
+			/* check if the override is compatible */
+			if (!bone_is_compatible_override(node,
+						bbrd->compatible_name))
+				continue;
+
+			slot = bone_capemgr_add_slot(info, node,
+					NULL, NULL);
+			if (IS_ERR(slot)) {
+				dev_err(&pdev->dev, "Failed to add slot #%d\n",
+					atomic_read(&info->next_slot_nr));
+				ret = PTR_ERR(slot);
+				goto err_exit;
+			}
+		}
+		of_node_put(slots_node);
+	}
+	slots_node = NULL;
+
+	pm_runtime_enable(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (IS_ERR_VALUE(ret)) {
+		dev_err(&pdev->dev, "Failed to pm_runtime_get_sync()\n");
+		goto err_exit;
+	}
+
+	pm_runtime_put(&pdev->dev);
+
+	bone_capemgr_info_sysfs_register(info);
+
+	/* now load each (take lock to be sure */
+	mutex_lock(&info->slots_list_mutex);
+	list_for_each_entry(slot, &info->slot_list, node) {
+		if (!slot->probe_failed && !slot->loaded) {
+			slot->loading = 1;
+			slot->loader_thread = kthread_run(bone_capemgr_loader,
+					slot, "capemgr-loader-%d",
+					slot->slotno);
+			if (IS_ERR(slot->loader_thread)) {
+				dev_warn(&pdev->dev, "slot #%d: Failed to "
+						"start loader\n", slot->slotno);
+				slot->loader_thread = NULL;
+			}
+		}
+	}
+
+	mutex_unlock(&info->slots_list_mutex);
+
+
+	dev_info(&pdev->dev, "initialized OK.\n");
+
+	return 0;
+
+err_exit:
+	of_node_put(baseboardmaps_node);
+	of_node_put(capemaps_node);
+	platform_set_drvdata(pdev, NULL);
+	devm_kfree(&pdev->dev, info);
+
+	return ret;
+}
+
+static int __devexit bone_capemgr_remove(struct platform_device *pdev)
+{
+	struct bone_capemgr_info *info = platform_get_drvdata(pdev);
+	struct bone_cape_slot *slot, *slotn;
+	int ret;
+
+	mutex_lock(&info->slots_list_mutex);
+	list_for_each_entry_safe(slot, slotn, &info->slot_list, node) {
+
+		/* unload just in case */
+		bone_capemgr_unload(slot);
+
+		/* if probed OK, remove the sysfs nodes */
+		if (slot->probed && !slot->probe_failed)
+			bone_cape_slot_sysfs_unregister(slot);
+
+		/* remove it from the list */
+		list_del(&slot->node);
+
+	}
+	mutex_unlock(&info->slots_list_mutex);
+
+	bone_capemgr_info_sysfs_unregister(info);
+
+	platform_set_drvdata(pdev, NULL);
+
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (IS_ERR_VALUE(ret))
+		return ret;
+
+	pm_runtime_put(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+
+	devm_kfree(&pdev->dev, info);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+#ifdef CONFIG_PM_RUNTIME
+static int bone_capemgr_runtime_suspend(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *_dev = platform_get_drvdata(pdev);
+
+	(void)_dev;
+	return 0;
+}
+
+static int bone_capemgr_runtime_resume(struct device *dev)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct bone_capemgr_info *_dev = platform_get_drvdata(pdev);
+
+	(void)_dev;
+	return 0;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
+static struct dev_pm_ops bone_capemgr_pm_ops = {
+	SET_RUNTIME_PM_OPS(bone_capemgr_runtime_suspend,
+			   bone_capemgr_runtime_resume, NULL)
+};
+#define BONE_CAPEMGR_PM_OPS (&bone_capemgr_pm_ops)
+#else
+#define BONE_CAPEMGR_PM_OPS NULL
+#endif /* CONFIG_PM */
+
+static struct platform_driver bone_capemgr_driver = {
+	.probe		= bone_capemgr_probe,
+	.remove		= __devexit_p(bone_capemgr_remove),
+	.driver		= {
+		.name	= "bone-capemgr",
+		.owner	= THIS_MODULE,
+		.pm	= BONE_CAPEMGR_PM_OPS,
+		.of_match_table = of_match_ptr(bone_capemgr_of_match),
+	},
+};
+
+module_platform_driver(bone_capemgr_driver);
+
+MODULE_AUTHOR("Pantelis Antoniou");
+MODULE_DESCRIPTION("Beaglebone cape manager");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:bone_capemgr");