* Re: [PATCH] pseries: cpu: Reduce the polling interval in __cpu_up()
From: Joel Schopp @ 2009-06-24 16:39 UTC (permalink / raw)
To: Gautham R Shenoy; +Cc: Nathan Lynch, linuxppc-dev, linux-kernel
In-Reply-To: <20090624092637.32078.88042.stgit@sofia.in.ibm.com>
>
> The code needs testing on other powerpc platforms.
>
I think given the numbers you showed this is a good improvement, and it
clearly can't do any harm on platforms that implement msleep correctly.
For what it's worth:
Acked-by: Joel Schopp <jschopp@austin.ibm.com>
> 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]) {
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] powerpc/85xx: Fix ethernet link detection on MPC8569E-MDS boards
From: Anton Vorontsov @ 2009-06-24 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Linux isn't able to detect link changes on ethernet ports that were
used by U-Boot. This is because U-Boot wrongly clears interrupt
polarity bit (INTPOL, 0x400) in the extended status register (EXT_SR,
0x1b) of Marvell PHYs.
There is no easy way for PHY drivers to know IRQ line polarity (we
could extract it from the device tree and pass it to phydevs, but
that'll be quite a lot of work), so for now just reset the PHYs to
their default states.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 3268c95..34664c0 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -223,6 +223,19 @@ static void __init mpc85xx_mds_setup_arch(void)
/* Turn UCC1 & UCC2 on */
setbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
setbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
+ } else if (machine_is(mpc8569_mds)) {
+#define BCSR7_UCC12_GETHnRST (0x1 << 2)
+#define BCSR8_UEM_MARVELL_RST (0x1 << 1)
+ /*
+ * U-Boot mangles interrupt polarity for Marvell PHYs,
+ * so reset built-in and UEM Marvell PHYs, this puts
+ * the PHYs into their normal state.
+ */
+ clrbits8(&bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ setbits8(&bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
+
+ setbits8(&bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ clrbits8(&bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
}
iounmap(bcsr_regs);
}
--
1.6.3.1
^ permalink raw reply related
* Re: [Question] m25p80 driver versus spi clock rate
From: Steven A. Falco @ 2009-06-24 16:14 UTC (permalink / raw)
To: David Brownell
Cc: linuxppc-dev@ozlabs.org, Stefan Roese, linux-mtd, Mike Frysinger
In-Reply-To: <200906240813.01220.david-b@pacbell.net>
David Brownell wrote:
> On Wednesday 24 June 2009, Steven A. Falco wrote:
>> Your changes to bitbang_work look good.
>
> You tested?
>
Yes - I built a kernel with your patch, combined with the changes I
just posted to linuxppc-dev@ozlabs.org as:
"[PATCH v1] Make spi_ppc4xx.c tolerate 0 bits-per-word and 0 speed_hz"
I was successful in operating both the m25p16 at 16 MHz and the AVR
at 240 KHz, as verified by oscilloscope. So my "ack" includes testing.
>
>> 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>
>
> The "-1" is for the init path, "1" for per-transfer overrides;
> this way it avoids some extra calls to set up the bits/speed.
Got it. No further comments. My "ack" stands.
I'll start looking at a revised version of the spi_ppc4xx.c driver,
integrating your comments.
Steve
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: David Brownell @ 2009-06-24 15:13 UTC (permalink / raw)
To: Steven A. Falco
Cc: linuxppc-dev@ozlabs.org, Stefan Roese, linux-mtd, Mike Frysinger
In-Reply-To: <4A423750.8080605@harris.com>
On Wednesday 24 June 2009, Steven A. Falco wrote:
> Your changes to bitbang_work look good.
You tested?
> 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>
The "-1" is for the init path, "1" for per-transfer overrides;
this way it avoids some extra calls to set up the bits/speed.
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: Stefan Roese @ 2009-06-24 14:50 UTC (permalink / raw)
To: Steven A. Falco
Cc: David Brownell, linuxppc-dev@ozlabs.org, linux-mtd,
Mike Frysinger
In-Reply-To: <4A423A0A.2010004@harris.com>
On Wednesday 24 June 2009 16:36:58 Steven A. Falco wrote:
> > 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
>
> Ok - I'll take that on.
Great, thanks.
> Please, both David and Stefan send me the latest versions
> and/or patches you have, and I'll integrate them and post
> to the PPC list.
I just sent you my latest driver version (v6). Here a link to David's latest
review:
http://article.gmane.org/gmane.linux.ports.ppc64.devel/55229
Best regards,
Stefan
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: Steven A. Falco @ 2009-06-24 14:36 UTC (permalink / raw)
To: Stefan Roese
Cc: David Brownell, linuxppc-dev@ozlabs.org, linux-mtd,
Mike Frysinger
In-Reply-To: <200906241633.35571.sr@denx.de>
Stefan Roese wrote:
> 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
Ok - I'll take that on.
Please, both David and Stefan send me the latest versions
and/or patches you have, and I'll integrate them and post
to the PPC list.
Steve
--
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
* [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
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