On Thu, Jan 08, 2009 at 11:53:10PM -0600, Matt Sealey wrote:
> Lennert Buytenhek wrote:
>> On Thu, Jan 08, 2009 at 11:38:33PM -0600, Matt Sealey wrote:
>>
>> On this topic, I sent a patch to linuxppc-dev@ some time ago that moves
>> the mv643xx_eth SRAM window programming code from the Pegasos plat
pr_debug() can now result in code being generated even when #DEBUG
is not defined. That's not really desirable in the ftrace code
which we want to be snappy.
With CONFIG_DYNAMIC_DEBUG=y:
size before:
textdata bss dec hex filename
3334 672 44010 faa arch/pow
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
drivers/ata/sata_fsl.c:340: warning: format '%x' expects type 'unsigned int',
but argument 4 has type 'dma_addr_t'
Signed-off-by: Kumar Gala
---
* v2: fixed extra 'x'
* v3: fixed whi
On Wed, May 13, 2009 at 02:11:22PM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> >
> >
> > Ok. If you have NOR flash, why couldn't you just put the dtb in a
> > separate partition of the NOR?
> >
> >
> It is not THE dtb, it is A dtb. Our systems support and typically use
> multiple F
On May 8, 2009, at 8:52 AM, Kumar Gala wrote:
We plan to use fsl,esdhc going forward as the base compatible so
update
the driver to bind against it.
Signed-off-by: Kumar Gala
---
drivers/mmc/host/sdhci-of.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Any feedback or possibil
On Tue, 28 Apr 2009 09:24:53 +0200 (CEST)
Geert Uytterhoeven wrote:
> On Tue, 28 Apr 2009, Stephen Rothwell wrote:
> > On Mon, 27 Apr 2009 14:50:31 -0700 Andrew Morton
> > wrote:
> > > powerpc allmodconfig, current mainline:
> > >
> > > drivers/video/logo/logo_linux_mono.c:11: error: logo_linu
This is based on v2.6.30-rc5.
- k
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
Documentation/powerpc/dts-bindings/ecm.txt | 64 +
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
Just added defconfig updates for the normal FSL set of HW.
- k
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/configs/83xx/asp8347_defconfig | 104 -
arch/powerpc/configs/
On May 12, 2009, at 3:36 AM, Li Yang wrote:
Signed-off-by: Li Yang
---
drivers/rapidio/rio-scan.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
applied to next
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
On May 12, 2009, at 3:35 AM, Li Yang wrote:
Instead of fixed address in old code.
Signed-off-by: Li Yang
---
arch/powerpc/sysdev/fsl_rio.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
applied to next
- k
___
Linuxppc-dev m
We we build with resource_size_t as a 64-bit quantity we get:
arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_setup':
arch/powerpc/sysdev/fsl_rio.c:1029: warning: format '%08x' expects type
'unsigned int', but argument 4 has type 'resource_size_t'
arch/powerpc/sysdev/fsl_rio.c:1029: warning:
On Wed, May 13, 2009 at 2:25 PM, Kumar Gala wrote:
> We we build with dma_addr_t as a 64-bit quantity we get:
>
> drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
> drivers/dma/fsldma.c:625: warning: cast to pointer from integer of different
> size
> drivers/dma/fsldma.c: In function '
On Wed, 6 May 2009 18:40:07 +0800
Dave Liu wrote:
> Freescale eSDHC controller has the special order for
> the HOST version register. that is not same as the other's
> registers. The address of HOSTVER in spec is 0xFE, and
> we need use the in_be16(0xFE) to access it, not in_be16(0xFC).
>
> Sig
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/dma/fsldma.c: In function 'fsl_chan_xfer_ld_queue':
drivers/dma/fsldma.c:625: warning: cast to pointer from integer of different
size
drivers/dma/fsldma.c: In function 'fsl_dma_chan_do_interrupt':
drivers/dma/fsldma.c:737: warning:
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
drivers/ata/sata_fsl.c:340: warning: format '%x' expects type 'unsigned int',
but argument 4 has type 'dma_addr_t'
Signed-off-by: Kumar Gala
---
* had one too many 'x'
- k
drivers/
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
drivers/ata/sata_fsl.c:340: warning: format '%x' expects type 'unsigned int',
but argument 4 has type 'dma_addr_t'
Signed-off-by: Kumar Gala
---
drivers/ata/sata_fsl.c |7 --
On May 13, 2009, at 4:12 PM, Kumar Gala wrote:
We we build with dma_addr_t as a 64-bit quantity we get:
drivers/ata/sata_fsl.c: In function 'sata_fsl_fill_sg':
drivers/ata/sata_fsl.c:340: warning: format '%x' expects type
'unsigned int', but argument 4 has type 'dma_addr_t'
Signed-off-by:
On Wed, 13 May 2009, Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> > Andi Kleen wrote:
> > > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> > >> Andi Kleen wrote:
> > >>
> > >>> network packets are normally processed by the network packet int
On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
> > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> >> Andi Kleen wrote:
> >>
> >>> network packets are normally processed by the network packet interrupt's
> >>> softirq or alternatively in the NAPI
Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
>> Andi Kleen wrote:
>>
>>> network packets are normally processed by the network packet interrupt's
>>> softirq or alternatively in the NAPI poll loop.
>> If we have a high priority task, ksoftirqd may not get a cha
Dear Li Yang,
In message <2a27d3730905130328m27743852w2d68a62ebc32c...@mail.gmail.com> you
wrote:
>
> Although 8MB seems to be the common size used. It can be very easy
> changed as a pluggable module. It might be better to make the code
> working for any reasonable flash sizes.
You either hav
On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
>
> > network packets are normally processed by the network packet interrupt's
> > softirq or alternatively in the NAPI poll loop.
>
> If we have a high priority task, ksoftirqd may not get a chance to run.
In thi
Andi Kleen wrote:
> network packets are normally processed by the network packet interrupt's
> softirq or alternatively in the NAPI poll loop.
If we have a high priority task, ksoftirqd may not get a chance to run.
My point is simply that the documentation says that softirqs are
processed on ret
On Wed, 13 May 2009, Wolfram Sang wrote:
> > diff --git a/include/linux/leds.h b/include/linux/leds.h
> > index 376fe07..66e7d75 100644
> > --- a/include/linux/leds.h
> > +++ b/include/linux/leds.h
> > @@ -141,9 +141,14 @@ struct gpio_led {
> > const char *name;
> > const char *default_trig
On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote:
> On Wed, 13 May 2009 15:28:26 +0200
> Bartlomiej Zolnierkiewicz wrote:
>
> > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote:
> > > On Mon, 27 Apr 2009 23:21:48 +0200
> > > Bartlomiej Zolnierkiewicz wrote:
> > >
> > > > On Monday 27 Apri
David Gibson wrote:
>
>
> Ok. If you have NOR flash, why couldn't you just put the dtb in a
> separate partition of the NOR?
>
>
It is not THE dtb, it is A dtb. Our systems support and typically use
multiple FPGA bit streams.
Clients are
That means each bitstream must have its own dtb, clients
On Wed, May 13, 2009 at 09:05:01AM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
> > Thomas Gleixner writes:
>
> >>Err, no. Chris is completely correct:
> >>
> >>if (!in_interrupt())
> >>wakeup_softirqd();
> >
> > Yes you have to wake it up just in case, but it doesn't norm
Thomas Gleixner wrote:
> On Wed, 13 May 2009, Chris Friesen wrote:
>> As far as I can tell, in this scenario softirqs may not get processed on
>> return from a syscall (contradicting the documentation). In the worst
>> case, they may not get processed until the next timer tick.
>
> Right because
From: Benjamin Krill
The receive interrupt routine checks the wrong register if the
receive fifo is empty. Further an explicit interrupt acknowledge
write is introduced. In some circumstances another interrupt was
issued.
Signed-off-by: Benjamin Krill
Signed-off-by: Arnd Bergmann
---
drivers/
Hi Ben,
I have three small fixes for Cell that I'd like you to
add to your powerpc tree.
git pull git.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git next
The first two patches might still be good to have in 2.6.30,
the patch from Jan is just a cleanup for 2.6.31.
Thanks,
Arnd <
From: Jan Blunck
This patch removes an unnecessary double check if the dentry returned by
lookup_create() is actually non-negative. Since lookup_create() itself returns
an error in this case just remove the check.
Signed-off-by: Jan Blunck
Signed-off-by: Arnd Bergmann
---
arch/powerpc/platfor
From: Gerhard Stenzel
There have been a series of checkstops on QS21 related to
ptcal being set up incorrectly. On systems that only
have memory on a single node, ptcal fails when it gets
a pointer to memory on the remote node.
Moreover, agressive prefetching in memcpy and other
functions may ac
On Wed, 13 May 2009, Chris Friesen wrote:
> Andi Kleen wrote:
> > Thomas Gleixner writes:
>
> >>Err, no. Chris is completely correct:
> >>
> >>if (!in_interrupt())
> >>wakeup_softirqd();
> >
> > Yes you have to wake it up just in case, but it doesn't normally
> > process the
Andi Kleen wrote:
> Thomas Gleixner writes:
>>Err, no. Chris is completely correct:
>>
>>if (!in_interrupt())
>> wakeup_softirqd();
>
> Yes you have to wake it up just in case, but it doesn't normally
> process the data because a normal softirq comes in faster. It's
> just a
Ben,
We have:
/* Platform specific bus fixups. This is currently only used
* by fsl_pci and I'm hoping to get rid of it at some point
*/
if (ppc_md.pcibios_fixup_bus)
ppc_md.pcibios_fixup_bus(bus);
I can remove this but would need to replace it
Andi Kleen a écrit :
> Thomas Gleixner writes:
>
>
>> Err, no. Chris is completely correct:
>>
>> if (!in_interrupt())
>> wakeup_softirqd();
>
> Yes you have to wake it up just in case, but it doesn't normally
> process the data because a normal softirq comes in faster. It'
> I have one machine SMP flooded by network frames, CPU0 handling all
Yes that's the case softirqd is supposed to handle. When you
spend a significant part of your CPU time in softirq context it kicks
in to provide somewhat fair additional CPU time.
But most systems (like mine) don't do that.
-
On Wed, 13 May 2009, Andi Kleen wrote:
> > "If a soft irq is raised in process context, raise_softirq() in
> > kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
>
> softirqd is only used when the softirq runs for too long or when
> there are no suitable irq exits for a long tim
Thomas Gleixner writes:
> Err, no. Chris is completely correct:
>
> if (!in_interrupt())
> wakeup_softirqd();
Yes you have to wake it up just in case, but it doesn't normally
process the data because a normal softirq comes in faster. It's
just a safety policy.
You can ch
> "If a soft irq is raised in process context, raise_softirq() in
> kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
softirqd is only used when the softirq runs for too long or when
there are no suitable irq exits for a long time.
In normal situations (not excessive time in so
Andi Kleen wrote:
> "Chris Friesen" writes:
>
>>One of the reasons I brought up this issue is that there is a lot of
>>documentation out there that says "softirqs will be processed on return
>>from a syscall". The fact that it actually depends on the scheduler
>>parameters of the task issuing th
cc'ed LKML
On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla wrote:
> Hallo
>
> we'd likes to use a RapidIO as a general communication bus on our new
> product, and so I have some questions about general design of Linux RIO
> subsystem. I did not find any better mailing list for RapidIO
> discussion.
On Wed, May 13, 2009 at 3:06 AM, Wolfgang Denk wrote:
> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00., while there are actually only 8 MB on
> the boards, mapped at 0xFF80.. When booting an uImage with such a
> device tree, the kernel crash
Hello Trent,
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 376fe07..66e7d75 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -141,9 +141,14 @@ struct gpio_led {
> const char *name;
> const char *default_trigger;
> unsignedgpio;
>
Friday 08 May 2009 05:30:15 John Rigby napisał(a):
> Did you choose to not support hardware ECC so you could use the spare area?
> The original driver only supported hardware ECC but unfortuneatly the
> hardware ECC includes the spare area so the spare area cannot be written
> separately.
In short
"Chris Friesen" writes:
>
> One of the reasons I brought up this issue is that there is a lot of
> documentation out there that says "softirqs will be processed on return
> from a syscall". The fact that it actually depends on the scheduler
> parameters of the task issuing the syscall isn't ever
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = <&pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
&pio2 2 0>;/* cs2 */
Signed-off-by: Rin
>> Um.. one thing I'm missing in this discussion of attaching the dtb to
>> the bitstream: I don't see how the bitstream becomes accessible to
>> the kernel at runtime. Unless you were exposing the dtb as part of
>> the fpga programming, but I thought you explicitly weren't doing that
>> because
48 matches
Mail list logo
