Hi all,
[I am now using gcc version 4.4.0 ...]
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no expression
Previous gcc versions didn't notice this because one of the preceding
#ifs always evaluated to true. I ha
On Apr 22, 2009, at 11:06 PM, David Gibson wrote:
Well, yes, I guess I agree. How immutable you consider the device
tree blob to be is a judgement call based on the specific details of
platform/board in question. If it is indeed a reference platform, in
the early stages of development where i
On Wed, 2009-04-22 at 20:15 -0700, Randy Dunlap wrote:
> Michael Ellerman wrote:
> > On Wed, 2009-04-22 at 21:46 +0530, Subrata Modak wrote:
> >> On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
> >>> Reported this earlier on 14th April 2009:
> >>> http://lkml.org/lkml/2009/4/14/480,
> >>>
>
On Wed, Apr 22, 2009 at 10:36:36PM -0500, Kumar Gala wrote:
>
> On Apr 22, 2009, at 9:26 PM, David Gibson wrote:
>
>> On Wed, Apr 22, 2009 at 04:55:42PM -0500, Kumar Gala wrote:
>>>
>>> On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
>>>
Kumar Gala wrote:
> I disagree. If you update your k
On Apr 22, 2009, at 6:40 PM, Mike Wolf wrote:
Resending. the patch was munged last time.
Oprofile is changing the naming it is using for the compatibility
modes.
Instead of having compat-power, oprofile will go to family naming
convention and use compat-v. Currently only compat-v1 will b
Refactor the check to determine if the quirk is applicable to the boards
into one inline function so we only have to change one place to add more
boards that the quirks might be applicable to.
Also removed a warning related to unused temp variable.
Signed-off-by: Kumar Gala
---
* With new and im
On Apr 22, 2009, at 9:26 PM, David Gibson wrote:
On Wed, Apr 22, 2009 at 04:55:42PM -0500, Kumar Gala wrote:
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your
device
tree (thus we have .dts in the kernel tree an
On Wed, Apr 22, 2009 at 9:37 PM, Grant Likely wrote:
> On Wed, Apr 22, 2009 at 5:12 PM, Graeme Smecher
> wrote:
>> Hi Grant,
>>
>> I'm not sure if you've caught this yet, but there's a typo in
>> drivers/net/xilinx_temac.c. The TX and RX ISRs (ll_temac_tx_irq and
>> ll_temac_rx_irq) take two argu
Michael Ellerman wrote:
> On Wed, 2009-04-22 at 21:46 +0530, Subrata Modak wrote:
>> On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
>>> Reported this earlier on 14th April 2009:
>>> http://lkml.org/lkml/2009/4/14/480,
>>>
>>> Michael,
>>>
>>> Any fix in sight ?
>>> http://lkml.org/lkml/200
On Wed, Apr 22, 2009 at 04:55:42PM -0500, Kumar Gala wrote:
>
> On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> I disagree. If you update your kernel you should update your device
>>> tree (thus we have .dts in the kernel tree and not somewhere else).
>>
>> No. The devi
So select GENERIC_HARDIRQS_NO__DO_IRQ to disable it.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4c78045..3ba167a 100644
--- a/arch/powerpc/Kconfig
+++ b/arc
Don't call __do_IRQ() directly in gatwick_action(), use
generic_handle_irq().
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/powermac/pic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pic.c
b/arch/powerpc/platforms/powerm
We should no longer have any irq code that needs __do_IRQ(), so
remove the fallback to __do_IRQ().
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/irq.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
in
The guts of do_IRQ() isn't really the right place to be documenting
the ppc_md.get_irq() interface. So move the comment into machdep.h
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/machdep.h |4
arch/powerpc/kernel/irq.c |7 ---
2 files changed, 4 inserti
Makes do_IRQ() shorter and clearer.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/irq.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index bc08827..f725610 100644
--- a/arc
Rather than a giant ifdef in the body of do_IRQ(), including a
dangling else, move the irq stack logic into a separate routine and
do the ifdef there.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/irq.c | 96 ++---
1 files changed, 56 insertion
On Tue, Apr 21, 2009 at 10:11:51AM -0500, Kumar Gala wrote:
>
> On Apr 21, 2009, at 7:49 AM, Mark Ware wrote:
>
> >Recent DMA changes result in a BUG() when NULL is passed to
> >dma_alloc_coherent in place of a device.
> >
> >Signed-off-by: Mark Ware
> >---
> >
> >This patch fixes the BUG() duri
On Wed, 2009-04-22 at 21:46 +0530, Subrata Modak wrote:
> On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
> > Reported this earlier on 14th April 2009:
> > http://lkml.org/lkml/2009/4/14/480,
> >
> > Michael,
> >
> > Any fix in sight ?
> > http://lkml.org/lkml/2009/4/14/676,
> >
> > CC
Because it selects PPC_OF_PLATFORM_PCI which depends on PCI, so
if we don't select PCI we can end up with PCI=n and
PPC_OF_PLATFORM_PCI=y which doesn't build.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/cell/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
For
On Wed, Apr 22, 2009 at 12:10 PM, Wolfgang Denk wrote:
> In message <1240422181.549...@antares> you wrote:
>> Any idea what goes wrong here, and how I could fix it?
>
> Apply this patch:
>
> http://patchwork.ozlabs.org/patch/24487/
No, that's not the problem in this case. 2.6.29 networking is br
On Wed, Apr 22, 2009 at 5:33 PM, Scott Wood wrote:
> All I'm asking is that we treat a mandatory dts upgrade as seriously as a
> mandatory firmware upgrade.
I agree with this statement 100%.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linux
Hi Kumar,
On Wed, 22 Apr 2009 11:56:10 -0500 Kumar Gala wrote:
>
> Refactor the check to determine if the quirk is applicable to the boards
> into one inline function so we only have to change one place to add more
> boards that the quirks might be applicable to.
>
> Also removed a warning relat
good try for the expr., platform.
在 2009年4月23日 上午2:10 時， Wolfgang Denk 寫到：
Dear Albrecht =?iso-8859-1?b?RHJl3w==?=,
In message <1240422181.549...@antares> you wrote:
this question is maybe off-topic on this list...
This is not off topic (actually, if you had bothered to check the
mailing i
Resending. the patch was munged last time.
Oprofile is changing the naming it is using for the compatibility modes.
Instead of having compat-power, oprofile will go to family naming
convention and use compat-v. Currently only compat-v1 will be
defined.
Signed-off-by: Mike Wolf
--- mainl
Kumar Gala wrote:
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
No. The device tree is a means to pass information from the firmware
to
On Apr 22, 2009, at 4:57 PM, Timur Tabi wrote:
Kumar Gala wrote:
New nodes. For example I've proposed a "local access window" node.
Once I add it I plan on changing code to use it. This will break an
old device tree booting with the new kernel and I'm completely ok
with
that.
Are we ha
Scott Wood wrote:
> That is indeed the case. A "demonstration" of that for the tree you
> quote is that the "reg" address changed -- if you tried feeding the old
> tree into the new kernel, it would not find the CPM command register.
> There is no code in the kernel that looks for the command-
Timur Tabi wrote:
Kumar Gala wrote:
The specific issue I'm talking about is the addition of new nodes that
might break old device trees.
New nodes or new properties? The CPM nodes are not new. On some device
trees, the original versions did not have a compatible property for the
CPM nodes
Kumar Gala wrote:
> New nodes. For example I've proposed a "local access window" node.
> Once I add it I plan on changing code to use it. This will break an
> old device tree booting with the new kernel and I'm completely ok with
> that.
Are we having two different conversations? I was
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your
device tree (thus we have .dts in the kernel tree and not somewhere
else).
No. The device tree is a means to pass information from the
firmware to the kernel.
On Apr 22, 2009, at 4:46 PM, Timur Tabi wrote:
Kumar Gala wrote:
The specific issue I'm talking about is the addition of new nodes
that
might break old device trees.
New nodes or new properties? The CPM nodes are not new. On some
device
trees, the original versions did not have a comp
Kumar Gala wrote:
> The specific issue I'm talking about is the addition of new nodes that
> might break old device trees.
New nodes or new properties? The CPM nodes are not new. On some device
trees, the original versions did not have a compatible property for the
CPM nodes (e.g. commit 0b5
We have built a new board based on the PPC440EPx. We are
using an SMII-mode phy for the ethernet.
The .dts file started as the one for Sequoia, and I have
changed the phy specifier to phy-mode = "smii" - I've also
removed the has-mdio property from RGMII0. The ethernet
is working in U-Boot, but
On Apr 22, 2009, at 4:33 PM, Timur Tabi wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
Is this a new policy? I was under the impression that supporting
older
device trees,
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
No. The device tree is a means to pass information from the firmware to
the kernel. It is part of the firmware. That the repository of t
CONFIG_DUET doesn't exist anymore, remove all the code that exists to
support it.
Signed-off-by: Kumar Gala
---
* Removed stale comment that went along w/DUET support
drivers/net/fs_enet/fs_enet-main.c | 35 +--
drivers/net/fs_enet/fs_enet.h |5 -
Kumar Gala wrote:
> I disagree. If you update your kernel you should update your device
> tree (thus we have .dts in the kernel tree and not somewhere else).
Is this a new policy? I was under the impression that supporting older
device trees, if not too inconvenient, is desirable. I've nack'
On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
Scott Wood wrote:
Timur Tabi wrote:
these two are related and seem like we could look for
"fsl,cpm2"
That's okay, as long as you don't break compatibility with older
device trees that don't have that property, unless you can
demonstrate
Kumar Gala wrote:
@@ -318,32 +314,6 @@ static void restart(struct net_device *dev)
/*
* adjust to speed (only for DUET & RMII)
*/
-#ifdef CONFIG_DUET
- if (fpi->use_rmii) {
Please remove the comment that goes with the code being removed.
Otherwise, ACK.
-Scott
CONFIG_DUET doesn't exist anymore, remove all the code that exists to
support it.
Signed-off-by: Kumar Gala
---
drivers/net/fs_enet/fs_enet-main.c | 35 +--
drivers/net/fs_enet/fs_enet.h |5 -
drivers/net/fs_enet/mac-fec.c | 30 --
Scott Wood wrote:
arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR (get_immrbase() +
0x8)
arch/powerpc/sysdev/cpm2.c:cpm2_immr = ioremap(get_immrbase(),
CPM_MAP_SIZE);
these two are related and seem like we could look for "fsl,cpm2"
And do what with it that wouldn't be a reimp
Timur Tabi wrote:
Scott Wood wrote:
Timur Tabi wrote:
these two are related and seem like we could look for "fsl,cpm2"
That's okay, as long as you don't break compatibility with older
device trees that don't have that property, unless you can demonstrate
that these trees would never wor
Scott Wood wrote:
> Timur Tabi wrote:
>>>these two are related and seem like we could look for "fsl,cpm2"
>> That's okay, as long as you don't break compatibility with older
>> device trees that don't have that property, unless you can demonstrate
>> that these trees would never work with t
Timur Tabi wrote:
these two are related and seem like we could look for "fsl,cpm2"
That's okay, as long as you don't break compatibility with older
device trees that don't have that property, unless you can demonstrate
that these trees would never work with the current kernel anyway.
A
On Thursday 08 January 2009, Stefan Roese wrote:
> This adds a SPI driver for the SPI controller found in the IBM/AMCC
> 4xx PowerPC's.
> +/*
> + * The PPC4xx SPI controller has no FIFO so each sent/received byte will
> + * generate an interrupt to the CPU. This can cause high CPU utilization.
>
On Apr 22, 2009, at 2:44 PM, Scott Wood wrote:
CPM/QE related users.
arch/powerpc/include/asm/cpm1.h:#define IMAP_ADDR
(get_immrbase())
only used drivers/net/fs_enet/fs_enet-main.c which seems evil.
That driver *is* evil. :-)
It looks like the only remaining user of fs_enet_imma
Kumar Gala wrote:
I'm not sure if we can actually get away with completely removing
get_immrbase() but I figured I'd give everyone something to flame me
about. The current users are:
I think we want to keep it for an eventual re-introduction of a large
TLB entry to cover IMMR (but no longer
On Wed, Apr 22, 2009 at 1:38 PM, Kumar Gala wrote:
> I'm not sure if we can actually get away with completely removing
> get_immrbase() but I figured I'd give everyone something to flame me about.
> The current users are:
>
> CPM/QE related users.
I'm okay with doing this for QE, but I don't see
Hello Scott
It is definitively more elegant...
Let me send tomorrow a patch
On Wed, Apr 22, 2009 at 20:11, Scott Wood wrote:
> Ricardo Ribalda Delgado wrote:
>>
>> Hi Scott
>>
>>> Perhaps "compatible" should be used instead?
>>
>> What do you mean?
>>
>> if (strcmp(partname, "partition") || s
Kill of some old defines and macros that we no longer use like
CPM_MAP_ADDR and CPM_IRQ_OFFSET.
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/cpm2.h|4
arch/powerpc/platforms/82xx/pq2ads.h | 13 -
arch/powerpc/platforms/8xx/mpc885ads.h |4
arch/
I'm not sure if we can actually get away with completely removing
get_immrbase() but I figured I'd give everyone something to flame me
about. The current users are:
CPM/QE related users.
arch/powerpc/include/asm/cpm1.h:#define IMAP_ADDR (get_immrbase())
only used driv
* Ricardo Ribalda Delgado | 2009-04-22 19:59:08 [+0200]:
>>
>> if (strcmp(partname, "partition") <= 0) {
>
>Anything alfabetically higher than partition (like "z" will pass
>the test :S)
You are totally right!
cheers
ben
___
Linuxppc
On Apr 22, 2009, at 1:16 PM, Scott Wood wrote:
Kumar Gala wrote:
What "we care about" at this point is irrelevant, given the PITA
it would be to change the device trees (or u-boot) that are
already in use once we do begin to care.
Which is exactly why I didn't put it in the .dts right now.
The rstcr register mapping code was written sometime ago before
of_iomap() existed. We can use it and clean up the code a bit
and get rid of one user of get_immrbase() in the process.
Signed-off-by: Kumar Gala
---
arch/powerpc/sysdev/fsl_soc.c | 14 --
1 files changed, 4 insertion
Kumar Gala wrote:
What "we care about" at this point is irrelevant, given the PITA it
would be to change the device trees (or u-boot) that are already in
use once we do begin to care.
Which is exactly why I didn't put it in the .dts right now.
???
Today we know NO code exists that cares abo
The first 4k region of CCSR space is well defined for local access
windows, CCSRBAR, etc. The second 4k region is well defined as
register for configuring and getting errors for the MPX coherency
module.
Signed-off-by: Kumar Gala
---
Please review. Once we close on this I intend to mimic this f
On Apr 22, 2009, at 12:38 PM, Scott Wood wrote:
Kumar Gala wrote:
On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:
Kumar Gala wrote:
On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we
should
indicate that here.
t
Ricardo Ribalda Delgado wrote:
Hi Scott
Perhaps "compatible" should be used instead?
What do you mean?
if (strcmp(partname, "partition") || strcmp(partname, "compatible") )
I can't see the advantages.
No, I mean:
foo {
compatible = "partition";
...
};
-Scott
Dear Albrecht =?iso-8859-1?b?RHJl3w==?=,
In message <1240422181.549...@antares> you wrote:
>
> this question is maybe off-topic on this list...
This is not off topic (actually, if you had bothered to check the
mailing ist archives before posting, you would have known - because
you would have foun
Eddie Dawydiuk wrote:
> Grant,
>
>> However, if you're writing one-off custom drivers and there is no
>> common coded needed for acking irqs, then I would probably just use
>> the external IRQ.
>
> Thanks for the suggestions I think going to just use the external IRQ.
> As a result I've been read
Grant,
However, if you're writing one-off custom drivers and there is no
common coded needed for acking irqs, then I would probably just use
the external IRQ.
Thanks for the suggestions I think going to just use the external IRQ. As a
result I've been reading through a few different dts files
Hello Benjamin
> Hi Recardo,
>
> I would suggest to do:
>
> if (strcmp(partname, "partition") <= 0) {
Anything alfabetically higher than partition (like "z" will pass
the test :S)
Regards
>
> cheers
> ben
>
>
--
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
Hi Scott
> Perhaps "compatible" should be used instead?
What do you mean?
if (strcmp(partname, "partition") || strcmp(partname, "compatible") )
I can't see the advantages.
>
>> Hi Recardo,
>>
>> I would suggest to do:
>>
>> if (strcmp(partname, "partition") <= 0) {
>
> Check wh
Hi,
this question is maybe off-topic on this list...
I use the Lite5200B board with stock kernel 2.6.29, and boot with the
root fs on nfs on an Ubuntu 8.10 PC. Both the Lite5200B and the Ubuntu
PC are part of a corporate network. On the root fs, I have busybox and
everything else needed.
Kumar Gala wrote:
On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:
Kumar Gala wrote:
On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.
that might be the case, but I leave it to u-boot to
Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c
and just moved the defines it cared about into there. Also fixed up
the ioremap to only map the one 4k page we need access to and to iounmap
when we are done.
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/mpc86xx.h
Hi,
On Wed, Apr 22, 2009 at 09:45:47PM +0530, Subrata Modak wrote:
> On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
> > I am observing this for the first time:
> >
> > CC drivers/net/ni65.o
> > drivers/net/ni65.c: In function ‘ni65_init_lance’:
> > drivers/net/ni65.c:585: error: im
Benjamin Krill wrote:
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, "name", &len);
- if (strcmp
On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:
Kumar Gala wrote:
On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we
should
indicate that here.
that might be the case, but I leave it to u-boot to do that.
Why?
Kumar Gala wrote:
On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.
that might be the case, but I leave it to u-boot to do that.
Why? There's no p2020 with an older eLBC, and there's no
>--- a/drivers/mtd/ofpart.c
>+++ b/drivers/mtd/ofpart.c
>@@ -48,7 +48,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
>
> /* check if this is a partition node */
> partname = of_get_property(pp, "name", &len);
>- if (strcmp(partname, "partiti
On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.
that might be the case, but I leave it to u-boot to do that.
Why? There's no p2020 with an older eLBC, and there's no block
version re
Kumar Gala wrote:
If this has an elbc more recent than 1.0 (looks like it), we should
indicate that here.
that might be the case, but I leave it to u-boot to do that.
Why? There's no p2020 with an older eLBC, and there's no block version
register.
-Scott
__
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty simila
On Apr 22, 2009, at 11:44 AM, Scott Wood wrote:
On Tue, Apr 21, 2009 at 10:31:45PM -0500, Kumar Gala wrote:
+ local...@ffe05000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc", "simple-bus";
If this has an elbc more rec
Refactor the check to determine if the quirk is applicable to the boards
into one inline function so we only have to change one place to add more
boards that the quirks might be applicable to.
Also removed a warning related to unused temp variable.
Signed-off-by: Kumar Gala
---
* Fixed compile i
On Tue, Apr 21, 2009 at 10:31:45PM -0500, Kumar Gala wrote:
> + local...@ffe05000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,elbc", "simple-bus";
If this has an elbc more recent than 1.0 (looks like it), we should
indicate that
Hi,
Stefan Roscher wrote:
On Wednesday 22 April 2009 04:10:18 pm michael wrote:
Hi,
I don't take the point, if it is not import use the vmalloc. Why you try
with a kmalloc
alloc first? and why do not use kzalloc?
Because kmalloc() is faster than vmalloc() causing a huge p
On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
> Reported this earlier on 14th April 2009:
> http://lkml.org/lkml/2009/4/14/480,
>
> Michael,
>
> Any fix in sight ?
> http://lkml.org/lkml/2009/4/14/676,
>
> CC arch/powerpc/kernel/of_platform.o
> arch/powerpc/kernel/of_platform.c: I
On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
> I am observing this for the first time:
>
> CC drivers/net/ni65.o
> drivers/net/ni65.c: In function ‘ni65_init_lance’:
> drivers/net/ni65.c:585: error: implicit declaration of function
> ‘isa_virt_to_bus’
> drivers/net/ni65.c: In func
Hi,
Stefan Roscher wrote:
In case of large queue pairs there is the possibillity of allocation failures
due to memory fragmentationo with kmalloc().To ensure the memory is allocated even
if kmalloc() can not find chunks which are big enough, we try to allocate the
memory
with vmalloc().
Signe
On Wednesday 22 April 2009 04:10:18 pm michael wrote:
> Hi,
>
> I don't take the point, if it is not import use the vmalloc. Why you try
> with a kmalloc
> alloc first? and why do not use kzalloc?
Because kmalloc() is faster than vmalloc() causing a huge performance win
when someone allocates a
Hello
You are right, remove the -1. I thought that strlen gives the #of
chars + 1 ('\0').
Thanks
On Wed, Apr 22, 2009 at 11:24, Peter Korsgaard wrote:
>> "Ricardo" == Ricardo Ribalda Delgado writes:
>
> Hi,
>
> Ricardo> Sometimes, an special partition is included in the device
> Ric
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partit...@ff00 {
reg = < 0x00 0x80 >;
label = "Root File System";
};
partit...@ff80 {
reg = < 0x80 0x1a >;
label = "Bitstream";
};
...
partition
Geert Uytterhoeven wrote:
> On Wed, 22 Apr 2009, Michael Ellerman wrote:
>> On Wed, 2009-04-22 at 00:23 +0530, Subrata Modak wrote:
>>> Reported this error on 14th April:
>>> http://lkml.org/lkml/2009/4/14/488,
>>>
>>> CC [M] drivers/staging/comedi/drivers.o
>>> drivers/staging/comedi/drivers.c:
On Wed, Apr 22, 2009 at 8:49 AM, Eddie Dawydiuk wrote:
> Hello,
>
> I'm working on a board based on the Yosemite AMCC 440EP. We have an FPGA
> connected via the PCI bus, and has an IRQ line connected directly to the
> 440EP. The FPGA implements two registers to indicate which core generated
> the
Tests done...
-I use ioremap for the mapping of the memory, so it should be uncacheable
-I inserted a eieio() before the read and there is no change. In
addition, I use outbe_32 and inbe_32, which make a sync or isync ... And
these functions are used for the serial port and perfectly work
abou
Hello,
I'm working on a board based on the Yosemite AMCC 440EP. We have an FPGA
connected via the PCI bus, and has an IRQ line connected directly to the 440EP.
The FPGA implements two registers to indicate which core generated the
interrupt. So now the question is from a design standpoint is i
At Wed, 22 Apr 2009 22:56:52 +1000,
Paul Mackerras wrote:
>
> Jean Delvare writes:
>
> > > I sympathize, but throwing disruptive changes into Linus' tree when
> > > we're past -rc3 is not the way to solve the problem.
> >
> > We're past -rc3 because people discuss instead of testing my patches.
In case of large queue pairs there is the possibillity of allocation failures
due to memory fragmentationo with kmalloc().To ensure the memory is allocated
even
if kmalloc() can not find chunks which are big enough, we try to allocate the
memory
with vmalloc().
Signed-off-by: Stefan Roscher
--
Jean Delvare writes:
> > I sympathize, but throwing disruptive changes into Linus' tree when
> > we're past -rc3 is not the way to solve the problem.
>
> We're past -rc3 because people discuss instead of testing my patches.
> Otherwise everything would be merged already.
Well, no. The first con
Thank you for your advices! I try it as soon as possible! (the board is
not often available...)
Nicolas Lavocat
Gabriel Paubert a écrit :
On Wed, Apr 22, 2009 at 10:04:29AM +0200, Nicolas Lavocat wrote:
Hi everybody!
I' am trying to configure a PCI bridge on a private board, with a
powe
On Thu, 16 Apr 2009 23:01:01 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the ppc
> therm_windtunnel driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> ---
> Can someone please
On Thu, 16 Apr 2009 22:59:27 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the ppc
> therm_adt746x driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> ---
> Can someone please te
Hi Paul,
On Wed, 22 Apr 2009 19:34:40 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
>
> > Not removing it now has a high risk of developers continuing to ignore
> > the deprecation warnings and adding new legacy drivers, which I then
> > must convert to the new model. This never ends.
> >
On Wed, Apr 22, 2009 at 10:04:29AM +0200, Nicolas Lavocat wrote:
> Hi everybody!
>
> I' am trying to configure a PCI bridge on a private board, with a
> powerpc . In a first time, I tried to get informations about PCI
> devices, in order to be sure that my read and write methods work (
> u
In fact, because system froze, I wanted to know where was the problem,
so, step by step, I removed operations, until try to read this
register, basic operation when a PCI device is used. This register can
be read with JTAG, and under uboot, so I think that it is not a PCI
problem..
Nicolas La
Hi Roland,
thanks for the quick review. I was hoping you could apply these changes
for 2.6.30 because this will be the codebase for the next OFED release.
The patch is well tested in HPC environment and we haven't seen any
issues.
Regarding Antons patch you are right. If a user allocates an
unr
Hum... It is a proprietary bridge... I don't know how works the marvel,
but it is not like tundra (TSI108)... But it seems that this bridge
works like X86 bridges. I 'm goigng to read documentations about
Marvel bridges!
Nicolas Lavocat
Liu Dave-R63238 a écrit :
So the host bridg
So the host bridge is important, what is the bridge?
Marvell or Tundra chipset?
From: Nicolas Lavocat [mailto:nicolas.lavo...@fr.thalesgroup.com]
Sent: Wednesday, April 22, 2009 4:32 PM
To: Liu Dave-R63238
Cc: linuxppc-dev
1 - 100 of 117 matches
Mail list logo
