On Tue, Feb 19, 2008 at 08:46:03AM +1100, Michael Ellerman wrote:
> On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> > On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > > >
> > > > This means it generates faster code with a
On Mon, Feb 18, 2008 at 09:39:56PM -0700, Bjorn Helgaas wrote:
> parisc: checks DEVICE_COUNT_RESOURCE (12) instead of PCI_NUM_RESOURCES
> (11) resources at (1),
>
Good catch.
> has no IORESOURCE_{IO,MEM} check at (3),
What else can it be?
> has no PCI_ROM_RESOURCE check at (4),
On Tuesday 19 February 2008 16:58, Willy Tarreau wrote:
> On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> > > Note in particular the last predictors; assuming branch ending
> > > with goto, including call, causing early function return or
> > > returning negative constant are not tak
> Index: work6/drivers/pci/Makefile
> ===
> --- work6.orig/drivers/pci/Makefile 2008-02-18 21:16:36.0 -0700
> +++ work6/drivers/pci/Makefile2008-02-18 21:16:38.0 -0700
> @@ -2,7 +2,7 @@
> # Makefile for the
On Mon, 2008-02-18 at 21:39 -0700, Bjorn Helgaas wrote:
> powerpc: has a different collision check at (5)
I've always found the collision check dodgy. I tend to want to keep
the way powerpc does it here.
pci_enable_device() should only enable resources that have successfully
been added to th
On Mon, 2008-02-18 at 21:39 -0700, Bjorn Helgaas wrote:
> plain text document attachment (ppc-pcibios_enable_resources)
> pcibios_enable_device() has an almost verbatim copy of
> pcibios_enable_resources(), (the only difference is that
> pcibios_enable_resources() turns on PCI_COMMAND_MEMORY if
>
On Mon, 2008-02-18 at 21:39 -0700, Bjorn Helgaas wrote:
> plain text document attachment (make-pcibios_enable_resources)
> On x86, pcibios_enable_device() is factored into
> pcibios_enable_resources() and pcibios_enable_irq(). On several other
> architectures, the functional equivalent of pcibios
On Mon, Feb 18, 2008 at 09:39:52PM -0700, Bjorn Helgaas wrote:
> - PA-RISC always turns on SERR and PARITY, which no other arch does
>
I suspect this is because we set the host bus adapters to hard fail
(HPMC) on detecting an error, since we don't want to
1) return possibly bogus (-1)
On Tue, Feb 19, 2008 at 01:33:53PM +1100, Nick Piggin wrote:
> > Note in particular the last predictors; assuming branch ending
> > with goto, including call, causing early function return or
> > returning negative constant are not taken. Just these alone
> > are likely 95+% of the unlikelies in th
pcibios_enable_device() has an almost verbatim copy of
pcibios_enable_resources(), (the only difference is that
pcibios_enable_resources() turns on PCI_COMMAND_MEMORY if
there's a ROM resource).
The duplication might be intentional, but I don't see any callers
of pcibios_enable_resources() on xten
pcibios_enable_device() has an almost verbatim copy of
pcibios_enable_resources(), (the only difference is that
pcibios_enable_resources() turns on PCI_COMMAND_MEMORY if
there's a ROM resource).
The duplication might be intentional, but I don't see any callers
of pcibios_enable_resources() on ppc,
On x86, pcibios_enable_device() is factored into
pcibios_enable_resources() and pcibios_enable_irq(). On several other
architectures, the functional equivalent of pcibios_enable_resources()
is expanded directly inside pcibios_enable_device().
This splits these pcibios_enable_device() implementati
There are many implementations of pcibios_enable_resources() that differ
in minor ways that look more like bugs than architectural differences.
This patch consolidates most of them to use the x86 version.
This patch is for discussion only at this point. I'm interested in
feedback about whether an
There are many implementations of pcibios_enable_resources() that differ
in minor ways that look more like bugs than architectural differences.
This patch series consolidates most of them to use the x86 version.
This series is for discussion only at this point. I'm interested in
feedback about wh
On Tuesday 19 February 2008 13:40, Arjan van de Ven wrote:
> On Tue, 19 Feb 2008 13:33:53 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Actually one thing I don't like about gcc is that I think it still
> > emits cmovs for likely/unlikely branches, which is silly (the gcc
> > developers seem
On Tuesday 19 February 2008 01:39, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > you have more faith in the authors knowledge of how his code actually
> > behaves than I think is warranted :)
>
> iirc there was a mm patch some time ago to keep track of the actual
> unlikely
On Tuesday 19 February 2008, Sean MacLennan wrote:
> I left in the volatiles, since I don't
> understand why they where needed. The memory always seems to be access
> with in_8 and out_8, which are declared volatile. But they could be
> there to fix a very specific bug.
It's very unlikely that
On Tue, 5 Feb 2008 09:38:20 -0600
Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Feb 2008 08:24:38 -0700
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> > On 2/5/08, Josh Boyer <[EMAIL PROTECTED]> wrote:
> > > > I mean, if you have not included 4xx support in the kernel, as is the
> > > > case
On Tue, 19 Feb 2008 13:33:53 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Actually one thing I don't like about gcc is that I think it still
> emits cmovs for likely/unlikely branches, which is silly (the gcc
> developers seem to be in love with that instruction). If that goes
> away, then bra
Here is an optional bonus patch that cleans up most of the checkpatch
warnings in the common code. I left in the volatiles, since I don't
understand why they where needed. The memory always seems to be access
with in_8 and out_8, which are declared volatile. But they could be
there to fix a ver
An updated version of the patch. This one should answer all of Jean's
concerns.
Cheers,
Sean
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
--- for-2.6.25/drivers/i2c/busses/orig-i2c-ibm_iic.c2008-02-18
16:36:30.0 -0500
+++ for-2.6.25/drivers/i2c/busses/i2c-ibm_iic.c 2008-
On Monday 18 February 2008, Kamalesh Babulal wrote:
> Hi,
>
> The next-20080218 kernel build fails on the powerpc(s)
>
> drivers/ide/ppc/pmac.c: In function ‘pmac_ide_macio_attach’:
> drivers/ide/ppc/pmac.c:1094: error: conversion to non-scalar type requested
> drive
On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote:
> [EMAIL PROTECTED] schrieb:
> > On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> >> I know two fb drivers which use endianess information (pm2fb and
> >> s3c2410fb).
> >> Both resolve endianess at driver level. Actually, both han
[EMAIL PROTECTED] schrieb:
> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
>> I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
>> Both resolve endianess at driver level. Actually, both handle it by setting
>> special
>> bits so the graphics chip itself reorde
Kumar Gala wrote:
> $ make V=1
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/uImage powerpc-unknown-linux-gnu-gcc -m32
>- Wp,-MD,arch/powerpc/boot/.treeboot-walnut.o.d -Wall -Wundef
>- Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -msoft-float
On Mon, 2008-02-18 at 16:13 +0200, Adrian Bunk wrote:
> On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> > On Mon, 18 Feb 2008, Adrian Bunk wrote:
> > >
> > > This means it generates faster code with a current gcc for your platform.
> > >
> > > But a future gcc might e.g. rep
>
> * Super-I/O chips at 0x2e/0x2f and 0x4e/0x4f.
>
> * Legacy PC hardware monitoring chips at 0x290-0x297.
>
> * IPMI interface at 0x0ca3 and 0x0cab (read-only).
>
> Please tell me which ones should be skipped on PowerPC.
Skip the whole thing. I consider that on a powerpc linux port, the
pla
On Mon, 18 Feb 2008 21:58:42 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
> >
> > > Maybe Christian's patch can be improved to not do the check on
> > > these? As long as /dev/port exists, it seems reasonable that the
> > > kern
On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
>
> > Maybe Christian's patch can be improved to not do the check on these?
> > As long as /dev/port exists, it seems reasonable that the kernel should
> > behave, no matter what I/O ports are accessed from user-space.
>
> nonsense
> Maybe Christian's patch can be improved to not do the check on these?
> As long as /dev/port exists, it seems reasonable that the kernel should
> behave, no matter what I/O ports are accessed from user-space.
nonsense.
/dev/mem exists for example, but you are still not supposed to go
bang all
Hi Ben,
On Thu, 14 Feb 2008 07:42:54 +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-02-13 at 18:35 +0100, Christian Krafft wrote:
> > sensors_detect crashes kernel on PowerPC, as it pokes directly to memory.
For the records, sensors-detect accesses I/O ports, not memory.
> > This patch a
Hello.
Stephen Neuendorffer wrote:
>>>Instead of attempting to come up with a generic description
>>>of this, I recommend just naming it after the actual device instance;
>>>something like compatible="xlnx,opb-uart16550";
>>Well, that means that we'll need a to add a code which "glues" the
On Feb 18, 2008 6:01 AM, Geert Uytterhoeven
<[EMAIL PROTECTED]> wrote:
> > This means it generates faster code with a current gcc for your platform.
> >
> > But a future gcc might e.g. replace the whole loop with a division
> > (gcc SVN head (that will soon become gcc 4.3) already does
> > transfor
On Mon, 18 Feb 2008 12:42:40 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 18, 2008 at 11:32:14AM -0700, Grant Likely wrote:
> > On Feb 18, 2008 11:31 AM, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On Feb 18, 2008 11:28 AM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> > > > I nee
On Mon, Feb 18, 2008 at 11:32:14AM -0700, Grant Likely wrote:
> On Feb 18, 2008 11:31 AM, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On Feb 18, 2008 11:28 AM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> > > I need to call i2c_register_board_info for the new i2c style ad7414
> > > driver. This need
On Mon, 18 Feb 2008 13:11:06 -0500
[EMAIL PROTECTED] wrote:
> On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
>
> > __builtin_expect() is useful on FRV where you _have_ to give each
> > branch and conditional branch instruction a measure of probability
> > whether the branch will be taken.
On Feb 18, 2008 11:31 AM, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 11:28 AM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> > I need to call i2c_register_board_info for the new i2c style ad7414
> > driver. This needs to be called at arch initcall time. Currently I just
> > do this:
>
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> Both resolve endianess at driver level. Actually, both handle it by setting
> special
> bits so the graphics chip itself reorder bytes to transform foreign
> e
On Feb 18, 2008 11:28 AM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> I need to call i2c_register_board_info for the new i2c style ad7414
> driver. This needs to be called at arch initcall time. Currently I just
> do this:
>
> static int __init warp_arch_init(void)
> {
> i2c_register_board_
On Feb 18, 2008 10:47 AM, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 18, 2008 at 01:43:52PM +0100, Laurent Pinchart wrote:
> > Should I put IP core nodes as children of the FPGA node ?
>
> You could do that as well.
I'd recommend doing that, then your subnodes are isolated from changes
to
I need to call i2c_register_board_info for the new i2c style ad7414
driver. This needs to be called at arch initcall time. Currently I just
do this:
static int __init warp_arch_init(void)
{
i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
return 0;
}
arch_ini
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
> __builtin_expect() is useful on FRV where you _have_ to give each branch and
> conditional branch instruction a measure of probability whether the branch
> will be taken.
What does gcc do the 99.998% of the time we don't have likely/unlikely
On Mon, Feb 18, 2008 at 01:43:52PM +0100, Laurent Pinchart wrote:
> [EMAIL PROTECTED],0 {
> device_type = "board-control";
> reg = <3 0 0020>;
> };
No device_type. Needs a compatible.
>
> [EMAIL
On Mon, Feb 18, 2008 at 12:30:11PM -0500, [EMAIL PROTECTED] wrote:
> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> > I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> > Both resolve endianess at driver level. Actually, both handle it by setting
> > special
On Mon, Feb 18, 2008 at 03:17:49PM +0100, Andreas Schwab wrote:
> Kamalesh Babulal <[EMAIL PROTECTED]> writes:
>
.
.
> Just remove the cast.
>
> Andreas.
Resending the patch after making the changes Andreas said.
Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
Cc: Andreas Schwab <[EMAIL PR
David Howells wrote:
> Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
>> Hence shouldn't we ask the gcc people what's the purpose of
>> __builtin_expect(), if it doesn't live up to its promise?
>
> __builtin_expect() is useful on FRV where you _have_ to give each branch and
> conditional branch
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> you have more faith in the authors knowledge of how his code actually behaves
> than I think is warranted :)
iirc there was a mm patch some time ago to keep track of the actual unlikely
values at runtime and it showed indeed some wrong ones. But the
So, like, the other day David Gibson mumbled:
> Since fdt_node_offset_by_compatible() was converted to the new
> fdt_next_node() iterator, a chunk of initialization code became
> redundant, but was not removed by oversight. This patch cleans it up.
>
> Signed-off-by: David Gibson <[EMAIL PROTECTE
So, like, the other day David Gibson mumbled:
> Currently the CHECK_HEADER() macro is defined local to fdt_ro.c.
> However, there are a handful of functions (fdt_move, rw_check_header,
> fdt_open_into) from other files which could also use it (currently
> they open-code something more-or-less ident
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> Hence shouldn't we ask the gcc people what's the purpose of
> __builtin_expect(), if it doesn't live up to its promise?
__builtin_expect() is useful on FRV where you _have_ to give each branch and
conditional branch instruction a measure of probabil
So, like, the other day David Gibson mumbled:
> In light of the recently discovered bug with NOP handling, this adds
> some more testcases for NOP handling. Specifically, it adds a helper
> program which will add a NOP tag after every existing tag in a dtb,
> and runs the standard battery of tests
Kamalesh Babulal <[EMAIL PROTECTED]> writes:
> --- linux-2.6.25-rc1/drivers/ide/ppc/pmac.c 2008-02-18 18:41:48.0
> +0530
> +++ linux-2.6.25-rc1/drivers/ide/ppc/~pmac.c 2008-02-18 19:20:37.0
> +0530
> @@ -1091,7 +1091,7 @@ pmac_ide_macio_attach(struct macio_dev *
> int ir
On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> On Mon, 18 Feb 2008, Adrian Bunk wrote:
> >
> > This means it generates faster code with a current gcc for your platform.
> >
> > But a future gcc might e.g. replace the whole loop with a division
> > (gcc SVN head (that will s
Hi,
The next-20080218 kernel build fails on the powerpc(s)
drivers/ide/ppc/pmac.c: In function ‘pmac_ide_macio_attach’:
drivers/ide/ppc/pmac.c:1094: error: conversion to non-scalar type requested
drivers/ide/ppc/pmac.c: In function ‘pmac_ide_pci_attach’:
drivers/ide/ppc/pmac.c:1232: error
On Mon, 18 Feb 2008, Adrian Bunk wrote:
> On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
> > On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
> >...
> > > for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> > > than the coder in general. Same for
On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
> On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
>...
> > for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> > than the coder in general. Same for most other architectures.
> >
> > unlikely() cre
Hi Bart,
the current linux-next produces this error for a pmac32 powerpc build:
drivers/ide/ppc/pmac.c:1094: error: conversion to non-scalar type requested
drivers/ide/ppc/pmac.c:1232: error: conversion to non-scalar type requested
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED
Hi Christian,
On Wed, 13 Feb 2008 18:37:01 +0100, Christian Krafft wrote:
> when probing i2c-pca-isa writes to legacy ioports, which crashes the kernel
> if there is no device at that port.
> This patch adds a check_legacy_ioport call, so probe failes gracefully
> and thus prevents the oops.
>
>
On Mon, 18 Feb 2008 04:32:24 -0500 (EST)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
>
> (AIUI, the entire ppc/ architecture is going away, yes? which means
> i probably shouldn't care about any errors within. is that correct?
> even so, build errors should probably still be avoided for now
Hi everybody,
I'm (at last) trying to move from ARCH=ppc to ARCH=powerpc. After reading
Documentation/powerpc/booting-without-of.txt and various device trees in
arch/powerpc/boot/dts, I still don't know how to express some devices in the
device tree.
The target board has several devices on the
When building current mainline for ps3_defconfig, I get the following
mm-related section mismatches:
| WARNING: mm/built-in.o(.text+0x25094): Section mismatch in reference from the
function .sparse_add_one_section() to the function
.meminit.text:.sparse_index_init()
| The function .sparse_add_on
switching to proper mail client...
Dave Hansen <[EMAIL PROTECTED]> wrote on 15.02.2008 17:55:38:
> I've been thinking about that, and I don't think you really *need* to
> keep a comprehensive map like that.
>
> When the memory is in a particular configuration (range of memory
> present along wi
Dave Hansen <[EMAIL PROTECTED]> wrote on 15.02.2008 17:55:38:
> I've been thinking about that, and I don't think you really *need* to
> keep a comprehensive map like that.
>
> When the memory is in a particular configuration (range of memory
> present along with unique set of holes) you get a un
(AIUI, the entire ppc/ architecture is going away, yes? which means
i probably shouldn't care about any errors within. is that correct?
even so, build errors should probably still be avoided for now.)
$ make ARCH=ppc defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
H
On Sun, 17 Feb 2008 10:44:32 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Feb 2008, Anton Vorontsov wrote:
> > On Thu, Feb 14, 2008 at 10:49:42PM -0800, Andrew Morton wrote:
> > > On Tue, 5 Feb 2008 18:44:32 +0300 Anton Vorontsov <[EMAIL PROTECTED]>
> > > wrote:
> > > A
65 matches
Mail list logo
