* Re: Handling of modular boards
From: Russell King - ARM Linux @ 2012-05-04 23:52 UTC (permalink / raw)
To: Mark Brown
Cc: Samuel Ortiz, Arnd Bergmann, Olof Johansson, Stephen Warren,
Igor Grinberg, linux-embedded, linux-arm-kernel, linux-kernel
In-Reply-To: <20120504234056.GV14230@opensource.wolfsonmicro.com>
On Sat, May 05, 2012 at 12:40:57AM +0100, Mark Brown wrote:
> On Fri, May 04, 2012 at 11:55:14PM +0100, Russell King - ARM Linux wrote:
> > On Fri, May 04, 2012 at 07:58:51PM +0100, Mark Brown wrote:
>
> > > I'm just starting to put some stuff together for this so I was wondering
> > > if anyone had been thinking about this and had any bright ideas for how
> > > to handle it, and also if people think that MFD is a good fit for this
> > > or if we should split the silicon MFDs from these PCBs.
>
> > I don't think its true to say that there's no support for this kind of
> > thing.
>
> > If you're thinking about a motherboard with separate add-on cards, then
> > you can view the cards as their own separate platform device. Your
> > platform device driver would be a "whole board driver" responsible
> > for creating and registering the specific devices found on the board
> > in its probe function, and unregistering them in the remove function.
>
> Oh, absolutely - there's support there at that level and several boards
> doing some or all of this in mainline already. It's not that you can't
> do it, it's that there's a bunch of generic stuff to do with how you map
> the resources through to the devices on the modules and describe the
> chips that are on the modules for which there's no infrastructure so
> everything needs to be hand coded on a per board basis. The board
> identification bits are board specific but the remapping and subdevice
> instantiation bits seem like they shouldn't be.
How about this - we have struct platform_device_info, which is used to
create platform devices. We can use this as an array to describe what
platform devices to create in the sub-driver, including what the resources
should be etc.
However, there's a problem with this - what if you need to do some board
level init before hand? That needs to be handled somehow before these
devices are instantiated. That could be done via a callback through
platform data.
But... this all seems wrong, because rather than having a driver which
knows about the details of the board, we now have all the details of the
board in question back in platform code which originally declared the
board device. That's wrong, because a daughter board may be shared
between different platforms, and we don't want multiple copies of that
data all around the place.
I don't think there's an easy or generic solution to this.
The best I can think of is ACPI, where they _do_ handle devices and
such like coming and going dynamically (I know this, it happens to my
serial and printer ports every time I dock and undock the laptop - and
stock Linux doesn't support that. Which reminds me I need to get those
patches properly prepared and submitted...) I'd assume that it also
deals with PCI bridges and buses behind that if you have one of those
docking stations too (I don't)...
^ permalink raw reply
* Re: Handling of modular boards
From: Mark Brown @ 2012-05-05 0:03 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Samuel Ortiz, Arnd Bergmann, Olof Johansson, Stephen Warren,
Igor Grinberg, linux-embedded, linux-arm-kernel, linux-kernel
In-Reply-To: <20120504235225.GN897@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
On Sat, May 05, 2012 at 12:52:25AM +0100, Russell King - ARM Linux wrote:
> How about this - we have struct platform_device_info, which is used to
> create platform devices. We can use this as an array to describe what
> platform devices to create in the sub-driver, including what the resources
> should be etc.
We (well, I at least) need to handle devices on other buses like I2C and
SPI too but yes, that's the sort of thing I was looking for.
> However, there's a problem with this - what if you need to do some board
> level init before hand? That needs to be handled somehow before these
> devices are instantiated. That could be done via a callback through
> platform data.
> But... this all seems wrong, because rather than having a driver which
> knows about the details of the board, we now have all the details of the
> board in question back in platform code which originally declared the
> board device. That's wrong, because a daughter board may be shared
> between different platforms, and we don't want multiple copies of that
> data all around the place.
> I don't think there's an easy or generic solution to this.
I think that's OK - if there's any init stuff that needs to be done on a
prior to identification of the board then presumably it's a generic
thing for the motherboard which will apply to any plugin module on that
board and can be done as part of the normal board init. If the init
needs to be done after identification of the board then probably it
applies to any motherboard the board might be plugged in to so we can
just define callbacks for the plugin module that can be part of the
plugin module description.
Cases that depend on a specific combination will doubtless exist and do
have the problems you describe but are probably less frequent but I
think we can go a long way on the first two.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Handling of modular boards
From: Linus Walleij @ 2012-05-08 12:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Lee Jones, Mark Brown, Samuel Ortiz,
Arnd Bergmann, Olof Johansson, Stephen Warren, Igor Grinberg,
linux-embedded, linux-kernel
In-Reply-To: <201205041934.08830.arnd@arndb.de>
On Fri, May 4, 2012 at 9:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Thanks for getting the discussion started. I've seen the same issue come
> up for arch/arm/mach-ux500/board-mop500*uib.c and for the beaglebone.
> I'm sure there are many more, but we should make sure that everyone
> of these can live with whatever we come up with.
The same issue sort of comes up with any system that uses the idiom
to have a few GPIO lines indicate in a binary code what version of the
board we're dealing with and what devices are thus on it, right?
We have this issue for the U9540 reference design and potentially
on the Snowball as well.
Yours,
Linus Walleij
^ permalink raw reply
* Re: Handling of modular boards
From: Linus Walleij @ 2012-05-08 12:33 UTC (permalink / raw)
To: Mark Brown, Alessandro Rubini
Cc: Stephen Warren, Samuel Ortiz, linux-embedded, linux-kernel,
Igor Grinberg, Olof Johansson, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <20120504204455.GR14230@opensource.wolfsonmicro.com>
On Fri, May 4, 2012 at 10:44 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, May 04, 2012 at 01:50:01PM -0600, Stephen Warren wrote:
>
>> b) Doesn't integrate well with hotplug; the DT for the board
>> configuration is static at boot. What if a board can be unplugged and
>> another plugged in; a reboot or similar would be needed to adjust the
>> kernel to this.
>
> This is another issue - a similar set of problems does apply to some PCI
> type cards where the PCI device is essentially a bridge to a typical
> embedded system - though practically speaking it's much less severe.
I think Alessandro is working on a board like that right now, so looping
in Ale to this discussion to get his attention...
Linus Walleij
^ permalink raw reply
* Re: Handling of modular boards
From: Alessandro Rubini @ 2012-05-09 8:41 UTC (permalink / raw)
To: linus.walleij
Cc: broonie, swarren, sameo, linux-embedded, linux-kernel, grinberg,
olof, arnd, linux-arm-kernel
In-Reply-To: <CACRpkdbyp=BNGn8Eub6vcAgB9CS5PhYcGt2foi8kNxA3oU5Fzg@mail.gmail.com>
Hello.
>> This is another issue - a similar set of problems does apply to some PCI
>> type cards where the PCI device is essentially a bridge to a typical
>> embedded system - though practically speaking it's much less severe.
>
> I think Alessandro is working on a board like that right now, so looping
> in Ale to this discussion to get his attention...
> I think Alessandro is working on a board like that right now, so looping
> in Ale to this discussion to get his attention...
Yes, that's it. The vendor of my thing has wrapped everything under
pci headers, so the "typical embedded system", which actually is a
demasculated ARM SoC is self-described by PCI (no need for device tree)
A previous poster said:
>>> b) Doesn't integrate well with hotplug; the DT for the board
>>> configuration is static at boot. What if a board can be unplugged and
>>> another plugged in; a reboot or similar would be needed to adjust the
>>> kernel to this.
I think you need some enumeration mechanism in this case. Actually, I
think this will become common in the near future, as you can reprogram
your FPGA devices while the system runs.
The issue is real, and I'm involved in a self-description project; it
allows to use the well-known bus abstraction (with bus controller,
devices, drivers) to ease handling soft cores that may come and go
while the system is alive.
Thank you Linus for involving me, I'll now go to read the whole thread
/alessandro
^ permalink raw reply
* Re: Handling of modular boards
From: Mark Brown @ 2012-05-09 17:12 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, linux-arm-kernel, Lee Jones, Samuel Ortiz,
Arnd Bergmann, Olof Johansson, Stephen Warren, Igor Grinberg,
linux-embedded, linux-kernel
In-Reply-To: <CACRpkdb4LGXfJ72uODr841O7M4FGTYKa1X7y6ekeLUw9vaL=mw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On Tue, May 08, 2012 at 02:26:54PM +0200, Linus Walleij wrote:
> On Fri, May 4, 2012 at 9:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Thanks for getting the discussion started. I've seen the same issue come
> > up for arch/arm/mach-ux500/board-mop500*uib.c and for the beaglebone.
> > I'm sure there are many more, but we should make sure that everyone
> > of these can live with whatever we come up with.
> The same issue sort of comes up with any system that uses the idiom
> to have a few GPIO lines indicate in a binary code what version of the
> board we're dealing with and what devices are thus on it, right?
> We have this issue for the U9540 reference design and potentially
> on the Snowball as well.
Yes, I think that's basically the same problem.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Handling of modular boards
From: Ben Dooks @ 2012-05-10 10:41 UTC (permalink / raw)
To: Mark Brown
Cc: Wolfgang Denk, linux-embedded, Samuel Ortiz, Arnd Bergmann,
Stephen Warren, Linus Walleij, linux-kernel, Igor Grinberg,
Olof Johansson, Lee Jones, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <20120504220944.GT14230@opensource.wolfsonmicro.com>
On Fri, May 04, 2012 at 11:09:45PM +0100, Mark Brown wrote:
> On Fri, May 04, 2012 at 10:33:57PM +0200, Wolfgang Denk wrote:
>
> > On the other hand, some of the issues we're trying to solve here
> > for the kernel are also present in the boot loader, so this needs to
> > do this anyway - whether by inserting new or modifying (enabling or
> > disabling) existing properties in the DT is not really relevant here.
>
> FWIW if the bootloader can usefully handle this stuff I think that's a
> good approach but there is substantial variation in quality of
> implementation between bootloaders and even when the bootloader is a
> good one it's not always practical to update it or the data it relies
> on.
I agree, the list of devices should be in the device-tree handed to
whatever OS is being booted. It isn't a Linux specific problem that
we're looking at here.
Any operating system, pre-OS test suite, etc. is going going to need
this information, and in my view the bootloader should be doing whatever
is needed to create a device-tree to passed through to the next loaded
system.
Also, having the information available to $bootloader means the user
can verify the presence of the peripherals before the OS is loaded.
--
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* Re: Handling of modular boards
From: Ben Dooks @ 2012-05-10 10:43 UTC (permalink / raw)
To: Stephen Warren
Cc: Mark Brown, Samuel Ortiz, linux-embedded, linux-kernel,
Igor Grinberg, Olof Johansson, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <4FA432E9.9050606@wwwdotorg.org>
On Fri, May 04, 2012 at 01:50:01PM -0600, Stephen Warren wrote:
> On 05/04/2012 12:58 PM, Mark Brown wrote:
> > Quite a few reference platforms (including Wolfson ones, which is why
> > I'm particularly interested) use replaceable modules to allow
> > configuration changes. Since we can often identify the configuration at
> > runtime we should ideally do that but currently there's no infrastructure
> > to help with that...
>
> So, I'll respond within the context of device tree, although perhaps you
> were looking for something more general?
>
> I was just asked basically the same question internally to NVIDIA. One
> option that was floated was to store the device tree in chunks and have
> the bootloader piece them together. You'd start with the DT for the
> basic CPU board, probe what HW was available, and then graft in the
> content of additional DT chunks and pass the final result to the kernel.
> The advantages here are:
>
> a) The DT is stored in chunks for each plugin board, so there's no bloat
> in the DT that gets passed to the kernel; it contains exactly what's on
> the board.
Interesting, but how does it sort ofu things like mapping GPIO lines from
the add-in board's view to the rest of the system?
--
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* Re: Handling of modular boards
From: Igor Grinberg @ 2012-05-10 12:40 UTC (permalink / raw)
To: Mark Brown
Cc: Wolfgang Denk, Arnd Bergmann, linux-arm-kernel, Lee Jones,
Samuel Ortiz, Arnd Bergmann, Olof Johansson, Stephen Warren,
linux-embedded, linux-kernel, Linus Walleij
In-Reply-To: <20120504220944.GT14230@opensource.wolfsonmicro.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/05/12 01:09, Mark Brown wrote:
> On Fri, May 04, 2012 at 10:33:57PM +0200, Wolfgang Denk wrote:
>
>> On the other hand, some of the issues we're trying to solve here
>> for the kernel are also present in the boot loader, so this needs to
>> do this anyway - whether by inserting new or modifying (enabling or
>> disabling) existing properties in the DT is not really relevant here.
>
> FWIW if the bootloader can usefully handle this stuff I think that's a
> good approach but there is substantial variation in quality of
> implementation between bootloaders and even when the bootloader is a
> good one it's not always practical to update it or the data it relies
> on.
I agree on this (and also with Ben), all our boards/extensions/base boards/etc
can be discovered in the boot loader and we will use the DT to pass
the relevant information on the attached extensions and used base board.
Also, most (if not all) of our boards/extensions have I2C EEPROM which
describes the devices on that board/extension which is useful for
building/extending the DT in the bootloader.
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPq7dXAAoJEBDE8YO64Efag7sQAJ4Ipk/A24p6mO6ROtcd+q2s
gGlEjLHeZ7sNPnwCOCakCgX7+SYXKBv6w5aWKM70eLDUfoVLu9eaUeT4sYd2fGtR
4xFVkcYRenzkuO7MZ3GccAAF4Hg4WwMAn/3StIJU6pyBY7OmOsbqnoTa7PJjKr/J
HwwM8g8eo3q4tg2sB5P922Fol61BK2Wo3S7I9kzHtnwUx9yW3aG2mf/ublfXHUkQ
3RKfXrdREFJL30j9SrJzh6wVqQoE9Y7UrYs1BIiAs9AL/d2+eYgSPNKh/iBw+26f
V+Tr8t9xPyP1b1HGUjLVtGmwWtLncws2kfYnMcjvLKgES967SRbSboqRqwJL95yR
h9xKoVVrqC9lCXZn/uZCHmRaj/7DaPqr4/tbJefJTcU4ErS7bv/QxXARaj41SmS9
sq8A+qefiKaleBfinmiXjoCu8QcUKmfLF8oLt52tylb/4CUnipf4jLbnQ9fdPxGB
gQnrlg6T3WVTR7fzhOsXrgHQvocJa+3/YSYUyWbNvfjJBWFV6ZqERjTQCvhkXivG
bbwBn6tHAol+tRAUfGudlwzcaZZGbJ+vvK/GmSCI+tSfgz++O9uvd0spklatB4ab
NyikQLZBvSufnyWSY6Mp3iShhwgGZosxu9OGgQzclEh1tC8LQEbxOwETaRi/7uGq
PkkXsoPrmBc0C0dO+fIc
=icYW
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Handling of modular boards
From: Stephen Warren @ 2012-05-10 16:11 UTC (permalink / raw)
To: Ben Dooks
Cc: Mark Brown, Samuel Ortiz, linux-embedded, linux-kernel,
Igor Grinberg, Olof Johansson, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <20120510104311.GB30103@trinity.fluff.org>
On 05/10/2012 04:43 AM, Ben Dooks wrote:
> On Fri, May 04, 2012 at 01:50:01PM -0600, Stephen Warren wrote:
>> On 05/04/2012 12:58 PM, Mark Brown wrote:
>>> Quite a few reference platforms (including Wolfson ones, which is why
>>> I'm particularly interested) use replaceable modules to allow
>>> configuration changes. Since we can often identify the configuration at
>>> runtime we should ideally do that but currently there's no infrastructure
>>> to help with that...
>>
>> So, I'll respond within the context of device tree, although perhaps you
>> were looking for something more general?
>>
>> I was just asked basically the same question internally to NVIDIA. One
>> option that was floated was to store the device tree in chunks and have
>> the bootloader piece them together. You'd start with the DT for the
>> basic CPU board, probe what HW was available, and then graft in the
>> content of additional DT chunks and pass the final result to the kernel.
>> The advantages here are:
>>
>> a) The DT is stored in chunks for each plugin board, so there's no bloat
>> in the DT that gets passed to the kernel; it contains exactly what's on
>> the board.
>
> Interesting, but how does it sort ofu things like mapping GPIO lines from
> the add-in board's view to the rest of the system?
To be fully general, we'd need to have some kind of proxy GPIO object
that always exists on the main board, for the plugin boards to provide
GPIOs to, or consume GPIOs from.
The simple case of a GPIO provider being on the main board and the
consumer being on a plugin board doesn't need this. The case of the GPIO
provider being on a plugin board, and the only GPIO consumer being on
the main board might not need this.
But if the GPIO provider is on one plugin board, and the GPIO consumer
on another, we'd want to have the DT chunks for each plugin board be
completely independent, so you'd need to route everything through
something that always exists, in the motherboard's DT. I haven't really
thought how that would look yet.
I think this is probably true irrespective of whether the bootloader is
merging the DT chunks, or the kernel did it during boot, or any other
way of constructing the final complete DT.
^ permalink raw reply
* Re: Handling of modular boards
From: Stephen Warren @ 2012-05-10 16:15 UTC (permalink / raw)
To: Igor Grinberg
Cc: Mark Brown, Wolfgang Denk, Arnd Bergmann, linux-arm-kernel,
Lee Jones, Samuel Ortiz, Arnd Bergmann, Olof Johansson,
linux-embedded, linux-kernel, Linus Walleij
In-Reply-To: <4FABB758.7000702@compulab.co.il>
On 05/10/2012 06:40 AM, Igor Grinberg wrote:
> On 05/05/12 01:09, Mark Brown wrote:
>> On Fri, May 04, 2012 at 10:33:57PM +0200, Wolfgang Denk wrote:
>
>>> On the other hand, some of the issues we're trying to solve
>>> here for the kernel are also present in the boot loader, so
>>> this needs to do this anyway - whether by inserting new or
>>> modifying (enabling or disabling) existing properties in the DT
>>> is not really relevant here.
>
>> FWIW if the bootloader can usefully handle this stuff I think
>> that's a good approach but there is substantial variation in
>> quality of implementation between bootloaders and even when the
>> bootloader is a good one it's not always practical to update it
>> or the data it relies on.
>
> I agree on this (and also with Ben), all our boards/extensions/base
> boards/etc can be discovered in the boot loader and we will use the
> DT to pass the relevant information on the attached extensions and
> used base board.
>
> Also, most (if not all) of our boards/extensions have I2C EEPROM
> which describes the devices on that board/extension which is useful
> for building/extending the DT in the bootloader.
I believe that's true for all/many NVIDIA boards too.
But, duplicating all this in every bootloader might not make sense.
Sure there are some cases where the bootloader needs this information
(e.g. to load the kernel from an SD card that's on 1 of N plugin
boards), but there may be much information the bootloader doesn't care
about.
Would it make sense to write a DT-identifying-and-merging shim that
can be executed by the bootloader, create the final DT, and then jump
to the kernel?
Hmmm. That's probably a bad idea, since then it means needing e.g. I2C
drivers to read the ID EEPROMs, pinmux drivers, ... in the shim.
Perhaps the common shim idea makes sense, but we need a standardized
API it can use that all bootloaders provide for it to operate.
This is beginning to sound a lot like a UEFI byte code module (I
assume; I know little about them)
^ permalink raw reply
* Re: Handling of modular boards
From: Igor Grinberg @ 2012-05-11 6:15 UTC (permalink / raw)
To: Stephen Warren
Cc: Mark Brown, Wolfgang Denk, Arnd Bergmann, linux-arm-kernel,
Lee Jones, Samuel Ortiz, Arnd Bergmann, Olof Johansson,
linux-embedded, linux-kernel, Linus Walleij
In-Reply-To: <4FABE9BE.2010108@wwwdotorg.org>
On 05/10/12 19:15, Stephen Warren wrote:
> On 05/10/2012 06:40 AM, Igor Grinberg wrote:
>> On 05/05/12 01:09, Mark Brown wrote:
>>> On Fri, May 04, 2012 at 10:33:57PM +0200, Wolfgang Denk wrote:
>>
>>>> On the other hand, some of the issues we're trying to solve
>>>> here for the kernel are also present in the boot loader, so
>>>> this needs to do this anyway - whether by inserting new or
>>>> modifying (enabling or disabling) existing properties in the DT
>>>> is not really relevant here.
>>
>>> FWIW if the bootloader can usefully handle this stuff I think
>>> that's a good approach but there is substantial variation in
>>> quality of implementation between bootloaders and even when the
>>> bootloader is a good one it's not always practical to update it
>>> or the data it relies on.
>>
>> I agree on this (and also with Ben), all our boards/extensions/base
>> boards/etc can be discovered in the boot loader and we will use the
>> DT to pass the relevant information on the attached extensions and
>> used base board.
>>
>> Also, most (if not all) of our boards/extensions have I2C EEPROM
>> which describes the devices on that board/extension which is useful
>> for building/extending the DT in the bootloader.
>
> I believe that's true for all/many NVIDIA boards too.
>
> But, duplicating all this in every bootloader might not make sense.
Yeah, I agree on this, especially when you have multiple bootloaders
for the same board...
On the other hand, that is a common problem of the open source
software - anyone can create a bootloader, publish and use it...
> Sure there are some cases where the bootloader needs this information
> (e.g. to load the kernel from an SD card that's on 1 of N plugin
> boards), but there may be much information the bootloader doesn't care
> about.
>
> Would it make sense to write a DT-identifying-and-merging shim that
> can be executed by the bootloader, create the final DT, and then jump
> to the kernel?
>
> Hmmm. That's probably a bad idea, since then it means needing e.g. I2C
> drivers to read the ID EEPROMs, pinmux drivers, ... in the shim.
>
> Perhaps the common shim idea makes sense, but we need a standardized
> API it can use that all bootloaders provide for it to operate.
Let's see where we're heading:
We created/extended the DT to abstract all the SoC/board specific
(probably also undetectable) stuff away from the kernel and now we will
create a special shi(t)m that will interface the bootloader and create the DT?
I don't think it is a good idea, especially because you still need to change
the bootloader(s) and if you place the I2C/pinmux/gpio drivers inside that
shi(t)m, you duplicate the bootloader, no?
I think we should let the bootloader(s) create/extend the DT and if for some
reason a bootloader wants to separate the DT code into a shim, let it be so.
>
> This is beginning to sound a lot like a UEFI byte code module (I
> assume; I know little about them)
That's another curse... probably we will not get away from it...
--
Regards,
Igor.
^ permalink raw reply
* [PATCH] kernel: Shrink embedded kernel, remove WARN strings when !CONFIG_PRINTK
From: Joe Perches @ 2012-05-23 1:34 UTC (permalink / raw)
To: linux-kernel
Cc: linux-embedded, Paul Gortmaker, linux-arm-kernel, Matt Mackall,
David Woodhouse
WARN strings are currently always saved in text.
When printk is not enabled, this wastes space.
Don't call or compile slowpath_warn_<foo> when !CONFIG_PRINTK.
This makes an embedded image without printk support ~1% smaller.
x86-32 allnoconfig/embedded:
$ size vmlinux.new vmlinux.old
text data bss dec hex filename
1180807 182720 1269372 2632899 282cc3 vmlinux.new
1198760 182720 1267948 2649428 286d54 vmlinux.old
Signed-off-by: Joe Perches <joe@perches.com>
---
include/asm-generic/bug.h | 18 +++++++++++++++++-
kernel/panic.c | 3 +++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 2520a6e..a16101a 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -59,7 +59,8 @@ struct bug_entry {
* appear at runtime. Use the versions with printk format strings
* to provide better diagnostics.
*/
-#ifndef __WARN_TAINT
+#if !defined(__WARN_TAINT)
+
#ifndef __ASSEMBLY__
extern __printf(3, 4)
void warn_slowpath_fmt(const char *file, const int line,
@@ -70,15 +71,30 @@ void warn_slowpath_fmt_taint(const char *file, const int line, unsigned taint,
extern void warn_slowpath_null(const char *file, const int line);
#define WANT_WARN_ON_SLOWPATH
#endif
+
+#ifdef CONFIG_PRINTK
#define __WARN() warn_slowpath_null(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg)
#define __WARN_printf_taint(taint, arg...) \
warn_slowpath_fmt_taint(__FILE__, __LINE__, taint, arg)
#else
+#define __WARN() do {} while (0)
+#define __WARN_printf(fmt, ...) \
+do { \
+ if (0) \
+ printk(fmt, ##__VA_ARGS__); \
+} while (0)
+#define __WARN_printf_taint(taint, fmt, ...) \
+ __WARN_printf(fmt, ##__VA_ARGS__)
+#endif
+
+#else
+
#define __WARN() __WARN_TAINT(TAINT_WARN)
#define __WARN_printf(arg...) do { printk(arg); __WARN(); } while (0)
#define __WARN_printf_taint(taint, arg...) \
do { printk(arg); __WARN_TAINT(taint); } while (0)
+
#endif
#ifndef WARN_ON
diff --git a/kernel/panic.c b/kernel/panic.c
index 8ed89a1..bc57785 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -396,6 +396,7 @@ struct slowpath_args {
va_list args;
};
+#ifdef CONFIG_PRINTK
static void warn_slowpath_common(const char *file, int line, void *caller,
unsigned taint, struct slowpath_args *args)
{
@@ -449,6 +450,8 @@ void warn_slowpath_null(const char *file, int line)
EXPORT_SYMBOL(warn_slowpath_null);
#endif
+#endif
+
#ifdef CONFIG_CC_STACKPROTECTOR
/*
^ permalink raw reply related
* Bids for open project proposals
From: Tim Bird @ 2012-05-24 23:59 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded
Everyone,
The CE Working Group has been collecting project proposals for 2012
contract work at:
http://elinux.org/Project_Proposals_for_2012
Most of this work is related to enhancing aspects of the Linux
kernel for use in embedded products.
The Architecture Group of the CEWG will be considering these
proposals at a meeting in Japan on June 5. I realize that time
is very short, and I apologize for the late notice. However,
if you are interested in bidding on any of these projects, please
send me an email with either a formal bid, or at a minimum, some
information about yourself. This should include your hourly rate,
amount of available time, and experience with embedded Linux
development. If you have any special qualifications - like having
worked on the particular subsystem in question - then please
list that as well.
Thanks and regards,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Q: file system for embedded
From: Ran Shalit @ 2012-06-13 21:31 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <CAJ2oMh++ji7YBrx6UcLdhPVDmLuTZCr8kGQR8aEAYWyob_ccBQ@mail.gmail.com>
Hello,
I hope you can help main understand issue of file system for embedded linux.
I read free-electrons "Embedded Linux system development training" and
some of the files recommended there such as cramfs, are aceesing the
flash during execution of apllications. As far as I understand
accessing the flash after initilization is not good in embedded
system.
Is there something here that I am missing ?
Thanks, Ran
^ permalink raw reply
* Re: Q: file system for embedded
From: Christophe Aeschlimann @ 2012-06-14 8:34 UTC (permalink / raw)
To: Ran Shalit; +Cc: linux-embedded
In-Reply-To: <CAJ2oMhLpMJZ_UT1Z+12s7=5hGjRbA9WNvv3CU4m9B2rDp9yr3Q@mail.gmail.com>
Hi,
Le 13.06.2012 23:31, Ran Shalit a écrit :
> Hello,
>
> I hope you can help main understand issue of file system for embedded linux.
> I read free-electrons "Embedded Linux system development training" and
> some of the files recommended there such as cramfs, are aceesing the
> flash during execution of apllications. As far as I understand
> accessing the flash after initilization is not good in embedded
> system.
Define not good... some applications requires write accesses to the
flash. (how would you program music in your MP3 player ? Where do you
store crash dumps so they are persistent across reboot ? Where do you
store your user configurable options, etc.)
There are different kinds of flash memory but each have a limited number
of program/erase cycle so you have to use them sparingly. (e.g. make
sure the write accesses are distributed across the chip that's called
"wear levelling", detect when bits have toggled and correct the error
using some extra redundancy stored in the out-of-band area of each block
(e.g. ECC). If the error cannot be repaired mark the block as unusable.
When you access the bare memory chips then these issues are solved in
the different layers of MTD [1] and the specific flash file system [2] :
JFFS2, UBIFS, etc.
If you don't access the bare memory chips e.g. you use eMMC or an SSD
these problems are left to a dedicated controller/firmware.
[1] http://www.linux-mtd.infradead.org/index.html
[2] http://elinux.org/File_Systems
Best regards,
--
Christophe Aeschlimann
Embedded Software Engineer & IT Manager
ACN Advanced Communications Networks S.A.
2000 - Neuchâtel, Switzerland
Tel. +41 32 724 74 31
^ permalink raw reply
* Re: Q: file system for embedded
From: Ran Shalit @ 2012-06-14 12:58 UTC (permalink / raw)
To: Christophe Aeschlimann; +Cc: linux-embedded
In-Reply-To: <4FD9A22B.7060207@acn-group.ch>
On Thu, Jun 14, 2012 at 11:34 AM, Christophe Aeschlimann
<c.aeschlimann@acn-group.ch> wrote:
> Hi,
>
> Le 13.06.2012 23:31, Ran Shalit a écrit :
>
>> Hello,
>>
>> I hope you can help main understand issue of file system for embedded linux.
>> I read free-electrons "Embedded Linux system development training" and
>> some of the files recommended there such as cramfs, are aceesing the
>> flash during execution of apllications. As far as I understand
>> accessing the flash after initilization is not good in embedded
>> system.
>
>
> Define not good... some applications requires write accesses to the
> flash. (how would you program music in your MP3 player ? Where do you
> store crash dumps so they are persistent across reboot ? Where do you
> store your user configurable options, etc.)
>
> There are different kinds of flash memory but each have a limited number
> of program/erase cycle so you have to use them sparingly. (e.g. make
> sure the write accesses are distributed across the chip that's called
> "wear levelling", detect when bits have toggled and correct the error
> using some extra redundancy stored in the out-of-band area of each block
> (e.g. ECC). If the error cannot be repaired mark the block as unusable.
>
> When you access the bare memory chips then these issues are solved in
> the different layers of MTD [1] and the specific flash file system [2] :
> JFFS2, UBIFS, etc.
>
> If you don't access the bare memory chips e.g. you use eMMC or an SSD
> these problems are left to a dedicated controller/firmware.
>
> [1] http://www.linux-mtd.infradead.org/index.html
> [2] http://elinux.org/File_Systems
>
> Best regards,
>
> --
> Christophe Aeschlimann
>
Hi Christophe,
Thanks for the reply.
I have no need to write to flash during the main application
execution: I will program the configuration and executable before
start of execution, and after initialization there is no need to write
again to flash.
What I still do not understand is why cramfs, ubifs are recommended
for embedded if they access the flash.
Is accessing the flash not a problem in embedded linux ? What does it
mean using mlockall with cramfs ?
Regards, Ran
^ permalink raw reply
* Re: Q: file system for embedded
From: Christophe Aeschlimann @ 2012-06-14 14:48 UTC (permalink / raw)
To: Ran Shalit; +Cc: linux-embedded
In-Reply-To: <CAJ2oMhKB6684j2_ZzRopCxipnUnuu9GbACCMg08OsHBJ7u6=_g@mail.gmail.com>
Le 14.06.2012 14:58, Ran Shalit a écrit :
> Hi Christophe,
>
> Thanks for the reply.
> I have no need to write to flash during the main application
> execution: I will program the configuration and executable before
> start of execution, and after initialization there is no need to write
> again to flash.
How are you going to program the flash ? Which initialization ?
> What I still do not understand is why cramfs, ubifs are recommended
> for embedded if they access the flash.
For the reasons I gave in my previous email. I never used cramfs but I
see that it is a read-only compressed format (like supported in JFFS2)
which decompresses your data on-the-fly before read/execution hence
allowing to store more information if your flash is small.
> Is accessing the flash not a problem in embedded linux ?
I'm not sure what you mean here. It's not a problem, but it requires
some care.
> What does it mean using mlockall with cramfs ?
Well if you don't have swap enabled mlockall has no effect since there
is nowhere to swap anyway. But I'm not sure I understand your question.
> Regards, Ran
Regards,
--
Christophe Aeschlimann
Embedded Software Engineer & IT Manager
ACN Advanced Communications Networks S.A.
2000 - Neuchâtel, Switzerland
Tel. +41 32 724 74 31
^ permalink raw reply
* Need help regarding the USB mass storage driver
From: Vishal Nandanwar @ 2012-06-20 9:39 UTC (permalink / raw)
To: Linux Docs, Linux Embedded Group, Linux Kernel, Linux USB,
Platform driver x86
Hi,
I am working on a USB mass storage driver for a pen drive. I have done
coding as per the USB_skeleton.c file provided in Linux 3.2 source
code. I could assign the driver to pen drive when pen driver is
inserted in USB connector.
I am stuck in data transfer, could not do the data transfer. During
enumeration interface sub class is 06 i.e. SCSI transparent command
set. Please find my questions below.
1. Where are these SCSI transparent command set documented?
2. Is there any sample code(apart from Linux source) which describes
the SCSI transparent command set and mass storage driver?
3. When I connect the pen drive and associate my driver, pop up
doesn't appear on the screen for this device. but when default
driver(usb_storage) is used this pop up does appear. What I need to do
here?
Any thing other I need to take care here?
Vishal N
^ permalink raw reply
* Re: Need help regarding the USB mass storage driver
From: Thomas Petazzoni @ 2012-06-20 10:12 UTC (permalink / raw)
To: Vishal Nandanwar
Cc: Linux Docs, Linux Embedded Group, Linux Kernel, Linux USB,
Platform driver x86
In-Reply-To: <CAKB833nfHQwdHzCFV6ELrk1-XZT-SN8WxMs=kzO=C8+6foTrDQ@mail.gmail.com>
Le Wed, 20 Jun 2012 15:09:20 +0530,
Vishal Nandanwar <operational.people@gmail.com> a écrit :
> I am working on a USB mass storage driver for a pen drive. I have done
> coding as per the USB_skeleton.c file provided in Linux 3.2 source
> code. I could assign the driver to pen drive when pen driver is
> inserted in USB connector.
Why do you need to write a new driver?
Normally, all the USB storage devices conform to the USB Mass Storage
specification, which means that the usb-storage driver of the Linux
kernel can be used for them. There is no need for a separate driver for
each USB storage device, unless of course it doesn't comply with the
USB Mass Storage specification.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: Need help regarding the USB mass storage driver
From: Alan Stern @ 2012-06-20 15:05 UTC (permalink / raw)
To: Vishal Nandanwar
Cc: Linux Docs, Linux Embedded Group, Linux Kernel, Linux USB,
Platform driver x86
In-Reply-To: <CAKB833nfHQwdHzCFV6ELrk1-XZT-SN8WxMs=kzO=C8+6foTrDQ@mail.gmail.com>
On Wed, 20 Jun 2012, Vishal Nandanwar wrote:
> Hi,
>
> I am working on a USB mass storage driver for a pen drive. I have done
> coding as per the USB_skeleton.c file provided in Linux 3.2 source
> code. I could assign the driver to pen drive when pen driver is
> inserted in USB connector.
Do you understand that the usb_skeleton.c file is totally inappropriate
as a model for a mass-storage driver?
> I am stuck in data transfer, could not do the data transfer. During
> enumeration interface sub class is 06 i.e. SCSI transparent command
> set. Please find my questions below.
>
> 1. Where are these SCSI transparent command set documented?
Google is your friend. But see the answer to your next question...
> 2. Is there any sample code(apart from Linux source) which describes
> the SCSI transparent command set and mass storage driver?
There is no such thing as the SCSI transparent command set. "SCSI
transparent" means "use whatever command set the relevant SCSI standard
specifies".
There is non-Linux source code for mass-storage drivers in other
open-source operating systems.
> 3. When I connect the pen drive and associate my driver, pop up
> doesn't appear on the screen for this device. but when default
> driver(usb_storage) is used this pop up does appear. What I need to do
> here?
Fix your driver. It's not possible to give a more complete answer
without further information.
Alan Stern
^ permalink raw reply
* IPV4 , IPV6 & Colocation Service
From: Dedicatedhk @ 2012-06-28 14:34 UTC (permalink / raw)
Whether you're looking for rack space or bandwidth, we are a smart business decision for IP Transit. We specializes in high quality wholesale bandwidth/rack space.
We have our own datacenter in Hong Kong & provide email/application/web rental service to clients.We are APNIC member & provide clean IPV4/IPV6 to clients.
Pls send us email for further information.Thanks,
Boris
boris@dedicatedserver.com.hk
If you do not wish to further receive this event message, email "borislamsv2@gmail.com" to unsubscribe this message or remove your email from the list.
^ permalink raw reply
* rionet driver with MMIO DMA capability
From: Vineeth @ 2012-07-04 6:15 UTC (permalink / raw)
To: linux-embedded, linuxppc-dev, linuxppc-embedded, Scott Wood,
mporter
Cc: ranenikhil19
[-- Attachment #1.1: Type: text/plain, Size: 715 bytes --]
Hi,
With kernel mainstream version 3.5.rc-5 there's SRIO low level driver with
DMA support for MMIO. But the rionet driver in the same kernel version
doesnt support MMIO.
We are trying to find the maximum bandwidth that we can achieve using our
custom board's(quad MPC8641 ) 4-lane SRIO.
Now we are worried how to use this SRIO low level driver effectively ?
The RIOnet driver (with 3.5.-rc5) uses message based communication. This
doesnt use the DMA capability of low level driver. with this we are getting
a bandwidth of nearly 900Mbps, which is very less.
Is there any example code or modified middle ware driver for rionet/ or any
code which uses the low level driver apis with MMIO DMA??
Thanks
Vineeth
[-- Attachment #1.2: Type: text/html, Size: 782 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: rionet driver with MMIO DMA capability
From: Li Yang-R58472 @ 2012-07-06 2:51 UTC (permalink / raw)
To: Vineeth, linux-embedded@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linuxppc-embedded@ozlabs.org,
Wood Scott-B07421, mporter@kernel.crashing.org
Cc: ranenikhil19@gmail.com, Alexandre Bounine
In-Reply-To: <CAFbQSaDWXTg429q-tTRvcgAEsA1OmHzFVhPNOmSRnWjMpSZfpA@mail.gmail.com>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+leoli=freescale.com@lists.ozlabs.org] On Behalf Of Vineeth
> Sent: Wednesday, July 04, 2012 1:16 AM
> To: linux-embedded@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> linuxppc-embedded@ozlabs.org; Wood Scott-B07421;
> mporter@kernel.crashing.org
> Cc: ranenikhil19@gmail.com
> Subject: rionet driver with MMIO DMA capability
>
>
> Hi,
>
> With kernel mainstream version 3.5.rc-5 there's SRIO low level driver
> with DMA support for MMIO. But the rionet driver in the same kernel
> version doesnt support MMIO.
>
> We are trying to find the maximum bandwidth that we can achieve using our
> custom board's(quad MPC8641 ) 4-lane SRIO.
> Now we are worried how to use this SRIO low level driver effectively ?
>
> The RIOnet driver (with 3.5.-rc5) uses message based communication. This
> doesnt use the DMA capability of low level driver. with this we are
> getting a bandwidth of nearly 900Mbps, which is very less.
>
> Is there any example code or modified middle ware driver for rionet/ or
> any code which uses the low level driver apis with MMIO DMA??
We provided the support for DMA in the old BSPs but didn't got the luck to make it upstream. I heard Alex (CCed) is working on an upstream-able version of the feature. Probably he can help to provide some code.
Leo
^ permalink raw reply
* [announce] Embedded Linux Conference Call for Presentations
From: Tim Bird @ 2012-07-12 18:21 UTC (permalink / raw)
To: linux-embedded
Hello everyone,
I'm writing to remind you all that the ELC Europe 2012
Call for Presentations is currently open. The conference
is in November (5-7) this year, in Barcelona Spain.
We are again co-located with LinuxCon Europe.
We're very excited for this opportunity once again to get
together as an industry and community, to talk about embedded
Linux. If you have been working on some aspect of embedded
Linux, such as security, audio, video, graphics, system size,
bootup time, power management, distribution, build systems
or tools, please consider submitting a proposal for the event.
The deadline for proposal submissions is August 1, which is
coming up in just a few weeks. It's right during vacation
season in Europe, so please don't forget!
For details on submitting a presentation proposal, please see:
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/cfp
We had a great time last year. For examples of previous
presentations, see: http://elinux.org/ELCE_2011_Presentations
or look at last year's schedule:
http://events.linuxfoundation.org/archive/2011/embedded-linux-conference-europe/schedule
I look forward to hearing about the interesting things you're
working on, and to seeing you at the event.
Thanks and regards,
-- Tim Bird
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox