* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-02-19 23:18 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <200802192355.17707.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 19 February 2008, Stefan Roese wrote:
>
>> On Tuesday 19 February 2008, Jean Delvare wrote:
>>
>>> With this Kconfig change, "make menuconfig" lets me select the
>>> i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
>>> that you want to restrict the build to PPC machines somehow, or at
>>> least make sure that either IBM_OCP or OF support is present.
>>>
>> How about this:
>>
>> - depends on IBM_OCP
>> + depends on 4xx
>>
>
> I think we should allow it to be built on other platforms as well,
> as long as they have of_platform_device support.
>
> The Axon south bridge used on IBMs QS21 blade probably has an ibm_iic,
> even though it's managed by the firmware and we probably don't want
> to use it at this time, someone could use the same chip in a new
> design and actually do that.
>
> In general, I also like to make it possible to enable drivers just
> for the benefit of compile testing, even for stuff that you can't
> find in any existing HW configuration, so as long as it builds on
> a platform, I think we shouldn't forbid it:
>
> - depends on IBM_OCP
> + depends on IBM_OCP || PPC_MERGE
>
>
I have no problem with this change. If everybody agrees, I can respin
the patch.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Stephen Rothwell @ 2008-02-19 23:41 UTC (permalink / raw)
To: Sean MacLennan
Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c, Arnd Bergmann
In-Reply-To: <47BB63AE.2090903@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
> > - depends on IBM_OCP
> > + depends on IBM_OCP || PPC_MERGE
not PPC_OF? or even OF (give the sparc guys the opportunity to build it
for us :-))?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] powerpc: don't create two devices for each cpm_uart device tree node
From: Nikita V. Youshchenko @ 2008-02-19 23:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]
powerpc: don't create two devices for each cpm_uart device tree node
Code in arch/powerpc/sysdev/fsl_soc.c used to create two 'struct device'
objects for each cpm_uart device tree node - one "fsl-cpm-scc:uart"
in cpm_uart_of_init() and one "fsl-cpm-smc:uart" in cpm_smc_uart_of_init().
This patch adds additional test to those routines, such that cpm_uart_of_init()
only registers devices with model "SCC", and cpm_smc_uart_of_init() only
registers devices with model "SMC".
Signed-off-by: Nikita Youshchenko <yoush@debian.org>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index f1b8412..536f8c9 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -890,6 +890,10 @@ static int __init cpm_uart_of_init(void)
const int *id;
const char *model;
+ model = of_get_property(np, "model", NULL);
+ if (!model || strcmp(model, "SCC") != 0)
+ continue;
+
memset(r, 0, sizeof(r));
memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
@@ -917,7 +921,6 @@ static int __init cpm_uart_of_init(void)
id = of_get_property(np, "device-id", NULL);
cpm_uart_data.fs_no = *id;
- model = of_get_property(np, "model", NULL);
strcpy(cpm_uart_data.fs_type, model);
cpm_uart_data.uart_clk = ppc_proc_freq;
@@ -1175,6 +1178,10 @@ static int __init cpm_smc_uart_of_init(void)
const int *id;
const char *model;
+ model = of_get_property(np, "model", NULL);
+ if (!model || strcmp(model, "SMC") != 0)
+ continue;
+
memset(r, 0, sizeof(r));
memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
@@ -1200,7 +1207,6 @@ static int __init cpm_smc_uart_of_init(void)
goto err;
}
- model = of_get_property(np, "model", NULL);
strcpy(cpm_uart_data.fs_type, model);
id = of_get_property(np, "device-id", NULL);
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-02-19 23:54 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jean Delvare, Stephen Rothwell, Stefan Roese, i2c, Sean MacLennan
In-Reply-To: <20080220104133.e9722e62.sfr@canb.auug.org.au>
On Wednesday 20 February 2008, Stephen Rothwell wrote:
> > > - =A0 =A0 =A0 depends on IBM_OCP
> > > + =A0 =A0 =A0 depends on IBM_OCP || PPC_MERGE
>=20
> not PPC_OF? =A0or even OF (give the sparc guys the opportunity to build it
> for us :-))?
>=20
Right, I was looking for that option but couldn't find it. I would
guess sparc doesn't work because it's lacking the necessary I/O functions,
in_8 and out_8 that are powerpc specific.
so maybe:
depends on PPC
depends on IBM_OCP || OF
Arnd <><
^ permalink raw reply
* Re: [patch v7 3/4] USB: add Cypress c67x00 OTG controller HCD driver
From: Greg KH @ 2008-02-19 23:55 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080219151149.684610000@sunsite.dk>
On Tue, Feb 19, 2008 at 04:09:19PM +0100, Peter Korsgaard wrote:
> This patch adds HCD support for the Cypress c67x00 family of devices.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
And it doesn't build:
CC [M] drivers/usb/c67x00/c67x00-hcd.o
distcc[2413] ERROR: compile /home/gregkh/.ccache/c67x00-hcd.tmp.mini.2409.i on localhost failed
drivers/usb/c67x00/c67x00-hcd.c:345: error: redefinition of 'c67x00_hcd_probe'
drivers/usb/c67x00/c67x00-hcd.h:119: error: previous definition of 'c67x00_hcd_probe' was here
drivers/usb/c67x00/c67x00-hcd.c:402: error: redefinition of 'c67x00_hcd_remove'
drivers/usb/c67x00/c67x00-hcd.h:126: error: previous definition of 'c67x00_hcd_remove' was here
make[2]: *** [drivers/usb/c67x00/c67x00-hcd.o] Error 1
make[1]: *** [drivers/usb/c67x00] Error 2
make: *** [_module_drivers/usb] Error 2
This is _after_ removing the obviously incorrect usb_disabled()
function that you included in your .h file.
I'm going to hold off applying any of these for now, as it doesn't look
like something is configured properly here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] [POWERPC] fix warning in pseries/power.c
From: Stephen Rothwell @ 2008-02-20 0:27 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Greg KH
Introduced by commit 79393fc46ede43451a500a132e5de9856f5a4c83 ("kobject:
convert pseries/power.c to kobj_attr interface").
sys_create_file takes a "struct attrbute *" not a "struct kobj_addribute *".
arch/powerpc/platforms/pseries/power.c: In function 'apo_pm_init':
arch/powerpc/platforms/pseries/power.c:78: warning: passing argument 2 of 'sysfs_create_file' from incompatible pointer type
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pseries/power.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/power.c b/arch/powerpc/platforms/pseries/power.c
index e95fc15..6d62662 100644
--- a/arch/powerpc/platforms/pseries/power.c
+++ b/arch/powerpc/platforms/pseries/power.c
@@ -75,7 +75,7 @@ core_initcall(pm_init);
#else
static int __init apo_pm_init(void)
{
- return (sysfs_create_file(power_kobj, &auto_poweron_attr));
+ return (sysfs_create_file(power_kobj, &auto_poweron_attr.attr));
}
__initcall(apo_pm_init);
#endif
--
1.5.4.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: David Miller @ 2008-02-20 0:30 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0802191350590.10089@blarg.am.freescale.net>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 13:51:37 -0600 (CST)
> If we add to an empty lmb region with a non-zero base we will not coalesce
> the number of regions down to one. This causes problems on ppc32 for the
> memory region as its assumed to only have one region.
>
> We can fix this easily by causing the initial add to replace the dummy
> region.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Fix a bug the initial patch introduced if we have a region that gets added
> at the beginning of the list we wouldn't actually add it.
>
> Dave can you replace the patch in you tree with this one.
I think my tree has already or will soon be pulled in so
I don't want to rebase it.
Why don't you simply send me the relative bug fix instead?
Thanks!
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Valdis.Kletnieks @ 2008-02-20 0:47 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <20080219040530.7b1d115d.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
On Tue, 19 Feb 2008 04:05:30 PST, Andrew Morton said:
> On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <clemens.koller@anagramm.de
> wrote:
> > That's not an issue in my case. The SM50x can be connected to
> > either an PCI or some Local/CPU-whateverbus IF.
> > I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses.
> > If the sm501 is attached to the MPC85xx' PCI like any other video card,
> > the PCI config-space is can be accessed as usual, whereas the framebuffer
> > memory area is byte-swapped compared to other common video cards.
> Anyway, my head is now officially spinning. Did anyone actually have a
> reason why we shouldn't proceed with Anton's patch?
Clemens answered my question regarding the real-life existence of hardware
that would benefit. I'd say if Anton's patch works on Clemens' hardware and
otherwise passes review, we should proceed...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Benjamin Herrenschmidt @ 2008-02-20 0:50 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven, Andrew Morton
In-Reply-To: <28238.1203468428@turing-police.cc.vt.edu>
On Tue, 2008-02-19 at 19:47 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 19 Feb 2008 04:05:30 PST, Andrew Morton said:
> > On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <clemens.koller@anagramm.de
> > wrote:
> > > That's not an issue in my case. The SM50x can be connected to
> > > either an PCI or some Local/CPU-whateverbus IF.
> > > I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses.
> > > If the sm501 is attached to the MPC85xx' PCI like any other video card,
> > > the PCI config-space is can be accessed as usual, whereas the framebuffer
> > > memory area is byte-swapped compared to other common video cards.
>
> > Anyway, my head is now officially spinning. Did anyone actually have a
> > reason why we shouldn't proceed with Anton's patch?
>
> Clemens answered my question regarding the real-life existence of hardware
> that would benefit. I'd say if Anton's patch works on Clemens' hardware and
> otherwise passes review, we should proceed...
No objection here neither.
Ben.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Paul Mackerras @ 2008-02-20 0:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <20080219040530.7b1d115d.akpm@linux-foundation.org>
Andrew Morton writes:
> Bizarrely, the original author of the patch (Anton) has fallen off the cc.
> Could whoever did that please thwap himself?
>
> Anyway, my head is now officially spinning. Did anyone actually have a
> reason why we shouldn't proceed with Anton's patch?
I was wondering if it would be sufficient to provide alternative
versions of fb_readl, fb_writel etc. that do byte-swapping. That
would mean that all framebuffers would have to have the same
endianness, but that would suffice for embedded systems such as
Anton's and would end up a lot simpler IMHO.
Paul.
^ permalink raw reply
* Re: libfdt: More tests of NOP handling behaviour
From: Jerry Van Baren @ 2008-02-20 1:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1JR6vQ-0000h9-2f@jdl.com>
Jon Loeliger wrote:
> 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 over trees mangled in this way.
>>
>> For now, this does not add a NOP at the very beginning of the
>> structure block. This causes problems for libfdt at present, because
>> we assume in many places that the root node's BEGIN_NODE tag is at
>> offset 0. I'm still contemplating what to do about this (with one
>> option being simply to declare such dtbs invalid).
>>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
>
> BTW, declaring DTBs with BEGIN_NODES not at offset 0
> as invalid seems like a fine choice to me.
>
> jdl
FWIIW, I vote ditto on declaring DTBs with BEGIN_NODES not at offset 0
as invalid. The root being at offset 0 assumption is pretty well
entrenched and I cannot think of any reason to change it that would be
worth the effort.
Best regards,
gvb
^ permalink raw reply
* Re: libfdt: More tests of NOP handling behaviour
From: David Gibson @ 2008-02-20 2:04 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <47BB7FDB.3050809@gmail.com>
On Tue, Feb 19, 2008 at 08:18:19PM -0500, Jerry Van Baren wrote:
> Jon Loeliger wrote:
> > 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 over trees mangled in this way.
> >>
> >> For now, this does not add a NOP at the very beginning of the
> >> structure block. This causes problems for libfdt at present, because
> >> we assume in many places that the root node's BEGIN_NODE tag is at
> >> offset 0. I'm still contemplating what to do about this (with one
> >> option being simply to declare such dtbs invalid).
> >>
> >> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Applied.
> >
> > BTW, declaring DTBs with BEGIN_NODES not at offset 0
> > as invalid seems like a fine choice to me.
> >
> > jdl
>
> FWIIW, I vote ditto on declaring DTBs with BEGIN_NODES not at offset 0
> as invalid. The root being at offset 0 assumption is pretty well
> entrenched and I cannot think of any reason to change it that would be
> worth the effort.
Well, it's actually not that hard to deal with. I've already been
planning to add a helper function/macro which validates a node offset
(something currently open-coded in a whole bunch of places). It would
be fairly easy to make it skip over nops as well.
But, likewise I can think of no reason that NOPs before the root node
would be useful or likely to occur in practice.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala @ 2008-02-20 3:02 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080219.163003.152862383.davem@davemloft.net>
On Feb 19, 2008, at 6:30 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue, 19 Feb 2008 13:51:37 -0600 (CST)
>
>> If we add to an empty lmb region with a non-zero base we will not
>> coalesce
>> the number of regions down to one. This causes problems on ppc32
>> for the
>> memory region as its assumed to only have one region.
>>
>> We can fix this easily by causing the initial add to replace the
>> dummy
>> region.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>>
>> Fix a bug the initial patch introduced if we have a region that
>> gets added
>> at the beginning of the list we wouldn't actually add it.
>>
>> Dave can you replace the patch in you tree with this one.
>
> I think my tree has already or will soon be pulled in so
> I don't want to rebase it.
>
> Why don't you simply send me the relative bug fix instead?
np. Are we trying to get this into 2.6.25 or .26?
- k
^ permalink raw reply
* Re: [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: David Miller @ 2008-02-20 3:31 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <4130F47E-4F4A-4911-B63B-403A8C423565@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 21:02:04 -0600
> np. Are we trying to get this into 2.6.25 or .26?
I'm ambivalent but I would obviously prefer 2.6.25 because
it would allow me to proceed more easily with my sparc64
NUMA work as well as get your bug fixes in more smoothly.
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-02-20 3:46 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a few more bug and warning fixes for powerpc. The diffstat is
bloated by the defconfig updates -- the actual code changes are only a
few dozen lines.
Thanks,
Paul.
arch/powerpc/boot/Makefile | 8
arch/powerpc/boot/dts/bamboo.dts | 3
arch/powerpc/boot/dts/ebony.dts | 2
arch/powerpc/boot/dts/katmai.dts | 2
arch/powerpc/boot/dts/kilauea.dts | 3
arch/powerpc/boot/dts/makalu.dts | 3
arch/powerpc/boot/dts/rainier.dts | 4
arch/powerpc/boot/dts/sequoia.dts | 4
arch/powerpc/boot/dts/taishan.dts | 4
arch/powerpc/configs/bamboo_defconfig | 81 ++-
arch/powerpc/configs/ebony_defconfig | 79 ++-
arch/powerpc/configs/ep405_defconfig | 92 ++-
arch/powerpc/configs/kilauea_defconfig | 69 ++
arch/powerpc/configs/makalu_defconfig | 69 ++
arch/powerpc/configs/ppc44x_defconfig | 904 ++++++++++++++++++++++++++++++++
arch/powerpc/configs/rainier_defconfig | 82 ++-
arch/powerpc/configs/sequoia_defconfig | 77 ++-
arch/powerpc/configs/taishan_defconfig | 81 ++-
arch/powerpc/configs/walnut_defconfig | 81 ++-
arch/powerpc/configs/warp_defconfig | 139 +++--
arch/powerpc/kernel/kprobes.c | 9
arch/powerpc/kernel/prom.c | 13
arch/powerpc/platforms/44x/Kconfig | 10
arch/powerpc/platforms/pseries/power.c | 2
arch/ppc/platforms/4xx/ibm440ep.c | 6
drivers/net/ibm_newemac/rgmii.c | 1
26 files changed, 1497 insertions(+), 331 deletions(-)
create mode 100644 arch/powerpc/configs/ppc44x_defconfig
Ananth N Mavinakayanahalli (1):
[POWERPC] Kill sparse warnings in kprobes
Becky Bruce (1):
[POWERPC] Fix dt_mem_next_cell() to read the full address
Josh Boyer (4):
[POWERPC] 4xx: Update defconfigs for 2.6.25
[POWERPC] 44x: Fix Kconfig formatting
[POWERPC] 44x: Add multiplatform defconfig
[POWERPC] Fix bootwrapper builds with older gcc versions
Stefan Roese (2):
[POWERPC] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
[POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
Stephen Rothwell (1):
[POWERPC] Fix warning in pseries/power.c
Wolfgang Ocker (1):
[POWERPC] PPC440EP Interrupt Triggering and Level Settings
^ permalink raw reply
* Sample driver
From: Silwer star @ 2008-02-20 4:13 UTC (permalink / raw)
To: linuxppc-embedded
Does anyone have sample drivers in Linux for the EBC interface for PPC405Ex?
I would be thankful if someone could put in a sample code here.
--
View this message in context: http://www.nabble.com/Sample-driver-tp15582059p15582059.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala @ 2008-02-20 4:27 UTC (permalink / raw)
To: davem; +Cc: sparclinux, linuxppc-dev, linux-kernel
We introduced a bug in fixing lmb_add_region to handle an initial
region being non-zero. Before that fix it was impossible to insert
a region at the head of the list since the first region always started
at zero.
Now that its possible for the first region to be non-zero we need to
check to see if the new region should be added at the head and if so
actually add it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
lib/lmb.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index e3c8dcb..3c43b95 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -184,6 +184,11 @@ static long __init lmb_add_region(struct lmb_region *rgn, u64 base, u64 size)
break;
}
}
+
+ if (base < rgn->region[0].base) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ }
rgn->cnt++;
return 0;
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: David Miller @ 2008-02-20 4:45 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0802192227170.2215@blarg.am.freescale.net>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 22:27:48 -0600 (CST)
> We introduced a bug in fixing lmb_add_region to handle an initial
> region being non-zero. Before that fix it was impossible to insert
> a region at the head of the list since the first region always started
> at zero.
>
> Now that its possible for the first region to be non-zero we need to
> check to see if the new region should be added at the head and if so
> actually add it.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
...
> @@ -184,6 +184,11 @@ static long __init lmb_add_region(struct lmb_region *rgn, u64 base, u64 size)
> break;
> }
> }
> +
> + if (base < rgn->region[0].base) {
> + rgn->region[0].base = base;
> + rgn->region[0].size = size;
> + }
> rgn->cnt++;
>
> return 0;
Are you sure this is sufficient?
It seems to me, to handle this properly, you'll need to handle
the case where the lower addressed entry you are inserting is
not contiguous with the existing entry 0.
Therefore, you need to move all existing entries up a slot,
then you can set the 0 entry to 'base' and 'size'.
What do you think?
^ permalink raw reply
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala @ 2008-02-20 5:16 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080219.204525.193731674.davem@davemloft.net>
On Feb 19, 2008, at 10:45 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue, 19 Feb 2008 22:27:48 -0600 (CST)
>
>> We introduced a bug in fixing lmb_add_region to handle an initial
>> region being non-zero. Before that fix it was impossible to insert
>> a region at the head of the list since the first region always
>> started
>> at zero.
>>
>> Now that its possible for the first region to be non-zero we need to
>> check to see if the new region should be added at the head and if so
>> actually add it.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ...
>> @@ -184,6 +184,11 @@ static long __init lmb_add_region(struct
>> lmb_region *rgn, u64 base, u64 size)
>> break;
>> }
>> }
>> +
>> + if (base < rgn->region[0].base) {
>> + rgn->region[0].base = base;
>> + rgn->region[0].size = size;
>> + }
>> rgn->cnt++;
>>
>> return 0;
>
> Are you sure this is sufficient?
>
> It seems to me, to handle this properly, you'll need to handle
> the case where the lower addressed entry you are inserting is
> not contiguous with the existing entry 0.
>
> Therefore, you need to move all existing entries up a slot,
> then you can set the 0 entry to 'base' and 'size'.
The for loop above the code I added will move all the existing slots
up one. Its just the tail cleanup we are missing.
- k
^ permalink raw reply
* Re: 2.6.24 for mpc8458amc
From: Kumar Gala @ 2008-02-20 5:19 UTC (permalink / raw)
To: raul.moreno
Cc: maxime louvel,
linuxppc-embedded-bounces+raul.moreno=telvent.abengoa.com,
linuxppc-embedded
In-Reply-To: <OF5ABF0D8A.75A05AE1-ONC12573F4.00426B12-C12573F4.0043B5F0@abengoa.com>
On Feb 19, 2008, at 6:19 AM, raul.moreno@telvent.abengoa.com wrote:
>
> Hello Maxime,
>
> if your board is still running, although you can't see the messages
> that
> means you don't have any console. Try to set one (I think you can
> use a SCM
> of the CPM) in the kernel configuration (characters devices) or in
> the
> command line (console=).
If you really have a mpc8548 than there is no CPM. It has 16550 style
UARTs on it.
- k
^ permalink raw reply
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: David Miller @ 2008-02-20 5:26 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <7A7ECF09-E547-4C04-A388-C3E8755478DD@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 23:16:18 -0600
> The for loop above the code I added will move all the existing slots
> up one. Its just the tail cleanup we are missing.
Aha, I see how this works now, thanks!
I'll add this to my LMB tree.
^ permalink raw reply
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala @ 2008-02-20 5:29 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080219.212655.173468988.davem@davemloft.net>
On Feb 19, 2008, at 11:26 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue, 19 Feb 2008 23:16:18 -0600
>
>> The for loop above the code I added will move all the existing slots
>> up one. Its just the tail cleanup we are missing.
>
> Aha, I see how this works now, thanks!
>
> I'll add this to my LMB tree.
Sounds good. Now just convince Paul or Linus to pull this in for
2.6.25 :)
- k
^ permalink raw reply
* [GIT PULL] Please pull spufs.git master branch
From: Jeremy Kerr @ 2008-02-20 5:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev
Hi Paul,
Please do a:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git master
I have two new bugfixes for spufs: these are both fixes for regressions
since .24.
Cheers,
Jeremy
--- 2 commits:
[POWERPC] spufs: fix scheduler starvation by idle contexts
Jeremy Kerr <jk@ozlabs.org>
arch/powerpc/platforms/cell/spufs/run.c | 1 +
arch/powerpc/platforms/cell/spufs/sched.c | 8 +++-----
2 files changed, 4 insertions(+), 5 deletions(-)
[POWERPC] cell: fix spurious false return from spu_trap_data_{map,seg}
Andre Detsch <adetsch@br.ibm.com>
arch/powerpc/platforms/cell/spu_base.c | 12 ------------
arch/powerpc/platforms/cell/spufs/switch.c | 6 +++---
include/asm-powerpc/spu.h | 3 +--
3 files changed, 4 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [patch 0/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Grant Grundler @ 2008-02-20 6:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <20080219043952.845136014@ldl.fc.hp.com>
On Mon, Feb 18, 2008 at 09:39:52PM -0700, Bjorn Helgaas wrote:
> 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 whether any of the differences are "real" and need to
> be preserved.
>
> ARM and PA-RISC, in particular, have interesting differences:
> - ARM always enables bridge devices, which no other arch does
> - PA-RISC always turns on SERR and PARITY, which no other arch does
>
> Should other arches do the same thing, or are these somehow related to
> ARM and PA-RISC architecture?
My impression was most x86 BIOS's did NOT turn on SERR/PERR when I added
that code to parisc-linux port (2000 or 2001 so) . HPUX was turning on
SERR/PERR and so I was comfortable the HW was stable and it not crash
under normal use unless something was really broken.
There is certainly nothing architectural specific about SERR/PERR.
I felt (at the time) this is more of a case of "if it's not reported to the
user, we won't get blamed for it not working well."
hth,
grant
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Jean Delvare @ 2008-02-20 6:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Stefan Roese, i2c, Sean MacLennan
In-Reply-To: <200802192355.17707.arnd@arndb.de>
Hi Arnd,
On Tue, 19 Feb 2008 23:55:16 +0100, Arnd Bergmann wrote:
> On Tuesday 19 February 2008, Stefan Roese wrote:
> > On Tuesday 19 February 2008, Jean Delvare wrote:
> > >
> > > With this Kconfig change, "make menuconfig" lets me select the
> > > i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
> > > that you want to restrict the build to PPC machines somehow, or at
> > > least make sure that either IBM_OCP or OF support is present.
> >=20
> > How about this:
> >=20
> > -=A0=A0=A0=A0=A0=A0=A0depends on IBM_OCP
> > +=A0=A0=A0=A0=A0=A0=A0depends on 4xx
>=20
> I think we should allow it to be built on other platforms as well,
> as long as they have of_platform_device support.
>=20
> The Axon south bridge used on IBMs QS21 blade probably has an ibm_iic,
> even though it's managed by the firmware and we probably don't want
> to use it at this time, someone could use the same chip in a new
> design and actually do that.
>=20
> In general, I also like to make it possible to enable drivers just
> for the benefit of compile testing, even for stuff that you can't
> find in any existing HW configuration, so as long as it builds on
> a platform, I think we shouldn't forbid it:
Fine with me as long as the default is set appropriately (i.e. default
to not building the driver on archs/platforms where it builds but is
known to be useless.)
>=20
> - depends on IBM_OCP
> + depends on IBM_OCP || PPC_MERGE
--=20
Jean Delvare
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox