* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Peter Korsgaard @ 2009-05-28 21:08 UTC (permalink / raw)
To: Esben Haabendal; +Cc: Esben Haabendal, linuxppc-dev, linux-i2c, Ben Dooks
In-Reply-To: <d2b9ea600905281341s24efa4e3l6277a8aa5dec5bd@mail.gmail.com>
>>>>> "Esben" == Esben Haabendal <esbenhaabendal@gmail.com> writes:
Hi,
Esben> It's strange, that line looks perfectly fine when I check the
Esben> mail in my GMail inbox and the outbox from the account I sent
Esben> it from.
Well, it is here and in the archive:
http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072274.html
Please consider using git send-email for patches.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-28 20:41 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: Esben Haabendal, linuxppc-dev, linux-i2c, Ben Dooks
In-Reply-To: <87ws8155md.fsf@macbook.be.48ers.dk>
> =A0Esben> I've checked both my copy in my "Sent" folder and the copy
> =A0Esben> received from the list, and I cannot see any "line break"
> =A0Esben> breakage of the patch.
>
> I guess Wolfram referred to the context line which was clearly word wrapp=
ed:
>
> @@ -456,17 +456,22 @@ static int mpc_xfer(struct i2c_adapter *adap,
> struct i2c_msg *msgs, int num)
>
> The other lines look fine.
It's strange, that line looks perfectly fine when I check the mail in my GM=
ail
inbox and the outbox from the account I sent it from.
/Esben
--=20
Esben Haabendal, Senior Software Consultant
Dor=E9Development ApS, Ved Stranden 1, 9560 Hadsund, DK-Denmark
Phone: +45 51 92 53 93, E-mail: eha@doredevelopment.dk
WWW: http://www.doredevelopment.dk
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Peter Korsgaard @ 2009-05-28 20:34 UTC (permalink / raw)
To: Esben Haabendal; +Cc: Esben Haabendal, linuxppc-dev, linux-i2c, Ben Dooks
In-Reply-To: <d2b9ea600905281310p16f47ed0i454e25bf256d3010@mail.gmail.com>
>>>>> "Esben" == Esben Haabendal <esbenhaabendal@gmail.com> writes:
Hi,
>> I wanted to test it, but it does not apply due to line breaks (check
>> @@-line). Also, I don't really have the time to dig into the topic, so I
>> would only test it and give a tested-by-tag if it doesn't break anything
>> here. I think Joakim would be a good candidate for an acked-by .
Esben> I've checked both my copy in my "Sent" folder and the copy
Esben> received from the list, and I cannot see any "line break"
Esben> breakage of the patch.
I guess Wolfram referred to the context line which was clearly word wrapped:
@@ -456,17 +456,22 @@ static int mpc_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
The other lines look fine.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-28 20:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <fa686aa40905281231o26c74a13v250bcedbd066e77b@mail.gmail.com>
On Thu, May 28, 2009 at 9:31 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Tue, May 26, 2009 at 5:30 AM, Esben Haabendal wrote:
>> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal wrote:
>>> This fixes MAL (arbitration lost) bug caused by illegal use of
>>> RSTA (repeated START) after STOP condition generated after last byte
>>> of reads. With this patch, it is possible to do an i2c_transfer() with
>>> additional i2c_msg's following the I2C_M_RD messages.
>>>
>>> It still needs to be resolved if it is possible to fix this issue
>>> by removing the STOP condition after reads in a robust way.
>>>
>>> Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
>>> ---
>>> =A0drivers/i2c/busses/i2c-mpc.c | =A0 =A09 +++++++--
>>> =A01 files changed, 7 insertions(+), 2 deletions(-)
>>
>> Any blockers to get this accepted?
>
> It helps if you cc: developers/maintainers of the device. =A0ie. Kumar
> for mpc8xxx, me for 52xx.
>
> This is the first time I noticed your posting. =A0It will take me a few
> days before I get a chance to review it.
Kumar, will you take a look at this patch?
/Esben
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-28 20:10 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Esben Haabendal, linux-i2c, Ben Dooks
In-Reply-To: <20090528171726.GE3112@pengutronix.de>
On Thu, May 28, 2009 at 7:17 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>> > Any blockers to get this accepted?
>>
>> It would be nice to get an ack from someone who can actually test
>> the driver before getting this merged.
>
> I wanted to test it, but it does not apply due to line breaks (check
> @@-line). Also, I don't really have the time to dig into the topic, so I
> would only test it and give a tested-by-tag if it doesn't break anything
> here. I think Joakim would be a good candidate for an acked-by .
I've checked both my copy in my "Sent" folder and the copy received
from the list,
and I cannot see any "line break" breakage of the patch.
It must be your mail client that is messing with it, so I cannot really do it
much better in that way.
If necessary, I can push a branch to a public repo you can pull from.
/Esben
^ permalink raw reply
* Re: 8544 external interrupt configuration problems
From: Scott Wood @ 2009-05-28 20:02 UTC (permalink / raw)
To: Nancy Isaac; +Cc: linuxppc-dev
In-Reply-To: <1bcc666d0905281205p63ee8119td5578a749bce8377@mail.gmail.com>
On Thu, May 28, 2009 at 12:05:52PM -0700, Nancy Isaac wrote:
> My device tree has the following entry for my fpga:
>
> CpuCpld\@f0000000{
> compatible = "MPC8544DS";
> device_type = "CpuCpld";
> reg = <f0000000 00000040>;
> interrupts = <41 2 42 2 43 2>;
> interrupt-parent = <&mpic>;
> };
Where did you get those interrupt numbers from? External interrupt
numbers start at zero on MPIC.
Is the level/sense information correct?
> My driver does the mapping to the virq:
>
> np = of_find_node_by_type(NULL, "CpuCpld");
> if (!np) {
> ret = -ENODEV;
> }
> cpldCpuDrv->MateIntIrq = irq_of_parse_and_map(np, 0);
> cpldCpuDrv->FtaIrq = irq_of_parse_and_map(np, 1);
> cpldCpuDrv->ExtractIrq = irq_of_parse_and_map(np, 2);
> cpldCpuDrv->XauiIrq = irq_of_parse_and_map(np, 0);
>
> of_node_put(np);
Looks good (other than that you should be using compatible (with a more
specific name) rather than device_type).
> Does anyone know what the virq should be for these external interrupts?
They're dynamically assigned.
> I've tried specifying the actual irq numbers 1,2 and 3 and that doesn't work
> either.
Specifying them where? In the device tree or as virq numbers? Never
hard-code virq numbers.
> Is there some PCI configuration that's getting in the way? I've tried
> disabling the FSL_PCIE and I get the same behavior.
Barring an unusual bug, PCI should have nothing to do with the interrupt
routing of things that aren't on the PCI bus.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Albrecht Dreß @ 2009-05-28 19:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <OF508468F5.9BFFC168-ONC12575C4.005846FD-C12575C4.00592585@transmode.se>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
Am 28.05.09 18:13 schrieb(en) Joakim Tjernlund:
> hmm, these do look a bit unoptimal anyway. Any reason not to write
> them something like below(written by me for uClibc long time ago).
> You will have to add eieio()/sync
No (and I wasn't aware of the PPC pre-inc vs. post-inc stuff) - I just
stumbled over this while fixing mtd accesses to the MPC5200's Local Bus
in 16-bit mode which doesn't allow byte accesses. And I didn't want to
go too deep into this as the real fix for me is actually somewhat
different...
> /* PPC can do pre increment and load/store, but not post increment
> and load/store.
> Therefore use *++ptr instead of *ptr++. */
[snip]
> copy_chunks:
> do {
> /* make gcc to load all data, then store it */
> tmp1 = *(unsigned long *)(tmp_from+4);
> tmp_from += 8;
> tmp2 = *(unsigned long *)tmp_from;
> *(unsigned long *)(tmp_to+4) = tmp1;
> tmp_to += 8;
> *(unsigned long *)tmp_to = tmp2;
> } while (--chunks);
Is this the same for all PPC cores, i.e. do they all benefit from
loading/storing 8 instead of 4 bytes?
Best, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Grant Likely @ 2009-05-28 19:31 UTC (permalink / raw)
To: Esben Haabendal; +Cc: linuxppc-dev, linux-i2c, Esben Haabendal
In-Reply-To: <d2b9ea600905260430i72290901p9266de4cade049c1@mail.gmail.com>
On Tue, May 26, 2009 at 5:30 AM, Esben Haabendal
<esbenhaabendal@gmail.com> wrote:
> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal <eha@doredevelopment.dk>=
wrote:
>> This fixes MAL (arbitration lost) bug caused by illegal use of
>> RSTA (repeated START) after STOP condition generated after last byte
>> of reads. With this patch, it is possible to do an i2c_transfer() with
>> additional i2c_msg's following the I2C_M_RD messages.
>>
>> It still needs to be resolved if it is possible to fix this issue
>> by removing the STOP condition after reads in a robust way.
>>
>> Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
>> ---
>> =A0drivers/i2c/busses/i2c-mpc.c | =A0 =A09 +++++++--
>> =A01 files changed, 7 insertions(+), 2 deletions(-)
>
> Any blockers to get this accepted?
It helps if you cc: developers/maintainers of the device. ie. Kumar
for mpc8xxx, me for 52xx.
This is the first time I noticed your posting. It will take me a few
days before I get a chance to review it.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] fsldma: do not clear bandwidth control bits on the 83xx controller
From: Ira Snyder @ 2009-05-28 19:26 UTC (permalink / raw)
To: linuxppc-dev, Li Yang, Dan Williams
The 83xx controller does not support the external pause feature. The bit
in the mode register that controls external pause on the 85xx controller
happens to be part of the bandwidth control settings for the 83xx
controller.
This patch fixes the driver so that it only clears the external pause bit
if the hardware is the 85xx controller. When driving the 83xx controller,
the bit is left untouched. This follows the existing convention that mode
registers settings are not touched unless necessary.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
There is currently no interface to change the bandwidth control setting.
I have changed the bandwidth control setting by requesting exclusive
access to the DMA channel (via dma_request_channel()) then, since I know
the channel is idle, I just add the value I need.
I have tested this using the DMA_SLAVE patch I posted last week, and
verified that the bandwidth control bits do not change on the 83xx
controller.
The conditional could be changed from "== 85XX" to "!= 83XX", as they
are equivalent in the current driver. I'm not sure which is better.
drivers/dma/fsldma.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b2fd35e..a662aac 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -148,10 +148,11 @@ static void dma_start(struct fsl_dma_chan *fsl_chan)
if (fsl_chan->feature & FSL_DMA_CHAN_PAUSE_EXT) {
DMA_OUT(fsl_chan, &fsl_chan->reg_base->bcr, 0, 32);
mr_set |= FSL_DMA_MR_EMP_EN;
- } else
+ } else if ((fsl_chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr,
DMA_IN(fsl_chan, &fsl_chan->reg_base->mr, 32)
& ~FSL_DMA_MR_EMP_EN, 32);
+ }
if (fsl_chan->feature & FSL_DMA_CHAN_START_EXT)
mr_set |= FSL_DMA_MR_EMS_EN;
--
1.5.4.3
^ permalink raw reply related
* [PATCH] fsldma: enable external start for the 83xx controller
From: Ira Snyder @ 2009-05-28 19:20 UTC (permalink / raw)
To: linuxppc-dev, Li Yang, Dan Williams
The 83xx controller has external start capability, but lacks external pause
capability. Hook up the external start function pointer for the 83xx
controller.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
Though there is no way to enable external start in the mainline driver,
the DMA_SLAVE patch I posted last week does give the ability to enable
external start.
I have tested this patch along with the DMA_SLAVE patch using a driver
for some custom hardware that uses the external DMA control lines.
drivers/dma/fsldma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index db07113..b2fd35e 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1099,9 +1099,9 @@ static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
switch (new_fsl_chan->feature & FSL_DMA_IP_MASK) {
case FSL_DMA_IP_85XX:
- new_fsl_chan->toggle_ext_start = fsl_chan_toggle_ext_start;
new_fsl_chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
case FSL_DMA_IP_83XX:
+ new_fsl_chan->toggle_ext_start = fsl_chan_toggle_ext_start;
new_fsl_chan->set_src_loop_size = fsl_chan_set_src_loop_size;
new_fsl_chan->set_dest_loop_size = fsl_chan_set_dest_loop_size;
}
--
1.5.4.3
^ permalink raw reply related
* 8544 external interrupt configuration problems
From: Nancy Isaac @ 2009-05-28 19:05 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]
Hi,
I have a custom board that's using powerpc 8544. I am trying to setup the
external interrupts using the device tree and I am having no luck getting
the interrupt. I think my problem is that I don't have the hwirq to virq
mapping correctly. We are using the freescale 8544ds as our base. We have a
PCI bus but we are not using PCIE. In my kernel configuration, I have
CONFIG_PCIEPORTBUS disabled. The PCI interrupt is connected to IRQ0 and it
is working fine. But, my FPGA has three interrupts, IRQ1, IRQ2 and IRQ3. I
configure this in the device tree and I've tried many different numbers for
the interrupt.
In the KConfig for ppc85xx, the configuration is the following
config MPC85xx_DS
bool "Freescale MPC8544 DS"
#select PPC_I8259
select DEFAULT_UIMAGE
select FSL_PCIE
config MPC85xx
bool
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
select FSL_PCIE
select SERIAL_8250_SHARE_IRQ if SERIAL_8250
default y if MPC8540_ADS || MPC85xx_CDS || MPC8560_ADS \
|| MPC85xx_MDS || MPC85xx_DS
My .config has the following configuration for PCI ( I am showing the PCI
configuration b/c 8544 seems to have different interrupt setup when PCIE is
configured)
CONFIG_ZONE_DMA=y
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_FSL_SOC=y
CONFIG_FSL_PCIE=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_PCI_DEBUG=y
My device tree has the following entry for my fpga:
CpuCpld\@f0000000{
compatible = "MPC8544DS";
device_type = "CpuCpld";
reg = <f0000000 00000040>;
interrupts = <41 2 42 2 43 2>;
interrupt-parent = <&mpic>;
};
My driver does the mapping to the virq:
np = of_find_node_by_type(NULL, "CpuCpld");
if (!np) {
ret = -ENODEV;
}
cpldCpuDrv->MateIntIrq = irq_of_parse_and_map(np, 0);
cpldCpuDrv->FtaIrq = irq_of_parse_and_map(np, 1);
cpldCpuDrv->ExtractIrq = irq_of_parse_and_map(np, 2);
cpldCpuDrv->XauiIrq = irq_of_parse_and_map(np, 0);
of_node_put(np);
Does anyone know what the virq should be for these external interrupts?
I've tried specifying the actual irq numbers 1,2 and 3 and that doesn't work
either.
Is there some PCI configuration that's getting in the way? I've tried
disabling the FSL_PCIE and I get the same behavior.
Any help or pointers will be appreciated.
Thanks
Nancy
[-- Attachment #2: Type: text/html, Size: 2814 bytes --]
^ permalink raw reply
* Re: [PATCH V3 4/4] Fabric bindings for STAC9766 on the Efika
From: Jon Smirl @ 2009-05-28 18:58 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <87eiu972ff.fsf@macbook.be.48ers.dk>
On Thu, May 28, 2009 at 10:00 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote=
:
>>>>>> "Jon" =3D=3D Jon Smirl <jonsmirl@gmail.com> writes:
>
> Hi,
>
> =A0Jon> Fabric bindings for STAC9766 AC97 codec on the Efika.
> =A0Jon> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> =A0Jon> ---
> =A0Jon> =A0sound/soc/fsl/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A08 ++=
+
> =A0Jon> =A0sound/soc/fsl/Makefile =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A01
> =A0Jon> =A0sound/soc/fsl/efika-audio-fabric.c | =A0 95 ++++++++++++++++++=
++++++++++++++++++
> =A0Jon> =A03 files changed, 104 insertions(+), 0 deletions(-)
> =A0Jon> =A0create mode 100644 sound/soc/fsl/efika-audio-fabric.c
>
> =A0Jon> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> =A0Jon> index 79579ae..f571c6e 100644
> =A0Jon> --- a/sound/soc/fsl/Kconfig
> =A0Jon> +++ b/sound/soc/fsl/Kconfig
> =A0Jon> @@ -47,3 +47,11 @@ config SND_MPC52xx_SOC_PCM030
> =A0Jon> =A0 help
> =A0Jon> =A0 =A0 Say Y if you want to add support for sound on the Phytec =
pcm030 baseboard.
>
> =A0Jon> +config SND_MPC52xx_SOC_EFIKA
> =A0Jon> + tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
> =A0Jon> + depends on PPC_EFIKA
> =A0Jon> + select SND_SOC_MPC5200_AC97
> =A0Jon> + select SND_SOC_STAC9766
> =A0Jon> + help
> =A0Jon> + =A0 Say Y if you want to add support for sound on the Efika.
> =A0Jon> +
>
> Wouldn't it make more sense to make this default y when it has such
> specific dependencies and is so deep down in the tree - Most efika
> users probably want to enable this if they have enabled ALSA and
> SND_SOC?
I can change it in the next round of updates. Right now I'd like to
get some people testing it and maybe doing some patches to enhance it.
For example I know he code has a problem where about 5% of the time
the codec doesn't reset right on boot. Someone needs to put an
oscilloscope on the codec chip and tell me why it is failing.
>
> --
> Bye, Peter Korsgaard
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Kernel bug in 2.6.23...was: RE: How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-28 18:46 UTC (permalink / raw)
To: Morrison, Tom, Kumar Gala
Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110F53C57@EMPBEDEX.empirix.com>
Kumar,
To follow up on our postings from late last week...
(which I was expecting a response (but never got) from you)...
-----
We (well, mostly a very bright engineer who was very persistent)=20
have(has) found the origin of how the kernel TLB got corrupted.
We tracked down the problem to a programming bug in the DataStorage
exception handler for our kernel (2.6.23). We have looked at newer
kernels, and have noticed that this piece of processing has changed,=20
but let me explain to you what happened (and the conditions that=20
caused the problem on our MPC8572E (running SMP)...
If you follow the logic of in this version of the kernel, it reads=20
the SPRN_DEAR into register R10, and then does some operations=20
(including a tlbsx operation (which uses R10)), and then attempts
to update the associated PTE entry.
Well, if you have REALLY bad luck, sometime between the time you=20
took this exception and try to update the PTE for this page, the=20
other core has decided to invalidate this page's PTE. The good=20
part is the kernel recognizes this unlucky case.
Unfortunately, in this 'bad luck' case, a kernel bug was=20
Introduced. The kernel uses R10 for some processing (puts
the physical address associated with this virtual page) and=20
then branches up 'above' the tlbsx operation to try again=20
...without restoring R10 to the SPRN_DEAR required by the tlbsx
operation...
This means, that even though the kernel recognized this exceptional
problem, it NEVER did the right thing, and instead, the kernel would=20
(attempt) to modify the unlucky TLB virtual address that corresponds=20
to the physical address of the original DataStorage exception.
The only way we caught this is that we also had a second piece of=20
'bad luck' by having that physical address map to the virtual address
of the kernel (0xC0000000), and thus, when it loops back to try again,
it gets the kernel page(s) from the tlbsx operation, and modifies=20
permissions on the kernel pages and thus causing an InstructionStore=20
Exception (forever).
We fixed this in our kernel by just restoring R10 to SPRN_DEAR value
just before it loops back, something like this:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
....
mtspr SPRN_MAS1, r13
tlbwe
/* because we did NOT find in PTE */
/* r10 was changed - so we need */
/* to re-load it here to work */
mfspr r10, SPRN_DEAR /* restore the faulting
address */
b 5b /* Try again */
....
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
That's the short and long of it...and 4 weeks of very stressful
problems...
I am wondering why nobody has found this problem before - are we the
first to be this unlucky? I am not sure that is a good thing!
Comments? Suggestions? What else should I be doing with this
information?
Tom Morrison
Principal Software Engineer
EMPIRIX=20
20 Crosby Drive - Bedford, MA 01730
p: 781.266.3567 f: 781.266.3670=20
email: tmorrison@empirix.com=20
www.empirix.com
>> -----Original Message-----
>> From: Morrison, Tom
>> Sent: Thursday, May 21, 2009 11:24 AM
>> To: Morrison, Tom; Kumar Gala
>> Cc: linuxppc-dev@ozlabs.org; Young, Andrew; Brown, Jeff; Geary Sean-
>> R60898
>> Subject: RE: How to debug a hung multi-core system....
>>=20
>> Just had a little conference with several co-workers...to go over
results
>>=20
>> We think that LT0 (the one that maps the kernel) has been corrupted:
>>=20
>> Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
>>
---------------------------------------------------------------
>> LT0 C0000000 00000000 00 0FF 04 9 0 0
>>=20
>> PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
>>
---------------------------------------------------------------
>> 0 0 P P E E D E E D D V
>>=20
>> Is absolutely wrong - this is TLB for the kernel - and as you can see
>> ...it does NOT have execution privileges (and in fact the user space
>> HAS executive privileges for this area (complete opposite of what it
>> should be)...
>>=20
>> This is why it is stuck AT that instruction (can't even single step
>> from that location)..
>>=20
>> (one of) The first problem(s) is how can/when did this TLB get
corrupted!
>>=20
>> Tom
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Joakim Tjernlund @ 2009-05-28 18:43 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, Esben Haabendal, Esben Haabendal, Ben Dooks,
linux-i2c
In-Reply-To: <20090528171726.GE3112@pengutronix.de>
Wolfram Sang <w.sang@pengutronix.de> wrote on 28/05/2009 19:17:26:
>
> > > Any blockers to get this accepted?
> >
> > It would be nice to get an ack from someone who can actually test
> > the driver before getting this merged.
>
> I wanted to test it, but it does not apply due to line breaks (check
> @@-line). Also, I don't really have the time to dig into the topic, so I
> would only test it and give a tested-by-tag if it doesn't break anything
> here. I think Joakim would be a good candidate for an acked-by .
It sure looks OK, even at a closer look :)
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Wolfram Sang @ 2009-05-28 17:17 UTC (permalink / raw)
To: Ben Dooks; +Cc: linuxppc-dev, Esben Haabendal, linux-i2c, Esben Haabendal
In-Reply-To: <20090526213351.GG23114@fluff.org.uk>
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
> > Any blockers to get this accepted?
>
> It would be nice to get an ack from someone who can actually test
> the driver before getting this merged.
I wanted to test it, but it does not apply due to line breaks (check
@@-line). Also, I don't really have the time to dig into the topic, so I
would only test it and give a tested-by-tag if it doesn't break anything
here. I think Joakim would be a good candidate for an acked-by .
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Joakim Tjernlund @ 2009-05-28 16:13 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1243454441.3489.1@antares>
>
> This trivial patch changes memcpy_(to|from)io as to transfer as many
> 32-bit words as possible in 32-bit accesses (in the current solution,=
> the last 32-bit word was transferred as 4 byte accesses).
>
> Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
> ---
>
> diff -urpN -X linux-2.6.29.1.orig/Documentation/dontdiff
> linux-2.6.29.1.orig/arch/powerpc/kernel/io.c
> linux-2.6.29.1/arch/powerpc/kernel/io.c
> --- linux-2.6.29.1.orig/arch/powerpc/kernel/io.c 2009-04-02
> 22:55:27.000000000 +0200
> +++ linux-2.6.29.1/arch/powerpc/kernel/io.c 2009-05-27
> 11:36:09.000000000 +0200
> @@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const vo
> dest++;
> n--;
> }
> - while(n > 4) {
> + while(n >=3D 4) {
> *((u32 *)dest) =3D *((volatile u32 *)vsrc);
> eieio();
> vsrc +=3D 4;
> @@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem
> vdest++;
> n--;
> }
> - while(n > 4) {
> + while(n >=3D 4) {
> *((volatile u32 *)vdest) =3D *((volatile u32 *)src);
> src +=3D 4;
> vdest +=3D 4;
hmm, these do look a bit unoptimal anyway. Any reason not to write
them something like below(written by me for uClibc long time ago). You =
will
have to add eieio()/sync
void *memcpy(void *to, const void *from, size_t n)
/* PPC can do pre increment and load/store, but not post increment and =
load/store.
Therefore use *++ptr instead of *ptr++. */
{
unsigned long rem, chunks, tmp1, tmp2;
unsigned char *tmp_to;
unsigned char *tmp_from =3D (unsigned char *)from;
chunks =3D n / 8;
tmp_from -=3D 4;
tmp_to =3D to - 4;
if (!chunks)
goto lessthan8;
rem =3D (unsigned long )tmp_to % 4;
if (rem)
goto align;
copy_chunks:
do {
/* make gcc to load all data, then store it */
tmp1 =3D *(unsigned long *)(tmp_from+4);
tmp_from +=3D 8;
tmp2 =3D *(unsigned long *)tmp_from;
*(unsigned long *)(tmp_to+4) =3D tmp1;
tmp_to +=3D 8;
*(unsigned long *)tmp_to =3D tmp2;
} while (--chunks);
lessthan8:
n =3D n % 8;
if (n >=3D 4) {
*(unsigned long *)(tmp_to+4) =3D *(unsigned long *)(tmp_from+4);
tmp_from +=3D 4;
tmp_to +=3D 4;
n =3D n-4;
}
if (!n ) return to;
tmp_from +=3D 3;
tmp_to +=3D 3;
do {
*++tmp_to =3D *++tmp_from;
} while (--n);
return to;
align:
rem =3D 4 - rem;
n =3D n - rem;
do {
*(tmp_to+4) =3D *(tmp_from+4);
++tmp_from;
++tmp_to;
} while (--rem);
chunks =3D n / 8;
if (chunks)
goto copy_chunks;
goto lessthan8;
}=
^ permalink raw reply
* Re: [PATCH V3 4/4] Fabric bindings for STAC9766 on the Efika
From: Peter Korsgaard @ 2009-05-28 14:00 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090525013853.3073.78627.stgit@terra>
>>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes:
Hi,
Jon> Fabric bindings for STAC9766 AC97 codec on the Efika.
Jon> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Jon> ---
Jon> sound/soc/fsl/Kconfig | 8 +++
Jon> sound/soc/fsl/Makefile | 1
Jon> sound/soc/fsl/efika-audio-fabric.c | 95 ++++++++++++++++++++++++++++++++++++
Jon> 3 files changed, 104 insertions(+), 0 deletions(-)
Jon> create mode 100644 sound/soc/fsl/efika-audio-fabric.c
Jon> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
Jon> index 79579ae..f571c6e 100644
Jon> --- a/sound/soc/fsl/Kconfig
Jon> +++ b/sound/soc/fsl/Kconfig
Jon> @@ -47,3 +47,11 @@ config SND_MPC52xx_SOC_PCM030
Jon> help
Jon> Say Y if you want to add support for sound on the Phytec pcm030 baseboard.
Jon> +config SND_MPC52xx_SOC_EFIKA
Jon> + tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
Jon> + depends on PPC_EFIKA
Jon> + select SND_SOC_MPC5200_AC97
Jon> + select SND_SOC_STAC9766
Jon> + help
Jon> + Say Y if you want to add support for sound on the Efika.
Jon> +
Wouldn't it make more sense to make this default y when it has such
specific dependencies and is so deep down in the tree - Most efika
users probably want to enable this if they have enabled ALSA and
SND_SOC?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 3/4] net/ucc_geth: Add SGMII support for UEC GETH driver Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
In-Reply-To: <1243516833328-git-send-email-Haiying.Wang@freescale.com>
---
arch/powerpc/include/asm/qe.h | 2 +
drivers/net/ucc_geth.c | 79 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/ucc_geth.h | 28 ++++++++++++++-
3 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index e0faf33..157c5ca 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,6 +675,8 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x00001000
#define UCC_GETH_UPSMR_CAM 0x00000400
#define UCC_GETH_UPSMR_BRO 0x00000200
+#define UCC_GETH_UPSMR_SMM 0x00000080
+#define UCC_GETH_UPSMR_SGMM 0x00000020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9dd16c9..dca4f4e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -64,6 +64,8 @@
static DEFINE_SPINLOCK(ugeth_lock);
+static void uec_configure_serdes(struct net_device *dev);
+
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1409,6 +1411,9 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
+ if ((ugeth->phy_interface == PHY_INTERFACE_MODE_SGMII))
+ upsmr |= UCC_GETH_UPSMR_SGMM;
+
out_be32(&uf_regs->upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1546,6 +1551,9 @@ static int init_phy(struct net_device *dev)
phydev = phy_connect(dev, ug_info->phy_bus_id, &adjust_link, 0,
priv->phy_interface);
+ if (priv->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ uec_configure_serdes(dev);
+
if (IS_ERR(phydev)) {
printk("%s: Could not attach to PHY\n", dev->name);
return PTR_ERR(phydev);
@@ -1566,7 +1574,41 @@ static int init_phy(struct net_device *dev)
return 0;
}
+/* Initialize TBI PHY interface for communicating with the
+ * SERDES lynx PHY on the chip. We communicate with this PHY
+ * through the MDIO bus on each controller, treating it as a
+ * "normal" PHY at the address found in the UTBIPA register. We assume
+ * that the UTBIPA register is valid. Either the MDIO bus code will set
+ * it to a value that doesn't conflict with other PHYs on the bus, or the
+ * value doesn't matter, as there are no other PHYs on the bus.
+ */
+static void uec_configure_serdes(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+
+ if (!ugeth->tbiphy) {
+ printk(KERN_WARNING "SGMII mode requires that the device "
+ "tree specify a tbi-handle\n");
+ return;
+ }
+
+ /*
+ * If the link is already up, we must already be ok, and don't need to
+ * configure and reset the TBI<->SerDes link. Maybe U-Boot configured
+ * everything for us? Resetting it takes the link down and requires
+ * several seconds for it to come back.
+ */
+ if (phy_read(ugeth->tbiphy, ENET_TBI_MII_SR) & TBISR_LSTATUS)
+ return;
+
+ /* Single clk mode, mii mode off(for serdes communication) */
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
+
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+
+}
static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
{
@@ -3506,6 +3548,8 @@ static phy_interface_t to_phy_interface(const char *phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, "rtbi") == 0)
return PHY_INTERFACE_MODE_RTBI;
+ if (strcasecmp(phy_connection_type, "sgmii") == 0)
+ return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3552,6 +3596,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_TBI, PHY_INTERFACE_MODE_RTBI,
+ PHY_INTERFACE_MODE_SGMII,
};
ugeth_vdbg("%s: IN", __func__);
@@ -3694,6 +3739,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_TBI:
case PHY_INTERFACE_MODE_RTBI:
+ case PHY_INTERFACE_MODE_SGMII:
max_speed = SPEED_1000;
break;
default:
@@ -3776,6 +3822,37 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ugeth->ndev = dev;
ugeth->node = np;
+ /* Find the TBI PHY. If it's not there, we don't support SGMII */
+ ph = of_get_property(np, "tbi-handle", NULL);
+ if (ph) {
+ struct device_node *tbi = of_find_node_by_phandle(*ph);
+ struct of_device *ofdev;
+ struct mii_bus *bus;
+ const unsigned int *id;
+
+ if (!tbi)
+ return 0;
+
+ mdio = of_get_parent(tbi);
+ if (!mdio)
+ return 0;
+
+ ofdev = of_find_device_by_node(mdio);
+
+ of_node_put(mdio);
+
+ id = of_get_property(tbi, "reg", NULL);
+ if (!id)
+ return 0;
+ of_node_put(tbi);
+
+ bus = dev_get_drvdata(&ofdev->dev);
+ if (!bus)
+ return 0;
+
+ ugeth->tbiphy = bus->phy_map[*id];
+ }
+
return 0;
}
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 46bb1d2..24a9739 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
+ * Copyright (C) Freescale Semicondutor, Inc. 2006-2009. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
*
@@ -193,6 +193,31 @@ struct ucc_geth {
#define ENET_TBI_MII_JD 0x10 /* Jitter diagnostics */
#define ENET_TBI_MII_TBICON 0x11 /* TBI control */
+/* TBI MDIO register bit fields*/
+#define TBISR_LSTATUS 0x0004
+#define TBICON_CLK_SELECT 0x0020
+#define TBIANA_ASYMMETRIC_PAUSE 0x0100
+#define TBIANA_SYMMETRIC_PAUSE 0x0080
+#define TBIANA_HALF_DUPLEX 0x0040
+#define TBIANA_FULL_DUPLEX 0x0020
+#define TBICR_PHY_RESET 0x8000
+#define TBICR_ANEG_ENABLE 0x1000
+#define TBICR_RESTART_ANEG 0x0200
+#define TBICR_FULL_DUPLEX 0x0100
+#define TBICR_SPEED1_SET 0x0040
+
+#define TBIANA_SETTINGS ( \
+ TBIANA_ASYMMETRIC_PAUSE \
+ | TBIANA_SYMMETRIC_PAUSE \
+ | TBIANA_FULL_DUPLEX \
+ )
+#define TBICR_SETTINGS ( \
+ TBICR_PHY_RESET \
+ | TBICR_ANEG_ENABLE \
+ | TBICR_FULL_DUPLEX \
+ | TBICR_SPEED1_SET \
+ )
+
/* UCC GETH MACCFG1 (MAC Configuration 1 Register) */
#define MACCFG1_FLOW_RX 0x00000020 /* Flow Control
Rx */
@@ -1189,6 +1214,7 @@ struct ucc_geth_private {
struct ugeth_mii_info *mii_info;
struct phy_device *phydev;
+ struct phy_device *tbiphy;
phy_interface_t phy_interface;
int max_speed;
uint32_t msg_enable;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/4] net/phy/marvell: update m88e1111 support for SGMII mode
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
Disable fiber/copper auto selection for Marvell m88e1111 SGMII support.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
drivers/net/phy/marvell.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 7a3ec9d..dd6f54d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -243,6 +243,7 @@ static int m88e1111_config_init(struct phy_device *phydev)
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
temp |= MII_M1111_HWCFG_MODE_SGMII_NO_CLK;
+ temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
if (err < 0)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
In-Reply-To: <12435168351655-git-send-email-Haiying.Wang@freescale.com>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
arch/powerpc/boot/dts/mpc8569mds.dts | 63 ++++++++++++++++++++++++++++++++++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/boot/dts/mpc8569mds.dts
index 39c2927..4e95abd 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -24,6 +24,8 @@
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
+ ethernet5 = &enet5;
+ ethernet7 = &enet7;
pci1 = &pci1;
rapidio0 = &rio0;
};
@@ -466,6 +468,37 @@
reg = <0x3>;
device_type = "ethernet-phy";
};
+ qe_phy5: ethernet-phy@04 {
+ interrupt-parent = <&mpic>;
+ reg = <0x04>;
+ device_type = "ethernet-phy";
+ };
+ qe_phy7: ethernet-phy@06 {
+ interrupt-parent = <&mpic>;
+ reg = <0x6>;
+ device_type = "ethernet-phy";
+ };
+ };
+ mdio@3520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3520 0x18>;
+ compatible = "fsl,ucc-mdio";
+
+ tbi0: tbi-phy@15 {
+ reg = <0x15>;
+ device_type = "tbi-phy";
+ };
+ };
+ mdio@3720 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3720 0x38>;
+ compatible = "fsl,ucc-mdio";
+ tbi1: tbi-phy@17 {
+ reg = <0x17>;
+ device_type = "tbi-phy";
+ };
};
enet2: ucc@2200 {
@@ -513,6 +546,36 @@
phy-connection-type = "rgmii-id";
};
+ enet5: ucc@3400 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ cell-index = <6>;
+ reg = <0x3400 0x200>;
+ interrupts = <41>;
+ interrupt-parent = <&qeic>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ rx-clock-name = "none";
+ tx-clock-name = "none";
+ tbi-handle = <&tbi0>;
+ phy-handle = <&qe_phy5>;
+ phy-connection-type = "sgmii";
+ };
+
+ enet7: ucc@3600 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ cell-index = <8>;
+ reg = <0x3600 0x200>;
+ interrupts = <43>;
+ interrupt-parent = <&qeic>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ rx-clock-name = "none";
+ tx-clock-name = "none";
+ tbi-handle = <&tbi1>;
+ phy-handle = <&qe_phy7>;
+ phy-connection-type = "sgmii";
+ };
+
muram@10000 {
#address-cells = <1>;
#size-cells = <1>;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/4] fsl_pq_mido: Set the first UCC as the mii management interface master
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
In-Reply-To: <12435168302841-git-send-email-Haiying.Wang@freescale.com>
Current code makes the UCC whose register range includes the current mdio
register to be the MII managemnt interface master of the QE. If there is more
than one mdio bus for QE, the UCC of the last mdio bus will be the MII
management interface master which will make the primary mdio bus working
unproperly, e.g. can notget the right clock. Normally the primary mdio bus is
the first UEC's mdio bus.
This patch allows the first UCC to be the MII management interface master of the
multiple UCC mdio buses.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
drivers/net/fsl_pq_mdio.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index aa1eb88..fd317a0 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -338,13 +338,17 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
of_device_is_compatible(np, "ucc_geth_phy")) {
#ifdef CONFIG_UCC_GETH
u32 id;
+ static u32 mii_mng_master;
tbipa = ®s->utbipar;
if ((err = get_ucc_id_for_range(addr, addr + size, &id)))
goto err_free_irqs;
- ucc_set_qe_mux_mii_mng(id - 1);
+ if (!mii_mng_master) {
+ mii_mng_master = id;
+ ucc_set_qe_mux_mii_mng(id - 1);
+ }
#else
err = -ENODEV;
goto err_free_irqs;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Kumar Gala @ 2009-05-28 13:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: FUJITA Tomonori, linuxppc-dev list
In-Reply-To: <1243491063.3171.117.camel@pasglop>
On May 28, 2009, at 1:11 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2009-05-27 at 23:42 -0500, Kumar Gala wrote:
>> Ben,
>>
>> Any comments on this.. need a decision so we can have patches ready
>> for .31.
>
>>> Clamping the DMA mask is even worse than the additional indirection
>>> for us. We have valid scenarios in which we'd have 512M of outbound
>>> PCI address space and 4G of mem and thus 3.5G of inbound PCI address
>>> space. With the DMA mask we'd be limited to 2G and bouncing from
>>> 2..3.5G when we don't need to.
>
> Ok and agreed.
>
>>> I think our options are to change archdata as follows:
>>>
>>> Option 1 - just add a new data member to dev_archdata
>>>
>>> struct dev_archdata {
>>> /* Optional pointer to an OF device node */
>>> struct device_node *of_node;
>>>
>>> /* DMA operations on that device */
>>> struct dma_mapping_ops *dma_ops;
>>> void *dma_data;
>>> dma_addr_t direct_dma_addr;
>>> };
>
> That sounds like the "simple" option, might want for now to make
> it conditional on SWIOTLB but the bloat is reasonably small I would
> expect.
>
>>> Option 2 - introduce a proper container for how we use dma_data.
>>> This may just be moving the indirection from an indirection function
>>> call to an indirection data reference:
>
> Right, it somewhat defeats the purpose though an indirect data
> reference
> tends to hit the pipeline less hard than an indirect function call...
>
>>> Option 3 - use dma_data to keep the addr at which we need to bounce
>>> vs not for SWIOTLB - this has potential issues w/conflicting with
>>> dma_data being used as the dma_offset. (need to think on that a bit
>>> more). Additionally this has the benefit in that we need dma_data
>>> to be a 64-bit quantity on ppc32 w/>32-bit phys addr.
>
> Well, that means that swiotlb can not be used with a !0 offset. That
> -might- be an issue if the PCI is setup "backward", ie with 0..N being
> the outbound MMIO and N..4G the DMA region, remapped to 0. There are
> reasons to do it this way, it's not invalid, for example it allow easy
> access to ISA/VGA holes.
Yeah, realized that after thinking about it a bit more.
> At this stage I have no firm opinion. I'm thinking that either we try
> to limit the overhead and option 1 is probably the simplest, at the
> expense of a little bit of memory, or we think the overhead is going
> to be minimum and we may as well stick to 2 functions since that's
> going to be more flexible.
If you don't have a firm opinion I would ask you pull in this patch as
it is in your next tree. If we decide to move away from the 2
function method and use a little bit more memory per dev_archdata we
at least have the history in the tree of the 2 function method.
- k
^ permalink raw reply
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Wolfram Sang @ 2009-05-28 12:33 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev@ozlabs.org, Daniel Ng
In-Reply-To: <4A1E6877.2060106@aimvalley.nl>
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
> this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel driver
> registers for the PIT IRQ (Interrupt ID 65)
>
> #define PIT_IRQ 65
>
> virq = irq_create_mapping(NULL, PIT_IRQ);
> set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
>
> if(request_irq(virq, (irq_handler_t)timerEvent, 0, "timer2", (void *)0)) {
> printk(KERN_ERR "request_irq() returned error for irq=%d virq=%d\n", PIT_IRQ, virq);
> }
It is some time ago, but when I did something similar I needed the
following patch in order to use NULL for irq_create_mapping(). Have a
try, and if it is still needed (as it looks from a glimpse), then maybe
we should get it merged?
===
From: Wolfram Sang <w.sang@pengutronix.de>
Subject: [PATCH] powerpc/cpm2: make cpm2_pic the default host
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
arch/powerpc/sysdev/cpm2_pic.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2_pic.c b/arch/powerpc/sysdev/cpm2_pic.c
index 78f1f7c..7a7d4e5 100644
--- a/arch/powerpc/sysdev/cpm2_pic.c
+++ b/arch/powerpc/sysdev/cpm2_pic.c
@@ -272,4 +272,5 @@ void cpm2_pic_init(struct device_node *node)
printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
return;
}
+ irq_set_default_host(cpm2_pic_host);
}
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Norbert van Bolhuis @ 2009-05-28 10:33 UTC (permalink / raw)
To: Daniel Ng; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <547eba1b0905280037j3336d0av7cc5d4069622d8f4@mail.gmail.com>
Hi Daniel,
"Ethos" driver... hmm. sounds familiar!
(good to hear that it is still used in active development)
About your question.
Since almost 2 years (kernel 2.6.22 from july 2007) the rule is that you can't
directly map a hardware irq number because the powerpc kernel keeps a
mapping between hardware irq numbers and virtual irq numbers.
request_irq() expects a virtual irq number.
Here's some background info why the linux PowerPC kernel works this way:
The basic request_irq() function is generic, but the value of the
arguments (especially the number for the IRQ line) is architecture
specific in many ways. This is one difference between the i386 code
and the powerpc code inside Linux. Most i386 hardware is standard
PC hardware with very clearly defined interrupt sources. Because of
this, the mapping from the numeric IRQ value to a real hardware
interrupt source is defined pretty clearly.
(In fact, not even clearly anymore :-) IE, there are still some legacy
interrupts at fixed numbers but most things are remapped on x86 too
nowadays when using IO_APICs, the kernel obtains numbers from ACPI,
remaps them etc...)
The powerpc architecture code has to support almost arbitrarily complex
hardware, and the embedded world is the source of most of the complexity.
Because of this, the powerpc code has to dynamically allocate those numeric
IRQ sources and tie them to a specific hardware interrupt.
This is why there's a mapping between hardware irq numbers and virtual
irq numbers.
this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel driver
registers for the PIT IRQ (Interrupt ID 65)
#define PIT_IRQ 65
virq = irq_create_mapping(NULL, PIT_IRQ);
set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
if(request_irq(virq, (irq_handler_t)timerEvent, 0, "timer2", (void *)0)) {
printk(KERN_ERR "request_irq() returned error for irq=%d virq=%d\n", PIT_IRQ, virq);
}
All the above info comes from this mailing (and the linuxppc-embedd list) though.
If you search these lists you'll find plenty of answers to similar questions.
---
N. van Bolhuis
AimValley
Daniel Ng wrote:
> Hi,
>
> I'm attempting to port our Ethos HDLC driver from 2.6.14 to 2.6.27, on
> a MPC8272-based platform.
>
> So far, the kernel crashes when the driver tries to open (see below).
>
> It seems that the interrupt handler fails to register, with the
> following condition in setup_irq() in manage.c:
>
> desc->chip == &no_irq_chip
>
> I notice that the only place where desc->chip is assigned to anything
> else besides &no_irq_chip is in __set_irq_handler() in
> kernel/irq/chip.c
>
> In that file, __set_irq_handler() assigns desc->chip to
> &dummy_irq_chip, but this seems to be done for a special ARM-specific
> case, according to the commenting:
>
> /*
> * Some ARM implementations install a handler for really dumb
> * interrupt hardware without setting an irq_chip. This worked
> * with the ARM no_irq_chip but the check in setup_irq would
> * prevent us to setup the interrupt at all. Switch it to
> * dummy_irq_chip for easy transition.
> */
>
> Should I try to somehow call __set_irq_handler(), or should I be
> looking elsewhere?
>
> If I should be calling __set_irq_handler(), it seems the only relevant
> function that calls this is cpm2_pic_host_map().
>
> The only relevant functions which call cpm2_pic_host_map() are
> irq_setup_virq() or irq_alloc_hosts() with the IRQ_HOST_MAP_LEGACY
> parameter. IRQ_HOST_MAP_LEGACY seems to be irrelevant. Can someone
> tell me what a virq is?
>
> Cheers,
> Daniel
>
>
>
> Badness at c00224ec [verbose debug info unavailable]
> NIP: c00224ec LR: c019b254 CTR: c01aa9f8
> REGS: c1a49c70 TRAP: 0700 Not tainted (2.6.27.19-800-OS-03050107)
> MSR: 00021032 <ME,IR,DR> CR: 22002022 XER: 00000000
> TASK = c1bda400[306] 'pppd' THREAD: c1a48000
> GPR00: 00000001 c1a49d20 c1bda400 00000000 c0318880 c19c4d80 c1b92211 00000000
> GPR08: 00001032 c02cb240 00000000 00000000 22002022 fffffffe 01ff8000 00000000
> GPR16: 10344020 00000000 00000002 10049ac0 c194f800 ffff8914 c18cd900 c18cd90c
> GPR24: c1a49e48 00009032 c1a48000 c02b5fdc 00000002 c19c4d80 c1a48000 c1a48000
> NIP [c00224ec] local_bh_enable+0x94/0xb4
> LR [c019b254] dev_queue_xmit+0x108/0x580
> Call Trace:
> [c1a49d20] [c19c4d80] 0xc19c4d80 (unreliable)
> [c1a49d30] [c019b254] dev_queue_xmit+0x108/0x580
> [c1a49d50] [c016ac98] sppp_flush_xmit+0x20/0x44
> [c1a49d60] [c016c0b4] sppp_open+0x80/0xac
> [c1a49d80] [c016a104] ppp_open+0x70/0x98
> --- Exception: bfd26bb0 at 0x8914
> LR = 0xc1a49e90
> [c1a49da0] [c01699e0] hdlc_open+0x3c/0x104 (unreliable)
> [c1a49dc0] [c016cdd4] ethos_wan_genhdlc_open+0xb0/0xef8
> [c1a49df0] [c019c490] dev_open+0xbc/0x120
> [c1a49e00] [c019bbc8] dev_change_flags+0x8c/0x1d0
> [c1a49e20] [c01e1678] devinet_ioctl+0x700/0x7ac
> [c1a49e90] [c01e2538] inet_ioctl+0xcc/0xf8
> [c1a49ea0] [c018b584] sock_ioctl+0x60/0x268
> [c1a49ec0] [c0084ab0] vfs_ioctl+0x3c/0xc4
> [c1a49ee0] [c0084bb8] do_vfs_ioctl+0x80/0x454
> [c1a49f10] [c0084fcc] sys_ioctl+0x40/0x88
> [c1a49f40] [c000f928] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0x480af50c
> LR = 0x480af5e4
> Instruction dump:
> 41a20008 482044e1 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c02d
> 3929b240 800900dc 7c000034 5400d97e <0f000000> 2f800000 41beff90 38000001
> hdlc2: Carrier detected
> setup_irq()- desc->chip == &no_irq_chip
> request_irq()- setup_irq() FAILED
> ethos_wan_genhdlc_open(): request_irq() FAILED! ethos_wan->io_addr: 0xc5080000
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Daniel Ng @ 2009-05-28 7:37 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
I'm attempting to port our Ethos HDLC driver from 2.6.14 to 2.6.27, on
a MPC8272-based platform.
So far, the kernel crashes when the driver tries to open (see below).
It seems that the interrupt handler fails to register, with the
following condition in setup_irq() in manage.c:
desc->chip == &no_irq_chip
I notice that the only place where desc->chip is assigned to anything
else besides &no_irq_chip is in __set_irq_handler() in
kernel/irq/chip.c
In that file, __set_irq_handler() assigns desc->chip to
&dummy_irq_chip, but this seems to be done for a special ARM-specific
case, according to the commenting:
/*
* Some ARM implementations install a handler for really dumb
* interrupt hardware without setting an irq_chip. This worked
* with the ARM no_irq_chip but the check in setup_irq would
* prevent us to setup the interrupt at all. Switch it to
* dummy_irq_chip for easy transition.
*/
Should I try to somehow call __set_irq_handler(), or should I be
looking elsewhere?
If I should be calling __set_irq_handler(), it seems the only relevant
function that calls this is cpm2_pic_host_map().
The only relevant functions which call cpm2_pic_host_map() are
irq_setup_virq() or irq_alloc_hosts() with the IRQ_HOST_MAP_LEGACY
parameter. IRQ_HOST_MAP_LEGACY seems to be irrelevant. Can someone
tell me what a virq is?
Cheers,
Daniel
Badness at c00224ec [verbose debug info unavailable]
NIP: c00224ec LR: c019b254 CTR: c01aa9f8
REGS: c1a49c70 TRAP: 0700 Not tainted (2.6.27.19-800-OS-03050107)
MSR: 00021032 <ME,IR,DR> CR: 22002022 XER: 00000000
TASK = c1bda400[306] 'pppd' THREAD: c1a48000
GPR00: 00000001 c1a49d20 c1bda400 00000000 c0318880 c19c4d80 c1b92211 00000000
GPR08: 00001032 c02cb240 00000000 00000000 22002022 fffffffe 01ff8000 00000000
GPR16: 10344020 00000000 00000002 10049ac0 c194f800 ffff8914 c18cd900 c18cd90c
GPR24: c1a49e48 00009032 c1a48000 c02b5fdc 00000002 c19c4d80 c1a48000 c1a48000
NIP [c00224ec] local_bh_enable+0x94/0xb4
LR [c019b254] dev_queue_xmit+0x108/0x580
Call Trace:
[c1a49d20] [c19c4d80] 0xc19c4d80 (unreliable)
[c1a49d30] [c019b254] dev_queue_xmit+0x108/0x580
[c1a49d50] [c016ac98] sppp_flush_xmit+0x20/0x44
[c1a49d60] [c016c0b4] sppp_open+0x80/0xac
[c1a49d80] [c016a104] ppp_open+0x70/0x98
--- Exception: bfd26bb0 at 0x8914
LR = 0xc1a49e90
[c1a49da0] [c01699e0] hdlc_open+0x3c/0x104 (unreliable)
[c1a49dc0] [c016cdd4] ethos_wan_genhdlc_open+0xb0/0xef8
[c1a49df0] [c019c490] dev_open+0xbc/0x120
[c1a49e00] [c019bbc8] dev_change_flags+0x8c/0x1d0
[c1a49e20] [c01e1678] devinet_ioctl+0x700/0x7ac
[c1a49e90] [c01e2538] inet_ioctl+0xcc/0xf8
[c1a49ea0] [c018b584] sock_ioctl+0x60/0x268
[c1a49ec0] [c0084ab0] vfs_ioctl+0x3c/0xc4
[c1a49ee0] [c0084bb8] do_vfs_ioctl+0x80/0x454
[c1a49f10] [c0084fcc] sys_ioctl+0x40/0x88
[c1a49f40] [c000f928] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x480af50c
LR = 0x480af5e4
Instruction dump:
41a20008 482044e1 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c02d
3929b240 800900dc 7c000034 5400d97e <0f000000> 2f800000 41beff90 38000001
hdlc2: Carrier detected
setup_irq()- desc->chip == &no_irq_chip
request_irq()- setup_irq() FAILED
ethos_wan_genhdlc_open(): request_irq() FAILED! ethos_wan->io_addr: 0xc5080000
^ 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