Re: PowerMac G4 (Digital Audio)
2010/12/5, Johannes Berg : > >> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p15.diff >> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16.diff > > These patches are odd -- the first one adds something the second > removes? Am I supposed to look at the combination? > Not really, the second one adds gpio16 but still keeps gpio15. > > But frankly, it's been so long that it's not all making perfect sense to > me right now. If you send me a tarball of /proc/device-tree/ maybe I can > take a look -- just looked at my collection and I don't have that one. > > johannes > A device tree dump is located at http://manulix.wikidot.com/hidden:device-tree-my_G4 The tarball can be wget-ted from http://manulix.wikidot.com/local--files/hidden:device-tree-my-g4/device-tree.tar.bz2 Risto ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: MPC831x (and others?) NAND erase performance improvements
> 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. > > What I would see is that, as the writes happened, the erases would > wind up batched and issued all at once, such that frequently 400-700 > erases were issued in rapid succession with a 1ms LBC BUSY cycle per > erase. Are those just the reads of the status register polling to determine when the sector erase has completed ? In which case a software delay beteen the reads might work. Writes probably also have to be polled, but the individual writes happen faster. It is possible that an uncached read of another memory area will stall the cpu long enough to allow another LBC master in. One every few writes might be enough. I had to do something similar on rather different hardware ... David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac G4 (Digital Audio)
On Tue, 2010-12-07 at 10:51 +0200, Risto Suominen wrote: > 2010/12/5, Johannes Berg : > > > >> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p15.diff > >> http://ristosu.wippiespace.com/pub/alsa-tumbler-1.0.22.1-p16.diff > > > > These patches are odd -- the first one adds something the second > > removes? Am I supposed to look at the combination? > > > Not really, the second one adds gpio16 but still keeps gpio15. Oh, so the change to "gpio1" was intended to be some wildcard? > > But frankly, it's been so long that it's not all making perfect sense to > > me right now. If you send me a tarball of /proc/device-tree/ maybe I can > > take a look -- just looked at my collection and I don't have that one. > A device tree dump Hmm ok, it's not really making a lot of sense to me now either. Can you hack the file I previously pointed out and see if that helps? johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac G4 (Digital Audio)
2010/12/7, Johannes Berg : > > Oh, so the change to "gpio1" was intended to be some wildcard? > Yes. I know, not very pretty. > > Can you hack the file I previously pointed out and see if that helps? > Well, I could try. Actually, I don't own a machine to test with. So, as far as I can see, you don't have any special handling for this machine, or any other either? And you don't look for these gpio15 (hp) and gpio16 (lo). They are the detect inputs, not mute outputs. So can they cause such problems that no sound is played? Hmm... One solution could be to just remove the support from snd-aoa and continue using snd-powermac. Now it's difficult because of the auto-loading. Risto ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac G4 (Digital Audio)
On Tue, 2010-12-07 at 13:27 +0200, Risto Suominen wrote: > > Can you hack the file I previously pointed out and see if that helps? > > > Well, I could try. Actually, I don't own a machine to test with. Oh, ok... I thought you did. > So, as far as I can see, you don't have any special handling for this > machine, or any other either? And you don't look for these gpio15 (hp) > and gpio16 (lo). They are the detect inputs, not mute outputs. So can > they cause such problems that no sound is played? Hmm... Right, normally we don't need any special handling since the DT has the right names ... this machine just needs an override for the GPIO names (gpio15/16 rather than the proper detect names). > One solution could be to just remove the support from snd-aoa and > continue using snd-powermac. Now it's difficult because of the > auto-loading. Yeah, not really ... I wrote aoa, so I guess I'm biased, but really snd-powermac is quite a mess. johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac G4 (Digital Audio)
2010/12/7, Johannes Berg : > > Right, normally we don't need any special handling since the DT has the > right names ... this machine just needs an override for the GPIO names > (gpio15/16 rather than the proper detect names). > And setting the active-state manually to 1. Risto ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac G4 (Digital Audio)
On Tue, 2010-12-07 at 13:41 +0200, Risto Suominen wrote: > 2010/12/7, Johannes Berg : > > > > Right, normally we don't need any special handling since the DT has the > > right names ... this machine just needs an override for the GPIO names > > (gpio15/16 rather than the proper detect names). > > > And setting the active-state manually to 1. Yes, I guess, it doesn't look like they have the typical property in the DT for these. johannes ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Getting the IRQ number (Was: Basic driver devel questions ?)
Michael, in your example, when is foo_driver_probe() actually called ? It's not being called when I do an insmod. -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Run 'usermode-agent' cause kernel panic on Powerpc
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
>
> 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/f300.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 CR: 44000624 XER:
> TASK = efc1de00[752] 'usermode-agent' THREAD: ef63e000
> GPR00: cc00cc00 ef63fe60 efc1de00 efc1de00 efc1f700 c04c8000 00258560
>
> GPR08: ffda8a00 4000 1fda c050 49eaebbd 1008b654 3ff8a900
>
> GPR16: eed84c40 c03b4570 c04ee4d0 c04ca870 ef63e03c
>
> GPR24: c04f7ee8 c04ee4c0 0004 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
--
Dave Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC831x (and others?) NAND erase performance improvements
David Laight wrote: > > 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. > > > > What I would see is that, as the writes happened, the erases would > > wind up batched and issued all at once, such that frequently 400-700 > > erases were issued in rapid succession with a 1ms LBC BUSY cycle per > > erase. > > Are those just the reads of the status register polling to > determine when the sector erase has completed ? No, it's not, since it isn't polling the status register. It's using a hardware line from the NAND to indicate that the NAND is busy. That one hardware line is shared between all devices on the bus, so if one device says it's busy then all bus traffic stops until the NAND deasserts the busy line. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC831x (and others?) NAND erase performance improvements
On Mon, 6 Dec 2010 22:15:54 -0500 Mark Mason 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC831x (and others?) NAND erase performance improvements
Scott Wood wrote: > On Mon, 6 Dec 2010 22:15:54 -0500 > Mark Mason 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 FI
[PATCH] powerpc: iommu: Add device name to iommu error printks
Right now its difficult to see which device is running out of iommu space:
iommu_alloc failed, tbl c0076e096660 vaddr c00768806600 npages 1
Use dev_info() so we get the device name and location:
ipr :00:01.0: iommu_alloc failed, tbl c0076e096660 vaddr
c00768806600 npages 1
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/kernel/iommu.c
===
--- powerpc.git.orig/arch/powerpc/kernel/iommu.c2010-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;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Getting the IRQ number (Was: Basic driver devel questions ?)
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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC831x (and others?) NAND erase performance improvements
On Tue, 7 Dec 2010 18:24:45 -0500 Mark Mason wrote: > Scott Wood wrote: > > > On Mon, 6 Dec 2010 22:15:54 -0500 > > Mark Mason 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Getting the IRQ number (Was: Basic driver devel questions ?)
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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Run 'usermode-agent' cause kernel panic on Powerpc
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
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/f300.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 CR: 44000624 XER:
TASK = efc1de00[752] 'usermode-agent' THREAD: ef63e000
GPR00: cc00cc00 ef63fe60 efc1de00 efc1de00 efc1f700 c04c8000 00258560
GPR08: ffda8a00 4000 1fda c050 49eaebbd 1008b654 3ff8a900
GPR16: eed84c40 c03b4570 c04ee4d0 c04ca870 ef63e03c
GPR24: c04f7ee8 c04ee4c0 0004 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
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 "x[-][@]" > 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 > cc: linux-fb...@vger.kernel.org > cc: devicetree-disc...@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? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Hardcode popcnt instructions for old assemblers
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 --- 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 0x6000 #define PPC_INST_POPCNTB 0x7cf4 #define PPC_INST_POPCNTB_MASK 0xfc0007fe +#define PPC_INST_POPCNTD 0x7c0003f4 +#define PPC_INST_POPCNTW 0x7c0002f4 #define PPC_INST_RFCI 0x4c66 #define PPC_INST_RFDI 0x4c4e #define PPC_INST_RFMCI 0x4c4c @@ -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) srdir4,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) srdir4,r3,16 add r3,r4,r3 srdir4,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) srdir4,r3,32 add r3,r4,r3 srdir4,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) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Hardcode popcnt instructions for old assemblers
Hi Anton, On Wed, 8 Dec 2010 16:58:17 +1100 Anton Blanchard 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 That certainly fixes the build issue for me (tested ppc64_defconfig with binutils 2.19.1). -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpdNfsKMhZqz.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
