* 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
* 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: 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: 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 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: 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
* [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: 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
* 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: 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
* [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: 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
* 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: [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
* [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: 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
* 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: 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: 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
* [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: [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] ucc_geth: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-24 17:45 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Li Yang, netdev
Currently the half-duplex operation seems to not work reliably for
RGMII/GMII PHY interfaces. It takes about 10 minutes to boot NFS
rootfs using 10/half link, following symptoms were observed:
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC1 at 0xe0082000 (irq = 32)
[...]
Sending DHCP and RARP requests .
PHY: mdio@e0082120:07 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:13.
Freeing unused kernel memory: 204k init
eth0: no IPv6 routers present
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
The statistic shows that there are indeed some errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
tx-64-frames: 42
tx-65-127-frames: 9
tx-128-255-frames: 4768
rx-64-frames: 41
rx-65-127-frames: 260
rx-128-255-frames: 2679
tx-bytes-ok: 859634
tx-multicast-frames: 5
tx-broadcast-frames: 7
rx-frames: 8333
rx-bytes-ok: 8039364
rx-bytes-all: 8039364
stats-counter-mask: 4294901760
tx-single-collision: 324
tx-multiple-collision: 47
tx-late-collsion: 604
tx-aborted-frames: 604
tx-frames-ok: 4967
tx-256-511-frames: 3
tx-512-1023-frames: 79
tx-1024-1518-frames: 71
rx-256-511-frames: 37
rx-512-1023-frames: 73
rx-1024-1518-frames: 5243
According to current QEIWRM (Rev. 2 5/2009), FDX bit can be 0 for
RGMII(10/100) modes, while MPC8568ERM (Rev. C 02/2007) spec says
that cleared FDX bit is permitted for MII/RMII modes only.
The symptoms above were seen on MPC8569E-MDS boards, so QEIWRM is
clearly wrong, and this patch completely cures the problems above.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 464df03..e618cf2 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1469,12 +1469,16 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = in_be32(&ug_regs->maccfg2);
u32 upsmr = in_be32(&uf_regs->upsmr);
+ phy_interface_t phyi = ugeth->phy_interface;
+
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != ugeth->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FDX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII))
+ tempval &= ~MACCFG2_FDX;
else
tempval |= MACCFG2_FDX;
ugeth->oldduplex = phydev->duplex;
--
1.6.3.1
^ permalink raw reply related
* Re: 85xx Address space query
From: kernel mailz @ 2009-06-24 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <D47FC871-1535-4DBF-8617-6EEA8C180484@kernel.crashing.org>
On Wed, Jun 24, 2009 at 6:45 PM, Kumar Gala<galak@kernel.crashing.org> wrot=
e:
>
> 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=3D0 AS=3D0 and PID=3D0, which user space appl=
ication
>> run in PR=3D1 AS=3D0 and PID 1-255.
>> Is this correct.
>
> correct.
>
>> (b) I am writing a small program where the application code opens invoke=
s
>> 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=3D0 accesses it and does the copy. I am no=
t
>> able to see a address space switch in the asm code of copy_tofrom_user.
>
> There isn't a address space switch. =A0But address spaces exist at the sa=
me
> time. =A0The user app is given 0..0xc000_0000 and the kernel uses
> 0xc000_0000..0xffff_ffff.
>
Ah Ok, I get it Thanks Kumar
But If the app was running with PID=3D1, interrupt occurs, kernel code
gets executed in PID=3D1, how does the kernel handle this ? and goes
back to PID=3D0, since its translations are all in PID=3D0
> - k
>
^ permalink raw reply
* Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-24 17:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Li Yang, Ira Snyder
In-Reply-To: <4A40FB26.8080301@intel.com>
Dan Williams wrote:
> Kumar Gala wrote:
>>>> Kumar, Leo,
>>>>
>>>> Can I get your acked-by's for the current state of async_tx.git/
>>>> next? I
>>>> just pushed out Ira's latest so it may take a moment to mirror out.
>>> Acked-by: Li Yang <leoli@freescale.com>
>>>
>>> However, the addition of arch/powerpc/include/asm/fsldma.h still needs
>>> the ack from Kumar. It doesn't seem to be a common practice though.
>> hmm, why are we moving fsldma.h?
>
> There are now two fsldma.h files.
>
> drivers/dma/fsldma.h: no changes, houses the private driver
> implementation details.
>
> arch/powerpc/include/asm/fsldma.h: adds some helper routines and
> definitions for the DMA_SLAVE capability of the driver. It defines an
> interface for other drivers to use fsldma to initiate device-to-memory
> dma. Any drivers that use the interface will depend on CONFIG_FSL_DMA
> hence placing this public header under arch/powerpc/include.
>
Kumar? Shall we push this decision off to 2.6.32, I would prefer not to
as Ira had his initial patches available before the merge window opened?
Ira, aside from the pci read multiple patch are there any others that
are suitable for 2.6.31 if the dma_slave implementation gets held back?
Thanks,
Dan
^ permalink raw reply
* [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-24 18:27 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Li Yang, Andy Fleming, netdev
It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
[...]
Sending DHCP requests .
PHY: mdio@e0024520:02 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:11.
Freeing unused kernel memory: 188k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
And just as with ucc_geth, statistic shows errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
rx-dropped-by-kernel: 2
tx-rx-64-frames: 49
tx-rx-65-127-frames: 1270
tx-rx-128-255-frames: 9992
tx-rx-256-511-frames: 75
tx-rx-512-1023-frames: 142
tx-rx-1024-1518-frames: 8828
rx-bytes: 13299414
rx-packets: 13122
rx-jabber-frames: 9
tx-byte-counter: 1284847
tx-packets: 8115
tx-broadcast-packets: 3
tx-deferral-packets: 43
tx-single-collision-packets: 15
tx-multiple-collision-packets: 301
tx-late-collision-packets: 872
tx-total-collision: 999
tx-undersize-frames: 6
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set.
It's no wonder though, QE Ethernet and TSEC are pretty similar.
[1] http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073631.html
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/gianfar.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..15dbffa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,16 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = gfar_read(®s->maccfg2);
u32 ecntrl = gfar_read(®s->ecntrl);
+ phy_interface_t phyi = phydev->interface;
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FULL_DUPLEX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII))
+ tempval &= ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
--
1.6.3.1
^ permalink raw reply related
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