Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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-disc...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, Mar 26, 2013 at 04:16:10PM +, Grant Likely wrote: On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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'. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones lee.jo...@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 = 0xc000 + 0x1000 * i;
lmdev-resource.end = lmdev-resource.start + 0x0fff;
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 majord...@vger.kernel.org
More majordomo info
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
(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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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 -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Mon, Jan 07, 2013 at 09:35:04PM +, 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
A cape loader based on DT overlays and DT objects. Beaglebone cape manager implementation. Signed-off-by: Pantelis Antoniou pa...@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 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 000..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 000..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 000..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 000..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 000..651f48d --- /dev/null +++ b/drivers/misc/cape/beaglebone/capemgr.c @@ -0,0 +1,1835 @@ +/* + * TI Beaglebone cape controller + * + * Copyright (C) 2012 Pantelis Antoniou pa...@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
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
* Pantelis Antoniou pa...@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 pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Tony, On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@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 pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
* Pantelis Antoniou pa...@antoniou-consulting.com [130107 12:16]: Hi Tony, On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@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 pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Tony, On Jan 7, 2013, at 10:23 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [130107 12:16]: Hi Tony, On Jan 7, 2013, at 10:09 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@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 pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
* Pantelis Antoniou pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Tony, On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
* Pantelis Antoniou pa...@antoniou-consulting.com [130107 12:43]: Hi Tony, On Jan 7, 2013, at 10:35 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
(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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
