* [PATCH v1] Make spi_ppc4xx.c tolerate 0 bits-per-word and 0 speed_hz
From: Steven A. Falco @ 2009-06-24 14:34 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org; +Cc: David Brownell, Stefan Roese
If a SPI transfer is set up, but does not explicitly set bits-per-word
and speed_hz, then the transaction fails, because spi_ppc4xx_setupxfer
rejects it.
This patch modifies the logic to chose the struct spi_transfer parameters
only if they are non-zero. Otherwise, the struct spi_device parameters
are used.
Additionally, since there is no OF binding for bits-per-word, we have to
tolerate the case where both t->bits_per_word and spi->bits_per_word are
zero.
---
This was brought to light by a pending patch to spi_bitbang, which results
in more calls to spi_ppc4xx_setupxfer.
drivers/spi/spi_ppc4xx.c | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
index e46292b..9775bf2 100644
--- a/drivers/spi/spi_ppc4xx.c
+++ b/drivers/spi/spi_ppc4xx.c
@@ -151,16 +151,24 @@ static int spi_ppc4xx_setupxfer(struct spi_device *spi, struct spi_transfer *t)
/* Write new configration */
out_8(&hw->regs->mode, cs->mode);
+ /* Start with the generic configuration for this device. */
+ bpw = spi->bits_per_word;
+ cs->speed_hz = spi->max_speed_hz;
+
/*
- * Allow platform reduce the interrupt load on the CPU during SPI
- * transfers. We do not target maximum performance, but rather allow
- * platform to limit SPI bus frequency and interrupt rate.
+ * Allow the platform to reduce the interrupt load on the CPU during
+ * SPI transfers. We do not target maximum performance, but rather
+ * allow the platform to limit SPI bus frequency and interrupt rate.
*/
- bpw = t ? t->bits_per_word : spi->bits_per_word;
- cs->speed_hz = t ? min(t->speed_hz, spi->max_speed_hz) :
- spi->max_speed_hz;
+ if(t) {
+ if(t->bits_per_word)
+ bpw = t->bits_per_word;
+
+ if(t->speed_hz)
+ cs->speed_hz = min(t->speed_hz, spi->max_speed_hz);
+ }
- if (bpw != 8) {
+ if (bpw && bpw != 8) {
dev_err(&spi->dev, "invalid bits-per-word (%d)\n", bpw);
return -EINVAL;
}
--
1.6.0.2
^ permalink raw reply related
* Re: [Question] m25p80 driver versus spi clock rate
From: Stefan Roese @ 2009-06-24 14:33 UTC (permalink / raw)
To: Steven A. Falco
Cc: David Brownell, linuxppc-dev@ozlabs.org, linux-mtd,
Mike Frysinger
In-Reply-To: <4A423750.8080605@harris.com>
On Wednesday 24 June 2009 16:25:20 Steven A. Falco wrote:
> > Speaking of spi_ppc4xx issues ... I still have an oldish
> > copy in my review queue, it needs something like the
> > appended patch. (Plus something to accept bpw == 0.)
> > Is there a newer version?
>
> That is a question for Stefan. Perhaps when I post my patch
> to the PPC list, we can move this further along...
I have to admit that I didn't find the time to rework the driver after David's
latest review. Frankly, this could take some time since I'm currently busy
with other tasks. So it would be great if someone else (Steven?) might pick up
here and resubmit this driver so that we can get it finally included.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: Steven A. Falco @ 2009-06-24 14:25 UTC (permalink / raw)
To: David Brownell, Stefan Roese
Cc: linuxppc-dev@ozlabs.org, linux-mtd, Mike Frysinger
In-Reply-To: <200906231538.40125.david-b@pacbell.net>
David Brownell wrote:
> On Tuesday 23 June 2009, Steven A. Falco wrote:
>> m25p80 spi0.0: invalid bits-per-word (0)
>>
>> This message comes from spi_ppc4xx_setupxfer. I believe your patch
>> is doing what you intended (i.e. forcing an initial call to
>> spi_ppc4xx_setupxfer), but it exposes an OF / SPI linkage problem.
>>
>> Namely, of_register_spi_devices does not support a bits-per-word
>> property, so bits-per-word is zero.
>
> Bits-per-word == 0 must be interpreted as == 8.
>
> Simple bug in the ppc4xx code. It currently rejects
> values other than 8.
Ok - I'll post a patch for that. Your changes to bitbang_work look
good. I'm not clear on why you first set do_setup = -1 but later
use do_setup = 1. Perhaps they should both be "1". Other than that,
Acked-by: Steven A. Falco <sfalco@harris.com>
>
> Speaking of spi_ppc4xx issues ... I still have an oldish
> copy in my review queue, it needs something like the
> appended patch. (Plus something to accept bpw == 0.)
> Is there a newer version?
That is a question for Stefan. Perhaps when I post my patch
to the PPC list, we can move this further along...
Steve
^ permalink raw reply
* Re: 85xx Address space query
From: Kumar Gala @ 2009-06-24 13:15 UTC (permalink / raw)
To: kernel mailz; +Cc: linuxppc-dev
In-Reply-To: <abe8a1fd0906240244i6e33c260xadff5cf462df7b8c@mail.gmail.com>
On Jun 24, 2009, at 4:44 AM, kernel mailz wrote:
> Hi,
>
> I am a newbie, trying to learn but have a few queries, nice if you
> could respond
> For linux on 85xx systems...
>
> (a) Kernel code runs in PR=0 AS=0 and PID=0, which user space
> application run in PR=1 AS=0 and PID 1-255.
> Is this correct.
correct.
> (b) I am writing a small program where the application code opens
> invokes a ioctl call and passes a buffer pointer ( say 0x10000 in
> user space)
> Now the driver code is using copy_from_user.
> How this works internally ?
>
> 1. User code executes ioctl
> 2. interrupt goes to the kernel
On the interrupt the PR changes from 0 -> 1
> 3. ioctl handler in driver gets invoked
> The buffer pointer still contains 0x10000.
>
> How kernel code running in PR=0 accesses it and does the copy. I am
> not able to see a address space switch in the asm code of
> copy_tofrom_user.
There isn't a address space switch. But address spaces exist at the
same time. The user app is given 0..0xc000_0000 and the kernel uses
0xc000_0000..0xffff_ffff.
- k
^ permalink raw reply
* [PATCH] net/gianfar: add missing set_mac_address hook
From: Li Yang @ 2009-06-24 13:04 UTC (permalink / raw)
To: davem; +Cc: netdev, Li Yang, linuxppc-dev
Add the missing ndo_set_mac_address function to enable changing MAC
address. Also remove the unnecessary gfar_set_mac_address function.
Signed-off-by: Li Yang <leoli@freescale.com>
Acked-by: Andy Fleming <afleming@freescale.com>
---
drivers/net/gianfar.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 4ae1d25..f526c99 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -111,7 +111,6 @@ static int gfar_close(struct net_device *dev);
struct sk_buff *gfar_new_skb(struct net_device *dev);
static void gfar_new_rxbdp(struct net_device *dev, struct rxbd8 *bdp,
struct sk_buff *skb);
-static int gfar_set_mac_address(struct net_device *dev);
static int gfar_change_mtu(struct net_device *dev, int new_mtu);
static irqreturn_t gfar_error(int irq, void *dev_id);
static irqreturn_t gfar_transmit(int irq, void *dev_id);
@@ -142,6 +141,7 @@ void gfar_start(struct net_device *dev);
static void gfar_clear_exact_match(struct net_device *dev);
static void gfar_set_mac_for_addr(struct net_device *dev, int num, u8 *addr);
static int gfar_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
+static int gfar_set_mac_addr(struct net_device *dev, void *p)
MODULE_AUTHOR("Freescale Semiconductor, Inc");
MODULE_DESCRIPTION("Gianfar Ethernet Driver");
@@ -156,6 +156,7 @@ static const struct net_device_ops gfar_netdev_ops = {
.ndo_tx_timeout = gfar_timeout,
.ndo_do_ioctl = gfar_ioctl,
.ndo_vlan_rx_register = gfar_vlan_rx_register,
+ .ndo_set_mac_address = gfar_set_mac_addr,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = gfar_netpoll,
#endif
@@ -1182,7 +1183,7 @@ static int gfar_enet_open(struct net_device *dev)
/* Initialize a bunch of registers */
init_registers(dev);
- gfar_set_mac_address(dev);
+ gfar_set_mac_for_addr(dev, 0, dev->dev_addr);
err = init_phy(dev);
@@ -1426,15 +1427,19 @@ static int gfar_close(struct net_device *dev)
return 0;
}
-/* Changes the mac address if the controller is not running. */
-static int gfar_set_mac_address(struct net_device *dev)
+/* Changes the station mac address on the go */
+static int gfar_set_mac_addr(struct net_device *dev, void *p)
{
- gfar_set_mac_for_addr(dev, 0, dev->dev_addr);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+ memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
+ gfar_set_mac_for_addr(dev, 0, dev->dev_addr);
return 0;
}
-
/* Enables and disables VLAN insertion/extraction */
static void gfar_vlan_rx_register(struct net_device *dev,
struct vlan_group *grp)
--
1.6.3.1.6.g4bf1f
^ permalink raw reply related
* Re: ALSA fixes for non-coherent ppc32 again
From: Takashi Iwai @ 2009-06-24 9:47 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20090624084601.273130@gmx.net>
At Wed, 24 Jun 2009 10:46:01 +0200,
Gerhard Pircher wrote:
>
>
> -------- Original-Nachricht --------
> > Datum: Tue, 23 Jun 2009 23:42:24 +0200
> > Von: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> > An: benh@kernel.crashing.org, tiwai@suse.de
> > CC: linuxppc-dev@ozlabs.org
> > Betreff: Re: ALSA fixes for non-coherent ppc32 again
>
> > Okay, that's wrong. I somehow messed up the .config file. It doesn't
> > compile, too.
> I got it to compile now and it seems to work fine. I overlooked a typo
> in sound/core/Makefile first (ifndef CONFIG_SND_NONCOHERNT_DMA.)
Gah, thanks, fixed now on the git tree too.
Takashi
^ permalink raw reply
* 85xx Address space query
From: kernel mailz @ 2009-06-24 9:44 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
Hi,
I am a newbie, trying to learn but have a few queries, nice if you could
respond
For linux on 85xx systems...
(a) Kernel code runs in PR=0 AS=0 and PID=0, which user space application
run in PR=1 AS=0 and PID 1-255.
Is this correct.
(b) I am writing a small program where the application code opens invokes a
ioctl call and passes a buffer pointer ( say 0x10000 in user space)
Now the driver code is using copy_from_user.
How this works internally ?
1. User code executes ioctl
2. interrupt goes to the kernel
3. ioctl handler in driver gets invoked
The buffer pointer still contains 0x10000.
How kernel code running in PR=0 accesses it and does the copy. I am not able
to see a address space switch in the asm code of copy_tofrom_user.
Please respond
-TRX
[-- Attachment #2: Type: text/html, Size: 855 bytes --]
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Benjamin Herrenschmidt @ 2009-06-24 9:31 UTC (permalink / raw)
To: michael
Cc: Olof Johansson, linuxppc-dev, debian-powerpc,
Guennadi Liakhovetski, blackluck
In-Reply-To: <1245824392.9237.85.camel@concordia>
On Wed, 2009-06-24 at 16:19 +1000, Michael Ellerman wrote:
> sym53c8xx 0000:00:0c.0: enabling device (0140 -> 0143)
> sym0: <896> rev 0x7 at pci 0000:00:0c.0 irq 17
> sym0: No NVRAM, ID 7, Fast-40, SE, parity checking
> _mpic_irq_read: val 0x80480004 shadow 0x80080014
> _mpic_irq_read: val 0x480004 shadow 0x480004
Strange.. it's like we read a different vector and polarity than
what is in the cache. Oh well, I'll have a closer look tomorrow
in the office.
Ben.
^ permalink raw reply
* [PATCH] pseries: cpu: Reduce the polling interval in __cpu_up()
From: Gautham R Shenoy @ 2009-06-24 9:26 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: Nathan Lynch
Time time taken for a single cpu online operation on a pseries machine
is as follows:
Dedicated LPAR (POWER6): ~220ms.
Shared LPAR (POWER5) : ~240ms.
Of this time, approximately 200ms is taken up by __cpu_up(). This is because
we poll every 200ms to check if the new cpu has notified it's presence
through the cpu_callin_map. We repeat this operation until the new cpu sets
the value in cpu_callin_map or 5 seconds elapse, whichever comes earlier.
However, using completion_structs instead of polling loops,
the time taken by the new processor to indicate it's presence has
found to be less than 1ms on pseries. This method however may not
work on all powerpc platforms due to the time-base synchronization code.
Keeping this in mind, we could reduce msleep polling interval from
200ms to 1ms while retaining the 5 second timeout.
With this, the time taken for a cpu online operation changes as follows:
Dedicated LPAR (POWER6): 20-25ms.
Shared LPAR (POWER5) : 60-80ms.
In both these cases, it was found that the code polls through the loop
only once indicating that 1ms is a reasonable value, atleast on pseries.
The code needs testing on other powerpc platforms.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
---
arch/powerpc/kernel/smp.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 65484b2..00c13a1 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -411,9 +411,8 @@ int __cpuinit __cpu_up(unsigned int cpu)
* CPUs can take much longer to come up in the
* hotplug case. Wait five seconds.
*/
- for (c = 25; c && !cpu_callin_map[cpu]; c--) {
- msleep(200);
- }
+ for (c = 5000; c && !cpu_callin_map[cpu]; c--)
+ msleep(1);
#endif
if (!cpu_callin_map[cpu]) {
^ permalink raw reply related
* Re: ALSA fixes for non-coherent ppc32 again
From: Gerhard Pircher @ 2009-06-24 8:46 UTC (permalink / raw)
To: tiwai, benh; +Cc: linuxppc-dev
In-Reply-To: <20090623214224.104620@gmx.net>
-------- Original-Nachricht --------
> Datum: Tue, 23 Jun 2009 23:42:24 +0200
> Von: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> An: benh@kernel.crashing.org, tiwai@suse.de
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: ALSA fixes for non-coherent ppc32 again
> Okay, that's wrong. I somehow messed up the .config file. It doesn't
> compile, too.
I got it to compile now and it seems to work fine. I overlooked a typo
in sound/core/Makefile first (ifndef CONFIG_SND_NONCOHERNT_DMA.)
^
I vote for a merge, if the config option and the typo is fixed. Ben,
should I resend a properly formatted patch for the dma_mmap_coherent
implementation or can we take the patch I already sent?
Thanks!
Gerhard
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Michael Ellerman @ 2009-06-24 6:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linuxppc-dev, debian-powerpc,
Guennadi Liakhovetski, blackluck
In-Reply-To: <1245823019.10356.69.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]
On Wed, 2009-06-24 at 15:56 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-06-24 at 15:53 +1000, Michael Ellerman wrote:
> > Doesn't fix my machine :/
> >
> That doesn't make sense ... What if you remove the bit inside the ifdef
> CONFIG_MPIC_BROKEN_REGREAD in _mpic_read() ?
>
> If that makes a difference, then it would be interesting to add a printk
> in there that prints what the original value "val" is and what we have
> in the shadow...
With this patch it boots:
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 2353adc..fc17289 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -231,13 +231,16 @@ static inline u32 _mpic_irq_read(struct mpic *mpic, unsign
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
unsigned int val;
+ unsigned int shadow;
val = _mpic_read(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)));
#ifdef CONFIG_MPIC_BROKEN_REGREAD
- if (reg == 0)
- val = (val & (MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY)) |
+ if (reg == 0) {
+ shadow = (val & (MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY)) |
mpic->isu_reg0_shadow[idx];
+ printk("%s: val 0x%x shadow 0x%x\n", __func__, val, shadow);
+ }
#endif
return val;
}
And I see:
sym53c8xx 0000:00:0c.0: enabling device (0140 -> 0143)
sym0: <896> rev 0x7 at pci 0000:00:0c.0 irq 17
sym0: No NVRAM, ID 7, Fast-40, SE, parity checking
_mpic_irq_read: val 0x80480004 shadow 0x80080014
_mpic_irq_read: val 0x480004 shadow 0x480004
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Benjamin Herrenschmidt @ 2009-06-24 5:56 UTC (permalink / raw)
To: michael
Cc: Olof Johansson, linuxppc-dev, debian-powerpc,
Guennadi Liakhovetski, blackluck
In-Reply-To: <1245822826.9237.62.camel@concordia>
On Wed, 2009-06-24 at 15:53 +1000, Michael Ellerman wrote:
> Doesn't fix my machine :/
>
That doesn't make sense ... What if you remove the bit inside the ifdef
CONFIG_MPIC_BROKEN_REGREAD in _mpic_read() ?
If that makes a difference, then it would be interesting to add a printk
in there that prints what the original value "val" is and what we have
in the shadow...
Cheers,
Ben.
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Michael Ellerman @ 2009-06-24 5:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linuxppc-dev, debian-powerpc,
Guennadi Liakhovetski, blackluck
In-Reply-To: <1245799792.10356.42.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
On Wed, 2009-06-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-06-24 at 07:57 +1000, Benjamin Herrenschmidt wrote:
> > > I tried on a POWER3 box I have here "IBM,7044-170" and things work fine
> > > here with current upstream. (I suspect a much smaller machine).
> > >
> > > I will really need an actual bisection here... In the meantime, I'll see
> > > if I can get my hand on one of these machines here.
> >
> > Ok so I think we may have found it... looks like
> > CONFIG_MPIC_BROKEN_REGREAD is what breaks it which is enabled by PA-Semi
> > support in the .config.
> >
> > Can you verify that disabling PA-Semi support removes that option from
> > your .config and that once removed, it works again ?
> >
> > We don't know yet -why- it breaks it, still investigating.
>
> Do the following patch also fix it ?
Doesn't fix my machine :/
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: Fix mapping of "DCR" based MPIC variants
From: Akira Tsukamoto @ 2009-06-24 5:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20090623024807.170CADDD1C@ozlabs.org>
Hi Benjamin,
On Tue, 23 Jun 2009 12:47:59 +1000,
Benjamin Herrenschmidt <benh@kernel.crashing.org> mentioned:
> Commit 31207dab7d2e63795eb15823947bd2f7025b08e2
> "Fix incorrect allocation of interrupt rev-map"
> introduced a regression crashing on boot on machines using
> a "DCR" based MPIC, such as the Cell blades.
>
> The reason is that the irq host data structure is initialized
> much later as a result of that patch, causing our calls to
> mpic_map() do be done before we have a host setup.
>
> Unfortunately, this breaks _mpic_map_dcr() which uses the
> mpic->irqhost to get to the device node.
>
> This fixes it by, instead, passing the device node explicitely
> to mpic_map().
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> arch/powerpc/sysdev/mpic.c | 29 ++++++++++++++++-------------
> 1 file changed, 16 insertions(+), 13 deletions(-)
I confirmed that the boot failure on IBM Cell Blades QS21/22 are fixed
with this patch.
Acked-by: Akira Tsukamoto <akirat@rd.scei.sony.co.jp>
--
Akira Tsukamoto
Sony Computer Entertainment Inc.
Architecture Lab.
Japan
^ permalink raw reply
* Re: How the kernel printk works before do console_setup.
From: Tim Bird @ 2009-06-24 5:03 UTC (permalink / raw)
To: Johnny Hung; +Cc: linuxppc-dev, linux-kernel, linux-embedded
In-Reply-To: <cb9ecdfa0906232050n6fcfee31ubeee4bcd9b8c0dfe@mail.gmail.com>
Johnny Hung wrote:
> Hi All:
> I have a powerpc arch platform. The default console is ttyS1 not
> ttyS0 in the platform. My question is how the kernel print debug
> message
> like DBG before parse kernel command line and do console_setup
> function. The command line passed to kernel about console info is
> console=ttyS1.
> So kernel can not print anything before parse cmd line and initial
> console but the result is against. Anyone point me or give me a clue
> is appreciate.
Before the console is set up, the printk data is formatted
and put into the kernel log buffer, but not sent to any console.
Any messages printk'ed before that are buffered but do not
appear. When the console is initialized, then all buffered
messages are sent to the console, and subsequent printks cause
the message to go to the log buffer, but then immediately
get sent from there to the console.
Under certain conditions you can examine the log buffer of
a kernel that failed to initialize it's console, after a
warm reset of the machine, using the firmware memory dump
command.
See http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot
for some tips on accessing the log buffer of a previous boot.
Note also, that if the serial console does not come up,
but the kernel successfully boots, and you can get a network
login on the machine, you can always print out the kernel log
buffer messages using 'dmesg' at a user-space shell prompt.
Hope this helps!
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* How the kernel printk works before do console_setup.
From: Johnny Hung @ 2009-06-24 3:50 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-embedded
Hi All:
I have a powerpc arch platform. The default console is ttyS1 not
ttyS0 in the platform. My question is how the kernel print debug
message
like DBG before parse kernel command line and do console_setup
function. The command line passed to kernel about console info is
console=ttyS1.
So kernel can not print anything before parse cmd line and initial
console but the result is against. Anyone point me or give me a clue
is appreciate.
BR, H. Johnny
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Use pr_devel() in ps3/mm.c
From: Michael Ellerman @ 2009-06-24 0:55 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <4A4108A3.8060003@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
On Tue, 2009-06-23 at 09:53 -0700, Geoff Levand wrote:
> On 06/22/2009 06:56 PM, Michael Ellerman wrote:
> > The non-debug case in ps3/mm.c uses pr_debug(), so that the compiler
> > still does type checks etc. and doesn't complain about unused
> > variables in the non-debug case.
> >
> > However with DEBUG=n and CONFIG_DYNAMIC_DEBUG=y there's still code
> > generated for those pr_debugs().
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > ---
> > arch/powerpc/platforms/ps3/mm.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Looks good, thanks. I put it on the todo list to go through
> the the remaining PS3 code to check for the same.
Cool, I've been slowly going through as I have time but I'll leave ps3
to you. I see ~270 uses in 9 files.
There are places where being able to dynamically enable the debug is
useful, but there are plenty where it's not also.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Michael Ellerman @ 2009-06-24 0:27 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, kexec, miltonm, Simon Horman
In-Reply-To: <20090623135604.GC1157@hmsreliant.think-freely.org>
[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]
On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote:
> On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote:
> > On Wed, Jun 17, 2009 at 10:40:07AM -0400, Neil Horman wrote:
> >
> > > > send objdump of fs2dt.o with and without this assignment.
> > > >
> > > That would be a fine thing to do, and I'd be happy to compare them. My though
> > > regarding the comparison of the device tree on a good and bad run was meant to
> > > expidite what change in the assembly we'd be looking for. If its the kdump
> > > kernel boot thats hanging, Its likely hanging on something in the device tree,
> > > as thats whats being manipulated by this code. So I figure that understanding
> > > whats changed there will point us toward what change in the assembly might be
> > > responsible for the hang. The assmebly's going to be signficantly different
> > > (lots of optimization might be lost from no longer inlining a function), so
> > > anything that helps us narrow down whats changed will be good
> >
> > I am attaching the objdumps of fs2dt with and without dt_len.
> >
> Well it definately looks like removing that variable had some code changes.
> It'll take some time to match it up to source, but Most interesting I think is
> the variance in putprops around address f34. Looks like its doing some string
> maniuplation in a reversed order, using a huge offset. Might be worthwhile to
> check to see if theres any string overruns in this code.
Yeah I still suspect it's just a bug in the code that's being exposed
now.
Mohan, can you try running it under valgrind?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Benjamin Herrenschmidt @ 2009-06-23 23:29 UTC (permalink / raw)
To: blackluck
Cc: Olof Johansson, linuxppc-dev, debian-powerpc,
Guennadi Liakhovetski
In-Reply-To: <1245794228.10356.31.camel@pasglop>
On Wed, 2009-06-24 at 07:57 +1000, Benjamin Herrenschmidt wrote:
> > I tried on a POWER3 box I have here "IBM,7044-170" and things work fine
> > here with current upstream. (I suspect a much smaller machine).
> >
> > I will really need an actual bisection here... In the meantime, I'll see
> > if I can get my hand on one of these machines here.
>
> Ok so I think we may have found it... looks like
> CONFIG_MPIC_BROKEN_REGREAD is what breaks it which is enabled by PA-Semi
> support in the .config.
>
> Can you verify that disabling PA-Semi support removes that option from
> your .config and that once removed, it works again ?
>
> We don't know yet -why- it breaks it, still investigating.
Do the following patch also fix it ?
Index: linux-work/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux-work.orig/arch/powerpc/sysdev/mpic.c 2009-06-24 09:24:51.000000000 +1000
+++ linux-work/arch/powerpc/sysdev/mpic.c 2009-06-24 09:26:45.000000000 +1000
@@ -230,14 +230,16 @@ static inline u32 _mpic_irq_read(struct
{
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
+ unsigned int val;
+ val = _mpic_read(mpic->reg_type, &mpic->isus[isu],
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
#ifdef CONFIG_MPIC_BROKEN_REGREAD
if (reg == 0)
- return mpic->isu_reg0_shadow[idx];
- else
+ val = (val & (MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY)) |
+ mpic->isu_reg0_shadow[idx];
#endif
- return _mpic_read(mpic->reg_type, &mpic->isus[isu],
- reg + (idx * MPIC_INFO(IRQ_STRIDE)));
+ return val;
}
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -251,7 +253,8 @@ static inline void _mpic_irq_write(struc
#ifdef CONFIG_MPIC_BROKEN_REGREAD
if (reg == 0)
- mpic->isu_reg0_shadow[idx] = value;
+ mpic->isu_reg0_shadow[idx] =
+ value & ~(MPIC_VECPRI_MASK | MPIC_VECPRI_ACTIVITY);
#endif
}
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: David Brownell @ 2009-06-23 22:38 UTC (permalink / raw)
To: Steven A. Falco
Cc: linuxppc-dev@ozlabs.org, Stefan Roese, linux-mtd, Mike Frysinger
In-Reply-To: <4A414E07.5050303@harris.com>
On Tuesday 23 June 2009, Steven A. Falco wrote:
> m25p80 spi0.0: invalid bits-per-word (0)
>
> This message comes from spi_ppc4xx_setupxfer. I believe your patch
> is doing what you intended (i.e. forcing an initial call to
> spi_ppc4xx_setupxfer), but it exposes an OF / SPI linkage problem.
>
> Namely, of_register_spi_devices does not support a bits-per-word
> property, so bits-per-word is zero.
Bits-per-word == 0 must be interpreted as == 8.
Simple bug in the ppc4xx code. It currently rejects
values other than 8.
Speaking of spi_ppc4xx issues ... I still have an oldish
copy in my review queue, it needs something like the
appended patch. (Plus something to accept bpw == 0.)
Is there a newer version?
- Dave
--- a/drivers/spi/spi_ppc4xx.c
+++ b/drivers/spi/spi_ppc4xx.c
@@ -61,9 +61,6 @@
/* RxD ready */
#define SPI_PPC4XX_SR_RBR (0x80 >> 7)
-/* the spi->mode bits understood by this driver: */
-#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
-
/* clock settings (SCP and CI) for various SPI modes */
#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
#define SPI_CLK_MODE1 0
@@ -198,9 +195,6 @@ static int spi_ppc4xx_setup(struct spi_d
struct spi_ppc4xx_cs *cs = spi->controller_state;
int init = 0;
- if (!spi->bits_per_word)
- spi->bits_per_word = 8;
-
if (spi->bits_per_word != 8) {
dev_err(&spi->dev, "invalid bits-per-word (%d)\n",
spi->bits_per_word);
@@ -212,12 +206,6 @@ static int spi_ppc4xx_setup(struct spi_d
return -EINVAL;
}
- if (spi->mode & ~MODEBITS) {
- dev_dbg(&spi->dev, "setup: unsupported mode bits %x\n",
- spi->mode & ~MODEBITS);
- return -EINVAL;
- }
-
if (cs == NULL) {
cs = kzalloc(sizeof *cs, GFP_KERNEL);
if (!cs)
@@ -268,10 +256,6 @@ static int spi_ppc4xx_setup(struct spi_d
}
}
- dev_dbg(&spi->dev, "%s: mode %d, %u bpw, %d hz\n",
- __func__, spi->mode, spi->bits_per_word,
- spi->max_speed_hz);
-
return 0;
}
@@ -442,6 +426,9 @@ static int __init spi_ppc4xx_of_probe(st
}
}
+ /* the spi->mode bits understood by this driver: */
+ master->modebits = SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST;
+
/* Setup the state for the bitbang driver */
bbp = &hw->bitbang;
bbp->master = hw->master;
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: Steven A. Falco @ 2009-06-23 21:49 UTC (permalink / raw)
To: David Brownell
Cc: linuxppc-dev@ozlabs.org, Stefan Roese, linux-mtd, Mike Frysinger
In-Reply-To: <200906231408.26912.david-b@pacbell.net>
Sorry to cross-post this to linuxppc-dev@ozlabs.org in the middle
of the story. I started this in linux-mtd@lists.infradead.org, but
there are OF issues here, and I'd like the PPC folks to be aware of
the issues.
David Brownell wrote:
> On Tuesday 23 June 2009, Steven A. Falco wrote:
>> David Brownell wrote:
>> The linkage appears correct - max_speed_hz is set correctly for each
>> device. The problem is that bitbang_work won't call spi_ppc4xx_setupxfer
>> unless speed_hz is non-zero, and m25p80 has no way to alter speed_hz.
>
> Or alternatively: that bitbang_work is missing an initial
> call to setup_xfer before the loop *starts* its work...
>
> I think the issue is that few other users have used this
> code with multiple devices, which had such mismatches in
> device speed that they would have noticed this bug.
>
> See if the below patch resolves this issue.
>
Fascinating. I now get a fatal error:
m25p80 spi0.0: invalid bits-per-word (0)
This message comes from spi_ppc4xx_setupxfer. I believe your patch
is doing what you intended (i.e. forcing an initial call to
spi_ppc4xx_setupxfer), but it exposes an OF / SPI linkage problem.
Namely, of_register_spi_devices does not support a bits-per-word
property, so bits-per-word is zero.
Since we had never called spi_ppc4xx_setupxfer for the m25p80, we
never saw this until now...
Here is part of spi_ppc4xx_setupxfer:
/*
* Allow platform reduce the interrupt load on the CPU during SPI
* transfers. We do not target maximum performance, but rather allow
* platform to limit SPI bus frequency and interrupt rate.
*/
bpw = t ? t->bits_per_word : spi->bits_per_word;
cs->speed_hz = t ? min(t->speed_hz, spi->max_speed_hz) :
spi->max_speed_hz;
if (bpw != 8) {
dev_err(&spi->dev, "invalid bits-per-word (%d)\n", bpw);
return -EINVAL;
}
if (cs->speed_hz == 0) {
dev_err(&spi->dev, "invalid speed_hz (must be non-zero)\n");
return -EINVAL;
}
Actually, the problem is not entirely with of_register_spi_devices.
bitbang_work will call spi_ppc4xx_setupxfer with a non-null
spi_transfer. So, the above code will always set bpw based on
t->bits_per_word. If t->bits_per_word is zero, it wouldn't even matter
if of_register_spi_devices set spi->bits_per_word, because the
transfer would override it.
How about:
bpw = t && t->bits_per_word ? t->bits_per_word : spi->bits_per_word;
Now, t->bits_per_word would have to be non-zero in order to override
spi->bits_per_word.
We would still need a patch to of_register_spi_devices to allow (require)
a bits-per-word property, along with device tree patches to add the
property. But that should take care of it.
I'm adding the ppc list as a CC, since this is turning into an OF
discussion.
Steve
> - Dave
>
>
> ---
> drivers/spi/spi_bitbang.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> --- a/drivers/spi/spi_bitbang.c
> +++ b/drivers/spi/spi_bitbang.c
> @@ -258,6 +258,11 @@ static void bitbang_work(struct work_str
> struct spi_bitbang *bitbang =
> container_of(work, struct spi_bitbang, work);
> unsigned long flags;
> + int do_setup = -1;
> + int (*setup_transfer)(struct spi_device *,
> + struct spi_transfer *);
> +
> + setup_transfer = bitbang->setup_transfer;
>
> spin_lock_irqsave(&bitbang->lock, flags);
> bitbang->busy = 1;
> @@ -269,8 +274,6 @@ static void bitbang_work(struct work_str
> unsigned tmp;
> unsigned cs_change;
> int status;
> - int (*setup_transfer)(struct spi_device *,
> - struct spi_transfer *);
>
> m = container_of(bitbang->queue.next, struct spi_message,
> queue);
> @@ -286,19 +289,19 @@ static void bitbang_work(struct work_str
> tmp = 0;
> cs_change = (spi != bitbang->exclusive);
> status = 0;
> - setup_transfer = NULL;
>
> list_for_each_entry (t, &m->transfers, transfer_list) {
>
> - /* override or restore speed and wordsize */
> - if (t->speed_hz || t->bits_per_word) {
> - setup_transfer = bitbang->setup_transfer;
> + /* override speed or wordsize? */
> + if (t->speed_hz || t->bits_per_word)
> + do_setup = 1;
> +
> + /* init or override transfer params */
> + if (do_setup != 0) {
> if (!setup_transfer) {
> status = -ENOPROTOOPT;
> break;
> }
> - }
> - if (setup_transfer) {
> status = setup_transfer(spi, t);
> if (status < 0)
> break;
> @@ -362,8 +365,9 @@ static void bitbang_work(struct work_str
> m->status = status;
>
> /* restore speed and wordsize */
> - if (setup_transfer)
> + if (do_setup == 1)
> setup_transfer(spi, NULL);
> + do_setup = 0;
>
> /* normally deactivate chipselect ... unless no error and
> * cs_change has hinted that the next message will probably
--
A: Because it makes the logic of the discussion difficult to follow.
Q: Why shouldn't I top post?
A: No.
Q: Should I top post?
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Benjamin Herrenschmidt @ 2009-06-23 21:57 UTC (permalink / raw)
To: blackluck
Cc: Olof Johansson, linuxppc-dev, debian-powerpc,
Guennadi Liakhovetski
In-Reply-To: <1245724218.4017.35.camel@pasglop>
> I tried on a POWER3 box I have here "IBM,7044-170" and things work fine
> here with current upstream. (I suspect a much smaller machine).
>
> I will really need an actual bisection here... In the meantime, I'll see
> if I can get my hand on one of these machines here.
Ok so I think we may have found it... looks like
CONFIG_MPIC_BROKEN_REGREAD is what breaks it which is enabled by PA-Semi
support in the .config.
Can you verify that disabling PA-Semi support removes that option from
your .config and that once removed, it works again ?
We don't know yet -why- it breaks it, still investigating.
Cheers,
Ben.
> Cheers,
> Ben.
>
> > Cheers,
> > Ben.
> >
> > > Thanks: blackluck
> > >
> > > Laszlo Fekete wrote:
> > > > Hello!
> > > >
> > > > I'm sorry about the annoyances, but I'd welcome all ideas, suggestions
> > > > to see what needs to be done or should be tested for the solution.
> > > >
> > > > Thank you very much!
> > > >
> > > > Guennadi Liakhovetski wrote:
> > > >> Ok, first attempt to forward this to scsi was wrong, as pointed out
> > > >> by Matthew Wilcox this does indeed look like an interrupt problem -
> > > >> no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I
> > > >> guess. In any case, I think, the OP would be grateful for any hints.
> > > >>
> > > >> Thanks
> > > >> Guennadi
> > > >> ---
> > > >> Guennadi Liakhovetski, Ph.D.
> > > >> Freelance Open-Source Software Developer
> > > >> http://www.open-technology.de/
> > > >>
> > > >> ---------- Forwarded message ----------
> > > >> Date: Sat, 13 Jun 2009 16:22:07 +0200
> > > >> From: Laszlo Fekete <blackluck@ktk.bme.hu>
> > > >> To: debian-powerpc@lists.debian.org
> > > >> Subject: sym scsi driver problem with 2.6.26 or newer debian kernel
> > > >> on p610
> > > >> Resent-Date: Sat, 13 Jun 2009 14:29:55 +0000 (UTC)
> > > >> Resent-From: debian-powerpc@lists.debian.org
> > > >>
> > > >> This is a multi-part message in MIME format.
> > > >> ------------------------------------------------------------------------
> > > >>
> > > >> Hello!
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Pls help me with sym scsi driver problem.
> > > >>
> > > >>
> > > >>
> > > >> I have Ibm P610 (and tested it on P630 and P640 too), installed debian
> > > >>
> > > >> etch and upgraded to lenny.
> > > >>
> > > >>
> > > >>
> > > >> But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi
> > > >>
> > > >> bus scan.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Whats the problem with it, or how can I fix this?
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> I attach the output from minicom with 2.6.29, 2.6.26, and the working
> > > >>
> > > >> 2.6.24 kernel booting.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Thank you very much!
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: ALSA fixes for non-coherent ppc32 again
From: Gerhard Pircher @ 2009-06-23 21:42 UTC (permalink / raw)
To: benh, tiwai; +Cc: linuxppc-dev
In-Reply-To: <20090623085554.9200@gmx.net>
-------- Original-Nachricht --------
> Datum: Tue, 23 Jun 2009 10:55:54 +0200
> Von: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> An: Takashi Iwai <tiwai@suse.de>, benh@kernel.crashing.org
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: ALSA fixes for non-coherent ppc32 again
>
> -------- Original-Nachricht --------
> > Datum: Mon, 22 Jun 2009 09:12:35 +0200
> > Von: Takashi Iwai <tiwai@suse.de>
> > An: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > CC: Gerhard Pircher <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> > Betreff: Re: ALSA fixes for non-coherent ppc32 again
>
> > But, it'd be helpful if someone can test the patches above beforehand,
> > of course :)
> Okay, I checked out your test/dma-fix branch and reformatted your
> dma_mmap_coherent for powerpc patch (
> http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027 ) to
> adapt it for dma_mapping_ops (please take a look at the patch below).
> I also had to change "def_bool n" to "def_bool y" for SND_NONCOHERENT_DMA
> to actually enable it.
>
> Unfortunately the build process stops with these error messages here
> (but compiles fine, if SND_COHERENT_DMA is not selected):
>
> CC [M] sound/core/memalloc.o
> CC [M] sound/core/sgbuf.o
> sound/core/sgbuf.c: In function ‘snd_free_sgbuf_pages’:
> sound/core/sgbuf.c:46: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:47: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:48: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:50: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:51: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:52: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:56: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:57: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c: In function ‘snd_malloc_sgbuf_pages’:
> sound/core/sgbuf.c:78: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:81: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:82: error: implicit declaration of function
> ‘snd_sgbuf_aligned_pages’
> sound/core/sgbuf.c:83: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:84: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:87: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:88: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:91: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:103: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:107: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:112: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:113: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:115: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:116: error: increment of pointer to unknown structure
> sound/core/sgbuf.c:116: error: arithmetic on pointer to an incomplete type
> sound/core/sgbuf.c:121: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:127: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:128: error: dereferencing pointer to incomplete type
> sound/core/sgbuf.c:132: error: dereferencing pointer to incomplete type
>
> I also tried to compile it with the orginal dma_mmap_coherent for
> powerpc patch, but that doesn't make a difference.
>
> As the next step I applied the reformatted dma_mmap_coherent patch and
> the following patches from your test/dma-fix branch to a 2.6.30-rc8
> branch:
> - ALSA: Remove old DMA-mmap code from arm/devdma.c
> - ALSA: Fix SG-buffer DMA with non-coherent architectures
> - ALSA: Fix mapping of DMA buffers
>
> This one compiled fine, but ALSA didn't work. No kernel oops, just the
> sound of silence. :)
Okay, that's wrong. I somehow messed up the .config file. It doesn't
compile, too.
Gerhard
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
^ permalink raw reply
* Re: [PATCH v2] fbdev: work around old compiler bug
From: Sam Ravnborg @ 2009-06-23 19:23 UTC (permalink / raw)
To: Kyle McMartin
Cc: Stephen Rothwell, James Simmons, ppc-dev, LKML, Krzysztof Helt,
Geert Uytterhoeven, Andrew Morton, Linus
In-Reply-To: <20090623164505.GA3101@bombadil.infradead.org>
On Tue, Jun 23, 2009 at 12:45:05PM -0400, Kyle McMartin wrote:
> On Tue, Jun 23, 2009 at 03:44:28PM +1000, Stephen Rothwell wrote:
> > When building with a 4.1.x compiler on powerpc64 (at least) we get
> > this error:
> >
> > drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a section type conflict
> >
> > This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
> > ("fbdev: move logo externs to header file"). This is a partial revert
> > of that commit sufficient to not hit the compiler bug.
> >
>
> We're seeing similar issues with 4.3 on parisc (the case I saw today was
> in fs/nfs/nfsroot.c...) Any ideas on the actual culprit or is it just
> gcc being unfriendly?
Al analysed this some time ago.
When we say something is const then _sometimes_ gcc annotate the
section as const(*) - sometimes not.
So if we have two variables/functions annotated __*const and
gcc decides to annotate the section const only in one case
we get a section type conflict.
(*) it is named something else I do not recall at the moment
in linker language.
Sam
^ permalink raw reply
* Re: [ewg] Re: [PATCH 2.6.31 try 2] ehca: Tolerate dynamic memory operations and huge pages
From: Roland Dreier @ 2009-06-23 17:30 UTC (permalink / raw)
To: Alexander Schmidt
Cc: Hannes Hering, linux-kernel, ewg, linuxppc-dev, raisch,
Hoang-Nam Nguyen
In-Reply-To: <20090623101123.72690731@BL3D1974.boeblingen.de.ibm.com>
applied...
^ 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