* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 8:34 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Steven Rostedt, David Miller,
linuxppc-dev, paulus, Ingo Molnar, Thomas Gleixner
In-Reply-To: <4A09933B.8010606@nortel.com>
"Chris Friesen" <cfriesen@nortel.com> writes:
>
> One of the reasons I brought up this issue is that there is a lot of
> documentation out there that says "softirqs will be processed on return
> from a syscall". The fact that it actually depends on the scheduler
> parameters of the task issuing the syscall isn't ever mentioned.
It's not mentioned because it is not currently.
However some network TCP RX processing can happen in process context,
which gives you most of the benefit anyways.
> In fact, "Documentation/DocBook/kernel-hacking.tmpl" in the kernel
> source still has the following:
>
> Whenever a system call is about to return to userspace, or a
> hardware interrupt handler exits, any 'software interrupts'
> which are marked pending (usually by hardware interrupts) are
> run (<filename>kernel/softirq.c</filename>).
>
> If anyone is looking at changing this code, it might be good to ensure
> that at least the kernel docs are updated.
So far the code is not changed in mainline. There have been some
proposals only.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [PATCH][POWERPC] mpc83xx : allow SPI without cs.
From: Rini van Zetten @ 2009-05-13 7:50 UTC (permalink / raw)
To: galak, spi-devel-general, Linuxppc-dev
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = <&pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
&pio2 2 0>; /* cs2 */
Signed-off-by: Rini van Zetten <rini@arvoo.nl>
---
drivers/spi/spi_mpc83xx.c | 44 +++++++++++++++++++++++---------------------
1 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index f4573a9..d06027e 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -687,9 +687,10 @@ static void mpc83xx_spi_cs_control(struct spi_device *spi, bool on)
struct mpc83xx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
u16 cs = spi->chip_select;
int gpio = pinfo->gpios[cs];
- bool alow = pinfo->alow_flags[cs];
-
- gpio_set_value(gpio, on ^ alow);
+ if ( gpio != -EEXIST ) {
+ bool alow = pinfo->alow_flags[cs];
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc83xx_spi_get_chipselects(struct device *dev)
@@ -728,27 +729,28 @@ static int of_mpc83xx_spi_get_chipselects(struct device *dev)
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, &flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
+ goto err_loop;
+ }
+ pinfo->gpios[i] = gpio;
+ pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo->gpios[i],
+ pinfo->alow_flags[i]);
+ if (ret) {
+ dev_err(dev, "can't set output direction for gpio "
+ "#%d: %d\n", i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo->gpios[i] = -EEXIST;
+ } else {
dev_err(dev, "invalid gpio #%d: %d\n", i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
- goto err_loop;
- }
-
- pinfo->gpios[i] = gpio;
- pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
- if (ret) {
- dev_err(dev, "can't set output direction for gpio "
- "#%d: %d\n", i, ret);
- goto err_loop;
- }
}
pdata->max_chipselect = ngpios;
--
^ permalink raw reply related
* RE: device trees.
From: Stephen Neuendorffer @ 2009-05-13 6:58 UTC (permalink / raw)
To: David H. Lynch Jr., grant.likely, linuxppc-dev
In-Reply-To: <4A0A6495.2050605@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]
>> Um.. one thing I'm missing in this discussion of attaching the dtb to
>> the bitstream: I don't see how the bitstream becomes accessible to
>> the kernel at runtime. Unless you were exposing the dtb as part of
>> the fpga programming, but I thought you explicitly weren't doing that
>> because of limited bram space.
> While I am not sure I grasp all of the nuances why, this is NOT the
>scheme Stephen recomends.
> But it looks to be the most promising for me at Pico.
There is not a general way to pass additional information which does not program configuration bits of the FPGA through
the configuration interface. There is a mechanism to do this in Virtex 4 and Virtex 5, but there is no
such mechanism for Spartan 3. The best option that works for all Xilinx FPGAs is to use the initial state of a
BRAM memory block to contain the .dtb, which can then be scavenged and reused in the system, if necessary, although this
can impact overall system design.
David specifically asked for a mechanism which:
1) works on Spartan 3, in addition to V4 and V5.
2) does not require reserving an initialized BRAM, since BRAM information is very expensive in his system.
The solution is highly specific to the configuration mechanism that David's company uses in their systems, and is not generally applicable
to all board designs.
The main point of all of this is to avoid separating the bitstream from the corresponding .dtb, in order to
avoid consistency issues. Essentially, the bitstream describes itself using a .dtb.
Steve
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 2530 bytes --]
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash, size
From: Heiko Schocher @ 2009-05-13 6:27 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <mailman.7754.1242158509.26545.linuxppc-dev@ozlabs.org>
Hello Wolfgang,
> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
Wouldn;t it be better, if u-boot fixes the device tree entries?
I think, u-boot should know, where the flash begins and ends, and
because this is maybe a dynamic variable for this board, it should
be better, if u-boot fixes this, so no need for adding a device tree
for every board variant.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PowerPC] Next May 8 boot failure: OOPS during ibmveth moduleinit
From: Stephen Rothwell @ 2009-05-13 6:39 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, linux-next, netdev, Jiri Pirko
In-Reply-To: <20090512174451.eeed4126.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
Hi Dave,
On Tue, 12 May 2009 17:44:51 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 12 May 2009 17:24:02 +1000
> Subject: [PATCH] net/ibmveth: fix panic in probe
>
> netdev->dev_addr changed from being an array to being a pointer, so we
> should not take its address for memcpy().
I have applied this to linux-next until you decide what to do with it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: device trees.
From: David Gibson @ 2009-05-13 6:21 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev
In-Reply-To: <4A0A6495.2050605@dlasys.net>
On Wed, May 13, 2009 at 02:11:33AM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> > On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
> >
> >> Another possibility is to pad the DTB with a DESYNC command and the
> >> correct pad frame, just in case it cannot be prevented.
> >>
> >
> > Um.. one thing I'm missing in this discussion of attaching the dtb to
> > the bitstream: I don't see how the bitstream becomes accessible to
> > the kernel at runtime. Unless you were exposing the dtb as part of
> > the fpga programming, but I thought you explicitly weren't doing that
> > because of limited bram space.
> >
> > I imagine this is simply due to my ignorance about FPGA techniques,
> > but if someone could enlighten me...?
> >
> While I am not sure I grasp all of the nuances why, this is NOT the
> scheme Stephen recomends.
> But it looks to be the most promising for me at Pico.
>
> In my instance, the FPGA code is typically in NOR Flash - actually
> several different FPGA bitstreams might be in Flash.
> The mechanism that we use to load the FPGA ensures that I can know
> the Flash File that was used to program the FPGA.
> That means that my monitor an read that file and extract the device
> tree.
> The remainder is a discussion of how to concatenate the dtb and the
> bit stream together, the pros/cons of prepending vs. appending,
> and work arrounds for issues.
> The critical factor is that the nature of the FPGA load process
> makes it possible to put data at the front or rear and assure that it
> gets ignored.
Ok. If you have NOR flash, why couldn't you just put the dtb in a
separate partition of the NOR?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: device trees.
From: David H. Lynch Jr. @ 2009-05-13 6:11 UTC (permalink / raw)
To: Stephen Neuendorffer, Grant Likely, linuxppc-dev,
David H. Lynch Jr.
In-Reply-To: <20090513023614.GJ24338@yookeroo.seuss>
David Gibson wrote:
> On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>
>> Another possibility is to pad the DTB with a DESYNC command and the
>> correct pad frame, just in case it cannot be prevented.
>>
>
> Um.. one thing I'm missing in this discussion of attaching the dtb to
> the bitstream: I don't see how the bitstream becomes accessible to
> the kernel at runtime. Unless you were exposing the dtb as part of
> the fpga programming, but I thought you explicitly weren't doing that
> because of limited bram space.
>
> I imagine this is simply due to my ignorance about FPGA techniques,
> but if someone could enlighten me...?
>
While I am not sure I grasp all of the nuances why, this is NOT the
scheme Stephen recomends.
But it looks to be the most promising for me at Pico.
In my instance, the FPGA code is typically in NOR Flash - actually
several different FPGA bitstreams might be in Flash.
The mechanism that we use to load the FPGA ensures that I can know
the Flash File that was used to program the FPGA.
That means that my monitor an read that file and extract the device
tree.
The remainder is a discussion of how to concatenate the dtb and the
bit stream together, the pros/cons of prepending vs. appending,
and work arrounds for issues.
The critical factor is that the nature of the FPGA load process
makes it possible to put data at the front or rear and assure that it
gets ignored.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: question about softirqs
From: Evgeniy Polyakov @ 2009-05-13 5:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: netdev, Steven Rostedt, David Miller, linuxppc-dev, paulus,
Ingo Molnar, Thomas Gleixner
In-Reply-To: <1242119578.11251.321.camel@twins>
Hi.
On Tue, May 12, 2009 at 11:12:58AM +0200, Peter Zijlstra (a.p.zijlstra@chello.nl) wrote:
> Wouldn't the even better solution be to get rid of softirqs
> all-together?
And move tasklets into some thread context?
Only if we are ready to fix 7 times rescheduling regressions compared to
kernel threads (work queue actually). At least that's how tasklet
behaved compared to work queue 1.5 years ago in the simplest
and quite naive test where tasklet/work rescheduled iself number of
times:
http://marc.info/?l=linux-crypto-vger&m=119462472517405&w=2
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [alsa-devel] [PATCH] aoa: remove driver_data direct access of struct device
From: Takashi Iwai @ 2009-05-13 5:44 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, johannes, Roel Kluin, alsa-devel, lkml
In-Reply-To: <20090512230514.GB11084@suse.de>
At Tue, 12 May 2009 16:05:14 -0700,
Greg KH wrote:
>
> On Tue, May 12, 2009 at 09:23:47AM +0200, Takashi Iwai wrote:
> > At Mon, 11 May 2009 23:57:43 -0700,
> > Greg KH wrote:
> > >
> > > On Tue, May 12, 2009 at 08:40:05AM +0200, Takashi Iwai wrote:
> > > > At Mon, 11 May 2009 21:54:51 +0200,
> > > > Roel Kluin wrote:
> > > > >
> > > > > To avoid direct access to the driver_data pointer in struct device, the
> > > > > functions dev_get_drvdata() and dev_set_drvdata() should be used.
> > > > >
> > > > > Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> > > >
> > > > The same fix has been already in Greg's tree (and thus in linux-next).
> > > >
> > > > Greg, is it OK that I take over your patch to sound git tree?
> > >
> > > Yes, please do, no objection from me at all.
> >
> > OK, will do.
> >
> > BTW, should it be pushed to 2.6.30? If "the near future" you
> > mentioned in the patch means 2.6.31, it'll be better to merge that fix
> > now. Otherwise, I'm going to apply the patch as a 2.6.31 material.
>
> .31 is fine, that is what I was meaning by with "near future" :)
OK, thanks!
Takashi
^ permalink raw reply
* Re: question about softirqs
From: David Miller @ 2009-05-13 5:28 UTC (permalink / raw)
To: paulus; +Cc: a.p.zijlstra, linuxppc-dev, netdev, rostedt, mingo, tglx
In-Reply-To: <18954.22390.754419.803434@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Wed, 13 May 2009 15:15:34 +1000
> David Miller writes:
>
>> I fully expected us to be, at this point, talking about putting the
>> pending softirq check back into the trap return path :-/
>
> Would that actually do any good, in the case where the system has
> decided that ksoftirqd is handling soft irqs at the moment?
Even if ksoftirqd is running, we check and run pending softirqs from
trap return.
Sure, I imagine we could re-enter this "ksoftirq blocked by highprio
thread" situation if we get flooded every single time over and over
again.
^ permalink raw reply
* Re: question about softirqs
From: Paul Mackerras @ 2009-05-13 5:15 UTC (permalink / raw)
To: David Miller; +Cc: a.p.zijlstra, linuxppc-dev, netdev, rostedt, mingo, tglx
In-Reply-To: <20090512.214427.193728136.davem@davemloft.net>
David Miller writes:
> I fully expected us to be, at this point, talking about putting the
> pending softirq check back into the trap return path :-/
Would that actually do any good, in the case where the system has
decided that ksoftirqd is handling soft irqs at the moment?
Paul.
^ permalink raw reply
* Re: [RFC] Hardware Breakpoint interfaces implementation for PPC64
From: David Gibson @ 2009-05-13 2:57 UTC (permalink / raw)
To: K.Prasad; +Cc: linuxppc-dev, Benjamin Herrenschmidt, paulus
In-Reply-To: <20090512202545.GE6033@in.ibm.com>
On Wed, May 13, 2009 at 01:55:45AM +0530, K.Prasad wrote:
> On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> > On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
[snip]
> I do see that Book-E processors will have severe memory footprint
> constraints (in embedded environment) and if the maintainers carry a
> different perspective (than the one cited above), the relevant fields
> can be migrated to a new structure whose pointer will be embedded in
> task_struct. The generic code may have to carry some #ifdefs though.
I think moving the debug register info into a separate structure makes
a fair bit of sense. As well as reducing the memory footprint for
systems with lots of debug regs, checking it the pointer is NULL
provides a simple and generic way of determining if the process has
touched the debug regs.
It seems to me that a kind of minimal requirement for a sensible
generic debug interface is that if no processes actually ask to use
the debug regs, then we should never touch them in the hardware. This
means that debugging hacks in the kernel can just use the debug regs
directly and don't have to go through the interface to avoid having
their stuff clobbered on context switch.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC] Hardware Breakpoint interfaces implementation for PPC64
From: David Gibson @ 2009-05-13 3:00 UTC (permalink / raw)
To: K.Prasad, Josh Boyer, linuxppc-dev, Benjamin Herrenschmidt,
paulus
In-Reply-To: <20090513025717.GN24338@yookeroo.seuss>
On Wed, May 13, 2009 at 12:57:17PM +1000, David Gibson wrote:
> On Wed, May 13, 2009 at 01:55:45AM +0530, K.Prasad wrote:
> > On Tue, May 12, 2009 at 07:51:49AM -0400, Josh Boyer wrote:
> > > On Tue, May 12, 2009 at 01:33:55AM +0530, K.Prasad wrote:
> [snip]
> > I do see that Book-E processors will have severe memory footprint
> > constraints (in embedded environment) and if the maintainers carry a
> > different perspective (than the one cited above), the relevant fields
> > can be migrated to a new structure whose pointer will be embedded in
> > task_struct. The generic code may have to carry some #ifdefs though.
>
> I think moving the debug register info into a separate structure makes
> a fair bit of sense. As well as reducing the memory footprint for
> systems with lots of debug regs, checking it the pointer is NULL
> provides a simple and generic way of determining if the process has
> touched the debug regs.
>
> It seems to me that a kind of minimal requirement for a sensible
> generic debug interface is that if no processes actually ask to use
> the debug regs, then we should never touch them in the hardware. This
> means that debugging hacks in the kernel can just use the debug regs
> directly and don't have to go through the interface to avoid having
> their stuff clobbered on context switch.
Uh, sorry, didn't fully read the earlier mail. Ingo makes a good
point that detaching the structure complicates locking / lifetime
issues. Leaving it in the thread_struct probably makes sense for now.
Although it raises other issues for when different CPUs in the same
architecture have different sets of debug registers (e.g. PPC server's
DABR/IABR set versus 44x's IAC/DAC/DBCR regs).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: question about softirqs
From: David Miller @ 2009-05-13 4:45 UTC (permalink / raw)
To: rostedt; +Cc: a.p.zijlstra, linuxppc-dev, netdev, paulus, mingo, tglx
In-Reply-To: <alpine.DEB.2.00.0905120818290.13234@gandalf.stny.rr.com>
From: Steven Rostedt <rostedt@goodmis.org>
Date: Tue, 12 May 2009 08:20:51 -0400 (EDT)
> I'm going to be playing around with bypassing the net-rx/tx with my
> network drivers. I'm going to add threaded irqs for my network cards and
> have the driver threads do the work to get through the tcp/ip stack.
>
> I'll still keep the softirqs for other cards, but I want to see how fast
> it speeds things up if I have the driver thread do it.
I think your latency is going to be dreadful.
^ permalink raw reply
* Re: question about softirqs
From: David Miller @ 2009-05-13 4:44 UTC (permalink / raw)
To: mingo; +Cc: a.p.zijlstra, linuxppc-dev, netdev, rostedt, paulus, tglx
In-Reply-To: <20090512092348.GA29796@elte.hu>
From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 12 May 2009 11:23:48 +0200
>> Wouldn't the even better solution be to get rid of softirqs
>> all-together?
>>
>> I see the recent work by Thomas to get threaded interrupts
>> upstream as a good first step towards that goal, once the RX
>> processing is moved to a thread (or multiple threads) one can
>> priorize them in the regular sys_sched_setscheduler() way and its
>> obvious that a FIFO task above the priority of the network tasks
>> will have network starvation issues.
>
> Yeah, that would be "nice". A single IRQ thread plus the process
> context(s) doing networking might perform well.
Nice for -rt goals, but not for latency.
So we're going to regress in this area again? I can't see how
that's so desirable, to be honest with you.
The fact that this discussion started about a task with a certain
priority not being able to make forward progress, even though it
was correct coded, just because softirqs are being processed in
a thread context, should be a big red flag that this is a buggered up
design.
I fully expected us to be, at this point, talking about putting the
pending softirq check back into the trap return path :-/
^ permalink raw reply
* Re: device trees.
From: Grant Likely @ 2009-05-13 4:03 UTC (permalink / raw)
To: Stephen Neuendorffer, Grant Likely, linuxppc-dev,
David H. Lynch Jr.
In-Reply-To: <20090513023614.GJ24338@yookeroo.seuss>
On Tue, May 12, 2009 at 8:36 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>>
>> Another possibility is to pad the DTB with a DESYNC command and the
>> correct pad frame, just in case it cannot be prevented.
>
> Um.. one thing I'm missing in this discussion of attaching the dtb to
> the bitstream: =A0I don't see how the bitstream becomes accessible to
> the kernel at runtime. =A0Unless you were exposing the dtb as part of
> the fpga programming, but I thought you explicitly weren't doing that
> because of limited bram space.
>
> I imagine this is simply due to my ignorance about FPGA techniques,
> but if someone could enlighten me...?
In this case the processor has access to the flash where the FPGA
bitstreams are stored and a set of registers in a CPLD which tells it
which bitstream was used to configure the FPGA.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: device trees.
From: David Gibson @ 2009-05-13 2:36 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, David H. Lynch Jr.
In-Reply-To: <20090513001048.490B533005D@mail141-va3.bigfish.com>
On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>
> Another possibility is to pad the DTB with a DESYNC command and the
> correct pad frame, just in case it cannot be prevented.
Um.. one thing I'm missing in this discussion of attaching the dtb to
the bitstream: I don't see how the bitstream becomes accessible to
the kernel at runtime. Unless you were exposing the dtb as part of
the fpga programming, but I thought you explicitly weren't doing that
because of limited bram space.
I imagine this is simply due to my ignorance about FPGA techniques,
but if someone could enlighten me...?
> > -----Original Message-----
> > From: Grant Likely [mailto:grant.likely@secretlab.ca]
> > Sent: Monday, May 11, 2009 10:30 PM
> > To: Stephen Neuendorffer
> > Cc: David H. Lynch Jr.; linuxppc-dev@ozlabs.org
> > Subject: Re: device trees.
> >
> > On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer
> > <stephen.neuendorffer@xilinx.com> wrote:
> > >> > OK, so the key question seems to be *when* the bitstream is
> > > associated
> > >> > with the
> > >> > device tree. If at bitstream generation time, you can prepend the
> > > .dtb
> > >> > to the bitstream. As long as the dtb doesn't contain the magic
> > >> > bitstream start code, you can go back and access it later.
> > >> >
> > >> You really mean prepend ? I was presuming that things would work
> > > better
> > >> if it was appended ?
> > >
> > > Yes, actually prepend is simpler because you don't have to know the size
> > > of the bitstream.
> > > Everything before the SYNC code in the bitstream is ignored.
> >
> > ...In this case, might need to preprocess the .dtb the escape out the
> > possibility of a sync code appearing.
> >
> > g.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: device trees.
From: David Gibson @ 2009-05-13 2:32 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev
In-Reply-To: <4A0A109F.7070803@dlasys.net>
On Tue, May 12, 2009 at 08:13:19PM -0400, David H. Lynch Jr. wrote:
>
>
> Are we all using the same meaning of firmware ?
>
> While firmware == BIOS is the norm for PC's
Well, BIOS, or bootloader is what I'm meaning here.
> atleast in the embedded FPGA space firmware could mean the FPGA
> programing that creates the hardware.
> For an FPGA based system a dtb generated by the same software that
> created the "firmware" for the FPGA,
> had better match the "hardware" exactly. Literally welding the
> "firmware" to the dtb makes alot of sense.
Well, yes, but FPGA based systems are not *that* common. And even in
this case the devtree will only match the "hardware" exactly if the
generator isn't buggy.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: device trees.
From: Grant Likely @ 2009-05-13 1:15 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4A0A109F.7070803@dlasys.net>
Whenever I say firmware I mean executable code that executes when the
processor comes out of reset.
When I mean the FPGA bitstream, I say bitstream. :-)
g.
On Tue, May 12, 2009 at 6:13 PM, David H. Lynch Jr. <dhlii@dlasys.net> wrot=
e:
>
>
> =A0 =A0Are we all using the same meaning of firmware ?
>
> =A0 =A0While firmware =3D=3D BIOS is the norm for PC's
> =A0 =A0 atleast in the embedded FPGA space firmware could mean the FPGA
> programing that creates the hardware.
> =A0 =A0For an FPGA based system a dtb generated by the same software that
> created the "firmware" for the FPGA,
> =A0 =A0had better match the "hardware" exactly. =A0Literally welding the
> "firmware" to the dtb makes alot of sense.
>
> =A0 =A0FPGA "firmware" is typically created with hardware programming
> languages like Verilog, and VHDL.
> =A0 =A0It is still "programmed" and like all programming quality varies.
>
> David Gibson wrote:
>> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
>>
>>> On Mon, May 11, 2009 at 7:12 PM, David Gibson
>>> <david@gibson.dropbear.id.au> wrote:
>>>
>>>> On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
>>>>
>>>>> In other words; having your bootloader support FDT is preferred, but
>>>>> not required.
>>>>>
>>>> I wouldn't even go so far as to say it's preferred. =A0IMO, people hav=
e
>>>> gone a bit prematurely keen on moving devtree handling into the
>>>> firmware. =A0Putting it in the firmware has a number of advantages, bu=
t
>>>> it also has a number of non-trivial disadvantages.
>>>>
>>> I disagree. =A0The more I work with it, the more I appreciate the
>>> advantage of decoupling the kernel image file from the hardware
>>> description. =A0It is valuable being able to build a single image file
>>> that boots on a wide range of boards because the device tree passed in
>>> by firmware.
>>>
>>
>> Heh, where all my work in the embedded space has led me to more and
>> more appreciate the fact that firmware is almost invariably crap, and
>> that it's therefore best not to trust anything it tells you.
>>
>>
>>> I'm not downplaying the disadvantages and problems, but I still hold
>>> the view that the striving for generic multiplatform kernel images is
>>> worth the effort.
>>>
>>> ... but I do agree that hard linking the .dtb into firmware, or making
>>> the .dtb hard to upgrade is the way of madness.
>>>
>>
>> Ah, we're talking at cross purposes a bit then. =A0Yeah, I'm talking
>> about the situation where the dtb is part of the firmware, or at least
>> as difficult / inconvenient to update as the firmware. =A0If the dtb is
>> separate from the kernel, but as easy to update / switch as the
>> kernel, that is indeed a very nice setup.
>>
>>
>
>
> --
> Dave Lynch =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DLA Systems
> Software Development: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0Embedded Linux
> 717.627.3770 =A0 =A0 =A0 =A0 =A0 dhlii@dlasys.net =A0 =A0 =A0 =A0 =A0 htt=
p://www.dlasys.net
> fax: 1.253.369.9244 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies too n=
umerous to list.
>
> "Any intelligent fool can make things bigger and more complex... It takes=
a touch of genius - and a lot of courage to move in the opposite direction=
."
> Albert Einstein
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: device trees.
From: David H. Lynch Jr. @ 2009-05-13 0:13 UTC (permalink / raw)
To: Grant Likely, David Gibson, linuxppc-dev
In-Reply-To: <20090512232446.GB24338@yookeroo.seuss>
Are we all using the same meaning of firmware ?
While firmware == BIOS is the norm for PC's
atleast in the embedded FPGA space firmware could mean the FPGA
programing that creates the hardware.
For an FPGA based system a dtb generated by the same software that
created the "firmware" for the FPGA,
had better match the "hardware" exactly. Literally welding the
"firmware" to the dtb makes alot of sense.
FPGA "firmware" is typically created with hardware programming
languages like Verilog, and VHDL.
It is still "programmed" and like all programming quality varies.
David Gibson wrote:
> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
>
>> On Mon, May 11, 2009 at 7:12 PM, David Gibson
>> <david@gibson.dropbear.id.au> wrote:
>>
>>> On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
>>>
>>>> In other words; having your bootloader support FDT is preferred, but
>>>> not required.
>>>>
>>> I wouldn't even go so far as to say it's preferred. IMO, people have
>>> gone a bit prematurely keen on moving devtree handling into the
>>> firmware. Putting it in the firmware has a number of advantages, but
>>> it also has a number of non-trivial disadvantages.
>>>
>> I disagree. The more I work with it, the more I appreciate the
>> advantage of decoupling the kernel image file from the hardware
>> description. It is valuable being able to build a single image file
>> that boots on a wide range of boards because the device tree passed in
>> by firmware.
>>
>
> Heh, where all my work in the embedded space has led me to more and
> more appreciate the fact that firmware is almost invariably crap, and
> that it's therefore best not to trust anything it tells you.
>
>
>> I'm not downplaying the disadvantages and problems, but I still hold
>> the view that the striving for generic multiplatform kernel images is
>> worth the effort.
>>
>> ... but I do agree that hard linking the .dtb into firmware, or making
>> the .dtb hard to upgrade is the way of madness.
>>
>
> Ah, we're talking at cross purposes a bit then. Yeah, I'm talking
> about the situation where the dtb is part of the firmware, or at least
> as difficult / inconvenient to update as the firmware. If the dtb is
> separate from the kernel, but as easy to update / switch as the
> kernel, that is indeed a very nice setup.
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* RE: device trees.
From: Stephen Neuendorffer @ 2009-05-13 0:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, David H. Lynch Jr.
In-Reply-To: <fa686aa40905112230ve176b30o25abcdf5c203f6c7@mail.gmail.com>
Another possibility is to pad the DTB with a DESYNC command and the correct=
pad frame, just in case it cannot be prevented.
Steve
> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca]
> Sent: Monday, May 11, 2009 10:30 PM
> To: Stephen Neuendorffer
> Cc: David H. Lynch Jr.; linuxppc-dev@ozlabs.org
> Subject: Re: device trees.
> =
> On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >> > OK, so the key question seems to be *when* the bitstream is
> > associated
> >> > with the
> >> > device tree. =A0If at bitstream generation time, you can prepend the=
> > .dtb
> >> > to the bitstream. =A0As long as the dtb doesn't contain the magic
> >> > bitstream start code, you can go back and access it later.
> >> >
> >> You really mean prepend ? I was presuming that things would work
> > better
> >> if it was appended ?
> >
> > Yes, actually prepend is simpler because you don't have to know the siz=
e
> > of the bitstream.
> > Everything before the SYNC code in the bitstream is ignored.
> =
> ...In this case, might need to preprocess the .dtb the escape out the
> possibility of a sync code appearing.
> =
> g.
> =
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: device trees.
From: Grant Likely @ 2009-05-13 0:01 UTC (permalink / raw)
To: Grant Likely, David H. Lynch Jr., linuxppc-dev
In-Reply-To: <20090512232446.GB24338@yookeroo.seuss>
On Tue, May 12, 2009 at 5:24 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
>> ... but I do agree that hard linking the .dtb into firmware, or making
>> the .dtb hard to upgrade is the way of madness.
>
> Ah, we're talking at cross purposes a bit then. =A0Yeah, I'm talking
> about the situation where the dtb is part of the firmware, or at least
> as difficult / inconvenient to update as the firmware. =A0If the dtb is
> separate from the kernel, but as easy to update / switch as the
> kernel, that is indeed a very nice setup.
:-D
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: device trees.
From: David Gibson @ 2009-05-12 23:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, David H. Lynch Jr.
In-Reply-To: <fa686aa40905112222q75056b60hd9c2465b335496d1@mail.gmail.com>
On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 7:12 PM, David Gibson
> <david@gibson.dropbear.id.au> wrote:
> > On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
> >> In other words; having your bootloader support FDT is preferred, but
> >> not required.
> >
> > I wouldn't even go so far as to say it's preferred. IMO, people have
> > gone a bit prematurely keen on moving devtree handling into the
> > firmware. Putting it in the firmware has a number of advantages, but
> > it also has a number of non-trivial disadvantages.
>
> I disagree. The more I work with it, the more I appreciate the
> advantage of decoupling the kernel image file from the hardware
> description. It is valuable being able to build a single image file
> that boots on a wide range of boards because the device tree passed in
> by firmware.
Heh, where all my work in the embedded space has led me to more and
more appreciate the fact that firmware is almost invariably crap, and
that it's therefore best not to trust anything it tells you.
> I'm not downplaying the disadvantages and problems, but I still hold
> the view that the striving for generic multiplatform kernel images is
> worth the effort.
>
> ... but I do agree that hard linking the .dtb into firmware, or making
> the .dtb hard to upgrade is the way of madness.
Ah, we're talking at cross purposes a bit then. Yeah, I'm talking
about the situation where the dtb is part of the firmware, or at least
as difficult / inconvenient to update as the firmware. If the dtb is
separate from the kernel, but as easy to update / switch as the
kernel, that is indeed a very nice setup.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] leds: Add options to have GPIO LEDs start on or keep their state
From: Sean MacLennan @ 2009-05-12 23:14 UTC (permalink / raw)
To: Trent Piepho; +Cc: linuxppc-dev, Richard Purdie, Trent Piepho
In-Reply-To: <1242167592-14649-1-git-send-email-xyzzy@speakeasy.org>
On Tue, 12 May 2009 15:33:12 -0700
Trent Piepho <xyzzy@speakeasy.org> wrote:
> + if (!strcmp(state, "keep")) {
> + led.default_state =
> LEDS_GPIO_DEFSTATE_KEEP;
> + } else if(!strcmp(state, "on")) {
> + led.default_state =
> LEDS_GPIO_DEFSTATE_ON;
> + } else {
> + led.default_state =
> LEDS_GPIO_DEFSTATE_OFF;
> + }
Just a nitpick, you don't need the {} braces here. Other than that:
Acked-by: Sean MacLennan <smaclennan@pikatech.com>
Tested-by: Sean MacLennan <smaclennan@pikatech.com>
Tested on a warp with the following:
power-leds {
compatible = "gpio-leds";
green {
gpios = <&GPIO1 0 0>;
default-state = "on";
};
red {
gpios = <&GPIO1 1 0>;
default-state = "keep";
};
};
I tested with both the red LED initially off and initially on as set in
u-boot.
Cheers,
Sean
^ permalink raw reply
* Re: [alsa-devel] [PATCH] aoa: remove driver_data direct access of struct device
From: Greg KH @ 2009-05-12 23:05 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, johannes, Roel Kluin, alsa-devel, lkml
In-Reply-To: <s5hoctyu6m4.wl%tiwai@suse.de>
On Tue, May 12, 2009 at 09:23:47AM +0200, Takashi Iwai wrote:
> At Mon, 11 May 2009 23:57:43 -0700,
> Greg KH wrote:
> >
> > On Tue, May 12, 2009 at 08:40:05AM +0200, Takashi Iwai wrote:
> > > At Mon, 11 May 2009 21:54:51 +0200,
> > > Roel Kluin wrote:
> > > >
> > > > To avoid direct access to the driver_data pointer in struct device, the
> > > > functions dev_get_drvdata() and dev_set_drvdata() should be used.
> > > >
> > > > Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> > >
> > > The same fix has been already in Greg's tree (and thus in linux-next).
> > >
> > > Greg, is it OK that I take over your patch to sound git tree?
> >
> > Yes, please do, no objection from me at all.
>
> OK, will do.
>
> BTW, should it be pushed to 2.6.30? If "the near future" you
> mentioned in the patch means 2.6.31, it'll be better to merge that fix
> now. Otherwise, I'm going to apply the patch as a 2.6.31 material.
.31 is fine, that is what I was meaning by with "near future" :)
thanks,
greg k-h
^ 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