* 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
* [PATCH] leds: Add options to have GPIO LEDs start on or keep their state
From: Trent Piepho @ 2009-05-12 22:33 UTC (permalink / raw)
To: linuxppc-dev, Richard Purdie; +Cc: Trent Piepho, Sean MacLennan
In-Reply-To: <fa686aa40904172207sc0f923eoefe8fb0a2703d548@mail.gmail.com>
There already is a "default-on" trigger but there are problems with it.
For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.
But the real reason is that is produces a glitch on the LED. The GPIO is
allocate with the LED *off*, then *later* when the trigger runs it is
turned back on. If the LED was already on via the GPIO's reset default or
action of the firmware, this produces a glitch where the LED goes from on
to off to on. While normally this is fast enough that it wouldn't be
noticeable to a human observer, there are still serious problems.
One is that there may be something else on the GPIO line, like a hardware
alarm or watchdog, that is fast enough to notice the glitch.
Another is that the kernel may panic before the LED is turned back on, thus
hanging with the LED in the wrong state. This is not just speculation, but
actually happened to me with an embedded system that has an LED which
should turn off when the kernel finishes booting, which was left in the
incorrect state due to a bug in the OF LED binding code.
We also let GPIO LEDs get their initial value from whatever the current
state of the GPIO line is. On some systems the LEDs are put into some
state by the firmware or hardware before Linux boots, and it is desired to
have them keep this state which is otherwise unknown to Linux.
This requires that the underlying GPIO driver support reading the value of
output GPIOs. Some drivers support this and some do not.
The platform device binding gains a field in the platform data
"default_state" that controls this. There are three constants defined to
select from on, off, or keeping the current state. The OpenFirmware
binding uses a property named "default-state" that can be set to "on",
"off", or "keep". The default if the property isn't present is off.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 17 ++++++++++++++++-
drivers/leds/leds-gpio.c | 21 ++++++++++++++++++---
include/linux/leds.h | 9 +++++++--
3 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt
index 4fe14de..064db92 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -16,10 +16,17 @@ LED sub-node properties:
string defining the trigger assigned to the LED. Current triggers are:
"backlight" - LED will act as a back-light, controlled by the framebuffer
system
- "default-on" - LED will turn on
+ "default-on" - LED will turn on, but see "default-state" below
"heartbeat" - LED "double" flashes at a load average based rate
"ide-disk" - LED indicates disk activity
"timer" - LED flashes at a fixed, configurable rate
+- default-state: (optional) The initial state of the LED. Valid
+ values are "on", "off", and "keep". If the LED is already on or off
+ and the default-state property is set the to same value, then no
+ glitch should be produced where the LED momentarily turns off (or
+ on). The "keep" setting will keep the LED at whatever its current
+ state is, without producing a glitch. The default is off if this
+ property is not present.
Examples:
@@ -30,14 +37,22 @@ leds {
gpios = <&mcu_pio 0 1>; /* Active low */
linux,default-trigger = "ide-disk";
};
+
+ fault {
+ gpios = <&mcu_pio 1 0>;
+ /* Keep LED on if BIOS detected hardware fault */
+ default-state = "keep";
+ };
};
run-control {
compatible = "gpio-leds";
red {
gpios = <&mpc8572 6 0>;
+ default-state = "off";
};
green {
gpios = <&mpc8572 7 0>;
+ default-state = "on";
};
}
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index d210905..b5fd008 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -76,7 +76,7 @@ static int __devinit create_gpio_led(const struct gpio_led *template,
struct gpio_led_data *led_dat, struct device *parent,
int (*blink_set)(unsigned, unsigned long *, unsigned long *))
{
- int ret;
+ int ret, state;
/* skip leds that aren't available */
if (!gpio_is_valid(template->gpio)) {
@@ -99,11 +99,15 @@ static int __devinit create_gpio_led(const struct gpio_led *template,
led_dat->cdev.blink_set = gpio_blink_set;
}
led_dat->cdev.brightness_set = gpio_led_set;
- led_dat->cdev.brightness = LED_OFF;
+ if (template->default_state == LEDS_GPIO_DEFSTATE_KEEP)
+ state = !!gpio_get_value(led_dat->gpio) ^ led_dat->active_low;
+ else
+ state = (template->default_state == LEDS_GPIO_DEFSTATE_ON);
+ led_dat->cdev.brightness = state ? LED_FULL : LED_OFF;
if (!template->retain_state_suspended)
led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
- ret = gpio_direction_output(led_dat->gpio, led_dat->active_low);
+ ret = gpio_direction_output(led_dat->gpio, led_dat->active_low ^ state);
if (ret < 0)
goto err;
@@ -223,12 +227,23 @@ static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
memset(&led, 0, sizeof(led));
for_each_child_of_node(np, child) {
enum of_gpio_flags flags;
+ const char *state;
led.gpio = of_get_gpio_flags(child, 0, &flags);
led.active_low = flags & OF_GPIO_ACTIVE_LOW;
led.name = of_get_property(child, "label", NULL) ? : child->name;
led.default_trigger =
of_get_property(child, "linux,default-trigger", NULL);
+ state = of_get_property(child, "default-state", NULL);
+ if (state) {
+ 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;
+ }
+ }
ret = create_gpio_led(&led, &pdata->led_data[pdata->num_leds++],
&ofdev->dev, NULL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 376fe07..66e7d75 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -141,9 +141,14 @@ struct gpio_led {
const char *name;
const char *default_trigger;
unsigned gpio;
- u8 active_low : 1;
- u8 retain_state_suspended : 1;
+ unsigned active_low : 1;
+ unsigned retain_state_suspended : 1;
+ unsigned default_state : 2;
+ /* default_state should be one of LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP) */
};
+#define LEDS_GPIO_DEFSTATE_OFF 0
+#define LEDS_GPIO_DEFSTATE_ON 1
+#define LEDS_GPIO_DEFSTATE_KEEP 2
struct gpio_led_platform_data {
int num_leds;
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH 5/6] rio: warn_unused_result warnings fix
From: Andrew Morton @ 2009-05-12 22:11 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, linux-kernel, linuxppc-dev, leoli, davem
In-Reply-To: <1242117363-14949-5-git-send-email-leoli@freescale.com>
On Tue, 12 May 2009 16:36:02 +0800
Li Yang <leoli@freescale.com> wrote:
> + if (rswitch) {
> + if (rswitch->route_table)
this `if' is unneeded.
> + kfree(rswitch->route_table);
> + kfree(rswitch);
> + }
^ permalink raw reply
* Re: [PATCH 4/6] rionet: add memory access to simulated Ethernet over rapidio
From: Andrew Morton @ 2009-05-12 22:10 UTC (permalink / raw)
To: Li Yang; +Cc: zw, netdev, linux-kernel, linuxppc-dev, leoli, davem
In-Reply-To: <1242117363-14949-4-git-send-email-leoli@freescale.com>
On Tue, 12 May 2009 16:36:01 +0800
Li Yang <leoli@freescale.com> wrote:
> Through the newly added IO memory access of RapidIO, sender can
> write directly to recipient's rx buffer, either by cpu or DMA engine.
>
> ...
>
> +/* Definitions for rionet memory map driver */
> +#define RIONET_DRVID 0x101
> +#define RIONET_MAX_SK_DATA_SIZE 0x1000
> +#define RIONET_MEM_RIO_BASE 0x10000000
> +#define RIONET_TX_RX_BUFF_SIZE (0x1000 * (128 + 128))
> +#define RIONET_QUEUE_NEXT(x) (((x) < 127) ? ((x) + 1) : 0)
References its arg multiple times, hence is buggy or inefficient when
passed an expression with side-effects.
static inline int rionet_queue_next(int x)
would be better. Assuming that some sane identifier is used instead of
"x".
> +#define RIONET_QUEUE_INC(x) (x = RIONET_QUEUE_NEXT(x))
It's pretty ugly to hide an assignment inside a macro like this. Why
not do
foo = rionet_queue_inc(foo);
at the callsites? It makes it much clearer for the reader.
>
> ...
>
> +#ifdef CONFIG_RIONET_MEMMAP
> +static int rio_send_mem(struct sk_buff *skb,
> + struct net_device *ndev, struct rio_dev *rdev)
> +{
> + struct rionet_private *rnet = netdev_priv(ndev);
> + int enqueue, dequeue;
> +
> + if (!rdev)
> + return -EFAULT;
Is that an appropriate error code?
>
> ...
>
^ permalink raw reply
* Re: [PATCH 3/6] powerpc: add memory map support to Freescale RapidIO block
From: Andrew Morton @ 2009-05-12 22:05 UTC (permalink / raw)
To: Li Yang; +Cc: zw, netdev, linux-kernel, linuxppc-dev, leoli, davem
In-Reply-To: <1242117363-14949-3-git-send-email-leoli@freescale.com>
On Tue, 12 May 2009 16:36:00 +0800
Li Yang <leoli@freescale.com> wrote:
> + align = (size < 0x1000) ? 0x1000 : 1 << (__ilog2(size - 1) + 1);
> +
> + /* Align the size */
> + if ((lstart + size) > (_ALIGN_DOWN(lstart, align) + align)) {
__ilog2() and _ALIGN_DOWN() are powerpc-specific functions. It would
be preferable to use more general helpers if possible. ALIGN() and ilog2()
might suit here.
^ permalink raw reply
* [PATCH] powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs
From: Kumar Gala @ 2009-05-12 22:07 UTC (permalink / raw)
To: linuxppc-dev
In these configuration we expect to have large amounts of memory (> 4G)
and thus will bounce via swiotlb some region of PCI address space.
The outbound windows were wasting 512M of address space by leaving a
gap between the top of the outbound window and the 4G boundary. By
moving the top of the outbound window up to the 4G boundary we can
reclaim the vast majority of the 512M (minus space needed for PEXCSRBAR)
and thus reduces the amount of memory we have to bounce.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 22 +++++++++++-----------
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 16 ++++++++--------
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8572ds_36b.dts b/arch/powerpc/boot/dts/mpc8572ds_36b.dts
index 1197965..f6365db 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_36b.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_36b.dts
@@ -533,7 +533,7 @@
#address-cells = <3>;
reg = <0xf 0xffe08000 0 0x1000>;
bus-range = <0 255>;
- ranges = <0x2000000 0x0 0xc0000000 0xc 0x00000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
@@ -660,8 +660,8 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <0x2000000 0x0 0xc0000000
- 0x2000000 0x0 0xc0000000
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
0x0 0x20000000
0x1000000 0x0 0x0
@@ -671,8 +671,8 @@
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
- ranges = <0x2000000 0x0 0xc0000000
- 0x2000000 0x0 0xc0000000
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
0x0 0x20000000
0x1000000 0x0 0x0
@@ -742,7 +742,7 @@
#address-cells = <3>;
reg = <0xf 0xffe09000 0 0x1000>;
bus-range = <0 255>;
- ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
@@ -760,8 +760,8 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <0x2000000 0x0 0xc0000000
- 0x2000000 0x0 0xc0000000
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
0x0 0x20000000
0x1000000 0x0 0x0
@@ -778,7 +778,7 @@
#address-cells = <3>;
reg = <0xf 0xffe0a000 0 0x1000>;
bus-range = <0 255>;
- ranges = <0x2000000 0x0 0xc0000000 0xc 0x40000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x40000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc20000 0x0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
@@ -796,8 +796,8 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <0x2000000 0x0 0xc0000000
- 0x2000000 0x0 0xc0000000
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
0x0 0x20000000
0x1000000 0x0 0x0
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
index 65893b9..8be8e70 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
@@ -370,7 +370,7 @@
#address-cells = <3>;
reg = <0x0f 0xffe08000 0x0 0x1000>;
bus-range = <0x0 0xff>;
- ranges = <0x02000000 0x0 0xc0000000 0x0c 0x00000000 0x0 0x20000000
+ ranges = <0x02000000 0x0 0xe0000000 0x0c 0x00000000 0x0 0x20000000
0x01000000 0x0 0x00000000 0x0f 0xffc00000 0x0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
@@ -496,8 +496,8 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <0x02000000 0x0 0xc0000000
- 0x02000000 0x0 0xc0000000
+ ranges = <0x02000000 0x0 0xe0000000
+ 0x02000000 0x0 0xe0000000
0x0 0x20000000
0x01000000 0x0 0x00000000
@@ -507,8 +507,8 @@
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
- ranges = <0x02000000 0x0 0xc0000000
- 0x02000000 0x0 0xc0000000
+ ranges = <0x02000000 0x0 0xe0000000
+ 0x02000000 0x0 0xe0000000
0x0 0x20000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
@@ -579,7 +579,7 @@
#address-cells = <3>;
reg = <0x0f 0xffe09000 0x0 0x1000>;
bus-range = <0x0 0xff>;
- ranges = <0x02000000 0x0 0xc0000000 0x0c 0x20000000 0x0 0x20000000
+ ranges = <0x02000000 0x0 0xe0000000 0x0c 0x20000000 0x0 0x20000000
0x01000000 0x0 0x00000000 0x0f 0xffc10000 0x0 0x00010000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
@@ -597,8 +597,8 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <0x02000000 0x0 0xc0000000
- 0x02000000 0x0 0xc0000000
+ ranges = <0x02000000 0x0 0xe0000000
+ 0x02000000 0x0 0xe0000000
0x0 0x20000000
0x01000000 0x0 0x00000000
--
1.6.0.6
^ permalink raw reply related
* [PATCH] powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
From: Kumar Gala @ 2009-05-12 21:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1242163655-880-1-git-send-email-galak@kernel.crashing.org>
Its feasible based on how the PCI address map is setup that the region
of PCI address space used for MSIs differs for each PHB on the same SoC.
Instead of assuming that the address mappes to CCSRBAR 1:1 we read
PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_msi.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index f25ce81..da38a1f 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -113,8 +113,13 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
struct msi_msg *msg)
{
struct fsl_msi *msi_data = fsl_msi;
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ u32 base = 0;
- msg->address_lo = msi_data->msi_addr_lo;
+ pci_bus_read_config_dword(hose->bus,
+ PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, &base);
+
+ msg->address_lo = msi_data->msi_addr_lo + base;
msg->address_hi = msi_data->msi_addr_hi;
msg->data = hwirq;
@@ -271,7 +276,7 @@ static int __devinit fsl_of_msi_probe(struct of_device *dev,
msi->irqhost->host_data = msi;
msi->msi_addr_hi = 0x0;
- msi->msi_addr_lo = res.start + features->msiir_offset;
+ msi->msi_addr_lo = features->msiir_offset + (res.start & 0xfffff);
rc = fsl_msi_init_allocator(msi);
if (rc) {
--
1.6.0.6
^ permalink raw reply related
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