* Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
From: Stephen Boyd @ 2010-12-07 19:10 UTC (permalink / raw)
To: Tony Lindgren
Cc: Randy Dunlap, Daniel Walker, Mike Frysinger, Arnd Bergmann,
Nicolas Pitre, linux-arm-msm, Greg Kroah-Hartman, linux-kernel,
FUJITA Tomonori, Andrew Morton, linuxppc-dev, Alan Cox
In-Reply-To: <4CF6AE04.6030201@codeaurora.org>
On 12/01/2010 12:20 PM, Stephen Boyd wrote:
> Definitely for TX since it seems like a redundant loop, but I agree RX
> code has changed. Instead of
>
> If RX buffer full
> Poll for RX buffer full
> Read character from RX buffer
>
> we would have
>
> If RX buffer full
> Read character from RX buffer
>
> which doesn't seem all that different assuming the RX buffer doesn't go
> from full to empty between the If and Poll steps. Hopefully Tony knows more.
>
Tony, any thoughts?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-07 20:51 UTC (permalink / raw)
To: Mark Mason; +Cc: linuxppc-dev
In-Reply-To: <20101207031554.GA12731@postdiluvian.org>
On Mon, 6 Dec 2010 22:15:54 -0500
Mark Mason <mason@postdiluvian.org> wrote:
> A few months ago I ran into some performance problems involving
> UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> found a solution for this, which worked well, at least with the
> hardware I was working with. I suspect the same problem affects other
> PPCs, probably including multicore devices, and maybe other
> architectures as well.
>
> I don't have experience with similar NAND controllers on other
> devices, so I'd like to explain what I found and see if someone who's
> more familiar with the family and/or driver can tell if this is
> useful.
>
> The problem cropped up when there was a lot of traffic to the NAND
> (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> a video chip that needed constant and prompt attention.
If you attach NAND to the LBC, you should not attach anything else to
it which is latency-sensitive.
> What I found, though, was that the NAND did not inherently assert BUSY
> as part of the erase - BUSY was asserted because the driver polled for
> the status (NAND_CMD_STATUS). If the status poll was delayed for the
> duration of the erase then the MPC could talk to the video chip while
> the erase was in progress. At the end of the 1ms delay I would then
> poll for status, which would complete effectively immediately.
That's what we originially did. The problem is that during this
interval the NAND chip will be driving the busy pin, which corrupts
other LBC transactions.
Newer chips have this added text in their reference manuals under "NAND
Flash Block Erase Command Sequence Example":
Note that operations specified by OP3 and OP4 (status read) should
never be skipped while erasing a NAND Flash device, because, in case
that happens, contention may arise on LGPL4. A possible case is that
the next transaction from eLBC may try to use that pin as an output
and since the NAND Flash device might already be driving it,
contention will occur. In case OP3 and OP4 operations are skipped,
it may also happen that a new command is issued to the NAND Flash
device even when the device has not yet finished processing the
previous request. This may also result in unpredictable behavior.
> Here's a code snippet from 2.6.37, with some comments I added.
> drivers/mtd/nand/fsl_elbc_nand.c - fsl_elbc_cmdfunc():
>
> /* ERASE2 uses the block and page address from ERASE1 */
> case NAND_CMD_ERASE2:
> dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD_ERASE2.\n");
>
> out_be32(&lbc->fir,
> (FIR_OP_CM0 << FIR_OP0_SHIFT) | /* Execute CMD0 (ERASE1). */
> (FIR_OP_PA << FIR_OP1_SHIFT) | /* Issue block and page address. */
> (FIR_OP_CM2 << FIR_OP2_SHIFT) | /* Execute CMD2 (ERASE2). */
> /* (delay needed here - this is where the erase happens) */
> (FIR_OP_CW1 << FIR_OP3_SHIFT) | /* Wait for LFRB (BUSY) to deassert */
> /* then issue CW1 (read status). */
> (FIR_OP_RS << FIR_OP4_SHIFT)); /* Read one byte. */
>
> out_be32(&lbc->fcr,
> (NAND_CMD_ERASE1 << FCR_CMD0_SHIFT) | /* 0x60 */
> (NAND_CMD_STATUS << FCR_CMD1_SHIFT) | /* 0x70 */
> (NAND_CMD_ERASE2 << FCR_CMD2_SHIFT)); /* 0xD0 */
>
> out_be32(&lbc->fbcr, 0);
> elbc_fcm_ctrl->read_bytes = 0;
> elbc_fcm_ctrl->use_mdr = 1;
>
> fsl_elbc_run_command(mtd);
> return;
>
> What I did was to issue two commands with fsl_elbc_run_command(), with
> a 1ms sleep in between (a tightloop delay worked almost as well, the
> important part was having 1ms between the erase and the status poll).
> The first command did the FIR_OP_CM0 (NAND_CMD_ERASE1), FIR_OP_PA, and
> FIR_OP_CM2 (NAND_CMD_ERASE2). The second did the FIR_OP_CW1
> (NAND_CMD_STATUS) and FIR_OP_RS.
So essentially, you reverted commit
476459a6cf46d20ec73d9b211f3894ced5f9871e
:-)
Except for the 1ms delay.
> I know almost nothing at all about the scheduler, but I'm pretty sure
> that this behavior would cause the scheduler to think the video thread
> was a CPU hog, since the video thread was running for 1ms for every
> 20us that the UBI BGT ran, which would cause the scheduler to unfairly
> prefer the UBI BGT. I initially tried to address this problem with
> thread priorities, but the unfortunate reality was that either the
> NAND writes could fall behind or the video chip could fall behind, and
> there wasn't spare bandwidth to allow either.
If you set a realtime priority and have preemption enabled, you should
be able to avoid being delayed by more than one NAND transaction, until
the realtime thread sleeps. Be careful to ensure that it does sleep
enough for other things to run.
-Scott
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Mark Mason @ 2010-12-07 23:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20101207145153.540da45a@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote:
> On Mon, 6 Dec 2010 22:15:54 -0500
> Mark Mason <mason@postdiluvian.org> wrote:
>
> > A few months ago I ran into some performance problems involving
> > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > found a solution for this, which worked well, at least with the
> > hardware I was working with. I suspect the same problem affects other
> > PPCs, probably including multicore devices, and maybe other
> > architectures as well.
> >
> > I don't have experience with similar NAND controllers on other
> > devices, so I'd like to explain what I found and see if someone who's
> > more familiar with the family and/or driver can tell if this is
> > useful.
> >
> > The problem cropped up when there was a lot of traffic to the NAND
> > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > a video chip that needed constant and prompt attention.
>
> If you attach NAND to the LBC, you should not attach anything else
> to it which is latency-sensitive.
We found that out the hard way.
The 1ms latency wasn't a problem by itself, the real problem was that
the quantity of erases issued in a short time significantly decreased
the bandwidth available, and that the scheduler saw the video thread
use 1ms of CPU time even though it'd only done a couple hundred
nanoseconds worth of work.
> > What I found, though, was that the NAND did not inherently assert BUSY
> > as part of the erase - BUSY was asserted because the driver polled for
> > the status (NAND_CMD_STATUS). If the status poll was delayed for the
> > duration of the erase then the MPC could talk to the video chip while
> > the erase was in progress. At the end of the 1ms delay I would then
> > poll for status, which would complete effectively immediately.
>
> That's what we originially did. The problem is that during this
> interval the NAND chip will be driving the busy pin, which corrupts
> other LBC transactions.
This is not what we observed with our flash part. For a page erase,
the NAND did not assert the busy pin until the status read was done.
This was confirmed with a logic analyzer, and taking advantage of this
behavior is the sole purpose of the change.
I don't think that this behavior is what's described in the Samsung
datasheet, but it is what our parts did.
I incorrectly said "polled for status" in my original post. It did
not poll for status, it monitored the busy line from NAND and did a
single read from the status register.
> Newer chips have this added text in their reference manuals under
> "NAND Flash Block Erase Command Sequence Example":
>
> Note that operations specified by OP3 and OP4 (status read) should
> never be skipped while erasing a NAND Flash device, because, in
> case that happens, contention may arise on LGPL4. A possible case
> is that the next transaction from eLBC may try to use that pin as
> an output and since the NAND Flash device might already be driving
> it, contention will occur. In case OP3 and OP4 operations are
> skipped, it may also happen that a new command is issued to the
> NAND Flash device even when the device has not yet finished
> processing the previous request. This may also result in
> unpredictable behavior.
I would expect those operations to be mandatory.
> > Here's a code snippet from 2.6.37, with some comments I added.
> > drivers/mtd/nand/fsl_elbc_nand.c - fsl_elbc_cmdfunc():
> >
> > /* ERASE2 uses the block and page address from ERASE1 */
> > case NAND_CMD_ERASE2:
> > dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD_ERASE2.\n");
> >
> > out_be32(&lbc->fir,
> > (FIR_OP_CM0 << FIR_OP0_SHIFT) | /* Execute CMD0 (ERASE1). */
> > (FIR_OP_PA << FIR_OP1_SHIFT) | /* Issue block and page address. */
> > (FIR_OP_CM2 << FIR_OP2_SHIFT) | /* Execute CMD2 (ERASE2). */
> > /* (delay needed here - this is where the erase happens) */
> > (FIR_OP_CW1 << FIR_OP3_SHIFT) | /* Wait for LFRB (BUSY) to deassert */
> > /* then issue CW1 (read status). */
> > (FIR_OP_RS << FIR_OP4_SHIFT)); /* Read one byte. */
> >
> > out_be32(&lbc->fcr,
> > (NAND_CMD_ERASE1 << FCR_CMD0_SHIFT) | /* 0x60 */
> > (NAND_CMD_STATUS << FCR_CMD1_SHIFT) | /* 0x70 */
> > (NAND_CMD_ERASE2 << FCR_CMD2_SHIFT)); /* 0xD0 */
> >
> > out_be32(&lbc->fbcr, 0);
> > elbc_fcm_ctrl->read_bytes = 0;
> > elbc_fcm_ctrl->use_mdr = 1;
> >
> > fsl_elbc_run_command(mtd);
> > return;
> >
> > What I did was to issue two commands with fsl_elbc_run_command(), with
> > a 1ms sleep in between (a tightloop delay worked almost as well, the
> > important part was having 1ms between the erase and the status poll).
> > The first command did the FIR_OP_CM0 (NAND_CMD_ERASE1), FIR_OP_PA, and
> > FIR_OP_CM2 (NAND_CMD_ERASE2). The second did the FIR_OP_CW1
> > (NAND_CMD_STATUS) and FIR_OP_RS.
>
> So essentially, you reverted commit
> 476459a6cf46d20ec73d9b211f3894ced5f9871e
>
> :-)
>
> Except for the 1ms delay.
Well then, the 1ms delay is the value-add!
> > I know almost nothing at all about the scheduler, but I'm pretty
> > sure that this behavior would cause the scheduler to think the
> > video thread was a CPU hog, since the video thread was running for
> > 1ms for every 20us that the UBI BGT ran, which would cause the
> > scheduler to unfairly prefer the UBI BGT. I initially tried to
> > address this problem with thread priorities, but the unfortunate
> > reality was that either the NAND writes could fall behind or the
> > video chip could fall behind, and there wasn't spare bandwidth to
> > allow either.
>
> If you set a realtime priority and have preemption enabled, you
> should be able to avoid being delayed by more than one NAND
> transaction, until the realtime thread sleeps. Be careful to ensure
> that it does sleep enough for other things to run.
I tried that, but if the erases were held off enough to get the other
bus bandwidth we required then the NAND writes fell behind and the
kernel oom'd.
> -Scott
Thanks for reviewing it. It wouldn't surprise me if this wasn't
useful in a more general case, but it made a big difference for us.
^ permalink raw reply
* [PATCH] powerpc: iommu: Add device name to iommu error printks
From: Anton Blanchard @ 2010-12-08 0:36 UTC (permalink / raw)
To: benh, linuxppc-dev
Right now its difficult to see which device is running out of iommu space:
iommu_alloc failed, tbl c00000076e096660 vaddr c000000768806600 npages 1
Use dev_info() so we get the device name and location:
ipr 0000:00:01.0: iommu_alloc failed, tbl c00000076e096660 vaddr c000000768806600 npages 1
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/iommu.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/iommu.c 2010-12-08 11:28:39.055483332 +1100
+++ powerpc.git/arch/powerpc/kernel/iommu.c 2010-12-08 11:30:54.569176185 +1100
@@ -311,8 +311,9 @@ int iommu_map_sg(struct device *dev, str
/* Handle failure */
if (unlikely(entry == DMA_ERROR_CODE)) {
if (printk_ratelimit())
- printk(KERN_INFO "iommu_alloc failed, tbl %p vaddr %lx"
- " npages %lx\n", tbl, vaddr, npages);
+ dev_info(dev, "iommu_alloc failed, tbl %p "
+ "vaddr %lx npages %lu\n", tbl, vaddr,
+ npages);
goto failure;
}
@@ -579,9 +580,9 @@ dma_addr_t iommu_map_page(struct device
attrs);
if (dma_handle == DMA_ERROR_CODE) {
if (printk_ratelimit()) {
- printk(KERN_INFO "iommu_alloc failed, "
- "tbl %p vaddr %p npages %d\n",
- tbl, vaddr, npages);
+ dev_info(dev, "iommu_alloc failed, tbl %p "
+ "vaddr %p npages %d\n", tbl, vaddr,
+ npages);
}
} else
dma_handle |= (uaddr & ~IOMMU_PAGE_MASK);
@@ -627,7 +628,8 @@ void *iommu_alloc_coherent(struct device
* the tce tables.
*/
if (order >= IOMAP_MAX_ORDER) {
- printk("iommu_alloc_consistent size too large: 0x%lx\n", size);
+ dev_info(dev, "iommu_alloc_consistent size too large: 0x%lx\n",
+ size);
return NULL;
}
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-08 0:50 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012071346.13434.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
On Tue, 2010-12-07 at 13:46 +0100, Guillaume Dargaud wrote:
> Michael,
> in your example, when is foo_driver_probe() actually called ?
> It's not being called when I do an insmod.
It should be called when the driver core finds a device that matches
your match table.
When you register your driver the driver core will iterate over all
devices on the platform bus and if they match then it will call your
probe routine.
I assume you've update the compatible property in the match table, I'm
not sure what else could be causing it to not be called.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-08 0:37 UTC (permalink / raw)
To: Mark Mason; +Cc: linuxppc-dev
In-Reply-To: <20101207232445.GB29218@postdiluvian.org>
On Tue, 7 Dec 2010 18:24:45 -0500
Mark Mason <mason@postdiluvian.org> wrote:
> Scott Wood <scottwood@freescale.com> wrote:
>
> > On Mon, 6 Dec 2010 22:15:54 -0500
> > Mark Mason <mason@postdiluvian.org> wrote:
> >
> > > What I found, though, was that the NAND did not inherently assert BUSY
> > > as part of the erase - BUSY was asserted because the driver polled for
> > > the status (NAND_CMD_STATUS). If the status poll was delayed for the
> > > duration of the erase then the MPC could talk to the video chip while
> > > the erase was in progress. At the end of the 1ms delay I would then
> > > poll for status, which would complete effectively immediately.
> >
> > That's what we originially did. The problem is that during this
> > interval the NAND chip will be driving the busy pin, which corrupts
> > other LBC transactions.
>
> This is not what we observed with our flash part. For a page erase,
> the NAND did not assert the busy pin until the status read was done.
> This was confirmed with a logic analyzer, and taking advantage of this
> behavior is the sole purpose of the change.
How would that work, in the normal case where you wait for busy to go
away before reading status?
We observed this corruption happening. It was the motivation for
commit 476459a6cf46d20ec73d9b211f3894ced5f9871e.
> > Newer chips have this added text in their reference manuals under
> > "NAND Flash Block Erase Command Sequence Example":
> >
> > Note that operations specified by OP3 and OP4 (status read) should
> > never be skipped while erasing a NAND Flash device, because, in
> > case that happens, contention may arise on LGPL4. A possible case
> > is that the next transaction from eLBC may try to use that pin as
> > an output and since the NAND Flash device might already be driving
> > it, contention will occur. In case OP3 and OP4 operations are
> > skipped, it may also happen that a new command is issued to the
> > NAND Flash device even when the device has not yet finished
> > processing the previous request. This may also result in
> > unpredictable behavior.
>
> I would expect those operations to be mandatory.
...but you remove them from the original FIR. They're not just
mandatory to be done eventually, it has to be done within the one
transaction that is atomic at the LBC.
> > > I know almost nothing at all about the scheduler, but I'm pretty
> > > sure that this behavior would cause the scheduler to think the
> > > video thread was a CPU hog, since the video thread was running for
> > > 1ms for every 20us that the UBI BGT ran, which would cause the
> > > scheduler to unfairly prefer the UBI BGT. I initially tried to
> > > address this problem with thread priorities, but the unfortunate
> > > reality was that either the NAND writes could fall behind or the
> > > video chip could fall behind, and there wasn't spare bandwidth to
> > > allow either.
> >
> > If you set a realtime priority and have preemption enabled, you
> > should be able to avoid being delayed by more than one NAND
> > transaction, until the realtime thread sleeps. Be careful to ensure
> > that it does sleep enough for other things to run.
>
> I tried that, but if the erases were held off enough to get the other
> bus bandwidth we required then the NAND writes fell behind and the
> kernel oom'd.
Another possibility (but still hackish) is to have the NAND driver
poll rather than be interrupt driven, and disable interrupts while
polling. Then, whenever anything else runs (assuming no SMP), it
should be safe to access LBC without high latency -- so the scheduler
shouldn't get confused.
To make it somewhat cleaner, provide the same benefit on SMP, and allow
non-LBC things to run, you could use a mutex to synchronize between all
LBC users, though that's more work and could be a nuisance if you want
to access the LBC from an interrupt handler.
-Scott
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-08 1:03 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012061544.40124.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 3740 bytes --]
On Mon, 2010-12-06 at 15:44 +0100, Guillaume Dargaud wrote:
> Hello all,
>
> > OK, that should be all pretty straight forward, and covered by the
> > material in LDD and similar references. You just need to get your device
> > probed.
>
> I'm not sure what you mean with that term: simply identifying that the device
> works using device specific code ?
I just mean connecting your driver up to a struct device that represents
your device.
> I've looked at several *_probe functions from other drivers and they are all
> completely different with no common code...
Yes that's pretty normal, the probe routine usually finds device
specific info about the device and stores it in some sort of structure
for later use.
> Or do you mean calling of_platform_bus_probe() ? What does that function do ?
The platform code does that. That function create devices on the
platform bus by examining the device tree. It looks for nodes that are
compatible with the compatible strings you give it, and treats them as
busses, ie. creates devices for all child nodes of those nodes.
> > No it's just that platform_drivers are now able to do all the things an
> > of_platform_driver can do, so new code should just use platform_driver.
> >
> > I'm not sure if of_platform_bus_probe() will go away eventually, but for
> > now it is the only way to achieve what you need.
>
> I assume the kernel needs to be compiled with CONFIG_OF.
Yes absolutely.
> ...hmm I had to "git pull" in order for this to compile your snippet. That's
> really recent! Unfortunately i need to reflash my device with the new kernel
> before i can begin testing my module.
It shouldn't be that recent, what kernel version were you using?
> When I try to compile your (adapted) snippet, I got this minor problems:
>
> .probe = foo_driver_probe,
> ^ warning: initialization from incompatible pointer type
> Shouldn't foo_driver_probe be:
> static int foo_driver_probe(struct platform_device *pdev)
> instead of:
> static int foo_driver_probe(struct platform_device *device,
> const struct of_device_id *device_id)
Yes sorry, that's a cut & paste bug, between the old and new style code.
> Also:
> struct foo_device *foo;
> That's where I put my own content, right ?
Yep.
> And needs to be kfreed in a foo_driver_remove() function, right ?
If you have a remove then yes.
> > > I still need a platform_device_register() after your sample init, right ?
> >
> > I had one in there already, in foo_driver_init(), didn't I?
>
> You had platform_driver_register(), not that I'm all clear yet on the
> distinction...
Oh sorry, I always read those wrong.
platform_device_register() creates a device on the platform bus. You
then write a driver for that device, and register it with
platform_driver_register(), your driver then attaches to the device.
In this case though you don't need to call platform_device_register()
because the device has already been created, using the device tree (by
of_platform_bus_probe()).
In general on powerpc we don't use platform_device_register() much,
instead things are described in the device tree and devices are created
for them.
platform_device_register() tends to be for cases where you can't
discover or probe a device, but you "know" that it exists.
> Another question: I just spent 10 minutes trying to find where "struct device"
> was defined. (ack-)grep was absolutely no use. Isn't there a way to cross-
> reference my own kernel, the way I've compiled it ?
Yes, "make tags", then use vim :)
If you're cross-compiling make sure to set ARCH=powerpc when you make
tags.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Run 'usermode-agent' cause kernel panic on Powerpc
From: xufeng zhang @ 2010-12-08 1:20 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: Linuxppc-dev
In-Reply-To: <1291730683.16003.4.camel@shaggy-w500>
On 12/07/2010 10:04 PM, Dave Kleikamp wrote:
> On Tue, 2010-12-07 at 14:48 +0800, xufeng zhang wrote:
>
>> Hi Dave,
>>
>> I have a question with the below patch you made before:
>> ----------------------------------------
>> powerpc/booke: Add support for advanced debug registers
>>
>> From: Dave Kleikamp<shaggy@linux.vnet.ibm.com>
>>
>> Based on patches originally written by Torez Smith.
>> -----------------------------------------
>>
>> I meet a kernel panic problem while running 'usermode-agent' on PowerPC
>> ----------------------------------------
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> PREEMPT LTT NESTING LEVEL : 0
>> MPC8536 DS
>> last sysfs file:
>> /sys/devices/f3000000.soc/f3003100.i2c/i2c-1/i2c-dev/i2c-1/dev
>> Modules linked in:
>> NIP: c00081a0 LR: c03a9560 CTR: c003547c
>> REGS: ef11bf10 TRAP: 2002 Not tainted (2.6.34.6-WR4.0.0.0_standard)
>> MSR: 00021000<ME,CE> CR: 44000624 XER: 00000000
>> TASK = efc1de00[752] 'usermode-agent' THREAD: ef63e000
>> GPR00: cc00cc00 ef63fe60 efc1de00 efc1de00 efc1f700 c04c8000 00258560
>> ffffffff
>> GPR08: ffda8a00 40000000 00001fda c0500000 49eaebbd 1008b654 3ff8a900
>> 00000000
>> GPR16: 00000000 eed84c40 c03b4570 c04ee4d0 c04ca870 ef63e03c 00000000
>> 00000000
>> GPR24: c04f7ee8 c04ee4c0 00000004 c04ca440 ef63e000 efc1f700 c04ca440
>> efc1de00
>> NIP [c00081a0] __switch_to+0xac/0x104
>> LR [c03a9560] schedule+0x20c/0x3f4
>> Call Trace:
>> [ef63fe60] [efc1f700] 0xefc1f700 (unreliable)
>> [ef63fe70] [c03a9560] schedule+0x20c/0x3f4
>> [ef63fec0] [c00429e0] do_wait+0x1a4/0x278
>> [ef63fef0] [c0042b44] sys_wait4+0x90/0xf8
>> [ef63ff40] [c00106d4] ret_from_syscall+0x0/0x4
>> ------------------------------------------
>>
>> Actually, this problem is caused by enabling On Chip Debugging, when On
>> Chip Debugging is enabled, we enable MSR_DE as below:
>> #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)
>>
>> If I comment out "mtspr(SPRN_DBCR0, thread->dbcr0);" in
>> prime_debug_regs() function,
>> then it will be ok.
>>
>> Here is my analysis for this problem:
>> Run 'usermode-agent' application will set Internal Debug Mode(IDM) and
>> Instruction Complete Debug Event(ICMP)flags for thread.
>> As MSR_DE is enabled, when execute context switching in prime_debug_regs(),
>> thread->dbcr0 would write to SPRN_DBCR0 register.
>> So this will enable Instruction Complete Debug Event interrupt, and it
>> will cause a kernel-mode
>> exception right now, it will be handled in native_DebugException(), then
>> kernel detected
>> this exception not happens in user-mode, lastly kernel call die() and
>> kill current process.
>>
>> So my question is could I just comment out "mtspr(SPRN_DBCR0,
>> thread->dbcr0);" in prime_debug_regs()?
>> I'm sure whether or not it will impose a bad impact on debugging.
>>
> I believe it would have such an impact. I don't see that user-mode
> debugging would be enabled at all.
>
> Maybe something like this untested patch:
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 84906d3..0e7d1cf 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -323,6 +323,13 @@ static void set_debug_reg_defaults(struct thread_struct *thread)
>
> static void prime_debug_regs(struct thread_struct *thread)
> {
> + /*
> + * If we're setting up debug events for user space, make sure they
> + * don't fire in kernel space before we get to user space
> + */
> + if (thread->dbcr0& DBCR0_IDM)
> + mtmsr(mfmsr()& ~MSR_DE);
> +
> mtspr(SPRN_IAC1, thread->iac1);
> mtspr(SPRN_IAC2, thread->iac2);
> #if CONFIG_PPC_ADV_DEBUG_IACS> 2
>
>
Thanks for your reply, Dave, I know where the problem is.
Thanks,
Xufeng Zhang
^ permalink raw reply
* Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
From: Paul Mundt @ 2010-12-08 5:36 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, linuxppc-dev, Samuel Ortiz,
Ben Dooks
In-Reply-To: <1291451028-22532-1-git-send-email-hs@denx.de>
On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> - add commandline options:
> sm501.fb_mode:
> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> - Add support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the "edid" entry in the "smi,sm501" node is present,
> the driver will build mode database using EDID data
> and allow setting the display modes from this database.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> cc: linux-fbdev@vger.kernel.org
> cc: devicetree-discuss@ozlabs.org
> ---
> based against 2.6.37-rc4
>
> ./scripts/checkpatch.pl 0003-video-sm501-add-OF-binding-to-support-SM501.patch lems and is ready for
> total: 0 errors, 0 warnings, 1067 lines checked
>
> 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style problems and is ready for submission.
>
> Documentation/kernel-parameters.txt | 7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 ++++++++------
> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> include/linux/sm501.h | 8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
Given that this is all SM501 dependent, is there some particular reason
why you neglected to Cc the author or the MFD folks?
^ permalink raw reply
* [PATCH] powerpc: Hardcode popcnt instructions for old assemblers
From: Anton Blanchard @ 2010-12-08 5:58 UTC (permalink / raw)
To: benh, sfr; +Cc: linuxppc-dev
The popcnt instructions went into binutils relatively recently. As with a
number of other instructions, create macros and hardcode them.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/ppc-opcode.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/ppc-opcode.h 2010-12-08 16:50:12.760796093 +1100
+++ powerpc.git/arch/powerpc/include/asm/ppc-opcode.h 2010-12-08 16:57:10.181788576 +1100
@@ -36,6 +36,8 @@
#define PPC_INST_NOP 0x60000000
#define PPC_INST_POPCNTB 0x7c0000f4
#define PPC_INST_POPCNTB_MASK 0xfc0007fe
+#define PPC_INST_POPCNTD 0x7c0003f4
+#define PPC_INST_POPCNTW 0x7c0002f4
#define PPC_INST_RFCI 0x4c000066
#define PPC_INST_RFDI 0x4c00004e
#define PPC_INST_RFMCI 0x4c00004c
@@ -88,6 +90,12 @@
__PPC_RB(b) | __PPC_EH(eh))
#define PPC_MSGSND(b) stringify_in_c(.long PPC_INST_MSGSND | \
__PPC_RB(b))
+#define PPC_POPCNTB(a, s) stringify_in_c(.long PPC_INST_POPCNTB | \
+ __PPC_RA(a) | __PPC_RS(s))
+#define PPC_POPCNTD(a, s) stringify_in_c(.long PPC_INST_POPCNTD | \
+ __PPC_RA(a) | __PPC_RS(s))
+#define PPC_POPCNTW(a, s) stringify_in_c(.long PPC_INST_POPCNTW | \
+ __PPC_RA(a) | __PPC_RS(s))
#define PPC_RFCI stringify_in_c(.long PPC_INST_RFCI)
#define PPC_RFDI stringify_in_c(.long PPC_INST_RFDI)
#define PPC_RFMCI stringify_in_c(.long PPC_INST_RFMCI)
Index: powerpc.git/arch/powerpc/lib/hweight_64.S
===================================================================
--- powerpc.git.orig/arch/powerpc/lib/hweight_64.S 2010-12-08 16:50:12.760796093 +1100
+++ powerpc.git/arch/powerpc/lib/hweight_64.S 2010-12-08 16:50:16.560623089 +1100
@@ -28,7 +28,7 @@ BEGIN_FTR_SECTION
nop
nop
FTR_SECTION_ELSE
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_IFCLR(CPU_FTR_POPCNTB)
@@ -42,14 +42,14 @@ BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
BEGIN_FTR_SECTION_NESTED(50)
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
srdi r4,r3,8
add r3,r4,r3
clrldi r3,r3,64-8
blr
FTR_SECTION_ELSE_NESTED(50)
clrlwi r3,r3,16
- popcntw r3,r3
+ PPC_POPCNTW(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_POPCNTD, 50)
@@ -66,7 +66,7 @@ BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
BEGIN_FTR_SECTION_NESTED(51)
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
srdi r4,r3,16
add r3,r4,r3
srdi r4,r3,8
@@ -74,7 +74,7 @@ FTR_SECTION_ELSE
clrldi r3,r3,64-8
blr
FTR_SECTION_ELSE_NESTED(51)
- popcntw r3,r3
+ PPC_POPCNTW(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_POPCNTD, 51)
@@ -93,7 +93,7 @@ BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
BEGIN_FTR_SECTION_NESTED(52)
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
srdi r4,r3,32
add r3,r4,r3
srdi r4,r3,16
@@ -103,7 +103,7 @@ FTR_SECTION_ELSE
clrldi r3,r3,64-8
blr
FTR_SECTION_ELSE_NESTED(52)
- popcntd r3,r3
+ PPC_POPCNTD(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_POPCNTD, 52)
^ permalink raw reply
* Re: [PATCH] powerpc: Hardcode popcnt instructions for old assemblers
From: Stephen Rothwell @ 2010-12-08 7:27 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20101208165817.0df89814@kryten>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
Hi Anton,
On Wed, 8 Dec 2010 16:58:17 +1100 Anton Blanchard <anton@samba.org> wrote:
>
> The popcnt instructions went into binutils relatively recently. As with a
> number of other instructions, create macros and hardcode them.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
That certainly fixes the build issue for me (tested ppc64_defconfig with
binutils 2.19.1).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 7:59 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101207145153.540da45a@udp111988uds.am.freescale.net>
>
> On Mon, 6 Dec 2010 22:15:54 -0500
> Mark Mason <mason@postdiluvian.org> wrote:
>
> > A few months ago I ran into some performance problems involving
> > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > found a solution for this, which worked well, at least with the
> > hardware I was working with. I suspect the same problem affects other
> > PPCs, probably including multicore devices, and maybe other
> > architectures as well.
> >
> > I don't have experience with similar NAND controllers on other
> > devices, so I'd like to explain what I found and see if someone who's
> > more familiar with the family and/or driver can tell if this is
> > useful.
> >
> > The problem cropped up when there was a lot of traffic to the NAND
> > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > a video chip that needed constant and prompt attention.
>
> If you attach NAND to the LBC, you should not attach anything else to
> it which is latency-sensitive.
This "feature" makes the LBC useless to us. Is there some workaround or plan
to address this limitation?
Jocke
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-08 10:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291770234.2041.102.camel@concordia>
Thanks again for your detailed answer,
I'm learning, but not as fast as my colleagues with a deadline want me to !
> The platform code does that. That function create devices on the
> platform bus by examining the device tree. It looks for nodes that are
> compatible with the compatible strings you give it, and treats them as
> busses, ie. creates devices for all child nodes of those nodes.
Is there a way to enable some debug output from it, to see what's going on ?
> > ...hmm I had to "git pull" in order for this to compile your snippet.
> > That's really recent! Unfortunately i need to reflash my device with the
> > new kernel before i can begin testing my module.
>
> It shouldn't be that recent, what kernel version were you using?
I had to go from 2.6.34 to 2.6.35, xilinx git tree.
> Yes sorry, that's a cut & paste bug, between the old and new style code.
No worries, I knew it was some uncompiled example.
> platform_device_register() creates a device on the platform bus. You
> then write a driver for that device, and register it with
> platform_driver_register(), your driver then attaches to the device.
>
> In this case though you don't need to call platform_device_register()
> because the device has already been created, using the device tree (by
> of_platform_bus_probe()).
OK, I'll have to remove it from my sample code below.
> In general on powerpc we don't use platform_device_register() much,
> instead things are described in the device tree and devices are created
> for them.
>
> platform_device_register() tends to be for cases where you can't
> discover or probe a device, but you "know" that it exists.
When you see something in /sys/devices/plb.0/, it means that you don't need
platform_device_register, right ?
> Yes, "make tags", then use vim :)
Great, that works.
OK, here's the relevant part of my code, ripped directly from your sample,
with a few additions and different variable names. Why do you think
xad_driver_probe() is not being called ?
#include <linux/kernel.h>
#include <linux/init.h>
#include <asm/device.h>
#include <linux/platform_device.h>
#include <linux/cdev.h> // char device
#include <linux/fs.h>
#include <linux/of.h>
#include <linux/interrupt.h>
#define DEVNAME "xps-acqui-data"
#define NAME "xad" // This is only used for printk
#define SD "{%s %d} "
#define FL , __func__, __LINE__
static dev_t first;
static unsigned int count = 1;
static int my_major = 241, my_minor = 0;
// You must run "mknod /dev/xad c 241 0" in a shell at least once
struct cdev *my_cdev=NULL;
struct platform_device *pdev=NULL;
typedef struct XadDevice {
struct resource *hw_region;
struct device *dev;
int irq;
} tXadDevice;
tXadDevice Xad;
// There should be something in:
// ll /sys/devices/plb.0/c9800000.xps-acqui-data
static const struct of_device_id xad_device_id[] = {
{ .compatible = "xlnx,xps-acqui-data-3.00.a" }, // Must match
the DTS
{}
};
static irqreturn_t XadIsr(int irq, void *dev_id) {
printk(KERN_INFO SD "IRQ:%d\n" FL, irq);
return IRQ_HANDLED;
}
///////////////////////////////////////////////////////////////////////////////
// Platform Bus Support
///////////////////////////////////////////////////////////////////////////////
static int xad_driver_probe(struct platform_device *device /*,
const struct of_device_id *device_id*/ ) {
struct device_node *dn = device->dev.of_node;
int rc;
pr_devel("Probing %s\n", dn->full_name);
Xad.irq = irq_of_parse_and_map(dn, 0);
rc=request_irq(Xad.irq, XadIsr, IRQF_TRIGGER_RISING | IRQF_DISABLED,
"XadIsr", &Xad);
if (rc) printk(KERN_INFO SD "Failled IRQ request: %d\n" FL, rc);
return 0;
}
static int __devexit xad_driver_remove(struct platform_device *device) {
printk(KERN_INFO SD "Removing...\n" FL);
return 0;
}
static struct platform_driver xad_driver = {
.probe = xad_driver_probe,
.remove = xad_driver_remove,
.driver = {
.owner = THIS_MODULE,
.name = "xad-driver",
.of_match_table = xad_device_id,
},
};
///////////////////////////////////////////////////////////////////////////////
// This section deals with the /dev/xad device
///////////////////////////////////////////////////////////////////////////////
static int xad_open(struct inode *node, struct file *filep) {
printk (KERN_INFO SD "OPENING device: %s\n" FL, NAME);
return 0;
}
static int xad_release(struct inode *node, struct file *filep) {
printk (KERN_INFO SD "RELEASING device: %s\n" FL, NAME);
return 0;
}
static int xad_ioctl(struct inode *node, struct file *filep, unsigned int cmd,
unsigned long arg) {
printk (KERN_INFO SD "IOCTL on device: %s, cmd:%d, arg:%lu\n" FL, NAME, cmd,
arg);
return 0;
}
static struct file_operations fops = {
.owner = THIS_MODULE,
.open = xad_open,
.release = xad_release,
.ioctl = xad_ioctl,
};
///////////////////////////////////////////////////////////////////////////////
// Called on insmod
static int __init xad_init(void) {
int rc=0;
printk(KERN_INFO SD "Module %s: loading...\n" FL, NAME);
// Deal with the device
first = MKDEV (my_major, my_minor);
register_chrdev_region(first, count, DEVNAME);
my_cdev = cdev_alloc ();
if (NULL==my_cdev) goto Err;
cdev_init(my_cdev, &fops);
cdev_add (my_cdev, first, count);
printk(KERN_INFO SD "Module %s: Major=%d, Minor=%d, Count=%d\n" FL, NAME,
my_major, my_minor, count);
// Driver
rc = platform_driver_register(&xad_driver);
// rc = platform_driver_probe(&xad_driver, xad_driver_probe);
if (rc) goto err_plat;
// Device
pdev=platform_device_register_simple("xps-acqui-data", -1, NULL, 0);
if (IS_ERR(pdev)) {
rc = PTR_ERR(pdev);
platform_driver_unregister(&xad_driver);
goto err_plat;
}
return 0;
err_plat:
unregister_chrdev_region(first, count);
Err:
printk(KERN_ERR SD "Module %s: Failed loading rc=%d\n" FL, NAME, rc);
return rc;
}
///////////////////////////////////////////////////////////////////////////////
// Called on rmmod
static void xad_exit(void) {
platform_device_unregister(pdev); pdev=NULL;
platform_driver_unregister(&xad_driver);
cdev_del (my_cdev); my_cdev=NULL;
unregister_chrdev_region (first, count);
printk(KERN_INFO SD "Module %s unloaded\n" FL, NAME);
}
module_init(xad_init);
module_exit(xad_exit);
MODULE_AUTHOR("Guillaume Dargaud");
MODULE_LICENSE("GPL");
And here's the result:
# tail -f /var/log/messages &
# insmod xad.ko
Dec 7 14:42:02 gandalf user.info kernel: [15897.152109] {xad_init 162} Module
xad: loading...
Dec 7 14:42:02 gandalf user.info kernel: [15897.156665] {xad_init 173} Module
xad: Major=241, Minor=0, Count=1
# ./xad_test # A simple prog that opens, does an iocl and closes the device
./xad_test Initialisation
./xad_test Ioctl
./xad_test Closing
Dec 7 14:42:16 gandalf user.info kernel: [15911.160343] {xad_open 130}
OPENING device: xad
Dec 7 14:42:16 gandalf user.info kernel: [15911.164521] {xad_ioctl 142} IOCTL
on device: xad, cmd:0, arg:0
Dec 7 14:42:16 gandalf user.info kernel: [15911.173035] {xad_release 136}
RELEASING device: xad
# rmmod xad
Dec 7 14:42:23 gandalf user.info kernel: [15918.753661] {xad_exit 206} Module
xad unloaded
And in the dts:
/dts-v1/;
/ {
...
plb: plb@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-
bus";
ranges ;
...
xps_acqui_data_0: xps-acqui-data@c9800000 {
compatible = "xlnx,xps-acqui-data-3.00.a";
interrupt-parent = <&xps_intc_0>;
interrupts = < 0 2 >;
reg = < 0xc9800000 0x10000 >;
xlnx,family = "virtex4";
xlnx,include-dphase-timer = <0x1>;
xlnx,mplb-awidth = <0x20>;
xlnx,mplb-clk-period-ps = <0x2710>;
xlnx,mplb-dwidth = <0x40>;
xlnx,mplb-native-dwidth = <0x40>;
xlnx,mplb-p2p = <0x0>;
xlnx,mplb-smallest-slave = <0x20>;
} ;
...
} ;
...
} ;
# ll /sys/devices/plb.0/c9800000.xps-acqui-data/
-r--r--r-- 1 root root 4.0K Dec 7 12:55 devspec
-r--r--r-- 1 root root 4.0K Dec 7 12:55 modalias
-r--r--r-- 1 root root 4.0K Dec 7 12:55 name
lrwxrwxrwx 1 root root 0 Dec 7 12:55 subsystem ->
../../../bus/of_platform/
-rw-r--r-- 1 root root 4.0K Dec 7 12:55 uevent
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* [PATCH] powerpc: Fix incorrect comment about interrupt stack allocation
From: Anton Blanchard @ 2010-12-08 10:55 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
We now allow interrupt stacks anywhere in the first segment which can be
256M or 1TB. Fix the comment.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/setup_64.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/setup_64.c 2010-08-19 09:05:17.090741942 +1000
+++ powerpc.git/arch/powerpc/kernel/setup_64.c 2010-08-19 09:06:08.151991499 +1000
@@ -428,8 +428,8 @@ static void __init irqstack_early_init(v
unsigned int i;
/*
- * interrupt stacks must be under 256MB, we cannot afford to take
- * SLB misses on them.
+ * Interrupt stacks must be in the first segment since we
+ * cannot afford to take SLB misses on them.
*/
for_each_possible_cpu(i) {
softirq_ctx[i] = (struct thread_info *)
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-08 13:45 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012081118.13977.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 7255 bytes --]
On Wed, 2010-12-08 at 11:18 +0100, Guillaume Dargaud wrote:
> Thanks again for your detailed answer,
> I'm learning, but not as fast as my colleagues with a deadline want me to !
:)
> > The platform code does that. That function create devices on the
> > platform bus by examining the device tree. It looks for nodes that are
> > compatible with the compatible strings you give it, and treats them as
> > busses, ie. creates devices for all child nodes of those nodes.
>
> Is there a way to enable some debug output from it, to see what's going on ?
Not really, but there probably should be.
> > > ...hmm I had to "git pull" in order for this to compile your snippet.
> > > That's really recent! Unfortunately i need to reflash my device with the
> > > new kernel before i can begin testing my module.
> >
> > It shouldn't be that recent, what kernel version were you using?
>
> I had to go from 2.6.34 to 2.6.35, xilinx git tree.
Ah that is the problem I think.
Sorry I assumed you were working on mainline. In 2.6.35 you still need
to use an of_platform_driver, I'll describe below.
> > platform_device_register() tends to be for cases where you can't
> > discover or probe a device, but you "know" that it exists.
>
> When you see something in /sys/devices/plb.0/, it means that you don't need
> platform_device_register, right ?
That's right.
> > Yes, "make tags", then use vim :)
>
> Great, that works.
Cool.
> OK, here's the relevant part of my code, ripped directly from your sample,
> with a few additions and different variable names. Why do you think
> xad_driver_probe() is not being called ?
As I said above in 2.6.35 platform drivers and of_platform drivers were
still separate. So your device is on the of_platform_bus (ie. was
discovered using the device tree), but your driver is on the
platform_bus. Yes this is very confusing.
So basically you need to change all occurrences of platform_driver to
of_platform_driver.
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <asm/device.h>
> #include <linux/platform_device.h>
> #include <linux/cdev.h> // char device
> #include <linux/fs.h>
> #include <linux/of.h>
> #include <linux/interrupt.h>
>
> #define DEVNAME "xps-acqui-data"
> #define NAME "xad" // This is only used for printk
>
> #define SD "{%s %d} "
> #define FL , __func__, __LINE__
>
> static dev_t first;
> static unsigned int count = 1;
> static int my_major = 241, my_minor = 0;
> // You must run "mknod /dev/xad c 241 0" in a shell at least once
>
> struct cdev *my_cdev=NULL;
> struct platform_device *pdev=NULL;
>
> typedef struct XadDevice {
> struct resource *hw_region;
> struct device *dev;
> int irq;
> } tXadDevice;
> tXadDevice Xad;
>
> // There should be something in:
> // ll /sys/devices/plb.0/c9800000.xps-acqui-data
> static const struct of_device_id xad_device_id[] = {
> { .compatible = "xlnx,xps-acqui-data-3.00.a" }, // Must match
> the DTS
> {}
> };
>
>
> static irqreturn_t XadIsr(int irq, void *dev_id) {
> printk(KERN_INFO SD "IRQ:%d\n" FL, irq);
> return IRQ_HANDLED;
> }
>
> ///////////////////////////////////////////////////////////////////////////////
> // Platform Bus Support
> ///////////////////////////////////////////////////////////////////////////////
>
> static int xad_driver_probe(struct platform_device *device /*,
> const struct of_device_id *device_id*/ ) {
So you need to switch the prototype here to:
static int xad_driver_probe(struct of_platform_device *ofdev,
const struct of_device_id *device_id) {
> struct device_node *dn = device->dev.of_node;
> int rc;
>
> pr_devel("Probing %s\n", dn->full_name);
>
> Xad.irq = irq_of_parse_and_map(dn, 0);
> rc=request_irq(Xad.irq, XadIsr, IRQF_TRIGGER_RISING | IRQF_DISABLED,
> "XadIsr", &Xad);
> if (rc) printk(KERN_INFO SD "Failled IRQ request: %d\n" FL, rc);
>
> return 0;
> }
>
> static int __devexit xad_driver_remove(struct platform_device *device) {
> printk(KERN_INFO SD "Removing...\n" FL);
> return 0;
> }
>
> static struct platform_driver xad_driver = {
Becomes of_platform_driver
> .probe = xad_driver_probe,
> .remove = xad_driver_remove,
> .driver = {
> .owner = THIS_MODULE,
> .name = "xad-driver",
> .of_match_table = xad_device_id,
> },
> };
>
>
> ///////////////////////////////////////////////////////////////////////////////
> // This section deals with the /dev/xad device
> ///////////////////////////////////////////////////////////////////////////////
> static int xad_open(struct inode *node, struct file *filep) {
> printk (KERN_INFO SD "OPENING device: %s\n" FL, NAME);
> return 0;
> }
>
> static int xad_release(struct inode *node, struct file *filep) {
> printk (KERN_INFO SD "RELEASING device: %s\n" FL, NAME);
> return 0;
> }
>
> static int xad_ioctl(struct inode *node, struct file *filep, unsigned int cmd,
> unsigned long arg) {
> printk (KERN_INFO SD "IOCTL on device: %s, cmd:%d, arg:%lu\n" FL, NAME, cmd,
> arg);
> return 0;
> }
>
> static struct file_operations fops = {
> .owner = THIS_MODULE,
> .open = xad_open,
> .release = xad_release,
> .ioctl = xad_ioctl,
> };
>
>
> ///////////////////////////////////////////////////////////////////////////////
> // Called on insmod
> static int __init xad_init(void) {
> int rc=0;
> printk(KERN_INFO SD "Module %s: loading...\n" FL, NAME);
>
> // Deal with the device
> first = MKDEV (my_major, my_minor);
> register_chrdev_region(first, count, DEVNAME);
> my_cdev = cdev_alloc ();
> if (NULL==my_cdev) goto Err;
>
> cdev_init(my_cdev, &fops);
> cdev_add (my_cdev, first, count);
>
> printk(KERN_INFO SD "Module %s: Major=%d, Minor=%d, Count=%d\n" FL, NAME,
> my_major, my_minor, count);
>
> // Driver
> rc = platform_driver_register(&xad_driver);
Should be of_register_platform_driver()
> // rc = platform_driver_probe(&xad_driver, xad_driver_probe);
> if (rc) goto err_plat;
>
> // Device
> pdev=platform_device_register_simple("xps-acqui-data", -1, NULL, 0);
> if (IS_ERR(pdev)) {
> rc = PTR_ERR(pdev);
> platform_driver_unregister(&xad_driver);
> goto err_plat;
> }
>
>
> return 0;
>
> err_plat:
> unregister_chrdev_region(first, count);
> Err:
> printk(KERN_ERR SD "Module %s: Failed loading rc=%d\n" FL, NAME, rc);
> return rc;
> }
>
> ///////////////////////////////////////////////////////////////////////////////
> // Called on rmmod
> static void xad_exit(void) {
> platform_device_unregister(pdev); pdev=NULL;
> platform_driver_unregister(&xad_driver);
>
> cdev_del (my_cdev); my_cdev=NULL;
> unregister_chrdev_region (first, count);
> printk(KERN_INFO SD "Module %s unloaded\n" FL, NAME);
> }
>
> module_init(xad_init);
> module_exit(xad_exit);
>
> MODULE_AUTHOR("Guillaume Dargaud");
> MODULE_LICENSE("GPL");
>
>
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 0/4] V3 Add ability to link device blob(s) into vmlinux
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch set adds the ability to link device tree blobs into
vmlinux.
Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
adds a generic rule for generating DTB objects to be linked vmlinux.
Patch 2 implements linking a DTB into an x86 image.
Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
in patch 1.
This patch set has been tested on x86.
Powerpc and Microblaze have been compile tested with and without patch
3 and 4 applied.
Changes from V1:
Documentation added for dtc command in Makefile.lib to
Documentation/kbuild/makefiles.txt
Separate DTB_ALIGNMENT define removed.
FORCE removed from dtc rule.
Removed hardcoded path to dts files from dtc command.
Moved %.dtb: %.dts rule to arch specific makefiles.
Patch for adding kernel command line option to pass in dtb_compat
string dropped from this set will be submitted seperately.
Changes from V2:
Rule to create assembly wrapper for blob changed to use Sam Ravnborgs
suggested implementation.
Rules in architecture specific Makefiles changed to use the cmd
function instead of the if_changed function.
Dirk Brandewie (4):
of: Add support for linking device tree blobs into vmlinux
x86/of: Add building device tree blob(s) into image.
of/powerpc: Use generic rule to build dtb's
microblaze/of: Use generic rule to build dtb's
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
arch/microblaze/boot/Makefile | 12 +++---------
arch/powerpc/boot/Makefile | 8 +++-----
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
6 files changed, 65 insertions(+), 16 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0ef00bd..86e3cd0 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
resulting in the target file being recompiled for no
obvious reason.
+ dtc
+ Create flattend device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ Example:
+ #arch/x86/platform/ce4100/Makefile
+ clean-files := *dtb.S
+
+ DTC_FLAGS := -p 1024
+ obj-y += foo.dtb.o
+
+ $(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
--- 6.7 Custom kbuild commands
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bd69d79..05cbad0 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -67,7 +67,8 @@
* Align to a 32 byte boundary equal to the
* alignment gcc 4.5 uses for a struct
*/
-#define STRUCT_ALIGN() . = ALIGN(32)
+#define STRUCT_ALIGNMENT 32
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
/* The actual configuration determine if the init/exit sections
* are handled as text/data or they can be discarded (which
@@ -146,6 +147,13 @@
#define TRACE_SYSCALLS()
#endif
+
+#define KERNEL_DTB() \
+ STRUCT_ALIGN(); \
+ VMLINUX_SYMBOL(__dtb_start) = .; \
+ *(.dtb.init.rodata) \
+ VMLINUX_SYMBOL(__dtb_end) = .;
+
/* .data section */
#define DATA_DATA \
*(.data) \
@@ -468,7 +476,8 @@
MCOUNT_REC() \
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
- MEM_DISCARD(init.rodata)
+ MEM_DISCARD(init.rodata) \
+ KERNEL_DTB()
#define INIT_TEXT \
*(.init.text) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4c72c11..63b287c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP $@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
(rm -f $@ ; false)
+# DTC
+# ---------------------------------------------------------------------------
+
+# Generate an assembly file to wrap the output of the device tree compiler
+quiet_cmd_dt_S_dtb= DTB $@
+cmd_dt_S_dtb= \
+( \
+ echo '\#include <asm-generic/vmlinux.lds.h>'; \
+ echo '.section .dtb.init.rodata,"a"'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+ echo '.global __dtb_$(*F)_begin'; \
+ echo '__dtb_$(*F)_begin:'; \
+ echo '.incbin "$<" '; \
+ echo '__dtb_$(*F)_end:'; \
+ echo '.global __dtb_$(*F)_end'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+) > $@
+
+$(obj)/%.dtb.S: $(obj)/%.dtb
+ $(call cmd,dt_S_dtb)
+
+quiet_cmd_dtc = DTC $@
+ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
# Bzip2
# ---------------------------------------------------------------------------
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds linking device tree blob into vmlinux. DTB's are
added by adding the blob object name to list of objects to be linked
into the image.
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
index 91fc929..e5f3b7b 100644
--- a/arch/x86/platform/ce4100/Makefile
+++ b/arch/x86/platform/ce4100/Makefile
@@ -1 +1,11 @@
obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
+clean-files := *dtb.S
+
+ifdef CONFIG_X86_OF
+###
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
+
+$(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/powerpc/boot/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..96deec6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,7 +35,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-DTS_FLAGS ?= -p 1024
+DTC_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
@@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
-
-$(obj)/%.dtb: $(dtstree)/%.dts
- $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
+$(obj)/%.dtb: $(src)/dts/%.dts
+ $(call cmd,dtc)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/microblaze/boot/Makefile | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index be01d78..4c4e58e 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.%
OBJCOPYFLAGS := -O binary
-# Where the DTS files live
-dtstree := $(srctree)/$(src)/dts
-
# Ensure system.dtb exists
$(obj)/linked_dtb.o: $(obj)/system.dtb
@@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE
$(call if_changed,strip)
@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
-# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
# Rule to build device tree blobs
-quiet_cmd_dtc = DTC $@
- cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
+DTC_FLAGS := -p 1024
-$(obj)/%.dtb: $(dtstree)/%.dts FORCE
- $(call if_changed,dtc)
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
+ $(call cmd,dtc)
clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v2] powerpc, 5200: add support for charon board
From: Wolfram Sang @ 2010-12-08 15:49 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <1291705135-26805-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Tue, Dec 07, 2010 at 07:58:55AM +0100, Heiko Schocher wrote:
> Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-08 15:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291815910.12093.15.camel@concordia>
> Sorry I assumed you were working on mainline. In 2.6.35 you still need
> to use an of_platform_driver, I'll describe below.
> So basically you need to change all occurrences of platform_driver to
> of_platform_driver.
OK, thanks, I did that, compiled and ran the driver and its test prog... no
changes: xad_driver_probe() doesn't get called.
...?
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-08 17:18 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <OFF94B1B01.88594E81-ONC12577F3.002B63AA-C12577F3.002BEE0B@transmode.se>
On Wed, 8 Dec 2010 08:59:49 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > On Mon, 6 Dec 2010 22:15:54 -0500
> > Mark Mason <mason@postdiluvian.org> wrote:
> >
> > > A few months ago I ran into some performance problems involving
> > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > found a solution for this, which worked well, at least with the
> > > hardware I was working with. I suspect the same problem affects other
> > > PPCs, probably including multicore devices, and maybe other
> > > architectures as well.
> > >
> > > I don't have experience with similar NAND controllers on other
> > > devices, so I'd like to explain what I found and see if someone who's
> > > more familiar with the family and/or driver can tell if this is
> > > useful.
> > >
> > > The problem cropped up when there was a lot of traffic to the NAND
> > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > a video chip that needed constant and prompt attention.
> >
> > If you attach NAND to the LBC, you should not attach anything else to
> > it which is latency-sensitive.
>
> This "feature" makes the LBC useless to us. Is there some workaround or plan
> to address this limitation?
Complain to your support or sales contact.
I've complained about it in the past, and got a "but pins are a limited
resource!" response. They need to hear that it's a problem from
customers.
-Scott
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 17:32 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208111839.1cf95553@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
>
> On Wed, 8 Dec 2010 08:59:49 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > >
> > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > Mark Mason <mason@postdiluvian.org> wrote:
> > >
> > > > A few months ago I ran into some performance problems involving
> > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > found a solution for this, which worked well, at least with the
> > > > hardware I was working with. I suspect the same problem affects other
> > > > PPCs, probably including multicore devices, and maybe other
> > > > architectures as well.
> > > >
> > > > I don't have experience with similar NAND controllers on other
> > > > devices, so I'd like to explain what I found and see if someone who's
> > > > more familiar with the family and/or driver can tell if this is
> > > > useful.
> > > >
> > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > a video chip that needed constant and prompt attention.
> > >
> > > If you attach NAND to the LBC, you should not attach anything else to
> > > it which is latency-sensitive.
> >
> > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > to address this limitation?
>
> Complain to your support or sales contact.
>
> I've complained about it in the past, and got a "but pins are a limited
> resource!" response. They need to hear that it's a problem from
> customers.
Done, lets see what I get in return. I think this problem will be
a major obstacle for our next generation boards which will be NAND
based.
Jocke
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Mark Mason @ 2010-12-08 19:26 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF349DC945.8BC48D34-ONC12577F3.00601D94-C12577F3.00605153@transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> >
> > On Wed, 8 Dec 2010 08:59:49 +0100
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > >
> > > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > > Mark Mason <mason@postdiluvian.org> wrote:
> > > >
> > > > > A few months ago I ran into some performance problems involving
> > > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > > found a solution for this, which worked well, at least with the
> > > > > hardware I was working with. I suspect the same problem affects other
> > > > > PPCs, probably including multicore devices, and maybe other
> > > > > architectures as well.
> > > > >
> > > > > I don't have experience with similar NAND controllers on other
> > > > > devices, so I'd like to explain what I found and see if someone who's
> > > > > more familiar with the family and/or driver can tell if this is
> > > > > useful.
> > > > >
> > > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > > a video chip that needed constant and prompt attention.
> > > >
> > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > it which is latency-sensitive.
> > >
> > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > to address this limitation?
> >
> > Complain to your support or sales contact.
> >
> > I've complained about it in the past, and got a "but pins are a limited
> > resource!" response. They need to hear that it's a problem from
> > customers.
>
> Done, lets see what I get in return. I think this problem will be
> a major obstacle for our next generation boards which will be NAND
> based.
It was a big problem, and a big surprise, for me too. The next
generation of a couple of the chips on the bus have pcie, but those
are noticably more expensive.
Another problem I ran into was that the DMA performance from a
non-incrementing address was abysmal, PIO turned out to be
significantly faster. I guess internally the bus does an entire
cacheline transfer for every word read from a fixed address, or
something like that. I was doing DMA from a device that had only six
address bits, it should have been in the middle of the bus with the
bottom address pins not connected, which would have allowed
incrementing address DMA. The transfer speed wasn't so much of a
problem, but the longer transfers meant that there was that much less
bus bandwidth for the other devices, so we wound up sacrificing CPU to
get more bus bandwidth.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox