* Re: device trees.
From: David H. Lynch Jr. @ 2009-05-12 2:34 UTC (permalink / raw)
To: Stephen Neuendorffer, linuxppc-dev
In-Reply-To: <20090512005554.EEE1019D009B@mail129-dub.bigfish.com>
Stephen Neuendorffer wrote:
>
>> Many of our systems are LX systems but currently we are not running
>> Linux on them.
>>
>
> Master SelectMap, I presume? What FPGA family?
> Does the FPGA have access to the CPLD after boot, other than through the
> configuration pins?
>
>
One of the skills I have not had time to develop - because Pico has
plenty of qualified firmware/hardware people and not enough OS people,
is fluency with Xilinx tools.
FPGA Families - currently Spartan, virtex 4 and virtex 5.
LX & FX, in all kinds of sizes. So that as an example our E14 (1st
generation cardbus) comes in FX40's and FX60's and LX## .......
I am presuming that is what you mean.
Access to the hardware on the cards can be weird. As our cards are often
hosted, that means the firmware is often setup to allow host and target
access to hardware. In others only the host or only the target does.
What I know is that if I send a few magic values to the CPLD and then
start reading the bit file out of flash, I will trigger the CPLD to
reload the FPGA from the bitfile I selected.
> OK, so that means the boot monitor can open sector 2 of the flash and
> read info, right? (Or wherever else the bitstream is coming from.
On powerup the CPLD boots from sector 2. IF it is rebooted by the host
or target it can reboot from any flash sector.
In the "normal" setup the target has indirect access to the entire NOR
flash.
> Can
> the CPLD store one 32 bit int that the new bitstream can come back and
> read later?
>
Off the top of my head I do nto know, but if you are saying I need to
find someway of preserving a 32bit value through rebooting the FPGA I
can find a way to do it.
>
>
> 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 ?
Regardless, I have the means to know exactly what bit file is currently
loaded, and I can then look it up in the NOR Flash.
I can glue the dtb and the bit file together in anyway that will make
xilinx happy.
If it is prepended the only case I care about is the power up sequence,
because that must start loading the bit file at sector 2.
We do cope with the scenario where the sector 2 bit file is completely
screwed up. The CPLD STARTS trying to load at sector 2, but it will
continue to the end of flash until something actually loads. The dead
card scenario is sector 2 is the start of a valid but non-functional bit
file.
At that point you must load a bit image using JTAG and then write a good
bit file to flash.
Alright lets say I prepend. I am loosely familar with the magic start
code. Does that need to be aligned in anyway ?
And just for the sake of argument lets say I append the dtb. Do I need
some padding between the bitfile and the dtb to keep the
FPGA from loading the dtb as firmware ? Is there a magic stop sequence ?
Is the load terminated by the length of the bits.
> Is this sounding reasonable?
>
>
I am sure there is something I can work with here.
Thanks.
> 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.
>
>
>
--
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: [RFC] Hardware Breakpoint interfaces implementation for PPC64
From: Michael Neuling @ 2009-05-12 2:48 UTC (permalink / raw)
To: prasad, linuxppc-dev, Benjamin Herrenschmidt, paulus
In-Reply-To: <4234.1242089764@neuling.org>
> > +struct arch_hw_breakpoint {
> > + char *name; /* Contains name of the symbol to set bkpt */
> > + unsigned long address;
> > + u8 type;
> > +};
>
> Can you reorder this to pack the struct better (ie. put the unsigned
> long first).
Oops, this is a char * not just a char. Order is fine.
Mikey
^ permalink raw reply
* RE: device trees.
From: Stephen Neuendorffer @ 2009-05-12 4:27 UTC (permalink / raw)
To: David H. Lynch Jr., linuxppc-dev
In-Reply-To: <4A08E050.9000302@dlasys.net>
> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii@dlasys.net]
> Sent: Monday, May 11, 2009 7:35 PM
> To: Stephen Neuendorffer; linuxppc-dev@ozlabs.org
> Subject: Re: device trees.
> =
> Stephen Neuendorffer wrote:
> >
> >> Many of our systems are LX systems but currently we are not running
> >> Linux on them.
> >>
> >
> > Master SelectMap, I presume? What FPGA family?
> > Does the FPGA have access to the CPLD after boot, other than through
the
> > configuration pins?
> >
> >
> One of the skills I have not had time to develop - because Pico has
> plenty of qualified firmware/hardware people and not enough OS people,
> is fluency with Xilinx tools.
> =
> FPGA Families - currently Spartan, virtex 4 and virtex 5.
> LX & FX, in all kinds of sizes. So that as an example our E14 (1st
> generation cardbus) comes in FX40's and FX60's and LX## .......
> =
> I am presuming that is what you mean.
> =
> Access to the hardware on the cards can be weird. As our cards are
often
> hosted, that means the firmware is often setup to allow host and
target
> access to hardware. In others only the host or only the target does.
> =
> What I know is that if I send a few magic values to the CPLD and then
> start reading the bit file out of flash, I will trigger the CPLD to
> reload the FPGA from the bitfile I selected.
> =
> =
> =
> =
> =
> > OK, so that means the boot monitor can open sector 2 of the flash
and
> > read info, right? (Or wherever else the bitstream is coming from.
> On powerup the CPLD boots from sector 2. IF it is rebooted by the host
> or target it can reboot from any flash sector.
> In the "normal" setup the target has indirect access to the entire NOR
> flash.
> =
> > Can
> > the CPLD store one 32 bit int that the new bitstream can come back
and
> > read later?
> >
> Off the top of my head I do nto know, but if you are saying I need to
> find someway of preserving a 32bit value through rebooting the FPGA I
> can find a way to do it.
> =
> >
> >
> > 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.
For instance, this is the start of a spartan 3ADSP bitstream:
00000000 00 09 0f f0 0f f0 0f f0 0f f0 00 00 01 61 00 0b
|.............a..|
00000010 73 79 73 74 65 6d 2e 6e 63 64 00 62 00 0e 33 73
|system.ncd.b..3s|
00000020 64 33 34 30 30 61 66 67 36 37 36 00 63 00 0b 32
|d3400afg676.c..2|
00000030 30 30 39 2f 20 35 2f 20 31 00 64 00 09 31 34 3a |009/ 5/
1.d..14:|
00000040 34 38 3a 32 31 00 65 00 16 59 d4 ff ff ff ff ff
|48:21.e..Y......|
00000050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
00000060 ff ff ff ff ff ff ff ff ff ff ff aa 99 30 a1 00
|.............0..|
'FF FF AA 99' is the Spartan 3 DUMMY code/SYNC code combination,
everything before that
is discarded by the FPGA.
> Regardless, I have the means to know exactly what bit file is
currently
> loaded, and I can then look it up in the NOR Flash.
Yes, so as long as when the bitstream is loaded, it can figure out where
in the flash it was loaded *from* and then go back there and get the
dtb, then that should work. This would make it difficult to do certain
things (like loading a useful bitstream from anywhere OTHER than flash),
but if you can make that restriction, then it should work. I can think
of several ways of doing this, the simple of which is to have your
bootloader go to the CPLD after it has loaded to figure out where the
bitstream came from.
> I can glue the dtb and the bit file together in anyway that will make
> xilinx happy.
Fortunately, you don't have to keep Xilinx happy, only the FPGA.. :)
> If it is prepended the only case I care about is the power up
sequence,
> because that must start loading the bit file at sector 2.
> We do cope with the scenario where the sector 2 bit file is completely
> screwed up. The CPLD STARTS trying to load at sector 2, but it will
> continue to the end of flash until something actually loads. The dead
> card scenario is sector 2 is the start of a valid but non-functional
bit
> file.
> At that point you must load a bit image using JTAG and then write a
good
> bit file to flash.
> =
> Alright lets say I prepend. I am loosely familar with the magic start
> code. Does that need to be aligned in anyway ?
My understanding is that alignment does matter somewhat if you are using
SelectMap32, so if this is what you are doing, it's probably best to
preserve the existing alignment, padding the dtb to a number of words
divisible by 4. If you're using serial configuration modes, or
selectmap8, then it doesn't matter.
> And just for the sake of argument lets say I append the dtb. Do I need
> some padding between the bitfile and the dtb to keep the
> FPGA from loading the dtb as firmware ? Is there a magic stop sequence
?
> Is the load terminated by the length of the bits.
The bitstream ends with a DESYNC code, followed by a pad of frame data.
After that, everything is ignored until the next SYNC code. BTW, all of
this is documented in the various configuration user guides.
I'll add that if you are doing V4 and V5 only and don't care about S3,
then there is another mechanism which avoids 'knowing where you loaded
the bitstream from'. This relies on the USR_ACCESS_VIRTEX4 and
USER_ACCESS_VIRTEX5 primitives to pass further configuration information
to the FPGA design from the configuration source. You could use this to
append the dtb to the bitstream and to copy it into external memory
using a little bit of FPGA logic, and presumably, the processor.
However, this mechanism is not available on S3.
Steve
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: Next May 11 : BUG during scsi initialization
From: Nick Piggin @ 2009-05-12 4:57 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Stephen Rothwell, linux-scsi, linuxppc-dev, Pekka Enberg,
linux-next
In-Reply-To: <20090511122135.GC8112@parisc-linux.org>
On Mon, May 11, 2009 at 06:21:35AM -0600, Matthew Wilcox wrote:
> On Mon, May 11, 2009 at 05:34:07PM +0530, Sachin Sant wrote:
> > Matthew Wilcox wrote:
> >> On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote:
> >>
> >>> Today's Next tree failed to boot on a Power6 box with following BUG :
> >>
> >> This doesn't actually appear to be a SCSI bug ... it looks like SCSI tried
> >> to allocate memory and things went wrong in the memory allocator:
> >>
> >> [c0000000c7d038b0] [c0000000005d67d8] ._spin_lock+0x10/0x24
> >> [c0000000c7d03920] [c00000000013fbdc] .__slab_alloc_page+0x344/0x3cc
> >> [c0000000c7d039e0] [c000000000141168] .kmem_cache_alloc+0x13c/0x21c
> >> [c0000000c7d03aa0] [c000000000141b04] .kmem_cache_create+0x294/0x2a8
> >> [c0000000c7d03b90] [d000000000ea14cc] .scsi_init_queue+0x38/0x170 [scsi_mod]
> >>
> >> Which memory allocator did you have selected (SLAB, SLUB, SLOB, SLQB)?
> >>
> > Default one. SLQB
> >
> > CONFIG_SLQB_ALLOCATOR=y
> > CONFIG_SLQB=y
> >
> > Page size is 64K with Config DEBUG_PAGEALLOC set.
> >
> > CONFIG_PPC_HAS_HASH_64K=y
> > CONFIG_PPC_64K_PAGES=y
> > CONFIG_DEBUG_PAGEALLOC=y
>
> Hm. We've seen some similar problems at Intel while doing database
> performance tests with SLQB. Any ideas, Nick?
Hmm, I think (hope) your problems were fixed with the recent memory
coruption bug fix for SLQB. (if not, let me know)
This one possibly looks like a problem with remote memory allocation
or memory hotplug or something like that. I'll do a bit of code
review....
^ permalink raw reply
* Re: device trees.
From: Grant Likely @ 2009-05-12 5:22 UTC (permalink / raw)
To: Grant Likely, David H. Lynch Jr., linuxppc-dev
In-Reply-To: <20090512011219.GB18223@yookeroo.seuss>
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 have
> gone a bit prematurely keen on moving devtree handling into the
> firmware. =A0Putting 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.
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.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: device trees.
From: Grant Likely @ 2009-05-12 5:30 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, David H. Lynch Jr.
In-Reply-To: <20090512042733.8D4A21400054@mail184-dub.bigfish.com>
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 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.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Next May 11 : BUG during scsi initialization
From: Stephen Rothwell @ 2009-05-12 5:56 UTC (permalink / raw)
To: Nick Piggin
Cc: linux-scsi, Matthew Wilcox, linuxppc-dev, Pekka Enberg,
linux-next
In-Reply-To: <20090512045716.GC32535@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
Hi Nick,
On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin <npiggin@suse.de> wrote:
>
> Hmm, I think (hope) your problems were fixed with the recent memory
> coruption bug fix for SLQB. (if not, let me know)
>
> This one possibly looks like a problem with remote memory allocation
> or memory hotplug or something like that. I'll do a bit of code
> review....
These are -next kernels which include the two fixes you posted recently
(I am pretty sure). I am also getting the network failures that Sachin
is seeing on several of my machines here. The previously reported
problems have gone away.
--
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: Next May 11 : BUG during scsi initialization
From: Nick Piggin @ 2009-05-12 5:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-scsi, Matthew Wilcox, linuxppc-dev, Pekka Enberg,
linux-next
In-Reply-To: <20090512155613.881fa2ec.sfr@canb.auug.org.au>
On Tue, May 12, 2009 at 03:56:13PM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin <npiggin@suse.de> wrote:
> >
> > Hmm, I think (hope) your problems were fixed with the recent memory
> > coruption bug fix for SLQB. (if not, let me know)
> >
> > This one possibly looks like a problem with remote memory allocation
> > or memory hotplug or something like that. I'll do a bit of code
> > review....
>
> These are -next kernels which include the two fixes you posted recently
> (I am pretty sure).
Yes they should do.
> I am also getting the network failures that Sachin
> is seeing on several of my machines here. The previously reported
> problems have gone away.
This one is a SCSI failure... was there also a network one reported?
At any rate, I'm fairly sure this is a problem with SLQB, so it could
easily happen in any early driver setup.
^ permalink raw reply
* Re: Next May 11 : BUG during scsi initialization
From: Stephen Rothwell @ 2009-05-12 6:03 UTC (permalink / raw)
To: Nick Piggin
Cc: linux-scsi, Matthew Wilcox, linuxppc-dev, Pekka Enberg,
linux-next
In-Reply-To: <20090512055918.GF32535@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 3246 bytes --]
On Tue, 12 May 2009 07:59:18 +0200 Nick Piggin <npiggin@suse.de> wrote:
>
> On Tue, May 12, 2009 at 03:56:13PM +1000, Stephen Rothwell wrote:
> > Hi Nick,
> >
> > On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin <npiggin@suse.de> wrote:
> > >
> > > Hmm, I think (hope) your problems were fixed with the recent memory
> > > coruption bug fix for SLQB. (if not, let me know)
> > >
> > > This one possibly looks like a problem with remote memory allocation
> > > or memory hotplug or something like that. I'll do a bit of code
> > > review....
> >
> > These are -next kernels which include the two fixes you posted recently
> > (I am pretty sure).
>
> Yes they should do.
>
>
> > I am also getting the network failures that Sachin
> > is seeing on several of my machines here. The previously reported
> > problems have gone away.
>
> This one is a SCSI failure... was there also a network one reported?
> At any rate, I'm fairly sure this is a problem with SLQB, so it could
> easily happen in any early driver setup.
This is what I have been getting for the last few days:
calling .ibmveth_module_init+0x0/0x80 @ 1
Unable to handle kernel paging request for data at address 0x22640004002d310
Faulting instruction address: 0xc000000000038840
cpu 0x0: Vector: 300 (Data Access) at [c0000000be67ef50]
pc: c000000000038840: .memcpy+0x240/0x280
lr: c0000000002a7860: .__nla_put+0x30/0x50
sp: c0000000be67f1d0
msr: 8000000000009032
dar: 22640004002d310
dsisr: 40000000
current = 0xc0000000be67a000
paca = 0xc000000000913280
pid = 1, comm = swapper
enter ? for help
[link register ] c0000000002a7860 .__nla_put+0x30/0x50
[c0000000be67f1d0] c0000000002a7850 .__nla_put+0x20/0x50 (unreliable)
[c0000000be67f260] c0000000002a7bb8 .nla_put+0x48/0x60
[c0000000be67f2e0] c0000000004a50b0 .rtnl_fill_ifinfo+0x320/0x740
[c0000000be67f3e0] c0000000004a586c .rtmsg_ifinfo+0x7c/0x110
[c0000000be67f480] c0000000004a59f0 .rtnetlink_event+0xf0/0x110
[c0000000be67f500] c00000000008a848 .notifier_call_chain+0x78/0x100
[c0000000be67f5a0] c0000000004964b8 .call_netdevice_notifiers+0x28/0x40
[c0000000be67f620] c000000000497a40 .register_netdevice+0x340/0x400
[c0000000be67f700] c000000000497b58 .register_netdev+0x58/0x80
[c0000000be67f790] c000000000574b4c .ibmveth_probe+0x2ec/0x400
[c0000000be67f8a0] c0000000000248b0 .vio_bus_probe+0xa0/0xb0
[c0000000be67f930] c000000000328b30 .driver_probe_device+0xf0/0x210
[c0000000be67f9d0] c000000000328d28 .__driver_attach+0xd8/0xe0
[c0000000be67fa60] c000000000327c78 .bus_for_each_dev+0x98/0xf0
[c0000000be67fb10] c000000000328898 .driver_attach+0x28/0x40
[c0000000be67fb90] c00000000032849c .bus_add_driver+0xdc/0x2d0
[c0000000be67fc30] c000000000329314 .driver_register+0x84/0x1d0
[c0000000be67fcd0] c0000000000247f0 .vio_register_driver+0x40/0x60
[c0000000be67fd60] c00000000077c5ac .ibmveth_module_init+0x5c/0x80
[c0000000be67fde0] c00000000000901c .do_one_initcall+0x6c/0x1e0
[c0000000be67fee0] c00000000074ed1c .kernel_init+0x1fc/0x280
[c0000000be67ff90] c00000000002a4c0 .kernel_thread+0x54/0x70
--
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: [alsa-devel] [PATCH] aoa: remove driver_data direct access of struct device
From: Takashi Iwai @ 2009-05-12 6:40 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, johannes, Greg Kroah-Hartman, alsa-devel, lkml
In-Reply-To: <4A08828B.7090106@gmail.com>
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?
thanks,
Takashi
> ---
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index fbf5c93..586965f 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -1037,7 +1037,7 @@ static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
> }
> ldev->selfptr_headphone.ptr = ldev;
> ldev->selfptr_lineout.ptr = ldev;
> - sdev->ofdev.dev.driver_data = ldev;
> + dev_set_drvdata(&sdev->ofdev.dev, ldev);
> list_add(&ldev->list, &layouts_list);
> layouts_list_items++;
>
> @@ -1081,7 +1081,7 @@ static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
>
> static int aoa_fabric_layout_remove(struct soundbus_dev *sdev)
> {
> - struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
> + struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
> int i;
>
> for (i=0; i<MAX_CODECS_PER_BUS; i++) {
> @@ -1114,7 +1114,7 @@ static int aoa_fabric_layout_remove(struct soundbus_dev *sdev)
> #ifdef CONFIG_PM
> static int aoa_fabric_layout_suspend(struct soundbus_dev *sdev, pm_message_t state)
> {
> - struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
> + struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
>
> if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
> ldev->gpio.methods->all_amps_off(&ldev->gpio);
> @@ -1124,7 +1124,7 @@ static int aoa_fabric_layout_suspend(struct soundbus_dev *sdev, pm_message_t sta
>
> static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
> {
> - struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
> + struct layout_dev *ldev = dev_get_drvdata(&sdev->ofdev.dev);
>
> if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
> ldev->gpio.methods->all_amps_restore(&ldev->gpio);
> diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
> index 418c84c..4e3b819 100644
> --- a/sound/aoa/soundbus/i2sbus/core.c
> +++ b/sound/aoa/soundbus/i2sbus/core.c
> @@ -358,14 +358,14 @@ static int i2sbus_probe(struct macio_dev* dev, const struct of_device_id *match)
> return -ENODEV;
> }
>
> - dev->ofdev.dev.driver_data = control;
> + dev_set_drvdata(&dev->ofdev.dev, control);
>
> return 0;
> }
>
> static int i2sbus_remove(struct macio_dev* dev)
> {
> - struct i2sbus_control *control = dev->ofdev.dev.driver_data;
> + struct i2sbus_control *control = dev_get_drvdata(&dev->ofdev.dev);
> struct i2sbus_dev *i2sdev, *tmp;
>
> list_for_each_entry_safe(i2sdev, tmp, &control->list, item)
> @@ -377,7 +377,7 @@ static int i2sbus_remove(struct macio_dev* dev)
> #ifdef CONFIG_PM
> static int i2sbus_suspend(struct macio_dev* dev, pm_message_t state)
> {
> - struct i2sbus_control *control = dev->ofdev.dev.driver_data;
> + struct i2sbus_control *control = dev_get_drvdata(&dev->ofdev.dev);
> struct codec_info_item *cii;
> struct i2sbus_dev* i2sdev;
> int err, ret = 0;
> @@ -407,7 +407,7 @@ static int i2sbus_suspend(struct macio_dev* dev, pm_message_t state)
>
> static int i2sbus_resume(struct macio_dev* dev)
> {
> - struct i2sbus_control *control = dev->ofdev.dev.driver_data;
> + struct i2sbus_control *control = dev_get_drvdata(&dev->ofdev.dev);
> struct codec_info_item *cii;
> struct i2sbus_dev* i2sdev;
> int err, ret = 0;
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: Next May 11 : BUG during scsi initialization
From: Stephen Rothwell @ 2009-05-12 6:52 UTC (permalink / raw)
To: Nick Piggin
Cc: linux-scsi, Matthew Wilcox, linuxppc-dev, Pekka Enberg,
linux-next
In-Reply-To: <20090512160352.4a97d2f4.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Hi Nick,
On Tue, 12 May 2009 16:03:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> This is what I have been getting for the last few days:
bisected into the net changes, I will follow up there, sorry.
--
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: Next May 11 : BUG during scsi initialization
From: Nick Piggin @ 2009-05-12 6:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-scsi, Matthew Wilcox, linuxppc-dev, Pekka Enberg,
linux-next
In-Reply-To: <20090512165245.78b6bf83.sfr@canb.auug.org.au>
On Tue, May 12, 2009 at 04:52:45PM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Tue, 12 May 2009 16:03:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > This is what I have been getting for the last few days:
>
> bisected into the net changes, I will follow up there, sorry.
No problem. Phew, yours was looking like a nasty one if it was indeed
an SLQB bug ;)
Thanks,
Nick
^ permalink raw reply
* Re: [alsa-devel] [PATCH] aoa: remove driver_data direct access of struct device
From: Greg KH @ 2009-05-12 6:57 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, johannes, Roel Kluin, alsa-devel, lkml
In-Reply-To: <s5hws8mu8my.wl%tiwai@suse.de>
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.
thanks,
greg k-h
^ permalink raw reply
* Re: [PowerPC] Next May 8 boot failure: OOPS during ibmveth moduleinit
From: Stephen Rothwell @ 2009-05-12 7:04 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev, netdev, linux-next, David Miller, Jiri Pirko
In-Reply-To: <4A085B3D.5000806@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
Hi all,
On Mon, 11 May 2009 22:37:09 +0530 Sachin Sant <sachinp@in.ibm.com> wrote:
>
> Jiri Pirko wrote:
> > Fri, May 08, 2009 at 09:57:22PM CEST, davem@davemloft.net wrote:
> >
> >> From: Sachin Sant <sachinp@in.ibm.com>
> >> Date: Fri, 08 May 2009 18:22:48 +0530
> >>
> >>
> >>> Todays Next failed to boot on a Power6 JS22 blade with following oops.
> >>>
> >> Jiri, I suspect this might be your address list changes.
> >>
> >> Although that's just a guess. But please take a look.
> >>
> >
> > Hmm, only thing I see might cause the problem would be if calling __hw_addr_add
> > in dev_addr_init fails, then dev->dev_addr would contain zeroes (which looks
> > this is not the case). But in this case the oops would appear earlier (in
> > ibmveth_probe dev_addr memcpy).
> >
> > Will do the patch which checks the result to behave correctly in case of oom
> > but this imho this wouldn't help. Strange, I will dig into this more tomorrow.
Bisected down to:
commit f001fde5eadd915f4858d22ed70d7040f48767cf
Author: Jiri Pirko <jpirko@redhat.com>
Date: Tue May 5 02:48:28 2009 +0000
net: introduce a list of device addresses dev_addr_list (v6)
I can reproduce this at will on the last three linux-next trees.
--
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
* [PATCH] Trivial spelling fix in ppc code comments
From: Sankar P @ 2009-05-12 7:11 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, trivial@kernel.org, linuxppc-dev
Fixes a trivial spelling error in powerpc code comments.
Signed-off-by: Sankar P <sankar.curiosity@gmail.com>
---
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 89497fb..3b52c80 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -2,7 +2,7 @@
* PowerPC64 SLB support.
*
* Copyright (C) 2004 David Gibson <dwg@au.ibm.com>, IBM
- * Based on earlier code writteh by:
+ * Based on earlier code written by:
* Dave Engebretsen and Mike Corrigan {engebret|mikejc}@us.ibm.com
* Copyright (c) 2001 Dave Engebretsen
* Copyright (C) 2002 Anton Blanchard <anton@au.ibm.com>, IBM
^ permalink raw reply related
* Xilinx FIFO TEMAC !?
From: David H. Lynch Jr. @ 2009-05-12 7:20 UTC (permalink / raw)
To: linuxppc-dev
I am working on changes to xilinx_lltemac.c that support both
the SDMA and FIFO TEMAC's.
I was wondering if anyone else had done anything already ?
I have it pretty much working with a few issues:
every so often the read FIFO gets out of sync and I have to
reset it dropping atleast one packet.
Somehow something is screwed up that is breaking the
Busybox Web server. This is really weird because nothing else seems to
be broken.
I have no clue how a driver that has no idea what is in the
packets passing through it can selectively screw up HTTP packets, but I
have proven to myself that the problem is in the driver - despite the my
beleif that is impossible.
Anyway is there any interest in an LL FIFO TEMAC driver ?
Or adding the FIFO code to the SDMA TEMAC code ? It only adds a
couple of dozen lines to the driver.
--
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: [alsa-devel] [PATCH] aoa: remove driver_data direct access of struct device
From: Takashi Iwai @ 2009-05-12 7:23 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, johannes, Roel Kluin, alsa-devel, lkml
In-Reply-To: <20090512065743.GA25267@suse.de>
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.
thanks,
Takashi
^ permalink raw reply
* Re: device trees.
From: Wolfram Sang @ 2009-05-12 7:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, David H. Lynch Jr.
In-Reply-To: <fa686aa40905111704g29d18835w249c89b97d22fc0d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
On Mon, May 11, 2009 at 06:04:16PM -0600, Grant Likely wrote:
> > David: If you would like to have a discussion regarding particular
> > design tradeoffs, I'd be happy to, but since I doubt there is anyone on
> > this list who is interested in the vagaries of FPGA configuration
> > methods, I suggest we have the discussion privately.
>
> I disagree. There are lots of lurkers on this list who care about
> virtex stuff, not to mention non-lurkers like me. :-) I would at
> least like to be a fly on the wall of any such discussion.
+1 :)
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PowerPC] Next May 8 boot failure: OOPS during ibmveth moduleinit
From: Stephen Rothwell @ 2009-05-12 7:44 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, linux-next, netdev, Jiri Pirko
In-Reply-To: <20090512170458.39c4ffb7.sfr@canb.auug.org.au>
Hi Dave,
This fixes it (I wonder if this bug is lurking in any other drivers):
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().
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/ibmveth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
index 7902e5e..8daffad 100644
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -1285,7 +1285,7 @@ static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_
netdev->features |= NETIF_F_LLTX;
spin_lock_init(&adapter->stats_lock);
- memcpy(&netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
+ memcpy(netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
for(i = 0; i<IbmVethNumBufferPools; i++) {
struct kobject *kobj = &adapter->rx_buff_pool[i].kobj;
--
1.6.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: question about softirqs
From: Ingo Molnar @ 2009-05-12 8:12 UTC (permalink / raw)
To: Chris Friesen, Peter Zijlstra, Thomas Gleixner, Steven Rostedt
Cc: linuxppc-dev, paulus, David Miller, netdev
In-Reply-To: <4A08C62F.1050105@nortel.com>
* Chris Friesen <cfriesen@nortel.com> wrote:
> This started out as a thread on the ppc list, but on the
> suggestion of DaveM and Paul Mackerras I'm expanding the receiver
> list a bit.
>
> Currently, if a softirq is raised in process context the
> TIF_RESCHED_PENDING flag gets set and on return to userspace we
> run the scheduler, expecting it to switch to ksoftirqd to handle
> the softirqd processing.
>
> I think I see a possible problem with this. Suppose I have a
> SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under
> the scenario above, schedule() would re-run the spinning task
> rather than ksoftirqd, thus preventing any incoming packets from
> being sent up the stack until we get a real hardware
> interrupt--which could be a whole jiffy if interrupt mitigation is
> enabled in the net device.
TIF_RESCHED_PENDING will not be set if a SCHED_FIFO task wakes up a
SCHED_OTHER ksoftirqd task. But starvation of ksoftirqd processing
will occur.
> DaveM pointed out that if we're doing transmits we're likely to
> hit local_bh_enable(), which would process the softirq work.
> However, I think we may still have a problem in the above rx-only
> scenario--or is it too contrived to matter?
This could occur, and the problem is really that task priorities do
not extend across softirq work processing.
This could occur in ordinary SCHED_OTHER tasks as well, if the
softirq is bounced to ksoftirqd - which it only should be if there's
serious softirq overload - or, as you describe it above, if the
softirq is raised in process context:
if (!in_interrupt())
wakeup_softirqd();
that's not really clean. We look into eliminating process context
use of raise_softirq_irqsoff(). Such code sequence:
local_irq_save(flags);
...
raise_softirq_irqsoff(nr);
...
local_irq_restore(flags);
should be converted to something like:
local_irq_save(flags);
...
raise_softirq_irqsoff(nr);
...
local_irq_restore(flags);
recheck_softirqs();
If someone does not do proper local_bh_disable()/enable() sequences
for micro-optimization reasons, then push the check to after the
critcal section - and dont cause extra reschedules by waking up
ksoftirqd. raise_softirq_irqsoff() will also be faster.
Ingo
^ permalink raw reply
* Re: [PowerPC] Next May 8 boot failure: OOPS during ibmveth moduleinit
From: Jiri Pirko @ 2009-05-12 8:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-next, David Miller, netdev
In-Reply-To: <20090512174451.eeed4126.sfr@canb.auug.org.au>
Tue, May 12, 2009 at 09:44:51AM CEST, sfr@canb.auug.org.au wrote:
>Hi Dave,
>
>This fixes it (I wonder if this bug is lurking in any other drivers):
Grepping the sources I see some other places suffering this problem. I'll send
patch for this.
>
>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().
Nice!
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
>Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>---
> drivers/net/ibmveth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
>index 7902e5e..8daffad 100644
>--- a/drivers/net/ibmveth.c
>+++ b/drivers/net/ibmveth.c
>@@ -1285,7 +1285,7 @@ static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_
> netdev->features |= NETIF_F_LLTX;
> spin_lock_init(&adapter->stats_lock);
>
>- memcpy(&netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
>+ memcpy(netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
>
> for(i = 0; i<IbmVethNumBufferPools; i++) {
> struct kobject *kobj = &adapter->rx_buff_pool[i].kobj;
>--
>1.6.3
>
>
>--
>Cheers,
>Stephen Rothwell sfr@canb.auug.org.au
>http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* [PATCH 0/6] rapidio: adding memory mapping IO support and misc fixes
From: Li Yang @ 2009-05-12 8:40 UTC (permalink / raw)
To: akpm, Kumar Gala, David Miller, mporter
Cc: linuxppc-dev Development, linux-kernel, Netdev
This is a re-post of patch series which adds MMIO support to Linux
RapidIO and fixes a few nits.
- Leo
^ permalink raw reply
* [PATCH 3/6] powerpc: add memory map support to Freescale RapidIO block
From: Li Yang @ 2009-05-12 8:36 UTC (permalink / raw)
To: akpm, galak, davem, mporter
Cc: linuxppc-dev, Zhang Wei, Li Yang, linux-kernel, netdev
In-Reply-To: <1242117363-14949-2-git-send-email-leoli@freescale.com>
The RIO memory map functions are used to support direct IO memory access
to RapidIO space. The patch adds its support for Freescale RapidIO block
driver.
Signed-off-by: Zhang Wei <zw@zh-kernel.org>
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/sysdev/fsl_rio.c | 217 ++++++++++++++++++++++++++++++++++++++++-
1 files changed, 215 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index fa0720f..7056dc0 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -31,6 +31,9 @@
#define IRQ_RIO_TX(m) (((struct rio_priv *)(m->priv))->txirq)
#define IRQ_RIO_RX(m) (((struct rio_priv *)(m->priv))->rxirq)
+#define IS_64BIT_DMA ((sizeof(dma_addr_t) == 8) ? 1 : 0)
+#define IS_64BIT_PHYS ((sizeof(phys_addr_t) == 8) ? 1 : 0)
+
#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_P_MSG_REGS_OFFSET 0x11000
#define RIO_S_MSG_REGS_OFFSET 0x13000
@@ -40,6 +43,15 @@
#define RIO_ISR_AACR_AA 0x1 /* Accept All ID */
#define RIO_MAINT_WIN_SIZE 0x400000
#define RIO_DBELL_WIN_SIZE 0x1000
+#define RIO_MAX_INB_ATMU 4
+#define RIO_MAX_OUTB_ATMU 8
+#define RIO_INB_ATMU_REGS_OFFSET 0x10de0
+#define RIO_ATMU_EN_MASK 0x80000000
+
+#define RIO_NREAD 0x4
+#define RIO_NWRITE 0x4
+#define RIO_NWRITE_R 0x5
+#define RIO_NREAD_R 0x5
#define RIO_MSG_OMR_MUI 0x00000002
#define RIO_MSG_OSR_TE 0x00000080
@@ -83,6 +95,15 @@ struct rio_atmu_regs {
u32 pad3[3];
};
+struct rio_inb_atmu_regs {
+ u32 riwtar;
+ u32 pad1;
+ u32 riwbar;
+ u32 pad2;
+ u32 riwar;
+ u32 pad3[3];
+};
+
struct rio_msg_regs {
u32 omr;
u32 osr;
@@ -341,6 +362,188 @@ fsl_rio_config_write(struct rio_mport *mport, int index, u16 destid,
}
/**
+ * fsl_rio_map_inb_mem -- Mapping inbound memory region.
+ * @mport: RapidIO master port
+ * @lstart: Local memory space start address.
+ * @rstart: RapidIO space start address.
+ * @size: The mapping region size.
+ * @flags: Flags for mapping. 0 for using default flags.
+ *
+ * Return: 0 -- Success.
+ *
+ * This function will create the inbound mapping
+ * from rstart to lstart.
+ */
+static int fsl_rio_map_inb_mem(struct rio_mport *mport, dma_addr_t lstart,
+ resource_size_t rstart, resource_size_t size, u32 flags)
+{
+ int i;
+ struct rio_priv *priv = mport->priv;
+ struct rio_inb_atmu_regs __iomem *inbatmu = (struct rio_inb_atmu_regs *)
+ (priv->regs_win + RIO_INB_ATMU_REGS_OFFSET) - 1;
+ int size_ffs;
+ resource_size_t align;
+
+ if (flags == 0)
+ flags = (RIO_NREAD_R << 4) | RIO_NWRITE_R;
+
+ align = (size < 0x1000) ? 0x1000 : 1 << (__ilog2(size - 1) + 1);
+
+ /* Align the size */
+ if ((lstart + size) > (_ALIGN_DOWN(lstart, align) + align)) {
+ size_ffs = __ffs(_ALIGN_DOWN(lstart + size - 1, align));
+ size = 1 << (size_ffs + (((_ALIGN_DOWN(lstart, 1 << size_ffs) +
+ (1 << size_ffs)) < (lstart + size)) ? 1 : 0));
+ } else
+ size = align;
+
+ if ((lstart & (size - 1)) != (rstart & (size - 1))) {
+ dev_err(mport->dev, "The local address 0x%llx can not be "
+ "aligned to the same size 0x%llx with the RapidIO "
+ "space address 0x%llx!\n", (unsigned long long)lstart,
+ (unsigned long long)size, (unsigned long long)rstart);
+ return -EINVAL;
+ }
+
+ /* Search for free inbound ATMU */
+ for (i = 1;
+ (i <= RIO_MAX_INB_ATMU) && (inbatmu->riwar & RIO_ATMU_EN_MASK);
+ i++, inbatmu--)
+ ;
+
+ if (i > RIO_MAX_INB_ATMU) {
+ dev_err(mport->dev, "No free inbound ATMU!\n");
+ return -EBUSY;
+ }
+ out_be32(&inbatmu->riwtar, ((IS_64BIT_DMA ? (lstart >> 32)
+ & 0xf : 0) << 20) | ((lstart >> 12) & 0xfffff));
+ out_be32(&inbatmu->riwbar, ((IS_64BIT_DMA ? (rstart >> 32)
+ & 0x3 : 0) << 20) | ((rstart >> 12) & 0xfffff));
+ out_be32(&inbatmu->riwar, 0x80000000 | (0xf << 20)
+ | ((flags & 0xff) << 12)
+ | (__ilog2(size) - 1));
+ return 0;
+}
+
+/**
+ * fsl_rio_map_outb_mem -- Mapping outbound memory region.
+ * @mport: RapidIO master port
+ * @lstart: Local memory space start address.
+ * @rstart: RapidIO space start address.
+ * @size: The mapping region size.
+ * @tid: The target RapidIO device id.
+ * @flags: Flags for mapping. 0 for using default flags.
+ *
+ * Return: 0 -- Success.
+ *
+ * This function will create the outbound mapping
+ * from lstart to rstart.
+ */
+static int fsl_rio_map_outb_mem(struct rio_mport *mport, phys_addr_t lstart,
+ resource_size_t rstart, resource_size_t size,
+ u16 tid, u32 flags)
+{
+ int i;
+ struct rio_priv *priv = mport->priv;
+ struct rio_atmu_regs __iomem *outbatmu = (struct rio_atmu_regs *)
+ (priv->regs_win + RIO_ATMU_REGS_OFFSET) + 1;
+ int size_ffs;
+ resource_size_t align;
+
+ if (flags == 0)
+ flags = (RIO_NREAD << 4) | RIO_NWRITE_R;
+
+ align = (size < 0x1000) ? 0x1000 : 1 << (__ilog2(size - 1) + 1);
+
+ /* Align the size */
+ if ((lstart + size) > (_ALIGN_DOWN(lstart, align) + align)) {
+ size_ffs = __ffs(_ALIGN_DOWN(lstart + size - 1, align));
+ size = 1 << (size_ffs + (((_ALIGN_DOWN(lstart, 1 << size_ffs) +
+ (1 << size_ffs)) < (lstart + size)) ? 1 : 0));
+ } else
+ size = align;
+
+ if ((lstart & (size - 1)) != (rstart & (size - 1))) {
+ dev_err(mport->dev, "The local address 0x%llx can not be "
+ "aligned to the same size 0x%llx with the RapidIO "
+ "space address 0x%llx!\n", (unsigned long long)lstart,
+ (unsigned long long)size, (unsigned long long)rstart);
+ return -EINVAL;
+ }
+
+ /* Search for free outbound ATMU */
+ for (i = 1;
+ (i <= RIO_MAX_OUTB_ATMU) && (outbatmu->rowar & RIO_ATMU_EN_MASK);
+ i++, outbatmu++)
+ ;
+
+ if (i > RIO_MAX_OUTB_ATMU) {
+ dev_err(mport->dev, "No free outbound ATMU!\n");
+ return -EBUSY;
+ }
+ out_be32(&outbatmu->rowtar, ((tid & 0x3ff) << 22)
+ | ((IS_64BIT_PHYS ? (rstart >> 32) & 0x3 : 0) << 20)
+ | ((rstart >> 12) & 0xfffff));
+ if (mport->phy_type == RIO_PHY_SERIAL)
+ out_be32(&outbatmu->rowtear, tid >> 10);
+ out_be32(&outbatmu->rowbar, ((IS_64BIT_PHYS ?
+ (lstart >> 32) & 0xf : 0) << 20)
+ | ((lstart >> 12) & 0xfffff));
+ out_be32(&outbatmu->rowar, 0x80000000
+ | ((flags & 0xff) << 12)
+ | (__ilog2(size) - 1));
+ return 0;
+}
+
+/**
+ * fsl_rio_unmap_inb_mem -- Unmapping inbound memory region.
+ * @mport: RapidIO master port
+ * @lstart: Local memory space start address.
+ */
+static void fsl_rio_unmap_inb_mem(struct rio_mport *mport,
+ dma_addr_t lstart)
+{
+ int i;
+ struct rio_priv *priv = mport->priv;
+ struct rio_inb_atmu_regs __iomem *inbatmu = (struct rio_inb_atmu_regs *)
+ (priv->regs_win + RIO_INB_ATMU_REGS_OFFSET) - 1;
+
+ /* Search for inbound ATMU */
+ for (i = 1; i <= RIO_MAX_INB_ATMU ; i++, inbatmu--) {
+ u32 tar = ((IS_64BIT_DMA ? (lstart >> 32) & 0xf : 0) << 20)
+ | ((lstart >> 12) & 0xfffff);
+ if (inbatmu->riwtar == tar) {
+ out_be32(&inbatmu->riwar, ~(RIO_ATMU_EN_MASK));
+ return;
+ }
+ }
+}
+
+/**
+ * fsl_rio_unmap_outb_mem -- Unmapping outbound memory region.
+ * @mport: RapidIO master port
+ * @lstart: Local memory space start address.
+ */
+static void fsl_rio_unmap_outb_mem(struct rio_mport *mport,
+ phys_addr_t lstart)
+{
+ int i;
+ struct rio_priv *priv = mport->priv;
+ struct rio_atmu_regs __iomem *outbatmu = (struct rio_atmu_regs *)
+ (priv->regs_win + RIO_ATMU_REGS_OFFSET) + 1;
+
+ /* Search for outbound ATMU */
+ for (i = 1; i <= RIO_MAX_OUTB_ATMU ; i++, outbatmu++) {
+ u32 bar = ((IS_64BIT_PHYS ? (lstart >> 32) & 0xf : 0) << 20)
+ | ((lstart >> 12) & 0xfffff);
+ if (outbatmu->rowbar == bar) {
+ out_be32(&outbatmu->rowar, ~(RIO_ATMU_EN_MASK));
+ return;
+ }
+ }
+}
+
+/**
* rio_hw_add_outb_message - Add message to the MPC85xx outbound message queue
* @mport: Master port with outbound message queue
* @rdev: Target of outbound message
@@ -951,6 +1154,13 @@ static int fsl_rio_get_cmdline(char *s)
__setup("riohdid=", fsl_rio_get_cmdline);
+static struct rio_mem_ops fsl_mem_ops = {
+ .map_inb = fsl_rio_map_inb_mem,
+ .map_outb = fsl_rio_map_outb_mem,
+ .unmap_inb = fsl_rio_unmap_inb_mem,
+ .unmap_outb = fsl_rio_unmap_outb_mem,
+};
+
static inline void fsl_rio_info(struct device *dev, u32 ccsr)
{
const char *str;
@@ -1026,8 +1236,9 @@ int fsl_rio_setup(struct of_device *dev)
return -EFAULT;
}
dev_info(&dev->dev, "Of-device full name %s\n", dev->node->full_name);
- dev_info(&dev->dev, "Regs start 0x%08x size 0x%08x\n", regs.start,
- regs.end - regs.start + 1);
+ dev_info(&dev->dev, "Regs start 0x%llx size 0x%llx\n",
+ (unsigned long long)regs.start,
+ (unsigned long long)(regs.end - regs.start + 1));
dt_range = of_get_property(dev->node, "ranges", &rlen);
if (!dt_range) {
@@ -1067,6 +1278,7 @@ int fsl_rio_setup(struct of_device *dev)
port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL);
port->id = 0;
port->index = 0;
+ port->dev = &dev->dev;
priv = kzalloc(sizeof(struct rio_priv), GFP_KERNEL);
if (!priv) {
@@ -1095,6 +1307,7 @@ int fsl_rio_setup(struct of_device *dev)
priv->dev = &dev->dev;
port->ops = ops;
+ port->mops = &fsl_mem_ops;
port->host_deviceid = fsl_rio_get_hdid(port->id);
port->priv = priv;
--
1.5.4
^ permalink raw reply related
* [PATCH 2/6] powerpc/fsl_rio: use LAW address from device tree
From: Li Yang @ 2009-05-12 8:35 UTC (permalink / raw)
To: akpm, galak, davem, mporter; +Cc: linuxppc-dev, Li Yang, linux-kernel, netdev
In-Reply-To: <1242117363-14949-1-git-send-email-leoli@freescale.com>
Instead of fixed address in old code.
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/sysdev/fsl_rio.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index abdb124..fa0720f 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1077,8 +1077,9 @@ int fsl_rio_setup(struct of_device *dev)
INIT_LIST_HEAD(&port->dbells);
port->iores.start = law_start;
- port->iores.end = law_start + law_size;
+ port->iores.end = law_start + law_size - 1;
port->iores.flags = IORESOURCE_MEM;
+ port->iores.name = "rio_io_win";
priv->bellirq = irq_of_parse_and_map(dev->node, 2);
priv->txirq = irq_of_parse_and_map(dev->node, 3);
@@ -1156,14 +1157,15 @@ int fsl_rio_setup(struct of_device *dev)
out_be32((priv->regs_win + RIO_ISR_AACR), RIO_ISR_AACR_AA);
/* Configure maintenance transaction window */
- out_be32(&priv->maint_atmu_regs->rowbar, 0x000c0000);
- out_be32(&priv->maint_atmu_regs->rowar, 0x80077015);
+ out_be32(&priv->maint_atmu_regs->rowbar, law_start >> 12);
+ out_be32(&priv->maint_atmu_regs->rowar, 0x80077015); /* 4M */
priv->maint_win = ioremap(law_start, RIO_MAINT_WIN_SIZE);
/* Configure outbound doorbell window */
- out_be32(&priv->dbell_atmu_regs->rowbar, 0x000c0400);
- out_be32(&priv->dbell_atmu_regs->rowar, 0x8004200b);
+ out_be32(&priv->dbell_atmu_regs->rowbar,
+ (law_start + RIO_MAINT_WIN_SIZE) >> 12);
+ out_be32(&priv->dbell_atmu_regs->rowar, 0x8004200b); /* 4k */
fsl_rio_doorbell_init(port);
return 0;
--
1.5.4
^ permalink raw reply related
* [PATCH 6/6] rio: fix section mismatch
From: Li Yang @ 2009-05-12 8:36 UTC (permalink / raw)
To: akpm, galak, davem, mporter; +Cc: linuxppc-dev, Li Yang, linux-kernel, netdev
In-Reply-To: <1242117363-14949-5-git-send-email-leoli@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/rapidio/rio-scan.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
index 0838fb2..e29be3c 100644
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -296,7 +296,7 @@ static int __devinit rio_add_device(struct rio_dev *rdev)
* to a RIO device on success or NULL on failure.
*
*/
-static struct rio_dev *rio_setup_device(struct rio_net *net,
+static struct rio_dev __devinit *rio_setup_device(struct rio_net *net,
struct rio_mport *port, u16 destid,
u8 hopcount, int do_enum)
{
@@ -569,7 +569,7 @@ static void rio_net_add_mport(struct rio_net *net, struct rio_mport *port)
* Recursively enumerates a RIO network. Transactions are sent via the
* master port passed in @port.
*/
-static int rio_enum_peer(struct rio_net *net, struct rio_mport *port,
+static int __devinit rio_enum_peer(struct rio_net *net, struct rio_mport *port,
u8 hopcount)
{
int port_num;
@@ -728,7 +728,7 @@ static int rio_enum_complete(struct rio_mport *port)
* Recursively discovers a RIO network. Transactions are sent via the
* master port passed in @port.
*/
-static int
+static int __devinit
rio_disc_peer(struct rio_net *net, struct rio_mport *port, u16 destid,
u8 hopcount)
{
--
1.5.4
^ 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