> Am 28.05.09 18:13 schrieb(en) Joakim Tjernlund:
> > hmm, these do look a bit unoptimal anyway. Any reason not to write
> > them something like below(written by me for uClibc long time ago).
> > You will have to add eieio()/sync
>
> No (and I wasn't aware of the PPC pre-inc vs. post-inc stuff) - I
There's no need to wrap PPC_INST_NOP in a static inline.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/ftrace.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 8620ecb..f4ad248 100644
---
These macros were used in the original port, but since commit
e4486fe316 (ftrace, use probe_kernel API to modify code) they
are unused.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/ftrace.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/ke
Use ppc_function_entry() from code-patching.h.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/ftrace.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 70e2a73..8585217 100644
--- a/arch
On Wed, 2009-04-01 at 14:59 -0700, Roland McGrath wrote:
> Maynard asked about user_enable_block_step() support on powerpc.
> This is the old patch I've posted before. I haven't even tried
> to compile it lately, but it rebased cleanly.
>
> AFAIK the only reason this didn't go in several months a
On Mon, May 25, 2009 at 06:46:50AM +0530, K.Prasad wrote:
> Modify process handling code to recognise hardware debug registers during copy
> and flush operations. Introduce a new TIF_DEBUG task flag to indicate a
> process's use of debug register. Load the debug register values into a
> new CPU dur
On Mon, May 25, 2009 at 06:45:22AM +0530, K.Prasad wrote:
> Introduce PPC64 implementation for the generic hardware breakpoint interfaces
> defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
> Makefile.
[snip]
> +/* Store the kernel-space breakpoint address value */
> +s
Thank you for your response. My responses below.
On Thu, May 28, 2009 at 1:02 PM, Scott Wood wrote:
> On Thu, May 28, 2009 at 12:05:52PM -0700, Nancy Isaac wrote:
> > My device tree has the following entry for my fpga:
> >
> > cpucp...@f000{
> > compatible = "MPC8544
On Mon, May 25, 2009 at 06:44:23AM +0530, K.Prasad wrote:
> Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
> relevant constant definitions and function declarations.
>
> Signed-off-by: K.Prasad
> ---
> arch/powerpc/include/asm/hw_breakpoint.h | 57
> +++
Im facing some problems with serial, getting flooded with this
message:
---
serial8250: too much work for irq16
---
Something I notice, in my .dts I have the following lines:
serial0: ser...@4500, interrupts = <9 0x8>
serial1: ser...@4600, interrupts = <10 0x8>
spi: s...@7000, interr
On Thu, May 28, 2009 at 10:33 PM, Wolfram Sang wrote:
>> this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel
>> driver
>> registers for the PIT IRQ (Interrupt ID 65)
>>
>> #define PIT_IRQ 65
>>
>> virq = irq_create_mapping(NULL, PIT_IRQ);
>> set_irq_type(virq, IRQ
Peter Korsgaard wrote:
"Esben" == Esben Haabendal writes:
Hi,
Esben> It's strange, that line looks perfectly fine when I check the
Esben> mail in my GMail inbox and the outbox from the account I sent
Esben> it from.
Well, it is here and in the archive:
http://ozlabs.org/piper
> "Esben" == Esben Haabendal writes:
Hi,
Esben> It's strange, that line looks perfectly fine when I check the
Esben> mail in my GMail inbox and the outbox from the account I sent
Esben> it from.
Well, it is here and in the archive:
http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072274
> Esben> I've checked both my copy in my "Sent" folder and the copy
> Esben> received from the list, and I cannot see any "line break"
> Esben> breakage of the patch.
>
> I guess Wolfram referred to the context line which was clearly word wrapped:
>
> @@ -456,17 +456,22 @@ static int mpc_xfer(st
> "Esben" == Esben Haabendal writes:
Hi,
>> I wanted to test it, but it does not apply due to line breaks (check
>> @@-line). Also, I don't really have the time to dig into the topic, so I
>> would only test it and give a tested-by-tag if it doesn't break anything
>> here. I think Joakim
On Thu, May 28, 2009 at 9:31 PM, Grant Likely wrote:
> On Tue, May 26, 2009 at 5:30 AM, Esben Haabendal wrote:
>> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal wrote:
>>> This fixes MAL (arbitration lost) bug caused by illegal use of
>>> RSTA (repeated START) after STOP condition generated afte
On Thu, May 28, 2009 at 7:17 PM, Wolfram Sang wrote:
>> > Any blockers to get this accepted?
>>
>> It would be nice to get an ack from someone who can actually test
>> the driver before getting this merged.
>
> I wanted to test it, but it does not apply due to line breaks (check
> @@-line). Also,
On Thu, May 28, 2009 at 12:05:52PM -0700, Nancy Isaac wrote:
> My device tree has the following entry for my fpga:
>
> cpucp...@f000{
> compatible = "MPC8544DS";
> device_type = "CpuCpld";
> reg = ;
>
Am 28.05.09 18:13 schrieb(en) Joakim Tjernlund:
hmm, these do look a bit unoptimal anyway. Any reason not to write
them something like below(written by me for uClibc long time ago).
You will have to add eieio()/sync
No (and I wasn't aware of the PPC pre-inc vs. post-inc stuff) - I just
stu
On Tue, May 26, 2009 at 5:30 AM, Esben Haabendal
wrote:
> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal
> wrote:
>> This fixes MAL (arbitration lost) bug caused by illegal use of
>> RSTA (repeated START) after STOP condition generated after last byte
>> of reads. With this patch, it is possib
The 83xx controller does not support the external pause feature. The bit
in the mode register that controls external pause on the 85xx controller
happens to be part of the bandwidth control settings for the 83xx
controller.
This patch fixes the driver so that it only clears the external pause bit
The 83xx controller has external start capability, but lacks external pause
capability. Hook up the external start function pointer for the 83xx
controller.
Signed-off-by: Ira W. Snyder
---
Though there is no way to enable external start in the mainline driver,
the DMA_SLAVE patch I posted last
Hi,
I have a custom board that's using powerpc 8544. I am trying to setup the
external interrupts using the device tree and I am having no luck getting
the interrupt. I think my problem is that I don't have the hwirq to virq
mapping correctly. We are using the freescale 8544ds as our base. We ha
On Thu, May 28, 2009 at 10:00 AM, Peter Korsgaard wrote:
>> "Jon" == Jon Smirl writes:
>
> Hi,
>
> Jon> Fabric bindings for STAC9766 AC97 codec on the Efika.
> Jon> Signed-off-by: Jon Smirl
> Jon> ---
> Jon> sound/soc/fsl/Kconfig | 8 +++
> Jon> sound/soc/fsl/Makefile
Kumar,
To follow up on our postings from late last week...
(which I was expecting a response (but never got) from you)...
-
We (well, mostly a very bright engineer who was very persistent)
have(has) found the origin of how the kernel TLB got corrupted.
We tracked down the problem to a prog
Wolfram Sang wrote on 28/05/2009 19:17:26:
>
> > > Any blockers to get this accepted?
> >
> > It would be nice to get an ack from someone who can actually test
> > the driver before getting this merged.
>
> I wanted to test it, but it does not apply due to line breaks (check
> @@-line). Also, I do
> > Any blockers to get this accepted?
>
> It would be nice to get an ack from someone who can actually test
> the driver before getting this merged.
I wanted to test it, but it does not apply due to line breaks (check
@@-line). Also, I don't really have the time to dig into the topic, so I
would
>
> This trivial patch changes memcpy_(to|from)io as to transfer as many
> 32-bit words as possible in 32-bit accesses (in the current solution,
> the last 32-bit word was transferred as 4 byte accesses).
>
> Signed-off-by: Albrecht Dreß
> ---
>
> diff -urpN -X linux-2.6.29.1.orig/Documentation/d
> "Jon" == Jon Smirl writes:
Hi,
Jon> Fabric bindings for STAC9766 AC97 codec on the Efika.
Jon> Signed-off-by: Jon Smirl
Jon> ---
Jon> sound/soc/fsl/Kconfig |8 +++
Jon> sound/soc/fsl/Makefile |1
Jon> sound/soc/fsl/efika-audio-fabric.c | 95
---
arch/powerpc/include/asm/qe.h |2 +
drivers/net/ucc_geth.c| 79 -
drivers/net/ucc_geth.h| 28 ++-
3 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/as
Disable fiber/copper auto selection for Marvell m88e SGMII support.
Signed-off-by: Haiying Wang
---
drivers/net/phy/marvell.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 7a3ec9d..dd6f54d 100644
--- a/dri
Signed-off-by: Haiying Wang
---
arch/powerpc/boot/dts/mpc8569mds.dts | 63 ++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts
b/arch/powerpc/boot/dts/mpc8569mds.dts
index 39c2927..4e95abd 100644
--- a/arch/pow
Current code makes the UCC whose register range includes the current mdio
register to be the MII managemnt interface master of the QE. If there is more
than one mdio bus for QE, the UCC of the last mdio bus will be the MII
management interface master which will make the primary mdio bus working
unp
On May 28, 2009, at 1:11 AM, Benjamin Herrenschmidt wrote:
On Wed, 2009-05-27 at 23:42 -0500, Kumar Gala wrote:
Ben,
Any comments on this.. need a decision so we can have patches ready
for .31.
Clamping the DMA mask is even worse than the additional indirection
for us. We have valid scena
> this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel
> driver
> registers for the PIT IRQ (Interrupt ID 65)
>
> #define PIT_IRQ 65
>
> virq = irq_create_mapping(NULL, PIT_IRQ);
> set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
>
> if(request_irq(virq, (irq_handler_t)t
Hi Daniel,
"Ethos" driver... hmm. sounds familiar!
(good to hear that it is still used in active development)
About your question.
Since almost 2 years (kernel 2.6.22 from july 2007) the rule is that you can't
directly map a hardware irq number because the powerpc kernel keeps a
mapping between
Hi,
I'm attempting to port our Ethos HDLC driver from 2.6.14 to 2.6.27, on
a MPC8272-based platform.
So far, the kernel crashes when the driver tries to open (see below).
It seems that the interrupt handler fails to register, with the
following condition in setup_irq() in manage.c:
desc->chip =
37 matches
Mail list logo
