* Re: AMCC 440EP phy detection
From: Stefan Roese @ 2009-04-08 18:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Eddie Dawydiuk
In-Reply-To: <fa686aa40904081000x2dbdd417y149fe442b9fc55bf@mail.gmail.com>
On Wednesday 08 April 2009, Grant Likely wrote:
> >> I would like to eventually submit our changes for upstream support.
> >> Based on this would you recommend ensuring tx enable is configured
> >> properly in the initialization of the ibm_newemac driver or the platform
> >> initialization?
> >
> > This GPIO multiplexing configuration does not belong into the ibm_newemac
> > driver since it is very platform/board specific. The platform code is
> > definitely a better place.
>
> Even better is the platform specific boot code (firmware or equivalent)
Ack. We usually do all this setup in U-Boot. But as I understand Eddie, he is
using a custom bootloader.
Eddie, btw: Why are you not using U-Boot?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Kumar Gala @ 2009-04-08 17:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <20090408170348.GA27578@ld0162-tx32.am.freescale.net>
On Apr 8, 2009, at 12:03 PM, Scott Wood wrote:
> On Wed, Apr 08, 2009 at 12:22:29AM -0500, Kumar Gala wrote:
>>> hrummm. As I mentioned in my reply, I'm not convinced that the
>>> board
>>> one is the right thing in this case. I would have preferred it to
>>> be
>>> deferred.
>>
>> which part? I missed this whole thread as I had it forwarding to my
>> devicetree-discuss folder which I don't normally look at.
>
> Can you reorder your filters to check for more frequently read lists
> first?
Yeah I did.
- k
^ permalink raw reply
* Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Johannes Berg @ 2009-04-08 15:51 UTC (permalink / raw)
To: Jean Delvare; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <20090408150249.5a62a56c@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 4981 bytes --]
Hi!
> Basically the idea is to move the I2C device instantiation from the
> codec drivers (onyx, tas) to the I2C adapter driver (i2c-powermac.)
> This follows the Linux device driver model, requires slightly less
> code, runs faster and and lets the required chip drivers be loaded by
> udev or similar automatically.
Sounds weird -- how do you handle codecs that could be on different
buses? This seems to imply that any probing may potentially need to be
duplicated across any bus driver they could possibly connected to. But
that's not really relevant to this patch.
> The last driver to convert, keywest, is a mystery to me. I have a hard
> time understanding how it interacts with tumbler and daca. I have the
> feeling that it is essentially a glue module to workaround the legacy
> i2c model limitations, so probably it could go away entirely now, but
> I'm not sure how to do that in practice. Maybe tumbler and daca would
> be made separate i2c drivers, I'm not sure.
Sorry, I'm not familiar with this code.
> One thing in particular which I find strange is that tumbler has
> references to the TAS3004 device, much like the tas codec driver. It is
> unclear to me whether tas is a replacement for tumbler, or if both
> drivers work together, or if they are for separate hardware. I would
> appreciate clarifications about this.
Well... tumbler also drives the very similar tas3001 codec.
However, I need to start with a little more background.
Apple machines can contain various codecs, for example the tas3004,
which has various outputs. Due to the way Apple wires up the codec, you
need platform fabric to identify which outputs are connected where, cf.
sound/aoa/fabrics/layout.c. Note all machines have line-in for instance.
The aoa driver, which I wrote, currently supports only i2s buses for
actually transferring data, but I think there are some other ways to get
data to the codec -- I'm not too familiar with the old machines.
Now, aoa will currently automatically load from the layout fabric
module, and then pull in the modules for the codecs it _knows_ to be
present on the bus. Therefore, it seems that your patch makes things
less efficient because you probe for all those codecs, and there's no
machine that has all of them. The aoa fabric only loads the modules for
those it knows to be present, and they then probe (and in reality the
probing never fails because they really are there).
Now, since aoa needs information on how the entire system is glued
together (the fabric I was talking about with the line-in example), it
has to infer that from platform data, in this case the device tree.
Because I do not have any older machines, am lazy and snd-powermac works
for the old machines, snd-powermac with its "tumbler" is a driver for
the same tas3004 codec, but on a different, older, fabric.
Once upon a time the plan was to get rid of snd-powermac entirely and
port all its functionality into subdrivers of aoa, but that clearly
never happened. No fairy-tale happy ending here, quite obviously.
Now, looking at your patch, I think it will break snd-powermac. See, if
snd_aoa_codec_tas is automatically loaded on a system with an _old_
fabric that aoa knows nothing about, snd-powermac can no longer be
loaded. (Incidentally, snd-powermac cannot be auto-loaded at all
currently, while aoa can via the fabric driver's device-tree binding)
Therefore, probing the codecs in i2c-powermac and automatically loading
the corresponding aoa module will break sound on old machines.
I would think that if you removed the MODULE_DEVICE_TABLE from your
patch, it may continue to work because the aoa fabric driver loads the
modules as before, and on old machines nothing loads automatically and
snd-powermac can be loaded manually.
However, it will still be less efficient because you will be probing
_all_ those codecs, notably the tas family, even on machines that are
known to not have it (machines that have onyx). Putting that mutual
exclusion information into i2c-powermac would be misplaced, imho.
Note also that there's one more codec (topaz) which isn't currently
supported.
In conclusion, I think that the old/existing/legacy i2c binding model
was much better suited to platform knowledge about the way machines are
put together, and the new code is, as far as I can tell, less efficient
-- contrary to your assertion.
Since I'm away from all machines I could test this with I have no data
on any that or the module device table thing I pointed out for now.
Anyway, some more technical comments on your patch:
* I realise you just copied things around but it would be nice to clean
up the coding style, especially comment style, a little while at it.
(yeah, it's my fault)
* aoa_codec_* is the module name, I see no reason to use that as the
i2c name, that should be the codec's name instead (aka pcm3052 etc)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Scott Wood @ 2009-04-08 17:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <5FDB097C-7D71-41DF-A4F4-2DE34FD710C5@kernel.crashing.org>
On Wed, Apr 08, 2009 at 12:22:29AM -0500, Kumar Gala wrote:
> >hrummm. As I mentioned in my reply, I'm not convinced that the board
> >one is the right thing in this case. I would have preferred it to be
> >deferred.
>
> which part? I missed this whole thread as I had it forwarding to my
> devicetree-discuss folder which I don't normally look at.
Can you reorder your filters to check for more frequently read lists
first?
-Scott
^ permalink raw reply
* Re: AMCC 440EP phy detection
From: Grant Likely @ 2009-04-08 17:00 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Eddie Dawydiuk
In-Reply-To: <200904081801.27754.sr@denx.de>
On Wed, Apr 8, 2009 at 9:01 AM, Stefan Roese <sr@denx.de> wrote:
> On Wednesday 08 April 2009, Eddie Dawydiuk wrote:
>> > I found the ibm_newemac driver(2.6.29) makes the assumption that the
>> > bootloader has already configured the tx enable pin as it is a
>> > multiplexed pin. Unfortuantley I am not using U-Boot and our minimal
>> > bootloader does not do this. =A0After finding tx enable was never
>> > asserting for Eth0 a quick user space program verified tx enable was
>> > configured as a GPIO pin.
>>
>> I would like to eventually submit our changes for upstream support. Base=
d
>> on this would you recommend ensuring tx enable is configured properly in
>> the initialization of the ibm_newemac driver or the platform
>> initialization?
>
> This GPIO multiplexing configuration does not belong into the ibm_newemac
> driver since it is very platform/board specific. The platform code is
> definitely a better place.
Even better is the platform specific boot code (firmware or equivalent)
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: AMCC 440EP phy detection
From: Stefan Roese @ 2009-04-08 16:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Eddie Dawydiuk
In-Reply-To: <49DCC6FA.1050708@embeddedarm.com>
On Wednesday 08 April 2009, Eddie Dawydiuk wrote:
> > I found the ibm_newemac driver(2.6.29) makes the assumption that the
> > bootloader has already configured the tx enable pin as it is a
> > multiplexed pin. Unfortuantley I am not using U-Boot and our minimal
> > bootloader does not do this. After finding tx enable was never
> > asserting for Eth0 a quick user space program verified tx enable was
> > configured as a GPIO pin.
>
> I would like to eventually submit our changes for upstream support. Based
> on this would you recommend ensuring tx enable is configured properly in
> the initialization of the ibm_newemac driver or the platform
> initialization?
This GPIO multiplexing configuration does not belong into the ibm_newemac
driver since it is very platform/board specific. The platform code is
definitely a better place.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: any place to mark various compatible strings as deprecated?
From: Olof Johansson @ 2009-04-08 16:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linux/PPC Development
In-Reply-To: <BAE2DC43-2222-4353-BFA7-91A25ACD280F@kernel.crashing.org>
On Wed, Apr 08, 2009 at 10:21:54AM -0500, Kumar Gala wrote:
>
> On Apr 8, 2009, at 9:48 AM, Olof Johansson wrote:
>
>> On Wed, Apr 08, 2009 at 09:23:22AM -0500, Kumar Gala wrote:
>>> Do we have anywhere to list out compatible strings that are
>>> deprecated
>>> and warn if the kernel sees one?
>>
>> Wouldn't dtc be a better location for that? The kernel has to be
>> backwards
>> compatible anyway, I don't really see a reason to warn there.
>
> The reason is I want to eventually drop support in the kernel for some
> of the old compatibles.
If it's something that shipped then I don't see how you can ever
do that. Best thing you can do is do fixups like prom_init does and
translate them to the preferred compatible string of the week.
-Olof
^ permalink raw reply
* Re: any place to mark various compatible strings as deprecated?
From: David Gibson @ 2009-04-08 15:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: Linux/PPC Development
In-Reply-To: <20090408144845.GA29163@lixom.net>
On Wed, Apr 08, 2009 at 09:48:45AM -0500, Olof Johansson wrote:
> On Wed, Apr 08, 2009 at 09:23:22AM -0500, Kumar Gala wrote:
> > Do we have anywhere to list out compatible strings that are deprecated
> > and warn if the kernel sees one?
>
> Wouldn't dtc be a better location for that? The kernel has to be backwards
> compatible anyway, I don't really see a reason to warn there.
It should certainly be in dtc. Whether it should also be in the
kernel is debatable. It's also really easy to add this to dtc. Kumar
can you point me at the ones you're thinking of, and I'll add
appropriate checks to dtc (although probably not for a couple of weeks
when I return from vacation).
--
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: AMCC 440EP phy detection
From: Eddie Dawydiuk @ 2009-04-08 15:47 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <49DBEB8F.2040307@embeddedarm.com>
Hello,
> I found the ibm_newemac driver(2.6.29) makes the assumption that the
> bootloader has already configured the tx enable pin as it is a
> multiplexed pin. Unfortuantley I am not using U-Boot and our minimal
> bootloader does not do this. After finding tx enable was never
> asserting for Eth0 a quick user space program verified tx enable was
> configured as a GPIO pin.
I would like to eventually submit our changes for upstream support. Based on
this would you recommend ensuring tx enable is configured properly in the
initialization of the ibm_newemac driver or the platform initialization?
>> On Tue, Apr 7, 2009 at 9:32 AM, Eddie Dawydiuk <eddie@embeddedarm.com>
>> wrote:
>>> Hello,
>>>
>>> I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm
>>> having some difficulty getting both network interfaces working. The
>>> first
>>> problem I found is the ibm_newemac driver was detecting the two phys at
>>> address 0 and 1 where we have them wired for addresses 1 and 3. As a
>>> result
>>> I hardcoded the phy-address in the dts file. I then found I was able to
>>> receive and send data on eth1(phy-address 3) without incident.
>>> Although I
>>> found eth0 can receive data but I see no packets being
>>> transmitted(using a
>>> packet sniffer) and I see no indication from a software standpoint of
>>> any
>>> transmit failures. We are using Micrel KSZ8041FTL phys(RMII mode)
>>> where the
>>> Yosemite board used Micrel KS8721BL phys. I've reviewed the
>>> schematic and
>>> it appears both phys are connected identically and I've seen this same
>>> failure on multiple boards. I thought the fact that the driver
>>> detected a
>>> phy at address 0 might be a clue, but I can't make much of the clue.
>>> So I
>>> thought I'd post this info in the hopes someone else might have run
>>> into a
>>> similar problem or have a suggestion.
>>
>> Phy address 0 is the broadcast address. All phys will usually respond
>> to address 0 accesses. Off the top of my head, It sounds like one PHY
>> is responding to addresses 0 & 1, and the other phy isn't responding
>> at all.
>>
>> g.
>>
>
>
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
^ permalink raw reply
* Re: any place to mark various compatible strings as deprecated?
From: Kumar Gala @ 2009-04-08 15:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: Linux/PPC Development
In-Reply-To: <20090408144845.GA29163@lixom.net>
On Apr 8, 2009, at 9:48 AM, Olof Johansson wrote:
> On Wed, Apr 08, 2009 at 09:23:22AM -0500, Kumar Gala wrote:
>> Do we have anywhere to list out compatible strings that are
>> deprecated
>> and warn if the kernel sees one?
>
> Wouldn't dtc be a better location for that? The kernel has to be
> backwards
> compatible anyway, I don't really see a reason to warn there.
The reason is I want to eventually drop support in the kernel for some
of the old compatibles.
- k
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Kumar Gala @ 2009-04-08 15:21 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Linux/PPC Development, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <49DC515F.3040100@grandegger.com>
On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
>> So I'm a bit concerned with the output we now get:
>>
>> mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)
>>
>> why 0? is that right?
>
> This is the backward compatibility mode using hard-coded FDR values.
> The
> output is missleading, I agree.
>
> Wolfgang.
Can the output be fixed. 0 Hz seemed bad to me.
- k
^ permalink raw reply
* Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
From: Grant Likely @ 2009-04-08 14:53 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <49DC4F4D.10803@grandegger.com>
On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> Grant Likely wrote:
>> On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger <wg@grandegger.com> =
wrote:
>>> Preserve I2C clock settings for the Socrates MPC8544 board.
>>
>> I had thought that the preserve-clocking property was intended for
>> older boards that don't currently have any method of getting the clock
>> setting out of u-boot. =A0Since Socrates is a new board, U-Boot should
>> probably be made to fill in the real clock rate setting.
>
> I'm not sure if I understand what you mean. If an old version of U-Boot
> on an old board sets the I2C clock, it can be used (inherited) by Linux
> using the property "preserve-clocking".
>
> It is actually the customers choice to set the I2C clock in U-Boot and
> re-use it by Linux.
Setting it in the register !=3D recording the value in the device tree.
I'm saying that since Socrates is a new board it should not use the
preserve-clocking dirty trick (and it is a dirty trick) because the
correct clocking data can be passed via the device tree.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: any place to mark various compatible strings as deprecated?
From: Olof Johansson @ 2009-04-08 14:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linux/PPC Development
In-Reply-To: <84DDF2F3-F907-4131-8C41-A9156BD5ADB2@kernel.crashing.org>
On Wed, Apr 08, 2009 at 09:23:22AM -0500, Kumar Gala wrote:
> Do we have anywhere to list out compatible strings that are deprecated
> and warn if the kernel sees one?
Wouldn't dtc be a better location for that? The kernel has to be backwards
compatible anyway, I don't really see a reason to warn there.
-Olof
^ permalink raw reply
* any place to mark various compatible strings as deprecated?
From: Kumar Gala @ 2009-04-08 14:23 UTC (permalink / raw)
To: Linux/PPC Development
Do we have anywhere to list out compatible strings that are deprecated
and warn if the kernel sees one?
- k
^ permalink raw reply
* [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
From: Jean Delvare @ 2009-04-08 13:02 UTC (permalink / raw)
To: linuxppc-dev, Johannes Berg; +Cc: Takashi Iwai, alsa-devel
Hi all,
The legacy i2c model is going away soon, the remaining drivers that
still use it need to be converted very quickly. There are 3 sound
drivers remaining:
sound/aoa/codecs/onyx.c
sound/aoa/codecs/tas.c
sound/ppc/keywest.c
I've given a try to the former two, patch below. I could only
build-test it, so I would appreciate if anyone with supported hardware
could test the patch. I also welcome reviews and comments, of course. I
am not familiar with PowerPC so I might as well have done it wrong.
Basically the idea is to move the I2C device instantiation from the
codec drivers (onyx, tas) to the I2C adapter driver (i2c-powermac.)
This follows the Linux device driver model, requires slightly less
code, runs faster and and lets the required chip drivers be loaded by
udev or similar automatically.
The last driver to convert, keywest, is a mystery to me. I have a hard
time understanding how it interacts with tumbler and daca. I have the
feeling that it is essentially a glue module to workaround the legacy
i2c model limitations, so probably it could go away entirely now, but
I'm not sure how to do that in practice. Maybe tumbler and daca would
be made separate i2c drivers, I'm not sure.
One thing in particular which I find strange is that tumbler has
references to the TAS3004 device, much like the tas codec driver. It is
unclear to me whether tas is a replacement for tumbler, or if both
drivers work together, or if they are for separate hardware. I would
appreciate clarifications about this.
Thanks.
* * * * *
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>
---
drivers/i2c/busses/i2c-powermac.c | 76 +++++++++++++++++++++++++++++++
sound/aoa/codecs/onyx.c | 77 +++++++-------------------------
sound/aoa/codecs/tas.c | 89 +++++++++----------------------------
3 files changed, 116 insertions(+), 126 deletions(-)
--- linux-2.6.30-rc1.orig/drivers/i2c/busses/i2c-powermac.c 2009-04-08 08:52:48.000000000 +0200
+++ linux-2.6.30-rc1/drivers/i2c/busses/i2c-powermac.c 2009-04-08 13:48:31.000000000 +0200
@@ -204,7 +204,7 @@ static int __devexit i2c_powermac_remove
static int __devinit i2c_powermac_probe(struct platform_device *dev)
{
struct pmac_i2c_bus *bus = dev->dev.platform_data;
- struct device_node *parent = NULL;
+ struct device_node *parent = NULL, *busnode, *devnode;
struct i2c_adapter *adapter;
char name[32];
const char *basename;
@@ -212,6 +212,7 @@ static int __devinit i2c_powermac_probe(
if (bus == NULL)
return -EINVAL;
+ busnode = pmac_i2c_get_bus_node(bus);
/* Ok, now we need to make up a name for the interface that will
* match what we used to do in the past, that is basically the
@@ -289,6 +290,79 @@ static int __devinit i2c_powermac_probe(
}
}
+ devnode = NULL;
+ while ((devnode = of_get_next_child(busnode, devnode)) != NULL) {
+ struct i2c_board_info info;
+ const u32 *addr;
+
+ /* Instantiate I2C sound device if present */
+ if (of_device_is_compatible(devnode, "pcm3052")) {
+ printk(KERN_DEBUG "i2c-powermac: found pcm3052\n");
+ addr = of_get_property(devnode, "reg", NULL);
+ if (!addr)
+ continue;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ info.addr = (*addr) >> 1;
+ strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
+ info.platform_data = devnode;
+ i2c_new_device(adapter, &info);
+ continue;
+ }
+
+ if (of_device_is_compatible(devnode, "tas3004")) {
+ printk(KERN_DEBUG "i2c-powermac: found tas3004\n");
+ addr = of_get_property(devnode, "reg", NULL);
+ if (!addr)
+ continue;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ info.addr = ((*addr) >> 1) & 0x7f;
+ strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE);
+ info.platform_data = devnode;
+ i2c_new_device(adapter, &info);
+ continue;
+ }
+
+ /* older machines have no 'codec' node with a 'compatible'
+ * property that says 'tas3004', they just have a 'deq'
+ * node without any such property... */
+ if (strcmp(devnode->name, "deq") == 0) {
+ printk(KERN_DEBUG "i2c-powermac: found 'deq' node\n");
+ addr = of_get_property(devnode, "i2c-address", NULL);
+ if (!addr)
+ continue;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ info.addr = ((*addr) >> 1) & 0x7f;
+ /* now, if the address doesn't match any of the two
+ * that a tas3004 can have, we cannot handle this.
+ * I doubt it ever happens but hey. */
+ if (info.addr != 0x34 && info.addr != 0x35)
+ continue;
+ strlcpy(info.type, "aoa_codec_tas", I2C_NAME_SIZE);
+ info.platform_data = devnode;
+ i2c_new_device(adapter, &info);
+ continue;
+ }
+
+ /* if that didn't work, try desperate mode for older
+ * machines that have stuff missing from the device tree */
+ if (of_device_is_compatible(busnode, "k2-i2c")) {
+ unsigned short probe_onyx[] = {
+ 0x46, 0x47, I2C_CLIENT_END
+ };
+
+ printk(KERN_DEBUG "i2c-powermac: found k2-i2c, "
+ "checking if onyx chip is on it\n");
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "aoa_codec_onyx", I2C_NAME_SIZE);
+ info.platform_data = devnode;
+ i2c_new_probed_device(adapter, &info, probe_onyx);
+ }
+ }
+
return rc;
}
--- linux-2.6.30-rc1.orig/sound/aoa/codecs/onyx.c 2009-03-26 15:08:13.000000000 +0100
+++ linux-2.6.30-rc1/sound/aoa/codecs/onyx.c 2009-04-08 13:50:11.000000000 +0200
@@ -47,7 +47,7 @@ MODULE_DESCRIPTION("pcm3052 (onyx) codec
struct onyx {
/* cache registers 65 to 80, they are write-only! */
u8 cache[16];
- struct i2c_client i2c;
+ struct i2c_client *i2c;
struct aoa_codec codec;
u32 initialised:1,
spdif_locked:1,
@@ -72,7 +72,7 @@ static int onyx_read_register(struct ony
*value = onyx->cache[reg-FIRSTREGISTER];
return 0;
}
- v = i2c_smbus_read_byte_data(&onyx->i2c, reg);
+ v = i2c_smbus_read_byte_data(onyx->i2c, reg);
if (v < 0)
return -1;
*value = (u8)v;
@@ -84,7 +84,7 @@ static int onyx_write_register(struct on
{
int result;
- result = i2c_smbus_write_byte_data(&onyx->i2c, reg, value);
+ result = i2c_smbus_write_byte_data(onyx->i2c, reg, value);
if (!result)
onyx->cache[reg-FIRSTREGISTER] = value;
return result;
@@ -998,10 +998,10 @@ static void onyx_exit_codec(struct aoa_c
static struct i2c_driver onyx_driver;
-static int onyx_create(struct i2c_adapter *adapter,
- struct device_node *node,
- int addr)
+static int onyx_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
{
+ struct device_node *node = client->dev.platform_data;
struct onyx *onyx;
u8 dummy;
@@ -1011,20 +1011,12 @@ static int onyx_create(struct i2c_adapte
return -ENOMEM;
mutex_init(&onyx->mutex);
- onyx->i2c.driver = &onyx_driver;
- onyx->i2c.adapter = adapter;
- onyx->i2c.addr = addr & 0x7f;
- strlcpy(onyx->i2c.name, "onyx audio codec", I2C_NAME_SIZE);
-
- if (i2c_attach_client(&onyx->i2c)) {
- printk(KERN_ERR PFX "failed to attach to i2c\n");
- goto fail;
- }
+ onyx->i2c = client;
+ i2c_set_clientdata(client, onyx);
/* we try to read from register ONYX_REG_CONTROL
* to check if the codec is present */
if (onyx_read_register(onyx, ONYX_REG_CONTROL, &dummy) != 0) {
- i2c_detach_client(&onyx->i2c);
printk(KERN_ERR PFX "failed to read control register\n");
goto fail;
}
@@ -1036,7 +1028,6 @@ static int onyx_create(struct i2c_adapte
onyx->codec.node = of_node_get(node);
if (aoa_codec_register(&onyx->codec)) {
- i2c_detach_client(&onyx->i2c);
goto fail;
}
printk(KERN_DEBUG PFX "created and attached onyx instance\n");
@@ -1046,47 +1037,10 @@ static int onyx_create(struct i2c_adapte
return -EINVAL;
}
-static int onyx_i2c_attach(struct i2c_adapter *adapter)
+static int onyx_i2c_remove(struct i2c_client *client)
{
- struct device_node *busnode, *dev = NULL;
- struct pmac_i2c_bus *bus;
-
- bus = pmac_i2c_adapter_to_bus(adapter);
- if (bus == NULL)
- return -ENODEV;
- busnode = pmac_i2c_get_bus_node(bus);
+ struct onyx *onyx = i2c_get_clientdata(client);
- while ((dev = of_get_next_child(busnode, dev)) != NULL) {
- if (of_device_is_compatible(dev, "pcm3052")) {
- const u32 *addr;
- printk(KERN_DEBUG PFX "found pcm3052\n");
- addr = of_get_property(dev, "reg", NULL);
- if (!addr)
- return -ENODEV;
- return onyx_create(adapter, dev, (*addr)>>1);
- }
- }
-
- /* if that didn't work, try desperate mode for older
- * machines that have stuff missing from the device tree */
-
- if (!of_device_is_compatible(busnode, "k2-i2c"))
- return -ENODEV;
-
- printk(KERN_DEBUG PFX "found k2-i2c, checking if onyx chip is on it\n");
- /* probe both possible addresses for the onyx chip */
- if (onyx_create(adapter, NULL, 0x46) == 0)
- return 0;
- return onyx_create(adapter, NULL, 0x47);
-}
-
-static int onyx_i2c_detach(struct i2c_client *client)
-{
- struct onyx *onyx = container_of(client, struct onyx, i2c);
- int err;
-
- if ((err = i2c_detach_client(client)))
- return err;
aoa_codec_unregister(&onyx->codec);
of_node_put(onyx->codec.node);
if (onyx->codec_info)
@@ -1095,13 +1049,20 @@ static int onyx_i2c_detach(struct i2c_cl
return 0;
}
+static const struct i2c_device_id onyx_i2c_id[] = {
+ { "aoa_codec_onyx", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, onyx_i2c_id);
+
static struct i2c_driver onyx_driver = {
.driver = {
.name = "aoa_codec_onyx",
.owner = THIS_MODULE,
},
- .attach_adapter = onyx_i2c_attach,
- .detach_client = onyx_i2c_detach,
+ .probe = onyx_i2c_probe,
+ .remove = onyx_i2c_remove,
+ .id_table = onyx_i2c_id,
};
static int __init onyx_init(void)
--- linux-2.6.30-rc1.orig/sound/aoa/codecs/tas.c 2009-03-24 13:44:06.000000000 +0100
+++ linux-2.6.30-rc1/sound/aoa/codecs/tas.c 2009-04-08 13:50:22.000000000 +0200
@@ -82,7 +82,7 @@ MODULE_DESCRIPTION("tas codec driver for
struct tas {
struct aoa_codec codec;
- struct i2c_client i2c;
+ struct i2c_client *i2c;
u32 mute_l:1, mute_r:1 ,
controls_created:1 ,
drc_enabled:1,
@@ -108,9 +108,9 @@ static struct tas *codec_to_tas(struct a
static inline int tas_write_reg(struct tas *tas, u8 reg, u8 len, u8 *data)
{
if (len == 1)
- return i2c_smbus_write_byte_data(&tas->i2c, reg, *data);
+ return i2c_smbus_write_byte_data(tas->i2c, reg, *data);
else
- return i2c_smbus_write_i2c_block_data(&tas->i2c, reg, len, data);
+ return i2c_smbus_write_i2c_block_data(tas->i2c, reg, len, data);
}
static void tas3004_set_drc(struct tas *tas)
@@ -884,10 +884,10 @@ static void tas_exit_codec(struct aoa_co
static struct i2c_driver tas_driver;
-static int tas_create(struct i2c_adapter *adapter,
- struct device_node *node,
- int addr)
+static int tas_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
{
+ struct device_node *node = client->dev.platform_data;
struct tas *tas;
tas = kzalloc(sizeof(struct tas), GFP_KERNEL);
@@ -896,17 +896,11 @@ static int tas_create(struct i2c_adapter
return -ENOMEM;
mutex_init(&tas->mtx);
- tas->i2c.driver = &tas_driver;
- tas->i2c.adapter = adapter;
- tas->i2c.addr = addr;
+ tas->i2c = client;
+ i2c_set_clientdata(client, tas);
+
/* seems that half is a saner default */
tas->drc_range = TAS3004_DRC_MAX / 2;
- strlcpy(tas->i2c.name, "tas audio codec", I2C_NAME_SIZE);
-
- if (i2c_attach_client(&tas->i2c)) {
- printk(KERN_ERR PFX "failed to attach to i2c\n");
- goto fail;
- }
strlcpy(tas->codec.name, "tas", MAX_CODEC_NAME_LEN);
tas->codec.owner = THIS_MODULE;
@@ -915,69 +909,23 @@ static int tas_create(struct i2c_adapter
tas->codec.node = of_node_get(node);
if (aoa_codec_register(&tas->codec)) {
- goto detach;
+ goto fail;
}
printk(KERN_DEBUG
"snd-aoa-codec-tas: tas found, addr 0x%02x on %s\n",
- addr, node->full_name);
+ (unsigned int)client->addr, node->full_name);
return 0;
- detach:
- i2c_detach_client(&tas->i2c);
fail:
mutex_destroy(&tas->mtx);
kfree(tas);
return -EINVAL;
}
-static int tas_i2c_attach(struct i2c_adapter *adapter)
-{
- struct device_node *busnode, *dev = NULL;
- struct pmac_i2c_bus *bus;
-
- bus = pmac_i2c_adapter_to_bus(adapter);
- if (bus == NULL)
- return -ENODEV;
- busnode = pmac_i2c_get_bus_node(bus);
-
- while ((dev = of_get_next_child(busnode, dev)) != NULL) {
- if (of_device_is_compatible(dev, "tas3004")) {
- const u32 *addr;
- printk(KERN_DEBUG PFX "found tas3004\n");
- addr = of_get_property(dev, "reg", NULL);
- if (!addr)
- continue;
- return tas_create(adapter, dev, ((*addr) >> 1) & 0x7f);
- }
- /* older machines have no 'codec' node with a 'compatible'
- * property that says 'tas3004', they just have a 'deq'
- * node without any such property... */
- if (strcmp(dev->name, "deq") == 0) {
- const u32 *_addr;
- u32 addr;
- printk(KERN_DEBUG PFX "found 'deq' node\n");
- _addr = of_get_property(dev, "i2c-address", NULL);
- if (!_addr)
- continue;
- addr = ((*_addr) >> 1) & 0x7f;
- /* now, if the address doesn't match any of the two
- * that a tas3004 can have, we cannot handle this.
- * I doubt it ever happens but hey. */
- if (addr != 0x34 && addr != 0x35)
- continue;
- return tas_create(adapter, dev, addr);
- }
- }
- return -ENODEV;
-}
-
-static int tas_i2c_detach(struct i2c_client *client)
+static int tas_i2c_remove(struct i2c_client *client)
{
- struct tas *tas = container_of(client, struct tas, i2c);
- int err;
+ struct tas *tas = i2c_get_clientdata(client);
u8 tmp = TAS_ACR_ANALOG_PDOWN;
- if ((err = i2c_detach_client(client)))
- return err;
aoa_codec_unregister(&tas->codec);
of_node_put(tas->codec.node);
@@ -989,13 +937,20 @@ static int tas_i2c_detach(struct i2c_cli
return 0;
}
+static const struct i2c_device_id tas_i2c_id[] = {
+ { "aoa_codec_tas", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, tas_i2c_id);
+
static struct i2c_driver tas_driver = {
.driver = {
.name = "aoa_codec_tas",
.owner = THIS_MODULE,
},
- .attach_adapter = tas_i2c_attach,
- .detach_client = tas_i2c_detach,
+ .probe = tas_i2c_probe,
+ .remove = tas_i2c_remove,
+ .id_table = tas_i2c_id,
};
static int __init tas_init(void)
--
Jean Delvare
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Timur Tabi @ 2009-04-08 11:40 UTC (permalink / raw)
To: michael; +Cc: Tejun Heo, linux-ide, Jeff Garzik, Linux PPC Development
In-Reply-To: <1239156559.10104.7.camel@localhost>
On Tue, Apr 7, 2009 at 9:09 PM, Michael Ellerman <michael@ellerman.id.au> wrote:
> Have you confirmed that INTX is disabled before that call?
How do I do that?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 6/6] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb boards
From: Peter Korsgaard @ 2009-04-08 9:18 UTC (permalink / raw)
To: Anton Vorontsov
Cc: spi-devel-general, Andrew Morton, David Brownell, linux-kernel,
linuxppc-dev
In-Reply-To: <20090318200048.GD8182@oksana.dev.rtsoft.ru>
>>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
Hi,
Anton> The advantages of this:
Anton> - Don't encourage legacy support;
Anton> - Less external symbols, less code to compile-in for !MPC832x_RDB
Anton> platforms.
It's nice with your cleanups, but I wonder how to handle more
complicated chip select handling than simply toggling a single gpio.
I have a board (or 2 actually, but they are similar in this regard)
with a mpc8347 using SPI to a number of addon boards. For signal
integrity reasons the SPI signals are routed to a MUX, so the chip
select logic has to set the MUX in addition to controlling the CS line
of the device.
I've been using code like this since late 2007, but this patch
ofcourse breaks it:
static void thinx_spi_activate_cs(u8 cs, u8 polarity)
{
static u8 old_cs = 255;
if (cs != old_cs) {
/* mux setup (cs 2:1)*/
gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 1);
gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL0, cs&2);
gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL1, cs&4);
gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 0);
old_cs = cs;
}
switch (cs) {
case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, polarity); break;
case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, polarity); break;
case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, polarity); break;
case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, polarity); break;
}
}
static void thinx_spi_deactivate_cs(u8 cs, u8 polarity)
{
switch (cs) {
case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, !polarity); break;
case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, !polarity); break;
case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, !polarity); break;
case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, !polarity); break;
}
}
static __init int thinx_spi_init(void)
{
struct device_node *np;
struct of_gpio_chip *gc;
static const int gpios[] = {
GPIO_SPI_CS_BKL1,
GPIO_SPI_CS_BKL2,
GPIO_SPI_CS_OPT1,
GPIO_SPI_CS_OPT2,
GPIO_SPI_MUX_NOE,
GPIO_SPI_MUX_SEL0,
GPIO_SPI_MUX_SEL1
};
int i;
np = of_find_node_by_name(NULL, "gpio-controller");
if (!np || !np->data) {
printk(KERN_ERR
"gpio1 node not found or controller not registerred\n");
return -ENODEV;
}
gc = np->data;
gpio1 = gc->gc.base;
for (i=0; i<ARRAY_SIZE(gpios); i++) {
gpio_request(gpio1 + gpios[i], "spi");
gpio_direction_output(gpio1 + gpios[i], 1);
}
fsl_spi_init(thinx_spi_boardinfo, ARRAY_SIZE(thinx_spi_boardinfo),
thinx_spi_activate_cs, thinx_spi_deactivate_cs);
return 0;
}
Now, I don't quite see how to handle this with the new OF bindings -
Any ideas?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [2.6.30-rc1] Crash in .hpte_need_flush with hugetlbfs test[shm-fork]
From: Sachin Sant @ 2009-04-08 7:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: libhugetlbfs-devel
[-- Attachment #1: Type: text/plain, Size: 4667 bytes --]
I was executing libhugetlbfs tests on a power6 box [9117-MMA]. One of the
sub test (shm-fork) caused the machine to crash. Here is the information :
llm62 login: cpu 0x1: Vector: 300 (Data Access) at [c0000000f9827490]
pc: c000000000038028: .hpte_need_flush+0x1b8/0x2d8
lr: c000000000037edc: .hpte_need_flush+0x6c/0x2d8
sp: c0000000f9827710
msr: 8000000000009032
dar: c0000000d0157260
dsisr: 40000000
current = 0xc0000000f970bc20
paca = 0xc000000000a82500
pid = 11314, comm = shm-fork
enter ? for help
[c0000000f9827710] c000000000038050 .hpte_need_flush+0x1e0/0x2d8 (unreliable)
[c0000000f98277d0] c000000000039d78 .huge_ptep_get_and_clear+0x40/0x5c
[c0000000f9827850] c00000000010fe88 .__unmap_hugepage_range+0x178/0x2b8
[c0000000f9827940] c00000000011001c .unmap_hugepage_range+0x54/0x88
[c0000000f98279e0] c0000000000f9dc4 .unmap_vmas+0x178/0x8f4
[c0000000f9827b30] c0000000000ff4f4 .unmap_region+0xfc/0x1d8
[c0000000f9827c00] c000000000100c68 .do_munmap+0x2f4/0x38c
[c0000000f9827cc0] c000000000289a74 .SyS_shmdt+0xc0/0x188
[c0000000f9827d70] c00000000000c30c .sys_ipc+0x26c/0x2f4
[c0000000f9827e30] c0000000000084ac syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000004000020d2dc
SP (fffd23a3c50) is in userspace
1:mon> di %pc
c000000000038028 eb898000 ld r28,-32768(r9)
c00000000003802c 2f800000 cmpwi cr7,r0,0
c000000000038030 409e0028 bne cr7,c000000000038058 #
.hpte_need_flush+0x1e8/0x2d8
c000000000038034 7fe3fb78 mr r3,r31
c000000000038038 7f24cb78 mr r4,r25
c00000000003803c 7f85e378 mr r5,r28
c000000000038040 7f6607b4 extsw r6,r27
c000000000038044 7fa7eb78 mr r7,r29
c000000000038048 39000000 li r8,0
c00000000003804c 4bffc2cd bl c000000000034318 #
.flush_hash_page+0x0/0x1c0
c000000000038050 60000000 nop
c000000000038054 480000bc b c000000000038110 #
.hpte_need_flush+0x2a0/0x2d8
c000000000038058 7f0b07b5 extsw. r11,r24
c00000000003805c 41820030 beq c00000000003808c #
.hpte_need_flush+0x21c/0x2d8
c000000000038060 e81e0010 ld r0,16(r30)
c000000000038064 7fba0000 cmpd cr7,r26,r0
1:mon> r
R00 = 0000000000000000 R16 = 000000004f42e5b0
R01 = c0000000f9827710 R17 = 0000000000000000
R02 = c00000000098cf58 R18 = ffffffffffff9010
R03 = 0000000000000004 R19 = 0000000000000000
R04 = 000003ffec000000 R20 = 0000000000000000
R05 = c0000000d014f260 R21 = 0000040000000000
R06 = 0000220008000393 R22 = c0000000d014f260
R07 = 0000000000000001 R23 = 0000000000760000
R08 = 0000000000000004 R24 = 0000000000000000
R09 = c0000000d015f260 R25 = 0000220008000393
R10 = 000000000003ffec R26 = c0000000f947ca80
R11 = 0000000000000330 R27 = 0000000000000004
R12 = 0000000024022422 R28 = c000000000790430
R13 = c000000000a82500 R29 = 0000000000000001
R14 = 0000000000000010 R30 = c000000000ef0430
R15 = ffffffffffffffff R31 = 0fa89fffec000000
pc = c000000000038028 .hpte_need_flush+0x1b8/0x2d8
lr = c000000000037edc .hpte_need_flush+0x6c/0x2d8
msr = 8000000000009032 cr = 44022424
ctr = c0000000000fedc0 xer = 0000000000000001 trap = 300
dar = c0000000d0157260 dsisr = 40000000
1:mon> di %lr
c000000000037edc 60000000 nop
c000000000037ee0 7c7b1b78 mr r27,r3
c000000000037ee4 e8028cd8 ld r0,-29480(r2)
c000000000037ee8 7fbf0040 cmpld cr7,r31,r0
c000000000037eec 419d00a8 bgt cr7,c000000000037f94 #
.hpte_need_flush+0x124/0x2d8
c000000000037ef0 3800ffff li r0,-1
c000000000037ef4 3ba00000 li r29,0
c000000000037ef8 78000600 clrldi r0,r0,24
c000000000037efc 7fbf0040 cmpld cr7,r31,r0
c000000000037f00 409d000c ble cr7,c000000000037f0c #
.hpte_need_flush+0x9c/0x2d8
c000000000037f04 e9228ce0 ld r9,-29472(r2)
c000000000037f08 eba90002 lwa r29,0(r9)
c000000000037f0c 2fbd0000 cmpdi cr7,r29,0
c000000000037f10 e97a0390 ld r11,912(r26)
c000000000037f14 409e003c bne cr7,c000000000037f50 #
.hpte_need_flush+0xe0/0x2d8
c000000000037f18 796b83e4 rldicr r11,r11,16,47
1:mon>
CONFIG_PPC_64K_PAGES=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
Have attached the dmesg log extracted via xmon. The libhugetlbfs
tests [v2.0] are part of autotest framework [autotest.kernel.org].
The sub test that caused this was shm-fork. I have attached the
libhugetlbfs execution log.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: dmesg_log --]
[-- Type: text/plain, Size: 6067 bytes --]
72 bind 65536).
<6>TCP reno registered.
<6>NET: Registered protocol family 1.
<6>Unpacking initramfs... done.
<7>irq: irq 655360 on host null mapped to virtual irq 17.
<7>irq: irq 655362 on host null mapped to virtual irq 18.
<6>IOMMU table initialized, virtual merging enabled.
<7>irq: irq 589825 on host null mapped to virtual irq 19.
<7>RTAS daemon started.
<4>====[ backtrace testing ]===========.
<4>Testing a backtrace from process context..
<4>The following trace is a kernel self test and not a bug!.
<4>Call Trace:.
<4>[c0000000fe843c70] [c0000000000115ac] .show_stack+0x6c/0x16c (unreliable).
<4>[c0000000fe843d20] [c00000000009f91c] .backtrace_regression_test+0x44/0x134.
<4>[c0000000fe843e10] [c000000000009238] .do_one_initcall+0x80/0x19c.
<4>[c0000000fe843f00] [c000000000730370] .kernel_init+0x1a8/0x224.
<4>[c0000000fe843f90] [c00000000002b62c] .kernel_thread+0x54/0x70.
<4>Testing a backtrace from irq context..
<4>The following trace is a kernel self test and not a bug!.
<4>Call Trace:.
<4>[c000000001f9fcf0] [c0000000000115ac] .show_stack+0x6c/0x16c (unreliable).
<4>[c000000001f9fda0] [c00000000009f8b4] .backtrace_test_irq_callback+0x18/0x3c.
<4>[c000000001f9fe20] [c00000000006d1b4] .tasklet_action+0xec/0x1ac.
<4>[c000000001f9fec0] [c00000000006dc84] .__do_softirq+0x124/0x258.
<4>[c000000001f9ff90] [c00000000002b468] .call_do_softirq+0x14/0x24.
<4>[c0000000fe85bdb0] [c00000000000d4f0] .do_softirq+0x88/0xf0.
<4>[c0000000fe85be50] [c00000000006d628] .ksoftirqd+0xb8/0x184.
<4>[c0000000fe85bf00] [c0000000000827ac] .kthread+0x78/0xc4.
<4>[c0000000fe85bf90] [c00000000002b62c] .kernel_thread+0x54/0x70.
<4>Testing a saved backtrace..
<4>The following trace is a kernel self test and not a bug!.
<4> [000000009f9d0>] .backtrace_regression_test+0xf8/0x134.
<4> [000000009238>] .do_one_initcall+0x80/0x19c.
<4> [
<c000000000730370>] .kernel_init+0x1a8/0x224.
<4> [
<c00000000002b62c>] .kernel_thread+0x54/0x70.
<4>====[ end of backtrace testing ]====.
<6>audit: initializing netlink socket (disabled).
<5>type=2000 audit(1239168602.587:1): initialized.
<6>Kprobe smoke test started.
<6>Kprobe smoke test passed successfully.
<1>rcu-torture:--- Start of test: nreaders=8 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1.
<6>HugeTLB registered 16 MB page size, pre-allocated 0 pages.
<6>HugeTLB registered 16 GB page size, pre-allocated 0 pages.
<5>VFS: Disk quotas dquot_6.5.2.
<4>Dquot-cache hash table entries: 8192 (order 0, 65536 bytes).
<6>JFS: nTxBlock = 1896, nTxLock = 15168.
<6>msgmni has been set to 7584.
<6>alg: No test for stdrng (krng).
<6>Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254).
<6>io scheduler noop registered.
<6>io scheduler anticipatory registered.
<6>io scheduler deadline registered.
<6>io scheduler cfq registered (default).
<6>pci_hotplug: PCI Hot Plug PCI Core version: 0.5.
<6>rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1.
<7>vio_register_driver: driver hvc_console registering.
<7>HVSI: registered 0 devices.
<6>Generic RTC Driver v1.07.
<6>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled.
<6>input: Macintosh mouse button emulation as /class/input/input0.
<6>Uniform Multi-Platform E-IDE driver.
<6>ide-gd driver 1.18.
<7>vio_register_driver: driver ibmvscsi registering.
<6>ibmvscsi 30000002: SRP_VERSION: 16.a.
<6>scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8.
<6>ibmvscsi 30000002: partner initialization complete.
<6>ibmvscsi 30000002: sent SRP login.
<6>ibmvscsi 30000002: SRP_LOGIN succeeded.
<6>ibmvscsi 30000002: host srp version: 16.a, host partition VIO (1), OS 3, max io 1048576.
<5>scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3.
<4>Driver 'sd' needs updating - please use bus_type methods.
<5>sd 0:0:1:0: Attached scsi generic sg0 type 0.
<6>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver.
<6>ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver.
<5>sd 0:0:1:0: [sda] 167772160 512-byte hardware sectors: (85.8 GB/80.0 GiB).
<5>sd 0:0:1:0: [sda] Write Protect is off.
<7>sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08.
<5>sd 0:0:1:0: [sda] Cache data unavailable.
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through.
<5>sd 0:0:1:0: [sda] Cache data unavailable.
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through.
<6> sda: sda1 sda2
< sda5 > sda3 sda4.
<5>sd 0:0:1:0: [sda] Attached SCSI disk.
<6>mice: PS/2 mouse device common for all mice.
<6>EDAC MC: Ver: 2.1.0 Apr 8 2009.
<6>usbcore: registered new interface driver hiddev.
<6>usbcore: registered new interface driver usbhid.
<6>usbhid: v2.6:USB HID core driver.
<6>TCP cubic registered.
<6>NET: Registered protocol family 15.
<7>Running code patching self-tests ....
<7>Running feature fixup self-tests ....
<7>Running MSI bitmap self-tests ....
<4>registered taskstats version 1.
<4>Freeing unused kernel memory: 448k freed.
<6>SysRq : Changing Loglevel.
<4>Loglevel set to 1.
<6>udevd version 128 started.
<6>kjournald starting. Commit interval 5 seconds.
<6>EXT3 FS on sda5, internal journal.
<6>EXT3-fs: mounted filesystem with writeback data mode..
<6>udevd version 128 started.
<6>IBM eHEA ethernet device driver (Release EHEA_0100).
<7>irq: irq 590080 on host null mapped to virtual irq 256.
<6>ehea: eth0: Jumbo frames are disabled.
<6>ehea: eth0 -> logical port id #2.
<6>Adding 1044096k swap on /dev/sda3. Priority:-1 extents:1 across:1044096k .
<6>device-mapper: uevent: version 1.0.3.
<6>device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com.
<6>loop: module loaded.
<6>fuse init (API version 7.11).
<6>ehea: eth0: Physical port up.
<6>ehea: External switch port is backup port.
<7>irq: irq 776 on host null mapped to virtual irq 264.
<7>irq: irq 777 on host null mapped to virtual irq 265.
<6>NET: Registered protocol family 10.
<6>lo: Disabled Privacy Extensions.
<7>eth0: no IPv6 routers present.
<1>Unable to handle kernel paging request for data at address 0xc0000000d0157260.
<1>Faulting instruction address: 0xc000000000038028........................
[-- Attachment #3: libhugetlbfs.runlog --]
[-- Type: text/plain, Size: 20579 bytes --]
/usr/bin/gcc
VERSION
version string: 2.0
CC32 obj32/elflink.o
AS32 obj32/sys-elf32ppclinux.o
CC32 obj32/elf32ppclinux.o
CC32 obj32/hugeutils.o
CC32 obj32/version.o
CC32 obj32/init.o
CC32 obj32/morecore.o
CC32 obj32/debug.o
CC32 obj32/alloc.o
LD32 (shared) obj32/libhugetlbfs.so
CC64 obj64/elflink.o
AS64 obj64/sys-elf64ppc.o
CC64 obj64/elf64ppc.o
CC64 obj64/hugeutils.o
CC64 obj64/version.o
CC64 obj64/init.o
CC64 obj64/morecore.o
CC64 obj64/debug.o
CC64 obj64/alloc.o
LD64 (shared) obj64/libhugetlbfs.so
AR32 obj32/libhugetlbfs.a
AR64 obj64/libhugetlbfs.a
CC32 obj32/gethugepagesize.o
CC32 obj32/testutils.o
LD32 (lib test) obj32/gethugepagesize
CC32 obj32/test_root.o
LD32 (lib test) obj32/test_root
CC32 obj32/find_path.o
LD32 (lib test) obj32/find_path
CC32 obj32/unlinked_fd.o
LD32 (lib test) obj32/unlinked_fd
CC32 obj32/misalign.o
LD32 (lib test) obj32/misalign
CC32 obj32/readback.o
LD32 (lib test) obj32/readback
CC32 obj32/truncate.o
LD32 (lib test) obj32/truncate
CC32 obj32/shared.o
LD32 (lib test) obj32/shared
CC32 obj32/private.o
LD32 (lib test) obj32/private
CC32 obj32/fork-cow.o
LD32 (lib test) obj32/fork-cow
CC32 obj32/empty_mounts.o
LD32 (lib test) obj32/empty_mounts
CC32 obj32/large_mounts.o
LD32 (lib test) obj32/large_mounts
CC32 obj32/meminfo_nohuge.o
LD32 (lib test) obj32/meminfo_nohuge
CC32 obj32/ptrace-write-hugepage.o
LD32 (lib test) obj32/ptrace-write-hugepage
CC32 obj32/icache-hygiene.o
LD32 (lib test) obj32/icache-hygiene
CC32 obj32/slbpacaflush.o
LD32 (lib test) obj32/slbpacaflush
CC32 obj32/chunk-overcommit.o
LD32 (lib test) obj32/chunk-overcommit
CC32 obj32/mprotect.o
LD32 (lib test) obj32/mprotect
CC32 obj32/alloc-instantiate-race.o
LD32 (lib test) obj32/alloc-instantiate-race
CC32 obj32/mlock.o
LD32 (lib test) obj32/mlock
CC32 obj32/truncate_reserve_wraparound.o
LD32 (lib test) obj32/truncate_reserve_wraparound
CC32 obj32/truncate_sigbus_versus_oom.o
LD32 (lib test) obj32/truncate_sigbus_versus_oom
CC32 obj32/map_high_truncate_2.o
LD32 (lib test) obj32/map_high_truncate_2
CC32 obj32/truncate_above_4GB.o
LD32 (lib test) obj32/truncate_above_4GB
CC32 obj32/direct.o
LD32 (lib test) obj32/direct
CC32 obj32/misaligned_offset.o
LD32 (lib test) obj32/misaligned_offset
CC32 obj32/brk_near_huge.o
LD32 (lib test) obj32/brk_near_huge
CC32 obj32/task-size-overrun.o
LD32 (lib test) obj32/task-size-overrun
CC32 obj32/stack_grow_into_huge.o
LD32 (lib test) obj32/stack_grow_into_huge
CC32 obj32/counters.o
LD32 (lib test) obj32/counters
CC32 obj32/quota.o
LD32 (lib test) obj32/quota
CC32 obj32/heap-overflow.o
LD32 (lib test) obj32/heap-overflow
CC32 obj32/get_huge_pages.o
LD32 (lib test) obj32/get_huge_pages
CC32 obj32/malloc.o
LD32 (nolib test) obj32/malloc
CC32 obj32/malloc_manysmall.o
LD32 (nolib test) obj32/malloc_manysmall
CC32 obj32/dummy.o
LD32 (nolib test) obj32/dummy
CC32 obj32/heapshrink.o
LD32 (nolib test) obj32/heapshrink
CC32 obj32/mmap-gettest.o
LD32 (lib test) obj32/mmap-gettest
CC32 obj32/mmap-cow.o
LD32 (lib test) obj32/mmap-cow
CC32 obj32/shm-gettest.o
LD32 (lib test) obj32/shm-gettest
CC32 obj32/shm-getraw.o
LD32 (lib test) obj32/shm-getraw
CC32 obj32/shm-fork.o
LD32 (lib test) obj32/shm-fork
CC32 obj32/zero_filesize_segment.o
LD32 (preload test) obj32/zero_filesize_segment
collect2: ld terminated with signal 11 [Segmentation fault]
CC32 obj32/linkhuge.o
LD32 (hugelink test) obj32/linkhuge
CC32 obj32/linkhuge_nofd.o
LD32 (hugelink test) obj32/linkhuge_nofd
CC32 obj32/linkshare.o
LD32 (hugelink test) obj32/linkshare
LD32 (xB test) obj32/xB.linkhuge
LD32 (xB test) obj32/xB.linkhuge_nofd
LD32 (xB test) obj32/xB.linkshare
LD32 (xBDT test) obj32/xBDT.linkhuge
LD32 (xBDT test) obj32/xBDT.linkhuge_nofd
LD32 (xBDT test) obj32/xBDT.linkshare
CC32 obj32/linkhuge_rw.o
LD32 (hugelink_rw test) obj32/linkhuge_rw
CC64 obj64/gethugepagesize.o
CC64 obj64/testutils.o
LD64 (lib test) obj64/gethugepagesize
CC64 obj64/test_root.o
LD64 (lib test) obj64/test_root
CC64 obj64/find_path.o
LD64 (lib test) obj64/find_path
CC64 obj64/unlinked_fd.o
LD64 (lib test) obj64/unlinked_fd
CC64 obj64/misalign.o
LD64 (lib test) obj64/misalign
CC64 obj64/readback.o
LD64 (lib test) obj64/readback
CC64 obj64/truncate.o
LD64 (lib test) obj64/truncate
CC64 obj64/shared.o
LD64 (lib test) obj64/shared
CC64 obj64/private.o
LD64 (lib test) obj64/private
CC64 obj64/fork-cow.o
LD64 (lib test) obj64/fork-cow
CC64 obj64/empty_mounts.o
LD64 (lib test) obj64/empty_mounts
CC64 obj64/large_mounts.o
LD64 (lib test) obj64/large_mounts
CC64 obj64/meminfo_nohuge.o
LD64 (lib test) obj64/meminfo_nohuge
CC64 obj64/ptrace-write-hugepage.o
LD64 (lib test) obj64/ptrace-write-hugepage
CC64 obj64/icache-hygiene.o
LD64 (lib test) obj64/icache-hygiene
CC64 obj64/slbpacaflush.o
LD64 (lib test) obj64/slbpacaflush
CC64 obj64/chunk-overcommit.o
LD64 (lib test) obj64/chunk-overcommit
CC64 obj64/mprotect.o
LD64 (lib test) obj64/mprotect
CC64 obj64/alloc-instantiate-race.o
LD64 (lib test) obj64/alloc-instantiate-race
CC64 obj64/mlock.o
LD64 (lib test) obj64/mlock
CC64 obj64/truncate_reserve_wraparound.o
LD64 (lib test) obj64/truncate_reserve_wraparound
CC64 obj64/truncate_sigbus_versus_oom.o
LD64 (lib test) obj64/truncate_sigbus_versus_oom
CC64 obj64/map_high_truncate_2.o
LD64 (lib test) obj64/map_high_truncate_2
CC64 obj64/truncate_above_4GB.o
LD64 (lib test) obj64/truncate_above_4GB
CC64 obj64/direct.o
LD64 (lib test) obj64/direct
CC64 obj64/misaligned_offset.o
LD64 (lib test) obj64/misaligned_offset
CC64 obj64/brk_near_huge.o
LD64 (lib test) obj64/brk_near_huge
CC64 obj64/task-size-overrun.o
LD64 (lib test) obj64/task-size-overrun
CC64 obj64/stack_grow_into_huge.o
LD64 (lib test) obj64/stack_grow_into_huge
CC64 obj64/counters.o
LD64 (lib test) obj64/counters
CC64 obj64/quota.o
LD64 (lib test) obj64/quota
CC64 obj64/heap-overflow.o
LD64 (lib test) obj64/heap-overflow
CC64 obj64/get_huge_pages.o
LD64 (lib test) obj64/get_huge_pages
CC64 obj64/malloc.o
LD64 (nolib test) obj64/malloc
CC64 obj64/malloc_manysmall.o
LD64 (nolib test) obj64/malloc_manysmall
CC64 obj64/dummy.o
LD64 (nolib test) obj64/dummy
CC64 obj64/heapshrink.o
LD64 (nolib test) obj64/heapshrink
CC64 obj64/mmap-gettest.o
LD64 (lib test) obj64/mmap-gettest
CC64 obj64/mmap-cow.o
LD64 (lib test) obj64/mmap-cow
CC64 obj64/shm-gettest.o
LD64 (lib test) obj64/shm-gettest
CC64 obj64/shm-getraw.o
LD64 (lib test) obj64/shm-getraw
CC64 obj64/shm-fork.o
LD64 (lib test) obj64/shm-fork
CC64 obj64/zero_filesize_segment.o
LD64 (preload test) obj64/zero_filesize_segment
collect2: ld terminated with signal 11 [Segmentation fault]
CC64 obj64/linkhuge.o
LD64 (hugelink test) obj64/linkhuge
CC64 obj64/linkhuge_nofd.o
LD64 (hugelink test) obj64/linkhuge_nofd
CC64 obj64/linkshare.o
LD64 (hugelink test) obj64/linkshare
LD64 (xB test) obj64/xB.linkhuge
LD64 (xB test) obj64/xB.linkhuge_nofd
LD64 (xB test) obj64/xB.linkshare
LD64 (xBDT test) obj64/xBDT.linkhuge
LD64 (xBDT test) obj64/xBDT.linkhuge_nofd
LD64 (xBDT test) obj64/xBDT.linkshare
CC64 obj64/linkhuge_rw.o
LD64 (hugelink_rw test) obj64/linkhuge_rw
CC64 obj64/straddle_4GB.o
LD64 (lib test) obj64/straddle_4GB
CC64 obj64/huge_at_4GB_normal_below.o
LD64 (lib test) obj64/huge_at_4GB_normal_below
CC64 obj64/huge_below_4GB_normal_above.o
LD64 (lib test) obj64/huge_below_4GB_normal_above
CC32 obj32/get_hugetlbfs_path.o
LD32 (helper) obj32/get_hugetlbfs_path
CC64 obj64/get_hugetlbfs_path.o
LD64 (helper) obj64/get_hugetlbfs_path
CC32 obj32/heapshrink-helper-pic.o
LD32 (shared) obj32/libheapshrink.so
CC64 obj64/heapshrink-helper-pic.o
LD64 (shared) obj64/libheapshrink.so
CC obj/hugectl
CC obj/hugeedit
Benchmark started. Number of iterations: 1
Executing iteration 1 of 1
zero_filesize_segment (32): Bad toolchain: can't build this testcase
zero_filesize_segment (64): Bad toolchain: can't build this testcase
test_root (32): PASS
test_root (64): PASS
meminfo_nohuge (32): PASS
meminfo_nohuge (64): PASS
gethugepagesize (32): PASS
gethugepagesize (64): PASS
HUGETLB_VERBOSE=1 empty_mounts (32): PASS
HUGETLB_VERBOSE=1 empty_mounts (64): PASS
HUGETLB_VERBOSE=1 large_mounts (32): PASS
HUGETLB_VERBOSE=1 large_mounts (64): PASS
find_path (32): PASS
find_path (64): PASS
unlinked_fd (32): PASS
unlinked_fd (64): PASS
readback (32): PASS
readback (64): PASS
truncate (32): PASS
truncate (64): PASS
shared (32): PASS
shared (64): PASS
mprotect (32): PASS
mprotect (64): PASS
mlock (32): Bad configuration: Locked memory ulimit set below huge page size
mlock (64): Bad configuration: Locked memory ulimit set below huge page size
misalign (32): PASS
misalign (64): PASS
ptrace-write-hugepage (32): PASS
ptrace-write-hugepage (64): PASS
icache-hygiene (32): PASS
icache-hygiene (64): PASS
slbpacaflush (32): PASS (inconclusive)
slbpacaflush (64): PASS (inconclusive)
straddle_4GB (64): PASS
huge_at_4GB_normal_below (64): PASS
huge_below_4GB_normal_above (64): PASS
map_high_truncate_2 (32): PASS
map_high_truncate_2 (64): PASS
misaligned_offset (32): PASS (inconclusive)
misaligned_offset (64): PASS (inconclusive)
truncate_above_4GB (32): PASS
truncate_above_4GB (64): PASS
brk_near_huge (32): PASS
brk_near_huge (64): PASS
task-size-overrun (32): PASS
task-size-overrun (64): PASS
stack_grow_into_huge (32): PASS
stack_grow_into_huge (64): PASS
private (32): PASS
private (64): PASS
fork-cow (32): PASS
fork-cow (64): PASS
direct (32): PASS
direct (64): PASS
malloc (32): PASS
malloc (64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (32): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (64): PASS
malloc_manysmall (32): PASS
malloc_manysmall (64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (32): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (64): PASS
heapshrink (32): PASS
heapshrink (64): PASS
LD_PRELOAD=libheapshrink.so heapshrink (32): PASS
LD_PRELOAD=libheapshrink.so heapshrink (64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (32): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (64): PASS
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes heapshrink (32): PASS
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes heapshrink (64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes HUGETLB_MORECORE_SHRINK=yes heapshrink (32): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes HUGETLB_MORECORE_SHRINK=yes heapshrink (64): PASS
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes HUGETLB_MORECORE_SHRINK=yes heapshrink (32): PASS (inconclusive)
LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes HUGETLB_MORECORE_SHRINK=yes heapshrink (64): PASS (inconclusive)
HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (32): PASS
HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (64): PASS
HUGETLB_VERBOSE=0 linkhuge_nofd (32): PASS
HUGETLB_VERBOSE=0 linkhuge_nofd (64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (32): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (64): PASS
HUGETLB_VERBOSE=0 xB.linkhuge_nofd (32): obj32/xB.linkhuge_nofd: obj32/xB.linkhuge_nofd: cannot execute binary file
HUGETLB_VERBOSE=0 xB.linkhuge_nofd (64): obj64/xB.linkhuge_nofd: obj64/xB.linkhuge_nofd: cannot execute binary file
HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (32): obj32/xBDT.linkhuge_nofd: obj32/xBDT.linkhuge_nofd: cannot execute binary file
HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (64): obj64/xBDT.linkhuge_nofd: obj64/xBDT.linkhuge_nofd: cannot execute binary file
HUGETLB_MINIMAL_COPY=no HUGETLB_VERBOSE=0 xB.linkhuge_nofd (32): HUGETLB_MINIMAL_COPY=no HUGETLB_VERBOSE=0 xB.linkhuge_nofd (64): obj32/xB.linkhuge_nofd: obj32/xB.linkhuge_nofd: cannot execute binary file
obj64/xB.linkhuge_nofd: obj64/xB.linkhuge_nofd: cannot execute binary file
HUGETLB_MINIMAL_COPY=no HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (32): obj32/xBDT.linkhuge_nofd: obj32/xBDT.linkhuge_nofd: cannot execute binary file
HUGETLB_MINIMAL_COPY=no HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (64): obj64/xBDT.linkhuge_nofd: obj64/xBDT.linkhuge_nofd: cannot execute binary file
HUGETLB_ELFMAP=no HUGETLB_VERBOSE=0 xB.linkhuge_nofd (32): obj32/xB.linkhuge_nofd: obj32/xB.linkhuge_nofd: cannot execute binary file
HUGETLB_ELFMAP=no HUGETLB_VERBOSE=0 xB.linkhuge_nofd (64): obj64/xB.linkhuge_nofd: obj64/xB.linkhuge_nofd: cannot execute binary file
HUGETLB_ELFMAP=no HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (32): obj32/xBDT.linkhuge_nofd: obj32/xBDT.linkhuge_nofd: cannot execute binary file
HUGETLB_ELFMAP=no HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (64): obj64/xBDT.linkhuge_nofd: obj64/xBDT.linkhuge_nofd: cannot execute binary file
linkhuge (32): PASS
linkhuge (64): PASS
LD_PRELOAD=libhugetlbfs.so linkhuge (32): PASS
LD_PRELOAD=libhugetlbfs.so linkhuge (64): PASS
xB.linkhuge (32): obj32/xB.linkhuge: obj32/xB.linkhuge: cannot execute binary file
xB.linkhuge (64): obj64/xB.linkhuge: obj64/xB.linkhuge: cannot execute binary file
xBDT.linkhuge (32): obj32/xBDT.linkhuge: obj32/xBDT.linkhuge: cannot execute binary file
xBDT.linkhuge (64): obj64/xBDT.linkhuge: obj64/xBDT.linkhuge: cannot execute binary file
HUGETLB_MINIMAL_COPY=no xB.linkhuge (32): obj32/xB.linkhuge: obj32/xB.linkhuge: cannot execute binary file
HUGETLB_MINIMAL_COPY=no xB.linkhuge (64): obj64/xB.linkhuge: obj64/xB.linkhuge: cannot execute binary file
HUGETLB_MINIMAL_COPY=no xBDT.linkhuge (32): obj32/xBDT.linkhuge: obj32/xBDT.linkhuge: cannot execute binary file
HUGETLB_MINIMAL_COPY=no xBDT.linkhuge (64): obj64/xBDT.linkhuge: obj64/xBDT.linkhuge: cannot execute binary file
HUGETLB_ELFMAP=no xB.linkhuge (32): obj32/xB.linkhuge: obj32/xB.linkhuge: cannot execute binary file
HUGETLB_ELFMAP=no xB.linkhuge (64): obj64/xB.linkhuge: obj64/xB.linkhuge: cannot execute binary file
HUGETLB_ELFMAP=no xBDT.linkhuge (32): obj32/xBDT.linkhuge: obj32/xBDT.linkhuge: cannot execute binary file
HUGETLB_ELFMAP=no xBDT.linkhuge (64): obj64/xBDT.linkhuge: obj64/xBDT.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xB.linkshare (32): obj32/xB.linkshare: obj32/xB.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xB.linkshare (64): obj64/xB.linkshare: obj64/xB.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkshare (32): obj32/xBDT.linkshare: obj32/xBDT.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkshare (64): obj64/xBDT.linkshare: obj64/xBDT.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xB.linkshare (32): obj32/xB.linkshare: obj32/xB.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xB.linkshare (64): obj64/xB.linkshare: obj64/xB.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkshare (32): obj32/xBDT.linkshare: obj32/xBDT.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkshare (64): obj64/xBDT.linkshare: obj64/xBDT.linkshare: cannot execute binary file
HUGETLB_SHARE=1 xB.linkhuge (32): obj32/xB.linkhuge: obj32/xB.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xB.linkhuge (64): obj64/xB.linkhuge: obj64/xB.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xB.linkhuge (32): obj32/xB.linkhuge: obj32/xB.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xB.linkhuge (64): obj64/xB.linkhuge: obj64/xB.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkhuge (32): obj32/xBDT.linkhuge: obj32/xBDT.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkhuge (64): obj64/xBDT.linkhuge: obj64/xBDT.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkhuge (32): obj32/xBDT.linkhuge: obj32/xBDT.linkhuge: cannot execute binary file
HUGETLB_SHARE=1 xBDT.linkhuge (64): obj64/xBDT.linkhuge: obj64/xBDT.linkhuge: cannot execute binary file
linkhuge_rw (32): PASS
linkhuge_rw (64): PASS
HUGETLB_ELFMAP=R linkhuge_rw (32): PASS
HUGETLB_ELFMAP=R linkhuge_rw (64): PASS
HUGETLB_ELFMAP=W linkhuge_rw (32): PASS
HUGETLB_ELFMAP=W linkhuge_rw (64): PASS
HUGETLB_ELFMAP=RW linkhuge_rw (32): PASS
HUGETLB_ELFMAP=RW linkhuge_rw (64): PASS
HUGETLB_ELFMAP=no linkhuge_rw (32): PASS
HUGETLB_ELFMAP=no linkhuge_rw (64): PASS
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=R linkhuge_rw (32): PASS
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=R linkhuge_rw (64): PASS
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=W linkhuge_rw (32): PASS
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=W linkhuge_rw (64): PASS
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=RW linkhuge_rw (32): PASS
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=RW linkhuge_rw (64): PASS
HUGETLB_ELFMAP=R HUGETLB_SHARE=1 linkhuge_rw (32): PASS
HUGETLB_ELFMAP=R HUGETLB_SHARE=1 linkhuge_rw (64): PASS
HUGETLB_ELFMAP=R HUGETLB_SHARE=1 linkhuge_rw (32): PASS
HUGETLB_ELFMAP=R HUGETLB_SHARE=1 linkhuge_rw (64): PASS
HUGETLB_ELFMAP=W HUGETLB_SHARE=1 linkhuge_rw (32): PASS
HUGETLB_ELFMAP=W HUGETLB_SHARE=1 linkhuge_rw (64): PASS
HUGETLB_ELFMAP=W HUGETLB_SHARE=1 linkhuge_rw (32): PASS
HUGETLB_ELFMAP=W HUGETLB_SHARE=1 linkhuge_rw (64): PASS
HUGETLB_ELFMAP=RW HUGETLB_SHARE=1 linkhuge_rw (32): PASS
HUGETLB_ELFMAP=RW HUGETLB_SHARE=1 linkhuge_rw (64): PASS
HUGETLB_ELFMAP=RW HUGETLB_SHARE=1 linkhuge_rw (32): PASS
HUGETLB_ELFMAP=RW HUGETLB_SHARE=1 linkhuge_rw (64): PASS
chunk-overcommit (32): PASS
chunk-overcommit (64): PASS
alloc-instantiate-race shared (32): PASS
alloc-instantiate-race shared (64): PASS
alloc-instantiate-race private (32): PASS
alloc-instantiate-race private (64): PASS
truncate_reserve_wraparound (32): PASS
truncate_reserve_wraparound (64): PASS
truncate_sigbus_versus_oom (32): PASS
truncate_sigbus_versus_oom (64): PASS
get_huge_pages (32): PASS
get_huge_pages (64): PASS
quota (32): PASS
quota (64): PASS
counters (32): PASS
counters (64): PASS
mmap-gettest 10 20 (32): PASS
mmap-gettest 10 20 (64): PASS
mmap-cow 19 20 (32): PASS
mmap-cow 19 20 (64): PASS
set shmmax limit to 335544320
shm-fork 10 10 (32): PASS
shm-fork 10 10 (64): PASS
shm-fork 10 20 (32): PASS
shm-fork 10 20 (64):
^ permalink raw reply
* Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
From: Geert Uytterhoeven @ 2009-04-08 7:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <1239173283.10104.38.camel@localhost>
On Wed, 8 Apr 2009, Michael Ellerman wrote:
> On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
> > On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
> >
> > > The getter routines in here could really multiplex their return values
> > > with a negative error code, which I generally prefer, but this works I
> > > guess.
> >
> > I was hoping someone would notice and suggest it. tag you're it!
>
> I meant we /could/ change them, but we could also leave them, it's a bit
> of a coin-flip which is better. Nathan might have an opinion?
>
> Something like this:
>
> diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
> index bb37b1d..9f3a155 100644
> --- a/arch/powerpc/kernel/cacheinfo.c
> +++ b/arch/powerpc/kernel/cacheinfo.c
> -static int cache_size_kb(const struct cache *cache, unsigned int *ret)
> +static int cache_size_kb(const struct cache *cache)
> {
> unsigned int size;
^^^^^^^^^^^^
`int size', or Roel will come to get you ;-)
>
> - if (cache_size(cache, &size))
> - return -ENODEV;
> + size = cache_size(cache);
> + if (size < 0)
^^^^^^^^
> + return size;
I can't check the others, due to lacking context...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-04-08 7:25 UTC (permalink / raw)
To: Kumar Gala
Cc: Linux/PPC Development, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <F4E3E1FF-C544-460A-AC27-DB9501C13ED3@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 8, 2009, at 12:11 AM, Kumar Gala wrote:
>
>>
>> On Apr 7, 2009, at 3:20 AM, Wolfgang Grandegger wrote:
>>
>>> This patch series makes the I2C bus speed configurable by using the
>>> I2C node property "clock-frequency". If the property is not defined,
>>> the old fixed clock settings will be used for backward compatibility.
>>> The property "fsl,preserve-clocking" allows to inherit the settings
>>> from the bootloader. Furthermore, it does some cleanup and uses the
>>> new bindings for the Socrates board:
>>>
>>> i2c: i2c-mpc: various coding style fixes
>>> i2c: i2c-mpc: use dev based printout function
>>> i2c: i2c-mpc: make I2C bus speed configurable
>>
>> It looks like Ben picked up these patches.
>>
>>> powerpc: i2c-mpc: document new FSL I2C bindings and cleanup
>>> powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
>>
>> I would have preferred these two go via me, but it looks like the
>> board one got picked up by Ben. I'll deal with the doc/binding update.
>>>
>>> Ben, could you please consider this patch series for inclusion into
>>> 2.6.30
>
> So I'm a bit concerned with the output we now get:
>
> mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)
>
> why 0? is that right?
This is the backward compatibility mode using hard-coded FDR values. The
output is missleading, I agree.
Wolfgang.
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Jeff Garzik @ 2009-04-08 6:12 UTC (permalink / raw)
To: michael
Cc: Tejun Heo, linux-ide, Timur Tabi, Jesse Barnes,
Linux PPC Development
In-Reply-To: <1239156559.10104.7.camel@localhost>
Michael Ellerman wrote:
> On Tue, 2009-04-07 at 19:36 -0500, Timur Tabi wrote:
>> On Tue, Apr 7, 2009 at 6:57 PM, Tejun Heo <tj@kernel.org> wrote:
>>
>>> Hmmm... that means intx isn't set by default. I'm not sure what is
>>> the right thing to do here. I think it's something which should be
>>> handled by the PCI layer. Oh well, maybe we should just revert the
>>> change and keep setting intx?
>> cc'ing linuxppc-dev
>>
>> I really don't know what should be done. It seems to make sense to
>> have the PCI layer enable interrupts.
>>
>> This seems to be a powerpc-specific bug, but I don't know enough of
>> the PCI subsystem.
>
> Have you confirmed that INTX is disabled before that call?
The symptoms definitely indicate such, as well as his reversing that commit.
My guess is that this is a ULI M1575-specific bug, and the PCI layer
needs a quirk that knows this device does -not- disable INTX, when MSI
is enabled.
But honestly, I never saw any harm in disabling INTX manually. Indeed,
I wrote the code that disabled INTX out of now-substantiated paranoia
that some PCI devices would be too dumb to follow that particular MSI
rule... and the cost of twiddling INTX seemed quite low in comparison
the potential problems created by the absence of INTX twiddling.
Jeff
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-04-08 7:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <5FDB097C-7D71-41DF-A4F4-2DE34FD710C5@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 8, 2009, at 12:16 AM, Grant Likely wrote:
>
>> On Tue, Apr 7, 2009 at 10:11 PM, Kumar Gala
>> <galak@kernel.crashing.org> wrote:
>>>
>>> On Apr 7, 2009, at 3:20 AM, Wolfgang Grandegger wrote:
>>>
>>>> This patch series makes the I2C bus speed configurable by using the
>>>> I2C node property "clock-frequency". If the property is not defined,
>>>> the old fixed clock settings will be used for backward compatibility.
>>>> The property "fsl,preserve-clocking" allows to inherit the settings
>>>> from the bootloader. Furthermore, it does some cleanup and uses the
>>>> new bindings for the Socrates board:
>>>>
>>>> i2c: i2c-mpc: various coding style fixes
>>>> i2c: i2c-mpc: use dev based printout function
>>>> i2c: i2c-mpc: make I2C bus speed configurable
>>>
>>> It looks like Ben picked up these patches.
Ah, I just saw the pull request.
>>>> powerpc: i2c-mpc: document new FSL I2C bindings and cleanup
>>>> powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
>>>
>>> I would have preferred these two go via me, but it looks like the
>>> board one
>>> got picked up by Ben. I'll deal with the doc/binding update.
That was my intention, at least.
>> hrummm. As I mentioned in my reply, I'm not convinced that the board
>> one is the right thing in this case. I would have preferred it to be
>> deferred.
>
> which part? I missed this whole thread as I had it forwarding to my
> devicetree-discuss folder which I don't normally look at.
I hate these cross-postings as well. I just answered to Grant's mail.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
From: Wolfgang Grandegger @ 2009-04-08 7:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <fa686aa40904070843q248f3ae1l9c8ca0d5a65c8cc3@mail.gmail.com>
Grant Likely wrote:
> On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Preserve I2C clock settings for the Socrates MPC8544 board.
>
> I had thought that the preserve-clocking property was intended for
> older boards that don't currently have any method of getting the clock
> setting out of u-boot. Since Socrates is a new board, U-Boot should
> probably be made to fill in the real clock rate setting.
I'm not sure if I understand what you mean. If an old version of U-Boot
on an old board sets the I2C clock, it can be used (inherited) by Linux
using the property "preserve-clocking".
It is actually the customers choice to set the I2C clock in U-Boot and
re-use it by Linux.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
From: Michael Ellerman @ 2009-04-08 6:48 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20090408055126.GG16602@bilbo.ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]
On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
> On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
>
> > The getter routines in here could really multiplex their return values
> > with a negative error code, which I generally prefer, but this works I
> > guess.
>
> I was hoping someone would notice and suggest it. tag you're it!
I meant we /could/ change them, but we could also leave them, it's a bit
of a coin-flip which is better. Nathan might have an opinion?
Something like this:
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index bb37b1d..9f3a155 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -191,7 +191,7 @@ static void cache_cpu_set(struct cache *cache, int cpu)
}
}
-static int cache_size(const struct cache *cache, unsigned int *ret)
+static int cache_size(const struct cache *cache)
{
const char *propname;
const u32 *cache_size;
@@ -202,19 +202,18 @@ static int cache_size(const struct cache *cache, unsigned
if (!cache_size)
return -ENODEV;
- *ret = *cache_size;
- return 0;
+ return cache_size;
}
-static int cache_size_kb(const struct cache *cache, unsigned int *ret)
+static int cache_size_kb(const struct cache *cache)
{
unsigned int size;
- if (cache_size(cache, &size))
- return -ENODEV;
+ size = cache_size(cache);
+ if (size < 0)
+ return size;
- *ret = size / 1024;
- return 0;
+ return size / 1024;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
@@ -515,8 +514,9 @@ static ssize_t size_show(struct kobject *k, struct kobj_attr
cache = index_kobj_to_cache(k);
- if (cache_size_kb(cache, &size_kb))
- return -ENODEV;
+ size_kb = cache_size_kb(cache);
+ if (size_kb < 0)
+ return size_kb;
return sprintf(buf, "%uK\n", size_kb);
}
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
From: Michael Ellerman @ 2009-04-08 6:23 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20090408061352.GH16602@bilbo.ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
On Wed, 2009-04-08 at 16:13 +1000, Tony Breeds wrote:
> On Wed, Apr 08, 2009 at 03:51:26PM +1000, Tony Breeds wrote:
>
> > Hmm actually I think you're right. I dont want to push my luck with the gcc
> > hackers though
>
> Replying to myself.
>
> Yes this is a gcc bug but one introduced by CONFIG_TRACE_ALL_BRANCHES (or
> whatever that's called).
CONFIG_MAKE_MY_KERNEL_SUCK I think it is.
In that case I don't blame gcc.
If people want to use that option I think they can just deal with the
warnings, we can make -Werror depend on !CONFIG_PROFILE_ALL_BRANCHES.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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