* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Takashi Iwai @ 2009-04-14 14:45 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Johannes Berg, alsa-devel
In-Reply-To: <20090414163741.2a98b5d6@hyperion.delvare>
At Tue, 14 Apr 2009 16:37:41 +0200,
Jean Delvare wrote:
>
> On Fri, 10 Apr 2009 17:02:38 +0200, Jean Delvare wrote:
> > On Thu, 9 Apr 2009 14:19:45 +0200, Jean Delvare wrote:
> > > From: Jean Delvare <khali@linux-fr.org>
> > > Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers
> > >
> > > The legacy i2c binding model is going away soon, so convert the AOA
> > > codec drivers to the new model or they'll break.
> > >
> > > Signed-off-by: Jean Delvare <khali@linux-fr.org>
> > > Cc: Johannes Berg <johannes@sipsolutions.net>
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > ---
> > > sound/aoa/codecs/onyx.c | 71 +++++++++++++++++++++++++++++------------------
> > > sound/aoa/codecs/tas.c | 63 +++++++++++++++++++++++++----------------
> > > 2 files changed, 84 insertions(+), 50 deletions(-)
> >
> > Note to potential testers of this patch: you need to apply this i2c
> > patch first:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-loosen-driver-check.patch
>
> This patch is is Linus' tree now:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=935298696f469c0e07c73be687bd055878074ce0
Great, so we can simply apply patches to sound git tree.
Johannes, please let me know if the patch works. Then I'll merge them.
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Jean Delvare @ 2009-04-14 14:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: Benjamin, linuxppc-dev, alsa-devel, Takashi Iwai
In-Reply-To: <20090410170238.6cc3a420@hyperion.delvare>
On Fri, 10 Apr 2009 17:02:38 +0200, Jean Delvare wrote:
> On Thu, 9 Apr 2009 14:19:45 +0200, Jean Delvare wrote:
> > From: Jean Delvare <khali@linux-fr.org>
> > Subject: AOA: Convert onyx and tas codecs to new-style i2c drivers
> >
> > The legacy i2c binding model is going away soon, so convert the AOA
> > codec drivers to the new model or they'll break.
> >
> > Signed-off-by: Jean Delvare <khali@linux-fr.org>
> > Cc: Johannes Berg <johannes@sipsolutions.net>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> > sound/aoa/codecs/onyx.c | 71 +++++++++++++++++++++++++++++------------------
> > sound/aoa/codecs/tas.c | 63 +++++++++++++++++++++++++----------------
> > 2 files changed, 84 insertions(+), 50 deletions(-)
>
> Note to potential testers of this patch: you need to apply this i2c
> patch first:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-loosen-driver-check.patch
This patch is is Linus' tree now:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=935298696f469c0e07c73be687bd055878074ce0
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 1/2] keywest: Convert to new-style i2c driver
From: Jean Delvare @ 2009-04-14 14:37 UTC (permalink / raw)
To: alsa-devel; +Cc: linuxppc-dev
In-Reply-To: <20090410170951.084e9b5c@hyperion.delvare>
On Fri, 10 Apr 2009 17:09:51 +0200, Jean Delvare wrote:
> Ah, I forgot. You need the following patch applied before testing:
> ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-loosen-driver-check.patch
This patch is is Linus' tree now:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=935298696f469c0e07c73be687bd055878074ce0
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] therm_pm72: Convert to a new-style i2c driver
From: Jean Delvare @ 2009-04-14 14:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20090413165100.36b85c68@hyperion.delvare>
On Mon, 13 Apr 2009 16:51:00 +0200, Jean Delvare wrote:
> On Mon, 13 Apr 2009 16:09:27 +0200, Jean Delvare wrote:
> > The legacy i2c binding model is going away soon, so convert the
> > macintosh therm_pm72 driver to the new model or it will break.
> >
> > This is really a quick and dirty conversion, that should do the trick
> > for now, but no doubt that something cleaner can be done if anyone is
> > interested.
> >
> > Signed-off-by: Jean Delvare <khali@linux-fr.org>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> > Can anyone please run-test this patch? I could only build-test it.
>
> Damn, I forgot once again. You need to apply the following patch
> beforehand:
> ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-loosen-driver-check.patch
>
> I'll push this patch to Linus now.
This patch is is Linus' tree now:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=935298696f469c0e07c73be687bd055878074ce0
--
Jean Delvare
^ permalink raw reply
* Re: Help!Some memory doesn't work on PPC405Ex based board!
From: Grant Erickson @ 2009-04-14 14:04 UTC (permalink / raw)
To: SunNeo; +Cc: linuxppc-dev
In-Reply-To: <BAY114-W4176A96E45AE37FB5FBE02AB7C0@phx.gbl>
On 4/14/09 4:08 AM, SunNeo wrote:
> My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM is
> soldered on the board.
>
> As I said, my board was similar with "Kilauea" evb, so I created my
> configuration header file from Kilauea's at U-Boot. In the configuration file,
> register value for the DDR SDRAM controller is defined. But I have removed DDR
> autocalibraton related configuration from the configuration file, do you think
> this will cause any issues?
Sun:
Does your board have ECC? While it seems like simply following the static,
non-auto-calibrating configuration of the Kilauea or Haleakala board would
be sufficient, my experience is that it is not, especially if your design
has ECC.
Should you decide to escalate the issue with AMCC, I suspect
auto-calibration will be the first thing they ask you to enable and re-check
your design with.
Per Stefan's comments, unless you use an intensive and comprehensive memory
test of some sort, just running u-boot is not necessarily a sufficient
validation that memory works as it, in many configurations, touches and uses
little of the overall RAM during its operation.
Regards,
Grant
^ permalink raw reply
* Re: [PATCH 1/4 v2] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-04-14 12:57 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <fa686aa40904112258n1cc23b48t80b135b7016e9760@mail.gmail.com>
On Sunday 12 April 2009, Grant Likely wrote:
> > + =A0 =A0 =A0 info =3D kzalloc(sizeof(struct of_flash) +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct of_flash_lis=
t) * count, GFP_KERNEL);
> > + =A0 =A0 =A0 if (!info)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_out;
> > +
> > + =A0 =A0 =A0 mtd_list =3D kzalloc(sizeof(struct mtd_info) * count, GFP=
_KERNEL);
>
> Typically I prefer to see a single kzalloc in a driver which allocates
> all the space needed in one go because it simplifies the error/unwind
> path.
In general ack, but it doesn't make much sense in this case. The 2nd malloc=
is=20
for an temporary buffer needed for mtd_concat_create() call (list of struct=
=20
mtd_info. I can't really combine those two areas. So I'll leave this=20
untouched.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 1/4 v2] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-04-14 12:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-mtd
In-Reply-To: <fa686aa40904112258n1cc23b48t80b135b7016e9760@mail.gmail.com>
On Sunday 12 April 2009, Grant Likely wrote:
> On Tue, Apr 7, 2009 at 2:39 AM, Stefan Roese <sr@denx.de> wrote:
> > This patch adds support to handle multiple non-identical chips in one
> > flash device tree node. It also adds concat support to physmap_of. This
> > makes it possible to support e.g. the Intel P30 48F4400 chips which
> > internally consists of 2 non-identical NOR chips on one die. Additionally
> > partitions now can span over multiple chips.
>
> [...]
>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > CC: Grant Likely <grant.likely@secretlab.ca>
>
> Looks good to me. To comments below, but neither are enough to hold back
> my:
>
> Reviewd-by: Grant Likely <grant.likely@secretlab.ca>
Thanks.
> However, I have not tested this. I'd like to hear of some larger
> field testing before it is merged.
OK, I'll address your latest comments and resend a (hopefully) last version of
this patchset.
Thanks.
Stefan
^ permalink raw reply
* Re: Help!Some memory doesn't work on PPC405Ex based board!
From: Stefan Roese @ 2009-04-14 12:20 UTC (permalink / raw)
To: SunNeo; +Cc: linuxppc-dev, U-Boot-Users
In-Reply-To: <BAY114-W4176A96E45AE37FB5FBE02AB7C0@phx.gbl>
Hi Sun,
On Tuesday 14 April 2009, SunNeo wrote:
> My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM
> is soldered on the board.
>
> As I said, my board was similar with "Kilauea" evb, so I created my
> configuration header file from Kilauea's at U-Boot. In the configuration
> file, register value for the DDR SDRAM controller is defined. But I have
> removed DDR autocalibraton related configuration from the configuration
> file, do you think this will cause any issues?
Yes, this could definitely cause some SDRAM related problems. But this is
off-topic here. We should continue this discussion on the U-Boot mailing list
instead (on CC). So please when you reply to this mail, remove the
linuxppc-dev list from the recipients list.
Best regards,
Stefan
^ permalink raw reply
* [v2 PATCH 1/1] Fix 64bit Maple Host Bridge 'reg' property
From: tiejun.china @ 2009-04-14 10:13 UTC (permalink / raw)
To: segher; +Cc: linuxppc-dev, akpm
In the DTB tree created by firmware on some Maple 64bit targets, such as ATCA6101,
the "reg" property of host bridge node is incorrectly encoded as if #address-cells
and #size-cells were 1. So we have to provide one fixup function to fix that.
Signed-off-by: Tiejun Chen <tiejun.china@gmail.com>
---
arch/powerpc/kernel/prom_init.c | 50 ++++++++++++++++++++++++++++++++++++++-
1 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 2445945..36ef9f2 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1907,14 +1907,62 @@ static void __init flatten_device_tree(void)
}
#ifdef CONFIG_PPC_MAPLE
+/* On ATCA6101 64bit target host bridge parent node has specified address and
+ * size properties to be 2. But the actual "cell" value for host bridge node
+ * is 1 since early MOTLoad internal bug. */
+static void __init fixup_device_tree_atca6101(void)
+{
+ phandle hb;
+ u32 hb_ranges[4];
+ u32 size_cell, addr_cell;
+ struct prom_t *_prom = &RELOC(prom);
+ char *name;
+
+ name = "/hostbridge@f8000000";
+ hb = call_prom("finddevice", 1, 1, ADDR(name));
+ if (!PHANDLE_VALID(hb))
+ return;
+
+ if (prom_getproplen(hb, "reg") != 8)
+ return;
+
+ if (prom_getprop(hb, "reg", hb_ranges, (sizeof(hb_ranges))/2)
+ == PROM_ERROR)
+ return;
+
+ prom_getprop(_prom->root, "#address-cells", &addr_cell, sizeof(addr_cell));
+ prom_getprop(_prom->root, "#size-cells", &size_cell, sizeof(size_cell));
+
+ if ((addr_cell != 2) || (size_cell != 2) ||
+ (hb_ranges[0] != 0xf8000000))
+ return;
+
+ prom_printf("Fixing up bogus HOSTBRIDGE reg on ATCA6101...\n");
+
+ hb_ranges[3] = hb_ranges[1];
+ hb_ranges[1] = hb_ranges[0];
+ hb_ranges[0] = hb_ranges[2] = 0;
+ prom_setprop(hb, name, "reg", hb_ranges, sizeof(hb_ranges));
+}
/* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
- * The values are bad, and it doesn't even have the right number of cells. */
+ * The values are bad, and it doesn't even have the right number of cells.
+ * Additionally, the early MOTLoad generate incorrect address&size cells on
+ * some Maple platform such as ATCA6101. */
static void __init fixup_device_tree_maple(void)
{
phandle isa;
u32 rloc = 0x01002000; /* IO space; PCI device = 4 */
u32 isa_ranges[6];
char *name;
+ u32 node;
+ char prop[64];
+ int model;
+
+ /* FIXME: This may be used for more Maple targets not only ATCA6101. */
+ node = call_prom("finddevice", 1, 1, ADDR("/"));
+ model = prom_getprop(node, "model", prop, sizeof(prop));
+ if (model != PROM_ERROR && (strcmp(prop, "Motorola,ATCA-6101") == 0))
+ fixup_device_tree_atca6101();
name = "/ht@0/isa@4";
isa = call_prom("finddevice", 1, 1, ADDR(name));
--
1.5.6
^ permalink raw reply related
* Re: Has anyone debugged kernel 2.6.27 using KGDB?
From: Josh Boyer @ 2009-04-14 11:39 UTC (permalink / raw)
To: ���� ��; +Cc: linuxppc-dev
In-Reply-To: <BAY112-W200D1650425A8B738616C9A37C0@phx.gbl>
On Tue, Apr 14, 2009 at 07:51:18AM +0000, ���� �� wrote:
>
>Hi all.
>
>Has anyone tried to debug kernel 2.6.27 using KGDB?
>
>I'm now trying to use KGDB but I can't use it at all.
>
>I already red documents in kernel source about KGDB and I also know that KGDB is merged since 2.6.26.
>
>Absoultely I'm already done what I have to do in menuconfig like
>
>
>
>enable KGDB option
>
>enable tty serial
>
>enabel compile with .. and so on..
>
>
>
>I have embedded board that is target (PXA270, v2.6.27 android kernel) and development PC that is host(2.6.23)
That is an ARM based board. This is the PowerPC list. Perhaps you should find
a kgdb or ARM specific mailing list.
josh
^ permalink raw reply
* RE: Help!Some memory doesn't work on PPC405Ex based board!
From: SunNeo @ 2009-04-14 11:08 UTC (permalink / raw)
To: sr, linuxppc-dev
In-Reply-To: <200904141123.02495.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
Hi, Stefan,
Thanks for your help.
My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM is soldered on the board.
As I said, my board was similar with "Kilauea" evb, so I created my configuration header file from Kilauea's at U-Boot. In the configuration file, register value for the DDR SDRAM controller is defined. But I have removed DDR autocalibraton related configuration from the configuration file, do you think this will cause any issues?
I'm not sure what you mean about "intensive memory test". I use "mm" cmd under U-Boot command prompt to modify value of high 512M memory, and this command works well.
About booting Linux, the kernel hangs at the same location. Always after this print info "<4>Mount-cache hash table entries: 512".
Best Regards,
Sun
> From: sr@denx.de
> To: linuxppc-dev@ozlabs.org
> Subject: Re: Help!Some memory doesn't work on PPC405Ex based board!
> Date: Tue, 14 Apr 2009 11:23:02 +0200
> CC: sunwx2001@hotmail.com
>
> On Monday 13 April 2009, SunNeo wrote:
> > I'm porting Linux-2.6.29 on PPC405Ex based board, it's very similar to AMCC
> > "Kilauea" evb.
> >
> > In my board, two 512MB DDRII memory is connected to 2 ranks of the 405Ex
> > CPU. This 1GB memory works well at U-Boot-2009.01, but when I boot
> > Linux-2.6.29, the kernel hangs somewhere.
>
> Does it just hang "somewhere", or always at the same location? A random hangup
> could mean that you are having a memory problem (hardware, or wrong
> initialization).
>
> > What interesting is, if I
> > configured the system to use only 512MB memory at U-Boot, the Linux can
> > boot normally.
>
> Are you using DIMM's on your platform? Or soldered chips? Which memory
> initialization code are you using in U-Boot? And which autocalibration code?
>
> Did you do some intensive memory test?
>
> Best regards,
> Stefan
_________________________________________________________________
打工，挣钱，买房子，快来MClub一起”金屋藏娇”！
http://club.msn.cn/?from=10
[-- Attachment #2: Type: text/html, Size: 2469 bytes --]
^ permalink raw reply
* Re: [v1 PATCH 1/1] Fix 64bit Maple Host Bridge Address and Size Nodes
From: Tiejun Chen @ 2009-04-14 10:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, akpm
In-Reply-To: <3C36E383-13A3-49E9-B87B-D22D966B6F79@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
Segher,
Thank you very much for your review.
I already re-send this patch as you expect and please check this:
[v2 PATCH 1/1] Fix 64bit Maple Host Bridge 'reg' property
Best Regards
Tiejun
2009/4/14 Segher Boessenkool <segher@kernel.crashing.org>
> In the DTB tree created by firmware on some Maple 64bit targets, such as
>> ATCA6101,
>> these two properties, address&size, should be 2.
>>
>
> And they are.
>
> But the actual corresponding values
>> of host bridge node are set 1 incorrectly by the firmware, we have to
>> provide one
>> fixup function to fix that.
>>
>
> It is the "reg" property that is incorrectly encoded as-if
> #address-cells and #size-cells were 1.
>
> Please fix the commit message (and subject line).
>
> + name = "/hostbridge@f8000000";
>> + hb = call_prom("finddevice", 1, 1, ADDR(name));
>>
>
> It's interesting that the firmware can find your node this way,
> it won't match the "reg"! Looks like there is more than one
> bug in there.
>
> Code looks good,
>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
>
>
> Segher
>
>
[-- Attachment #2: Type: text/html, Size: 2117 bytes --]
^ permalink raw reply
* Re: alpha: half done futex implementation
From: Segher Boessenkool @ 2009-04-14 9:45 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Oliver Falk, linux-kernel, linuxppc-dev, Ivan Kokshaysky,
linux-alpha, Matt Turner, Jay Estabrook, Richard Henderson
In-Reply-To: <AE456C27-B568-4835-8843-F2A2E2D8FC32@kernel.crashing.org>
> If either the lwarx or the stwcx. faults, the routine returns -EFAULT
> and doesn't retry (label "3" is the end of the asm).
>
> If the stwcx. fails because the CPU lost the reservation, %1 isn't
> clobbered as far as I see?
Oh, "insn" writes to %1, never mind.
Segher
^ permalink raw reply
* Re: alpha: half done futex implementation
From: Segher Boessenkool @ 2009-04-14 9:40 UTC (permalink / raw)
To: Richard Henderson
Cc: Oliver Falk, linux-kernel, linuxppc-dev, Ivan Kokshaysky,
linux-alpha, Matt Turner, Jay Estabrook
In-Reply-To: <49E39F3D.4060501@twiddle.net>
> Also, there's a bug in the powerpc implementation. It appears that
> oparg is clobbered, and if stwcx fails the operation will be
> repeated with incorrect inputs.
If either the lwarx or the stwcx. faults, the routine returns -EFAULT
and doesn't retry (label "3" is the end of the asm).
If the stwcx. fails because the CPU lost the reservation, %1 isn't
clobbered as far as I see?
Segher
^ permalink raw reply
* Re: Help!Some memory doesn't work on PPC405Ex based board!
From: Stefan Roese @ 2009-04-14 9:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: SunNeo
In-Reply-To: <BAY114-W121B40A28E203154BC9209AB7F0@phx.gbl>
On Monday 13 April 2009, SunNeo wrote:
> I'm porting Linux-2.6.29 on PPC405Ex based board, it's very similar to AMCC
> "Kilauea" evb.
>
> In my board, two 512MB DDRII memory is connected to 2 ranks of the 405Ex
> CPU. This 1GB memory works well at U-Boot-2009.01, but when I boot
> Linux-2.6.29, the kernel hangs somewhere.
Does it just hang "somewhere", or always at the same location? A random hangup
could mean that you are having a memory problem (hardware, or wrong
initialization).
> What interesting is, if I
> configured the system to use only 512MB memory at U-Boot, the Linux can
> boot normally.
Are you using DIMM's on your platform? Or soldered chips? Which memory
initialization code are you using in U-Boot? And which autocalibration code?
Did you do some intensive memory test?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] therm_pm72: Convert to a new-style i2c driver
From: Jean Delvare @ 2009-04-14 8:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18915.50615.952282.915946@cargo.ozlabs.ibm.com>
Hi Paul,
On Tue, 14 Apr 2009 09:07:35 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
>
> > The legacy i2c binding model is going away soon, so convert the
> > macintosh therm_pm72 driver to the new model or it will break.
> >
> > This is really a quick and dirty conversion, that should do the trick
> > for now, but no doubt that something cleaner can be done if anyone is
> > interested.
> >
> > Signed-off-by: Jean Delvare <khali@linux-fr.org>
>
> Seems to work fine on my powermac7,2 machine (dual 2.0GHz G5).
Excellent, thanks a lot for the fast testing!
I'll try to convert the remaining powermac drivers by the end of the
week, but I wouldn't mind if somebody with more knowledge of these
drivers than me wants to help. Basically the remaining 5 drivers must
be converted the same way I did for the therm_pm72 driver.
--
Jean Delvare
^ permalink raw reply
* Re: [v1 PATCH 1/1] Fix 64bit Maple Host Bridge Address and Size Nodes
From: Segher Boessenkool @ 2009-04-14 8:11 UTC (permalink / raw)
To: tiejun.china; +Cc: linuxppc-dev, akpm
In-Reply-To: <1238755594-18869-2-git-send-email-tiejun.china@gmail.com>
> In the DTB tree created by firmware on some Maple 64bit targets,
> such as ATCA6101,
> these two properties, address&size, should be 2.
And they are.
> But the actual corresponding values
> of host bridge node are set 1 incorrectly by the firmware, we have
> to provide one
> fixup function to fix that.
It is the "reg" property that is incorrectly encoded as-if
#address-cells and #size-cells were 1.
Please fix the commit message (and subject line).
> + name = "/hostbridge@f8000000";
> + hb = call_prom("finddevice", 1, 1, ADDR(name));
It's interesting that the firmware can find your node this way,
it won't match the "reg"! Looks like there is more than one
bug in there.
Code looks good,
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Has anyone debugged kernel 2.6.27 using KGDB?
From: 재용 신 @ 2009-04-14 7:51 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
Hi all.
Has anyone tried to debug kernel 2.6.27 using KGDB?
I'm now trying to use KGDB but I can't use it at all.
I already red documents in kernel source about KGDB and I also know that KGDB is merged since 2.6.26.
Absoultely I'm already done what I have to do in menuconfig like
enable KGDB option
enable tty serial
enabel compile with .. and so on..
I have embedded board that is target (PXA270, v2.6.27 android kernel) and development PC that is host(2.6.23)
Is that a problem that I use lower version kernel in host system?
I attached boot parameter in menucofig as follow:
kgdbwait kgdb8250=ttyS0,115200
but When bootloader(BLOB) is loading kernel in embedded board, kernel never wait for host side' gdb signal.
Is there something I missed?
I'm now confused slightly. plz help me. o<-<
thanks in advance.
Sincerely
Shin Jaeyong.
_________________________________________________________________
Show them the way! Add maps and directions to your party invites.
http://www.microsoft.com/windows/windowslive/products/events.aspx
[-- Attachment #2: Type: text/html, Size: 1336 bytes --]
^ permalink raw reply
* [PATCH 1/1] Fix build failure drivers/parport/parport_pc.c for powerpc
From: Tony Breeds @ 2009-04-14 5:33 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev; +Cc: Alan Cox
In commit 51dcdfec6a274afc1c6fce180d582add9ff512c0 (parport: Use the PCI
IRQ if offered) parport_pc_probe_port() gained an irqflags arg. This
isn't being supplied on powerpc. This patch make powerpc fallback to
the old behaviour, that is using "0" for irqflags.
Fixes build failure:
In file included from drivers/parport/parport_pc.c:68:
arch/powerpc/include/asm/parport.h: In function 'parport_pc_find_nonpci_ports':
arch/powerpc/include/asm/parport.h:32: error: too few arguments to function 'parport_pc_probe_port'
arch/powerpc/include/asm/parport.h:32: error: too few arguments to function 'parport_pc_probe_port'
arch/powerpc/include/asm/parport.h:32: error: too few arguments to function 'parport_pc_probe_port'
make[3]: *** [drivers/parport/parport_pc.o] Error 1
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Resend due to MUA badness
arch/powerpc/include/asm/parport.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/parport.h b/arch/powerpc/include/asm/parport.h
index 414c50e..94942d6 100644
--- a/arch/powerpc/include/asm/parport.h
+++ b/arch/powerpc/include/asm/parport.h
@@ -29,7 +29,7 @@ static int __devinit parport_pc_find_nonpci_ports (int autoirq, int autodma)
prop = of_get_property(np, "interrupts", NULL);
if (!prop)
continue;
- if (parport_pc_probe_port(io1, io2, prop[0], autodma, NULL) != NULL)
+ if (parport_pc_probe_port(io1, io2, prop[0], autodma, NULL, 0) != NULL)
count++;
}
return count;
--
1.6.0.6
^ permalink raw reply related
* [PATCH] powerpc: VRM unused page hinting
From: Robert Jennings @ 2009-04-14 1:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Brian King, linuxppc-dev
Adds support for the "unused" page hint which can be used in shared
memory partitions to flag pages not in use, which will then be stolen
before active pages by the hypervisor when memory needs to be moved to
LPARs in need of additional memory. Failure to mark pages as 'unused'
makes the LPAR slower to give up unused memory to other partitions.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/page.h | 5 +++
arch/powerpc/platforms/pseries/lpar.c | 52 ++++++++++++++++++++++++++++++++++
2 files changed, 57 insertions(+)
Index: b/arch/powerpc/include/asm/page.h
===================================================================
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -231,6 +231,11 @@ extern void copy_user_page(void *to, voi
struct page *p);
extern int page_is_ram(unsigned long pfn);
+#ifdef CONFIG_PPC_SMLPAR
+void arch_free_page(struct page *page, int order);
+#define HAVE_ARCH_FREE_PAGE
+#endif
+
struct vm_area_struct;
typedef struct page *pgtable_t;
Index: b/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -609,3 +609,55 @@ void __init hpte_init_lpar(void)
ppc_md.flush_hash_range = pSeries_lpar_flush_hash_range;
ppc_md.hpte_clear_all = pSeries_lpar_hptab_clear;
}
+
+#ifdef CONFIG_PPC_SMLPAR
+#define CMMA_DEFAULT 1
+static int cmma_flag = CMMA_DEFAULT;
+
+static int __init cmma(char *str)
+{
+ char *parm;
+ parm = strstrip(str);
+
+ if (strcasecmp(parm, "no") == 0 || strcasecmp(parm, "off") == 0) {
+ printk(KERN_INFO "cmma: page marking is not active.\n");
+ cmma_flag = 0;
+ return 1;
+ }
+
+ cmma_flag = 1;
+ printk(KERN_INFO "cmma: page marking is active.\n");
+
+ if (strcasecmp(parm, "yes") == 0 || strcasecmp(parm, "on") == 0)
+ return 1;
+
+ return 0;
+}
+
+__setup("cmma=", cmma);
+
+static void pSeries_set_page_state(struct page *page, int order,
+ unsigned long state)
+{
+ int i, j;
+ unsigned long cmo_page_sz, addr;
+
+ cmo_page_sz = cmo_get_page_size();
+ addr = __pa((unsigned long)page_address(page));
+
+ for (i = 0; i < (1 << order); i++, addr += PAGE_SIZE) {
+ for (j = 0; j < PAGE_SIZE; j += cmo_page_sz)
+ plpar_hcall_norets(H_PAGE_INIT, state, addr + j, 0);
+ }
+}
+
+void arch_free_page(struct page *page, int order)
+{
+ if (!cmma_flag || !firmware_has_feature(FW_FEATURE_CMO))
+ return;
+
+ pSeries_set_page_state(page, order, H_PAGE_SET_UNUSED);
+}
+EXPORT_SYMBOL(arch_free_page);
+
+#endif
^ permalink raw reply
* [PATCH] powerpc: Fix bug in __futex_atomic_op
From: Paul Mackerras @ 2009-04-14 0:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Richard Henderson
Richard Henderson pointed out that the powerpc __futex_atomic_op has a
bug: it will write the wrong value if the stwcx. fails and it has to
retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten
by the result from the first time around the loop. This happens
because it uses the same register for 'oparg' (an input) as it uses
for the result.
This fixes it by using separate registers for 'oparg' and 'ret'.
Cc: stable@kernel.org
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Can anyone see any reason why the FUTEX_OP_SET case can't just do a
__put_user?
diff --git a/arch/powerpc/include/asm/futex.h b/arch/powerpc/include/asm/futex.h
index 6d406c5..9696cc3 100644
--- a/arch/powerpc/include/asm/futex.h
+++ b/arch/powerpc/include/asm/futex.h
@@ -27,7 +27,7 @@
PPC_LONG "1b,4b,2b,4b\n" \
".previous" \
: "=&r" (oldval), "=&r" (ret) \
- : "b" (uaddr), "i" (-EFAULT), "1" (oparg) \
+ : "b" (uaddr), "i" (-EFAULT), "r" (oparg) \
: "cr0", "memory")
static inline int futex_atomic_op_inuser (int encoded_op, int __user *uaddr)
@@ -47,19 +47,19 @@ static inline int futex_atomic_op_inuser (int encoded_op, int __user *uaddr)
switch (op) {
case FUTEX_OP_SET:
- __futex_atomic_op("", ret, oldval, uaddr, oparg);
+ __futex_atomic_op("mr %1,%4\n", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_ADD:
- __futex_atomic_op("add %1,%0,%1\n", ret, oldval, uaddr, oparg);
+ __futex_atomic_op("add %1,%0,%4\n", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_OR:
- __futex_atomic_op("or %1,%0,%1\n", ret, oldval, uaddr, oparg);
+ __futex_atomic_op("or %1,%0,%4\n", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_ANDN:
- __futex_atomic_op("andc %1,%0,%1\n", ret, oldval, uaddr, oparg);
+ __futex_atomic_op("andc %1,%0,%4\n", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_XOR:
- __futex_atomic_op("xor %1,%0,%1\n", ret, oldval, uaddr, oparg);
+ __futex_atomic_op("xor %1,%0,%4\n", ret, oldval, uaddr, oparg);
break;
default:
ret = -ENOSYS;
^ permalink raw reply related
* Re: [PATCH] therm_pm72: Convert to a new-style i2c driver
From: Paul Mackerras @ 2009-04-13 23:07 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev
In-Reply-To: <20090413160927.3b8675b8@hyperion.delvare>
Jean Delvare writes:
> The legacy i2c binding model is going away soon, so convert the
> macintosh therm_pm72 driver to the new model or it will break.
>
> This is really a quick and dirty conversion, that should do the trick
> for now, but no doubt that something cleaner can be done if anyone is
> interested.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Seems to work fine on my powermac7,2 machine (dual 2.0GHz G5).
Tested-by: Paul Mackerras <paulus@samba.org>
Paul.
^ permalink raw reply
* Re: alpha: half done futex implementation
From: Richard Henderson @ 2009-04-13 22:20 UTC (permalink / raw)
To: Andreas Schwab
Cc: Oliver Falk, linux-kernel, linuxppc-dev, Ivan Kokshaysky,
linux-alpha, Matt Turner, Jay Estabrook
In-Reply-To: <m263h8i5id.fsf@igel.home>
Andreas Schwab wrote:
> Richard Henderson <rth@twiddle.net> writes:
>
>> switch (op) {
>> case FUTEX_OP_SET:
>> __futex_atomic_op("mov %0,%1", ret, oldval, uaddr, oparg);
>
> That should probably be "mov %4,%1\n"?
You're right.
r~
^ permalink raw reply
* Re: alpha: half done futex implementation
From: Andreas Schwab @ 2009-04-13 21:54 UTC (permalink / raw)
To: Richard Henderson
Cc: Oliver Falk, linux-kernel, linuxppc-dev, Ivan Kokshaysky,
linux-alpha, Matt Turner, Jay Estabrook
In-Reply-To: <49E39F3D.4060501@twiddle.net>
Richard Henderson <rth@twiddle.net> writes:
> switch (op) {
> case FUTEX_OP_SET:
> __futex_atomic_op("mov %0,%1", ret, oldval, uaddr, oparg);
That should probably be "mov %4,%1\n"?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: alpha: half done futex implementation
From: Richard Henderson @ 2009-04-13 20:23 UTC (permalink / raw)
To: Matt Turner
Cc: Oliver Falk, linux-kernel, linuxppc-dev, Ivan Kokshaysky,
linux-alpha, Jay Estabrook
In-Reply-To: <b4198de60904111755u5c2078c7xcc689dbd78aeb957@mail.gmail.com>
Matt Turner wrote:
> Hi,
>
> Going on Richard's advice, I've tried to write an alpha futex
> implementation based on the powerpc futex.h.
>
> I've gotten this far.. :\
>
#define __futex_atomic_op(insn, ret, oldval, uaddr, oparg) \
__asm__ __volatile( \
__ASM_MB \
"1: ldl_l %0,0(%3)\n" \
insn \
"2: stl_c %1,0(%3)\n" \
" beq %1,4f\n" \
" mov $31,%1\n" \
"3: .subsection 2\n" \
"4: br 1b\n" \
" .previous\n" \
".section __ex_table,\"a\"\n" \
" .long 1b-.\n" \
" lda %0,3b-1b(%2)\n" \
" .long 2b-.\n" \
" lda %0,3b-2b(%2)\n" \
" .previous\n" \
: "=&r" (oldval), "=&r"(ret) \
: "r" (uaddr), "r"(oparg) \
: "memory")
switch (op) {
case FUTEX_OP_SET:
__futex_atomic_op("mov %0,%1", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_ADD:
__futex_atomic_op("addl %0,%4,%1\n", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_OR:
__futex_atomic_op("or %0,%4,%1\n", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_ANDN:
__futex_atomic_op("andnot %0,%4,%1\n", ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_XOR:
__futex_atomic_op("xor %0,%4,%1\n", ret, oldval, uaddr, oparg);
break;
default:
ret = -ENOSYS;
}
Also, there's a bug in the powerpc implementation. It appears that
oparg is clobbered, and if stwcx fails the operation will be repeated
with incorrect inputs.
r~
^ 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