* 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: 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-04 23:40 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: <20120504225514.GM897@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]
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.
> It also helps to give the right model to the power management support,
> because you're automatically arranging the child devices below the
> board-level device, which means all the child devices should be
> suspended before the board level device, and the board level device
> should be resumed before the child devices.
Yes, I'd anticipate that we'd have a device for the board which should
help with this sort of stuff.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Handling of modular boards
From: Russell King - ARM Linux @ 2012-05-04 22:55 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: <20120504185850.GO14230@opensource.wolfsonmicro.com>
On Fri, May 04, 2012 at 07:58:51PM +0100, 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, generally this seems to be done in arch code for the
> machine but this doesn't scale when even the CPU might change and isn't
> terribly device tree compatible either.
>
> For reference the code for current Wolfson plugin modules is in
> arch/arm/mach-s3c64xx/mach-crag6410-module.c.
>
> The most obvious current fit here is the MFD subsystem but it feels like
> we need some slightly different infastructure to what MFD currently
> provides. MFD is really set up to handle platform devices with a core
> and linear ranges of resources fanning out from that core since they're
> really oriented around chips. In contrast these boards are more about
> remapping random collections of potentially unrelated resources and
> instantiating devices on all sorts of buses and share more with board
> files.
>
> 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.
This is exactly how I've now setup the Assabet with Neponset daughter
board - all the Neponset devices sit behind the Neponset platform
device, including things like the SA1111 multifunction chip and SMC91x
network interface. I can bind and unbind the Neponset device from its
driver and have everything behind that driver appear and disappear
appropriately - which is useful if your modules can be hotplugged.
It also helps to give the right model to the power management support,
because you're automatically arranging the child devices below the
board-level device, which means all the child devices should be
suspended before the board level device, and the board level device
should be resumed before the child devices.
^ permalink raw reply
* Re: Handling of modular boards
From: Mark Brown @ 2012-05-04 22:09 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Arnd Bergmann, linux-arm-kernel, Lee Jones, Samuel Ortiz,
Arnd Bergmann, Olof Johansson, Stephen Warren, Igor Grinberg,
linux-embedded, linux-kernel, Linus Walleij
In-Reply-To: <20120504203357.6B79B206451@gemini.denx.de>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Handling of modular boards
From: Mark Brown @ 2012-05-04 21:52 UTC (permalink / raw)
To: Stephen Warren
Cc: Arnd Bergmann, linux-arm-kernel, Wolfgang Denk, Samuel Ortiz,
linux-embedded, Linus Walleij, linux-kernel, Igor Grinberg,
Olof Johansson, Lee Jones
In-Reply-To: <4FA4457F.1010900@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On Fri, May 04, 2012 at 03:09:19PM -0600, Stephen Warren wrote:
> On 05/04/2012 03:03 PM, Arnd Bergmann wrote:
> > Sure, there are a lot of things that the boot loader can use from the
> > device tree, but I'm not sure if the LCD panel connection fits into
> > the same category as the devices that Mark was thinking of.
> A board I have sitting on my desk right now has separate boards for (and
> multiple options for each of):
> * Motherboard
> * CPU+DRAM
> * PMU/PMIC
> * Display (LCD)
> ... and many more.
> Interaction with the PMU/PMIC is required for at least some of the boot
> media options.
Yeah, similar setup for our boards except the PMICs are soldered down
onto other boards. We've got a mainboard, three audio boards of various
kinds, a random non-audio components board and a CPU/DRAM board.
There's good solid engineering reasons for doing this. CPUs and RAMs
tend to be very high density devices with lots of pins and be difficult
enough to route to require large numbers of layers (and ideally you want
the PMIC to be physically close to them since long traces tend to become
electrically interesting for CPU style loads, especially when routed
through connectors) all of which leads to an expensive board which you
pay for by area. With reference boards with large form factors it's
worth the effort to have a separate, smaller, board manufactured to meet
these requirements - even in very low volumes the cost wins are
noticable.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Handling of modular boards
From: Stephen Warren @ 2012-05-04 21:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Wolfgang Denk, Samuel Ortiz, linux-embedded,
Linus Walleij, Mark Brown, linux-kernel, Igor Grinberg,
Olof Johansson, Lee Jones
In-Reply-To: <201205042103.34285.arnd@arndb.de>
On 05/04/2012 03:03 PM, Arnd Bergmann wrote:
> On Friday 04 May 2012, Wolfgang Denk wrote:
>> There are systems (and I bet it will be a growing number) where U-Boot
>> itself uses the DT for configuration. Also, there are functions that
>> are needed both by the boot loader and the kernel - for example to
>> dislay a splash screen the boot loader needs to initialize the
>> display, so it must be able to detect which type of LCD is attached
>> (resolution, color-depth, orientation) - the device tree comes in very
>> handy here. Why should Linux re-do all such things?
>
> Sure, there are a lot of things that the boot loader can use from the
> device tree, but I'm not sure if the LCD panel connection fits into
> the same category as the devices that Mark was thinking of.
A board I have sitting on my desk right now has separate boards for (and
multiple options for each of):
* Motherboard
* CPU+DRAM
* PMU/PMIC
* Display (LCD)
... and many more.
Interaction with the PMU/PMIC is required for at least some of the boot
media options.
Interaction with the display (LCD) while not technically required to
simply boot the kernel is required by desired use-cases, in order to
display a splash screen ASAP during early boot.
Oh, and the motherboard has a gazillion different HW mux options, which
affect, amongst many other things, which SD/eMMC/SDIO ports are usable
on the motherboard, and which are routed to various daughter boards. I'm
not actually 100% sure if the switches controlling those mux settings
are readable from SW. I certainly hope so...
^ permalink raw reply
* Re: Handling of modular boards
From: Arnd Bergmann @ 2012-05-04 21:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Wolfgang Denk, Samuel Ortiz, linux-embedded, Stephen Warren,
Linus Walleij, Mark Brown, linux-kernel, Igor Grinberg,
Olof Johansson, Lee Jones
In-Reply-To: <20120504205441.D293120645E@gemini.denx.de>
On Friday 04 May 2012, Wolfgang Denk wrote:
> There are systems (and I bet it will be a growing number) where U-Boot
> itself uses the DT for configuration. Also, there are functions that
> are needed both by the boot loader and the kernel - for example to
> dislay a splash screen the boot loader needs to initialize the
> display, so it must be able to detect which type of LCD is attached
> (resolution, color-depth, orientation) - the device tree comes in very
> handy here. Why should Linux re-do all such things?
Sure, there are a lot of things that the boot loader can use from the
device tree, but I'm not sure if the LCD panel connection fits into
the same category as the devices that Mark was thinking of.
Anyway, display controllers are definitely something that needs to
be handled in some way, which may or may not be the same way we
handle more complex collections of arbitrary devices.
Arnd
^ permalink raw reply
* Re: Handling of modular boards
From: Stephen Warren @ 2012-05-04 20:59 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Mark Brown, Samuel Ortiz, Arnd Bergmann, Olof Johansson,
Igor Grinberg, linux-arm-kernel, linux-embedded, linux-kernel
In-Reply-To: <20120504203857.49EAD206451@gemini.denx.de>
On 05/04/2012 02:38 PM, Wolfgang Denk wrote:
> Dear Stephen,
>
> In message <4FA432E9.9050606@wwwdotorg.org> you wrote:
>>
>> representation of how to identify the child boards, and then have the
>> kernel only use/parse certain chunks of the DT based on the ID results.
>
> I expect that this will quickly cause problems, for example in those
> many cases where pins and peripheral functions are multiplexed, or
> usable for different purposes. I would not want to maintain a DT that
> has to describe all combinations used by some boards - in a way that
> does not cause conflicts on either of them.
With the DT pinctrl bindings, you can define the pinctrl configuration
required to interact with particular child boards in the DT chunk for
that child board. So, I think this would work out fine; you wouldn't
have to represent a huge maze/array of conditional pinctrl settings in
the main board file.
^ permalink raw reply
* Re: Handling of modular boards
From: Wolfgang Denk @ 2012-05-04 20:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Lee Jones, Mark Brown, Samuel Ortiz,
Olof Johansson, Stephen Warren, Igor Grinberg, linux-embedded,
linux-kernel, Linus Walleij
In-Reply-To: <201205042039.25794.arnd@arndb.de>
Dear Arnd,
In message <201205042039.25794.arnd@arndb.de> you 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.
>
> I haven't seen a case where the add-on board is actually required
> for booting. What examples are you thinking of?
There are systems (and I bet it will be a growing number) where U-Boot
itself uses the DT for configuration. Also, there are functions that
are needed both by the boot loader and the kernel - for example to
dislay a splash screen the boot loader needs to initialize the
display, so it must be able to detect which type of LCD is attached
(resolution, color-depth, orientation) - the device tree comes in very
handy here. Why should Linux re-do all such things?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I must follow the people. Am I not their leader? - Benjamin Disraeli
^ permalink raw reply
* Re: Handling of modular boards
From: Mark Brown @ 2012-05-04 20:44 UTC (permalink / raw)
To: Stephen Warren
Cc: Samuel Ortiz, linux-embedded, linux-kernel, Igor Grinberg,
Olof Johansson, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <4FA432E9.9050606@wwwdotorg.org>
[-- Attachment #1.1: Type: text/plain, Size: 4317 bytes --]
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?
Like I just said in reply to Arnd I think that anything that relies on
the device tree is rather optimistic. Device tree isn't even universal
for ARM and there's a huge raft of architectures that have no current
intention to adopt DT at all. For example I understand that a lot of
the Blackfin boards are modular, though I don't know to what extent they
can usefully be enumerated from software.
I know DT is a shiny new toy and all that but when developing generic
infrastructure there needs to be an awareness that we can't rely on it.
> 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.
> a) Relies on the bootloader, so is somewhat out of our control.
Yes, this is a crippling issue for my personal usecases.
> 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.
> Another approach would be to put everything in a single DT, with some
> representation of how to identify the child boards, and then have the
> kernel only use/parse certain chunks of the DT based on the ID results.
> I’m not sure how complex that would be. Perhaps something like:
This does also have the disadvantage of requiring the device tree for
each CPU to be updated for every single plugin module which could get a
bit tedious (this does also apply to the approach of having the
bootloader create the DT - it scales fine if the CPU is a part of the
base board but if the CPU is one of the swappable modules it's less
clear). Plus...
> The complexity here is that all the devices on the daughter board would
> end up being on different buses (e.g. 2 different I2C busses, an SPI
> bus, even an MMIO bus) so representing this in the daughter board nodes
> would be complex. Do we insert a "daughter board mux" onto every single
> bus that's routed to the daughter board connectors, or add the ability
> to dynamically add nodes into pre-existing busses, e.g. add
> /daughter-board/board-a/i2c-0 into /tegra-i2c@xxx/?
...there's this, I'm not sure the daughterboard mux is going to fly.
It's requiring each and every bus to understand this concept which seems
like a bit of an imposition to me, especially given that it exists
purely to service the needs of DT. The idea of having DT blobs injected
for the modules seems easier than this.
I do think we want to be able to write drivers for modules; if we can go
with injecting DT blobs then from a kernel point of view everything is
already sorted so there's nothing to do but this doesn't feel like it
actually resolves the issue, at least for me. For example, with my
current systems it'd require a DT port for s3c6410 plus the addition of
both DT support and hardware module identification to our current
bootloader and then the ongoing maintainance of the device trees for all
the CPU and board combinations that might exist. This seems like a lot
of work.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Handling of modular boards
From: Arnd Bergmann @ 2012-05-04 20:39 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linux-arm-kernel, Lee Jones, Mark Brown, Samuel Ortiz,
Arnd Bergmann, Olof Johansson, Stephen Warren, Igor Grinberg,
linux-embedded, linux-kernel, Linus Walleij
In-Reply-To: <20120504203357.6B79B206451@gemini.denx.de>
On Friday 04 May 2012, Wolfgang Denk wrote:
> In message <201205041934.08830.arnd@arndb.de> you wrote:
> >
> > One idea that I've heard before is to put device tree fragments into the
> > kernel and dynamically add them to the device tree that was passed by the
> > boot loader whenever we detect the presence of a specific device.
> > This obviously means it works only for boards using DT for booting, but
> > it allows us to use some infrastructure that we already have.
> >
> > Another idea was to put all the possible extensions into the device tree
> > for a given board and disable them by default, putting it into the
> > responsibility of the boot loader to enable the one that is actually
> > being used. This has serious scalibility problems when there are many
> > possible extensions and also relies more on the boot loader than I would
> > like.
>
> 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.
I haven't seen a case where the add-on board is actually required
for booting. What examples are you thinking of?
Arnd
^ permalink raw reply
* Re: Handling of modular boards
From: Wolfgang Denk @ 2012-05-04 20:38 UTC (permalink / raw)
To: Stephen Warren
Cc: Mark Brown, Samuel Ortiz, Arnd Bergmann, Olof Johansson,
Igor Grinberg, linux-arm-kernel, linux-embedded, linux-kernel
In-Reply-To: <4FA432E9.9050606@wwwdotorg.org>
Dear Stephen,
In message <4FA432E9.9050606@wwwdotorg.org> you wrote:
>
> representation of how to identify the child boards, and then have the
> kernel only use/parse certain chunks of the DT based on the ID results.
I expect that this will quickly cause problems, for example in those
many cases where pins and peripheral functions are multiplexed, or
usable for different purposes. I would not want to maintain a DT that
has to describe all combinations used by some boards - in a way that
does not cause conflicts on either of them.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
CONSUMER NOTICE: Because of the "Uncertainty Principle," It Is
Impossible for the Consumer to Find Out at the Same Time Both
Precisely Where This Product Is and How Fast It Is Moving.
^ permalink raw reply
* Re: Handling of modular boards
From: Wolfgang Denk @ 2012-05-04 20:33 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, Linus Walleij
In-Reply-To: <201205041934.08830.arnd@arndb.de>
Dear Arnd,
In message <201205041934.08830.arnd@arndb.de> you wrote:
>
> One idea that I've heard before is to put device tree fragments into the
> kernel and dynamically add them to the device tree that was passed by the
> boot loader whenever we detect the presence of a specific device.
> This obviously means it works only for boards using DT for booting, but
> it allows us to use some infrastructure that we already have.
>
> Another idea was to put all the possible extensions into the device tree
> for a given board and disable them by default, putting it into the
> responsibility of the boot loader to enable the one that is actually
> being used. This has serious scalibility problems when there are many
> possible extensions and also relies more on the boot loader than I would
> like.
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.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Our business is run on trust. We trust you will pay in advance.
^ permalink raw reply
* Re: Handling of modular boards
From: Mark Brown @ 2012-05-04 20:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Lee Jones, Samuel Ortiz, Arnd Bergmann,
Olof Johansson, Stephen Warren, Igor Grinberg, linux-embedded,
linux-kernel, Linus Walleij
In-Reply-To: <201205041934.08830.arnd@arndb.de>
On Fri, May 04, 2012 at 07:34:08PM +0000, Arnd Bergmann wrote:
> One idea that I've heard before is to put device tree fragments into the
> kernel and dynamically add them to the device tree that was passed by the
> boot loader whenever we detect the presence of a specific device.
> This obviously means it works only for boards using DT for booting, but
> it allows us to use some infrastructure that we already have.
I think anything that relies on bootloaders (or DT for that matter) is a
bit of a non-starter for my personal use cases. Even where we're using
DT relying on a sane bootloader seems a bit scary - my personal use
cases would rely on updating this stuff in the field for non-technical
users who would have trouble recovering from issues.
> An intermediate solution that I really like is the ability to
> stuff device tree fragments on extension board themselves, but that
> can only work for new designs and causes problems when that information
> is not actually correct.
I can see the theory, but I can also see some practical concerns. And
with the boards I'm working with we currently have 8 bits of data so...
^ permalink raw reply
* Re: Handling of modular boards
From: Stephen Warren @ 2012-05-04 19:50 UTC (permalink / raw)
To: Mark Brown
Cc: Samuel Ortiz, Arnd Bergmann, Olof Johansson, Igor Grinberg,
linux-arm-kernel, linux-embedded, linux-kernel
In-Reply-To: <20120504185850.GO14230@opensource.wolfsonmicro.com>
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.
b) The kernel doesn't have to do anything much; it gets an exact
description of what's on this particular board configuration and doesn't
even care that it's modular.
c) This is probably pretty easy to implement in the bootloader; I
imagine libfdt already has the ability to graft together or overlay
different chunks of DT, and if not, it's most likely easy enough to add.
Disadvantages are:
a) Relies on the bootloader, so is somewhat out of our control.
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.
Another approach would be to put everything in a single DT, with some
representation of how to identify the child boards, and then have the
kernel only use/parse certain chunks of the DT based on the ID results.
I’m not sure how complex that would be. Perhaps something like:
daughter-board {
compatible = “daughter-board-mux-eeprom”;
eeprom = <&i2c_eeprom_node>;
eeprom-offset = <0x10>; // ID address within EEPOM
#address-cells = <2>; // # bytes in EEPROM
board-a {
compatible = “daughter-board”;
reg = <0x1234>;
… nodes for devices on this daughter board
… or perhaps a list of phandles elsewhere to go activate?
};
board-b {
compatible = “daughter-board”;
reg = <0x9876>;
… nodes for devices on this daughter board
};
};
The complexity here is that all the devices on the daughter board would
end up being on different buses (e.g. 2 different I2C busses, an SPI
bus, even an MMIO bus) so representing this in the daughter board nodes
would be complex. Do we insert a "daughter board mux" onto every single
bus that's routed to the daughter board connectors, or add the ability
to dynamically add nodes into pre-existing busses, e.g. add
/daughter-board/board-a/i2c-0 into /tegra-i2c@xxx/?
One advantage here is that everything is explicitly represented to the
kernel, so it has full knowledge of what's going on. Hotplug could
presumably be integrated pretty easily by making the
daughter-board-mux-eeprom able to react to plug events, and re-probe the
ID EEPROM.
^ permalink raw reply
* Re: Handling of modular boards
From: Arnd Bergmann @ 2012-05-04 19:34 UTC (permalink / raw)
To: linux-arm-kernel, Lee Jones
Cc: Mark Brown, Samuel Ortiz, Arnd Bergmann, Olof Johansson,
Stephen Warren, Igor Grinberg, linux-embedded, linux-kernel,
Linus Walleij
In-Reply-To: <20120504185850.GO14230@opensource.wolfsonmicro.com>
On Friday 04 May 2012, 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, generally this seems to be done in arch code for the
> machine but this doesn't scale when even the CPU might change and isn't
> terribly device tree compatible either.
>
> For reference the code for current Wolfson plugin modules is in
> arch/arm/mach-s3c64xx/mach-crag6410-module.c.
Hi Mark,
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 most obvious current fit here is the MFD subsystem but it feels like
> we need some slightly different infastructure to what MFD currently
> provides. MFD is really set up to handle platform devices with a core
> and linear ranges of resources fanning out from that core since they're
> really oriented around chips. In contrast these boards are more about
> remapping random collections of potentially unrelated resources and
> instantiating devices on all sorts of buses and share more with board
> files.
>
> 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.
One idea that I've heard before is to put device tree fragments into the
kernel and dynamically add them to the device tree that was passed by the
boot loader whenever we detect the presence of a specific device.
This obviously means it works only for boards using DT for booting, but
it allows us to use some infrastructure that we already have.
Another idea was to put all the possible extensions into the device tree
for a given board and disable them by default, putting it into the
responsibility of the boot loader to enable the one that is actually
being used. This has serious scalibility problems when there are many
possible extensions and also relies more on the boot loader than I would
like.
An intermediate solution that I really like is the ability to
stuff device tree fragments on extension board themselves, but that
can only work for new designs and causes problems when that information
is not actually correct.
Arnd
^ permalink raw reply
* Handling of modular boards
From: Mark Brown @ 2012-05-04 18:58 UTC (permalink / raw)
To: Samuel Ortiz, Arnd Bergmann, Olof Johansson, Stephen Warren,
Igor Grinberg
Cc: linux-arm-kernel, linux-embedded, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
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, generally this seems to be done in arch code for the
machine but this doesn't scale when even the CPU might change and isn't
terribly device tree compatible either.
For reference the code for current Wolfson plugin modules is in
arch/arm/mach-s3c64xx/mach-crag6410-module.c.
The most obvious current fit here is the MFD subsystem but it feels like
we need some slightly different infastructure to what MFD currently
provides. MFD is really set up to handle platform devices with a core
and linear ranges of resources fanning out from that core since they're
really oriented around chips. In contrast these boards are more about
remapping random collections of potentially unrelated resources and
instantiating devices on all sorts of buses and share more with board
files.
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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Call for presentations for the LSM embedded and open hardware track 2012
From: Florian Fainelli @ 2012-03-06 14:24 UTC (permalink / raw)
To: linux-embedded
The Libre Software Meeting (LSM) is an annual event on free software
taking place in july in France since 2000. The LSM meeting is organized
this year in Geneva, Switzerland from 7th to 12th July. Amongst several
tracks, the Libre Software Meeting will feature an « Embedded Systems
and Open Hardware » track, for which the call for presentations has been
released recently.
The purpose of the “Embedded Systems and Open Hardware” session is to
give the state of the art of free software for embedded systems and Open
Hardware. Technical topics of this session include but are not limited to:
* Embedded OS Development kernel architecture, implementation and port
for embedded systems
* Embedded Development Tools: tool chains and project cases (tool
chain projects, packaging for cross compilation, portability …)
* Embedded Linux, BSD, or any other free operating system
* Real-time extensions for Linux: RTLinux, RTAI…
* Hard real-time kernels: eCos, RTEMS, ADEOS, Xenomai…
* Soft Real-time kernels
* Embedded Java, LUA, Python ...
* GUI for embedded systems: EFL, Qt, Gtk…
* Linux and System on Chip (SoC)
* Open Hardware, Open design, free IP modules (Intellectual Property)
and softcores: opencores, OpenRISC, NIOS, Microblaze, LEONSparc, FPGA…
The conferences will last 30 minutes, questions included. Round tables
will be organized. Synthetic presentations are scheduled to last 20
minutes. PDF versions of the presentation are not mandatory but they
will be greatly appreciated (with an online web access just after the
LSM event, they are a very useful documentation source for the entire
community).
If you plan to participate and to propose a presentation, please send a
message as soon as possible to the following address:
embedded@listes2012.rmll.info with a summary of your presentation (and
if you can, a summary in English too) no later than 31th march 2012.
Feel free to forward this Call For Presentation to other places or to
everyone you think could be interested.
^ permalink raw reply
* Re: ELC2012 Presentations and Video
From: Bill Traynor @ 2012-02-24 12:26 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-embedded
In-Reply-To: <20120224110328.5c93d545@skate>
On Fri, Feb 24, 2012 at 05:03, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello Bill,
>
> Le Wed, 22 Feb 2012 16:46:40 -0500,
> Bill Traynor <wmat@naoi.ca> a écrit :
>
>> A huge thanks to the Linux Foundation for hosting the conference and
>> to Free Electrons for filming the talks.
>
> Thanks for the kind words, but the videos that are online at
> http://video.linux.com/categories/2012-embedded-linux-conference have
> not been recorded by Free Electrons. This year, both the Linux
> Foundation and Free Electrons have recorded the talks, and the videos
> at http://video.linux.com/categories/2012-embedded-linux-conference
> have been recorded by the Linux Foundation, thanks to the technology of
> Ubicast.
Thanks for the clarification, Thomas.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ELC2012 Presentations and Video
From: Thomas Petazzoni @ 2012-02-24 10:03 UTC (permalink / raw)
To: Bill Traynor; +Cc: linux-embedded
In-Reply-To: <CAN20qYon6vLzAFKjY0gh=me9f_GjEKvBMWU5-ep-k=xWu0kSYQ@mail.gmail.com>
Hello Bill,
Le Wed, 22 Feb 2012 16:46:40 -0500,
Bill Traynor <wmat@naoi.ca> a écrit :
> A huge thanks to the Linux Foundation for hosting the conference and
> to Free Electrons for filming the talks.
Thanks for the kind words, but the videos that are online at
http://video.linux.com/categories/2012-embedded-linux-conference have
not been recorded by Free Electrons. This year, both the Linux
Foundation and Free Electrons have recorded the talks, and the videos
at http://video.linux.com/categories/2012-embedded-linux-conference
have been recorded by the Linux Foundation, thanks to the technology of
Ubicast.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* ELC2012 Presentations and Video
From: Bill Traynor @ 2012-02-22 21:46 UTC (permalink / raw)
To: linux-embedded
The majority of the presentations given at ELC 2012 are now online, as is video:
http://elinux.org/ELC_2012_Presentations
http://video.linux.com/categories/2012-embedded-linux-conference
A huge thanks to the Linux Foundation for hosting the conference and
to Free Electrons for filming the talks.
^ permalink raw reply
* [Vortex86] External SPI
From: Lukasz Majewski @ 2012-02-19 22:17 UTC (permalink / raw)
To: linux-rt-users
Cc: Andy O'Brien, platform-driver-x86, linux-8086, linux-iio,
Lukasz Majewski, linux-embedded, soc
Hi all,
I posses a Vortex86DX SoC based computer.
According to the spec it has two SPI interfaces - namely: internal -
access to BIOS and external, which is connected to serial memory
(MX25L3205 [1])
My application requires reading data from SPI sensor. I've given a shot
for a bitbang SPI driver. It worked, but slow access to
GPIOs caused a very slow transmission.
For speed up I've decided to unsolder the memory [1] and solder the
sensor (via 8cm cables).
Unfortunately, documents provided from DM&P[2]: [3] , [4] give some
hints on setting up a base address to get access to the SPI memory
region, and proper GPIO configuration.
What they DO NOT tell is how to perform the SPI transmission.
SPI controller address map:
BA is the Base Address
BA + 08h External SPI Output Data Register (8 bit transfer)
BA + 09h External SPI Input Register
BA + 0Ah External SPI Control Register
BA + 0Bh External SPI Status Register
BA + 0Ch External SPI Chip Select Register
BA + 0Dh External SPI Error Status Register
I've discovered that:
- Access (read/write) to control register (CS) is not causing the clock
generation
- The Chip Select line is directly controlled by bit 0 (1 << 0) in the
"Chip Select Regsiter". It must be explicitly changed (by writing
data to the register) to toggle CS line state. After that the WCTE
bit at "Error Status Register" is set to 1 (which means "controller
busy")
- To send data via SPI, one needs to write the data to the 8 bit
"Output Data Register". It seems, that writing data starts clock
generation. For correct transmission one needs to wait until the ODC
bit at "Status Register" is set to 1.
The _problem_ is with reading data (with full or half duplex):
Inserting:
rx = inb(addr + 0x09); // "SPI Input Register" is not causing
reading data.
However:
Writing data to the "SPI Input Register":
outb(0x00, addr + 0x09) // the CLK generation starts
and waiting for IDR bit at "Status Register" set to 1, causes
operation:
rx = inb(addr + 0x09);
to read correct data.
The above only works when FIFO is enabled (bit FIEN - 4 at "Control
Register")
The problem is, that the sent data seems to be
somewhat random (e.g. the first/last send data) and
I don't have a feeling that I'm fully controlling the operation of SPI.
Conclusion:
- outb is needed to force SPI block to start generating SCLK (also
when one wants to read data).
- FIFO is involved in reading data from SPI - I don't know how to
control it.
- It seems, that the controller is half-duplex.
I suspect, that this simple type of controller has been also used at
other SoC's. Maybe it is an FPGA based design, or some standard Intel's
chip (like 8255). I was asking "uncle google" but with no satisfactory
results.
Has someone dealt with a similar controller? Any advice? Hint?
links:
[1] MX25L3205 - SPI flash memory
http://www.mxic.com.tw/QuickPlace/hq/Main.nsf/h_Toc/5c179475fbb1d010482574440028bdf4/?OpenDocument
[2] http://www.dmp.com.tw/tech/vortex86dx/
[3] "DM&P Vortex86 Series (SX/DX/MX) Software Programming Reference"
[4] "Vortex86DX Fact Sheet 32-BIT x86 SoC"
Best regards,
Lukasz Majewski
^ permalink raw reply
* Re: [PATCH 5/5] logger: clarify non-update of w_off in do_write_log_from_user
From: Dima Zavin @ 2012-02-09 6:10 UTC (permalink / raw)
To: Tim Bird
Cc: Greg KH, linux-embedded, linux kernel, Brian Swetland,
Andrew Morton
In-Reply-To: <4F31DF34.8000205@am.sony.com>
On Tue, Feb 7, 2012 at 6:34 PM, Tim Bird <tim.bird@am.sony.com> wrote:
> Add comment to explain when w_off is not updated in case of failed second
> fragment copy to buffer.
>
> Signed-off-by: Tim Bird <tim.bird@am.sony.com>
Acked-by: Dima Zavin <dima@android.com>
> ---
> drivers/staging/android/logger.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
> index 8d9d4f1..115d8ed 100644
> --- a/drivers/staging/android/logger.c
> +++ b/drivers/staging/android/logger.c
> @@ -330,6 +330,12 @@ static ssize_t do_write_log_from_user(struct logger_log *log,
>
> if (count != len)
> if (copy_from_user(log->buffer, buf + len, count - len))
> + /*
> + * Note that by not updating w_off, this abandons the
> + * portion of the new entry that *was* successfully
> + * copied, just above. This is intentional to avoid
> + * message corruption from missing fragments.
> + */
> return -EFAULT;
>
> log->w_off = logger_offset(log, log->w_off + count);
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [PATCH 4/5] logger: clarify code in clock_interval
From: Dima Zavin @ 2012-02-09 6:09 UTC (permalink / raw)
To: Tim Bird
Cc: Greg KH, linux-embedded, linux kernel, Brian Swetland,
Andrew Morton
In-Reply-To: <4F31DEA2.7000702@am.sony.com>
To be honest, i don't find the new logic code much different or
cleaner than the old code. I think just documenting (as well as the
function rename) as you've done without inverting the logic would be
sufficient. The ascii art helps immensely.
--Dima
On Tue, Feb 7, 2012 at 6:32 PM, Tim Bird <tim.bird@am.sony.com> wrote:
> Add commentary, rename the function and make the code easier to read.
>
> Signed-off-by: Tim Bird <tim.bird@am.sony.com>
> ---
> drivers/staging/android/logger.c | 28 ++++++++++++++++++++--------
> 1 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
> index 54b7cdf..8d9d4f1 100644
> --- a/drivers/staging/android/logger.c
> +++ b/drivers/staging/android/logger.c
> @@ -242,16 +242,28 @@ static size_t get_next_entry(struct logger_log *log, size_t off, size_t len)
> }
>
> /*
> - * clock_interval - is a < c < b in mod-space? Put another way, does the line
> - * from a to b cross c?
> + * is_between - is a < c < b, accounting for wrapping of a, b, and c
> + * positions in the buffer
> + *
> + * That is, if a<b, check for c between a and b
> + * and if a>b, check for c outside (not between) a and b
> + *
> + * |------- a xxxxxxxx b --------|
> + * c^
> + *
> + * |xxxxx b --------- a xxxxxxxxx|
> + * c^
> + * or c^
> */
> -static inline int clock_interval(size_t a, size_t b, size_t c)
> +static inline int is_between(size_t a, size_t b, size_t c)
> {
> - if (b < a) {
> - if (a < c || b >= c)
> + if (a < b) {
> + /* is c between a and b? */
> + if (a < c && c <= b)
> return 1;
> } else {
> - if (a < c && b >= c)
> + /* is c outside of b through a? */
> + if (c <= b || a < c)
> return 1;
> }
>
> @@ -272,11 +284,11 @@ static void fix_up_readers(struct logger_log *log, size_t len)
> size_t new = logger_offset(log, old + len);
> struct logger_reader *reader;
>
> - if (clock_interval(old, new, log->head))
> + if (is_between(old, new, log->head))
> log->head = get_next_entry(log, log->head, len);
>
> list_for_each_entry(reader, &log->readers, list)
> - if (clock_interval(old, new, reader->r_off))
> + if (is_between(old, new, reader->r_off))
> reader->r_off = get_next_entry(log, reader->r_off, len);
> }
>
> --
> 1.7.2.3
>
^ 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