* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 3:39 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090708233954.GA3181@bubble.grove.modra.org>
On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> If we modify the linker script:
>>
>> _end2 = .;
>> _end3 = ALIGN(4096);
>> _end4 = ALIGN(PAGE_SIZE);
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>
> Possibly some section with a zero vma is being placed before _end.
> Generate a link map to see if this is so.
Playing with this further I think its related to the -me500 option we
pass and thus wondering if its something with the APU section
handling. If I hack the kernel up a little and pass -m440 instead
things seem to be ok.
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 3:52 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, Edmar Wienskoski-RA8797,
Alan Modra, bug-binutils
In-Reply-To: <E6EB8DA7-8B38-4C97-BE3C-4649DFA295C8@kernel.crashing.org>
On Jul 8, 2009, at 10:39 PM, Kumar Gala wrote:
>
> On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
>
>> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>>> If we modify the linker script:
>>>
>>> _end2 = .;
>>> _end3 = ALIGN(4096);
>>> _end4 = ALIGN(PAGE_SIZE);
>>> . = ALIGN(PAGE_SIZE);
>>> _end = . ;
>>> PROVIDE32 (end = .);
>>>
>>> and the result is:
>>>
>>> 00001000 A _end
>>> c067f678 A _end2
>>> c0680000 A _end3
>>> c0680000 A _end4
>>
>> Possibly some section with a zero vma is being placed before _end.
>> Generate a link map to see if this is so.
>
> Playing with this further I think its related to the -me500 option
> we pass and thus wondering if its something with the APU section
> handling. If I hack the kernel up a little and pass -m440 instead
> things seem to be ok.
To further verify this if I switch the -me500 to -mspe and build
things seem to be ok. This further points at some APU section related
bug.
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-09 4:40 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <AB02ECF3-9C72-436B-A946-CBCCD3859762@kernel.crashing.org>
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
> To further verify this if I switch the -me500 to -mspe and build things
> seem to be ok. This further points at some APU section related bug.
Like omitting .PPC.EMB.apuinfo from your kernel link script? See the
ld info doc on orphan sections.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* SPI driver on mpc5121
From: Canella Matteo @ 2009-07-09 9:30 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
Hi,
I'm on a mpc5121 platform, kernel 2.6.24.6, and I'm using the mpc512x_psc_spi driver to communicate with a touch screen controller.
I'm sending commands and reading data from the controller using 24-bit packet (3 bytes).
The speed of the SPI is set to 640 KHz.
I thought that I would need 8/640K = 12,5 us each byte I send, but this is not true.
I'm verifying the time needed by mpc512x_psc_spi_transfer_rxtx function in order to send one byte toggling a digital output when it sets the TX/RX flags (after it copies data in the transmission buffer) and toggling the output again when the empty buffer interrupt is triggered.
I see that the actual 12,5us data transfer is preceded by a 20us delay and followed by another 15,6us delay. So the transfer is done in almost 50 us.
Is this a normal behavior? Does the PSC controller need this overhead in the transfer time?
DSCKI and DTL delays are set to zero.
Another doubt I have:
In mpc512x_psc_spi_transfer_rxtx, Mode Register 2 of the PSC is set to zero. This is done (as manual says) by access to MR1 (by a read) and then write a zero on the same address.:
in_8(&psc->mode);
mdelay(1);
out_8(&psc->mode, 0x0);
mdelay(1);
I don't understand why a 1ms delay is needed. The manual doesn't say anything about this.
I tried to comment out these delays and anyway it seems to work correctly.
Best regards,
Matteo Canella
[-- Attachment #2: Type: text/html, Size: 5097 bytes --]
^ permalink raw reply
* Re: ALSA fixes for non-coherent ppc32 again
From: Gerhard Pircher @ 2009-07-09 11:22 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev
In-Reply-To: <s5hfxd7qn49.wl%tiwai@suse.de>
-------- Original-Nachricht --------
> Datum: Wed, 08 Jul 2009 16:13:10 +0200
> Von: Takashi Iwai <tiwai@suse.de>
> An: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Gerhard Pircher <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: ALSA fixes for non-coherent ppc32 again
> At Wed, 08 Jul 2009 13:01:50 +1000,
> Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2009-06-22 at 08:34 +1000, Benjamin Herrenschmidt wrote:
> > > On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
> > > > Hi,
> > > >
> > > > Takashi Iwai posted patches to make ALSA work on non-coherent
> > > > PPC32 systems (almost exactly) a year ago. See here:
> > > >
> > > > http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
> > > >
> > > > As far as I can see these patches never went upstream. Where
> > > > there any objections or did we just forget about them? It would
> > > > be cool, if the patches could be merged now, as at least two
> > > > platforms need this bugfix (namely Sam440 and AmigaOne).
> > >
> > > I definitely forgot about those... But I'm fine with what Takashi
> > > did for now, I can always make the powerpc helper for
> > > dma_mmap_coherent() smarter later on if necessary.
> >
> > BTW. Can you guys send a "final" patch for adding mmap_coherent to
> > powerpc ? Please make so that the dma_mmap_coherent() function doesn't
> > explose if dma_ops->mmap_coherent is NULL though (either fail
> > gracefully or fallback to some standard mmap).
>
> The attached is the revised patch. It falls backs to the standard
> mmap.
>
> The whole patch series are found in test/dma-fix branch of sound git
> tree below:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> test/dma-fix
>
> I had no time to play cross-build yet, so it'd be helpful if someone
> can test it...
> (BTW, any good minimal gcc and binutils package for kernel builds for
> PPC32?)
Okay, I cross-build it on a x86 machine and tested it on my AmigaOne with
the VIA686 onboard sound and a Soundblaster 5.1. It worked fine after I
applied the "ALSA: Fix SG-buffer DMA with non-coherent architectures"
patch.
Thanks!
Gerhard
--
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
^ permalink raw reply
* Re: [PATCH]: [MPC5200] Add ATA DMA support
From: Roman Fietze @ 2009-07-09 14:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40901050731i3fb3ee2er221af3b174051aa@mail.gmail.com>
Hallo,
On Monday 05 January 2009 16:31:33 Grant Likely wrote:
> DMA support is now in mainline, but it is disabled by
> default ...
I had problems using ATA DMA on an own MPC5200B board, too. This board
has no problems at all using DMA33 with DENX 2.4.25, with all kinds of
automotive disks from 20 to 40GB. I definitively tested all three
listed drives below, but we are using other drives as well
(e.g. Hitachi 20 and 40 GB variants).
On exactly those boards I'm now running the 2.6.30 from DENX. The
following harddisks work well on this board, including network traffic
in parallel (which sometimes was a problem on old kernels or MPC5200's
w/o a 'B'):
=2D Toshiba MK4036GA
=2D Hitachi HEJ423020F9AT00
But an old 20GB Seagate ST940813AM shows the following problem when
booting the system:
PHY: f0003000:00 - Link is Up - 100/Half
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
ata1.00: BMDMA stat 0x5
ata1.00: cmd ca/00:08:1f:10:9c/00:00:00:00:00/e0 tag 0 dma 4096 out
res 51/84:08:1f:10:9c/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { ICRC ABRT }
ata1: soft resetting link
ata1.00: configured for UDMA/33
ata1: EH complete
I think this is similar to the errors reported after the ATA DMA patch
for the MPC5200B was introduced in this mailing list.
I even tried to use some modified timings from the 2.4.25 kernel, but
(of course) w/o success.
Are there any other patches I should try? Anything I could do to help
you to get this problem fixed?
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 15:22 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090709044007.GB3181@bubble.grove.modra.org>
On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>> To further verify this if I switch the -me500 to -mspe and build
>> things
>> seem to be ok. This further points at some APU section related bug.
>
> Like omitting .PPC.EMB.apuinfo from your kernel link script? See the
> ld info doc on orphan sections.
Ok, not terribly enlightening, but why would .PPC.EMB.apuinfo sections
be different than something like .debug sections which we also dont
list in the linker script.
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 16:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <6CF38C94-45EB-4FD7-B8E0-B9899F4EEF90@kernel.crashing.org>
On Wed, Jul 08, 2009 at 03:58:02PM -0500, Kumar Gala wrote:
>
> On Jul 8, 2009, at 2:33 PM, Ira W. Snyder wrote:
>
>> On Wed, Jul 08, 2009 at 01:09:39PM -0500, Kumar Gala wrote:
>>>
>>> On Jul 8, 2009, at 11:19 AM, Ira W. Snyder wrote:
>>>
>>>> Add support for the Freescale MPC83xx memory controller to the
>>>> existing
>>>> driver for the Freescale MPC85xx memory controller. The only
>>>> difference
>>>> between the two processors are in the CS_BNDS register parsing code.
>>>>
>>>> The L2 cache controller does not exist on the MPC83xx, but the OF
>>>> subsystem
>>>> will not use the driver if the device is not present in the OF
>>>> device
>>>> tree.
>>>>
>>>> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
>>>> ---
>>>>
>>>> This was tested on an MPC8349EMDS-based board.
>>>>
>>>> I don't really like how the MCE disable works on mpc85xx (clearing
>>>> the
>>>> HID1 register), but this can be revisited when mpc86xx support gets
>>>> added. It sucks to have this happen before the probe() routine is
>>>> called
>>>> and we know what kind of hardware we're actually running on.
>>>>
>>>> drivers/edac/Kconfig | 6 +++---
>>>> drivers/edac/mpc85xx_edac.c | 38 +++++++++++++++++++++++++++
>>>> +----------
>>>> drivers/edac/mpc85xx_edac.h | 3 +++
>>>> 3 files changed, 34 insertions(+), 13 deletions(-)
>>>
>>> [snip]
>>>
>>>> /************************ MC SYSFS parts
>>>> ***********************************/
>>>>
>>>> @@ -738,7 +740,8 @@ static irqreturn_t mpc85xx_mc_isr(int irq, void
>>>> *dev_id)
>>>> return IRQ_HANDLED;
>>>> }
>>>>
>>>> -static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
>>>> +static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci,
>>>> + const struct of_device_id *match)
>>>> {
>>>> struct mpc85xx_mc_pdata *pdata = mci->pvt_info;
>>>> struct csrow_info *csrow;
>>>> @@ -784,18 +787,26 @@ static void __devinit
>>>> mpc85xx_init_csrows(struct
>>>> mem_ctl_info *mci)
>>>> }
>>>>
>>>> for (index = 0; index < mci->nr_csrows; index++) {
>>>> - u32 start;
>>>> - u32 end;
>>>> + u32 start, end, extra;
>>>>
>>>> csrow = &mci->csrows[index];
>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>> +
>>>> + if (match->data && match->data == MPC83xx) {
>>>> + start = (cs_bnds & 0x00ff0000) << 8;
>>>> + end = (cs_bnds & 0x000000ff) << 24;
>>>> + extra = 0x00ffffff;
>>>> + } else {
>>>> + start = (cs_bnds & 0x0fff0000) << 4;
>>>> + end = (cs_bnds & 0x00000fff) << 20;
>>>> + extra = 0x000fffff;
>>>> + }
>>>
>>> I don't understand this at all.. The only difference between 83xx &
>>> 85xx
>>> is that we should have an extra 4-bits for 36-bit physical addresses.
>>>
>>> We should be able to write this code in such a way that it works for
>>> both 83xx & 85xx.
>>>
>>> start = (cs_bnds & 0xffff0000) >> 16;
>>> end = (cs_bnds & 0xffff);
>>>
>>> if (start == end)
>>> continue;
>>> start <<= (20 - PAGE_SHIFT);
>>> end <<= (20 - PAGE_SHIFT);
>>> end |= (1 << (20 - PAGE_SHIFT)) - 1;
>>>
>>
>> Sorry, I don't know a thing about PAGE_SHIFT. Looking in
>> arch/powerpc/platforms/Kconfig.cputype, PPC_85xx doesn't seem to imply
>> a
>> change in PAGE_SIZE, which changes the PAGE_SHIFT in
>> arch/powerpc/include/asm/page.h.
>>
>> Also, are you sure you cannot use 4K pages on an 85xx? If you can use
>> 4K
>> pages on 85xx, then PAGE_SHIFT == 12, and your solution breaks.
>>
>> I admit I don't know much about all of the different powerpc
>> platforms.
>
> PAGE_SHIFT is the same.. I was folding in the code from below the diff:
>
> csrow->first_page = start >> PAGE_SHIFT;
> csrow->last_page = end >> PAGE_SHIFT;
>
> into the calculation of start/end. I know PAGE_SHIFT is a minimum 12 on
> any PPC based system (and at this point its always 12 on 85xx/83xx). The
> idea is to ensure that when shift start/end up that it still fits in
> 32-bits. This is to handle the case of >4G of memory.
>
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
/sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
The attached patch DOES work on my board, but I'm confident that it does
NOT work on a system with PAGE_SIZE != 4096. Any idea what I did wrong?
If I'm reading things correctly:
csrow->first_page full address of the first page (NOT pfn)
csrow->last_page full address of the last page (NOT pfn)
csrow->nr_pages number of pages
The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the size_mb
sysfs value.
If csrow->first_page and csrow->last_page ARE supposed to be the pfn,
then I think the original code got it wrong, and the calculation for
csrow->nr_pages needs to be changed.
Thanks,
Ira
>From a442c2e5a1cfbe29ea9d2ea7d45237677ff7899d Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <iws@ovro.caltech.edu>
Date: Wed, 8 Jul 2009 08:59:16 -0700
Subject: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
Add support for the Freescale MPC83xx memory controller to the existing
driver for the Freescale MPC85xx memory controller. The only difference
between the two processors are in the CS_BNDS register parsing code, which
has been changed so it will work on both processors.
The L2 cache controller does not exist on the MPC83xx, but the OF subsystem
will not use the driver if the device is not present in the OF device tree.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
drivers/edac/Kconfig | 6 +++---
drivers/edac/mpc85xx_edac.c | 30 ++++++++++++++++++++----------
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 4339b1a..78303f9 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -176,11 +176,11 @@ config EDAC_I5100
San Clemente MCH.
config EDAC_MPC85XX
- tristate "Freescale MPC85xx"
- depends on EDAC_MM_EDAC && FSL_SOC && MPC85xx
+ tristate "Freescale MPC83xx / MPC85xx"
+ depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)
help
Support for error detection and correction on the Freescale
- MPC8560, MPC8540, MPC8548
+ MPC8349, MPC8560, MPC8540, MPC8548
config EDAC_MV64X60
tristate "Marvell MV64x60"
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b4f5c63..e4832b4 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -43,7 +43,9 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
+#ifdef CONFIG_MPC85xx
static u32 orig_hid1[2];
+#endif
/************************ MC SYSFS parts ***********************************/
@@ -790,18 +792,19 @@ static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
csrow = &mci->csrows[index];
cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
(index * MPC85XX_MC_CS_BNDS_OFS));
- start = (cs_bnds & 0xfff0000) << 4;
- end = ((cs_bnds & 0xfff) << 20);
- if (start)
- start |= 0xfffff;
- if (end)
- end |= 0xfffff;
+
+ start = (cs_bnds & 0xffff0000) >> 16;
+ end = (cs_bnds & 0x0000ffff);
if (start == end)
continue; /* not populated */
- csrow->first_page = start >> PAGE_SHIFT;
- csrow->last_page = end >> PAGE_SHIFT;
+ start <<= PAGE_SHIFT;
+ end <<= PAGE_SHIFT;
+ end |= (1 << PAGE_SHIFT) - 1;
+
+ csrow->first_page = start;
+ csrow->last_page = end;
csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
csrow->grain = 8;
csrow->mtype = mtype;
@@ -986,6 +989,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8560-memory-controller", },
{ .compatible = "fsl,mpc8568-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
+ { .compatible = "fsl,mpc8349-memory-controller", },
{},
};
@@ -1001,13 +1005,13 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
-
+#ifdef CONFIG_MPC85xx
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
}
-
+#endif
static int __init mpc85xx_mc_init(void)
{
@@ -1040,26 +1044,32 @@ static int __init mpc85xx_mc_init(void)
printk(KERN_WARNING EDAC_MOD_STR "PCI fails to register\n");
#endif
+#ifdef CONFIG_MPC85xx
/*
* need to clear HID1[RFXE] to disable machine check int
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT)
on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+#endif
return 0;
}
module_init(mpc85xx_mc_init);
+#ifdef CONFIG_MPC85xx
static void __exit mpc85xx_mc_restore_hid1(void *data)
{
mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
}
+#endif
static void __exit mpc85xx_mc_exit(void)
{
+#ifdef CONFIG_MPC85xx
on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+#endif
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.5.4.3
^ permalink raw reply related
* Re: binutils 2.19 issue with kernel link
From: Dale Farnsworth @ 2009-07-09 16:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <09159ADA-39F9-419E-AE46-4CFAE612AFB9@kernel.crashing.org>
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
> We are seeing an issue w/ld and kernel linking of 32-bit kernels.
>
> The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not providing
> the proper address for _end.
>
> Building stock v2.6.30 w/the mpc85xx_defconfig we get:
>
> 00001000 A _end
>
> Using 2.18.50.20080215 we get:
>
> c0680000 A _end
>
> If we modify the linker script:
>
> _end2 = .;
> _end3 = ALIGN(4096);
> _end4 = ALIGN(PAGE_SIZE);
> . = ALIGN(PAGE_SIZE);
> _end = . ;
> PROVIDE32 (end = .);
>
> and the result is:
>
> 00001000 A _end
> c067f678 A _end2
> c0680000 A _end3
> c0680000 A _end4
>
> I used an old version of linker (2.18.50.20080215) and re-linked:
>
> c067f678 A _end2
> c0680000 A _end
> c0680000 A _end3
> c0680000 A _end4
>
> Any ideas?
We have found the following workaround to be useful.
Thanks to Andrew Jenner at Code Sourcery.
-Dale
Dale Farnsworth
MontaVista Software
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index acf237f..34b0181 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -282,4 +282,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
+
+#undef PPC
+ .PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
}
^ permalink raw reply related
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-09 17:58 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090709165844.GB29383@ovro.caltech.edu>
> Hello Kumar,
>
> I must not understand something going on here. Your proposed code
> doesn't work at all on my board. The
> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
What does it come out as? How much memory do you have in the system?
> The attached patch DOES work on my board, but I'm confident that it
> does
> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
> wrong?
>
> If I'm reading things correctly:
> csrow->first_page full address of the first page (NOT pfn)
> csrow->last_page full address of the last page (NOT pfn)
> csrow->nr_pages number of pages
>
> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the size_mb
> sysfs value.
>
> If csrow->first_page and csrow->last_page ARE supposed to be the pfn,
> then I think the original code got it wrong, and the calculation for
> csrow->nr_pages needs to be changed.
>
> Thanks,
> Ira
[snip]
> /************************ MC SYSFS parts
> ***********************************/
>
> @@ -790,18 +792,19 @@ static void __devinit
> mpc85xx_init_csrows(struct mem_ctl_info *mci)
> csrow = &mci->csrows[index];
> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
> (index * MPC85XX_MC_CS_BNDS_OFS));
> - start = (cs_bnds & 0xfff0000) << 4;
> - end = ((cs_bnds & 0xfff) << 20);
> - if (start)
> - start |= 0xfffff;
> - if (end)
> - end |= 0xfffff;
can you printk what cs_bnds values are in your setup.
> +
> + start = (cs_bnds & 0xffff0000) >> 16;
> + end = (cs_bnds & 0x0000ffff);
>
> if (start == end)
> continue; /* not populated */
>
> - csrow->first_page = start >> PAGE_SHIFT;
> - csrow->last_page = end >> PAGE_SHIFT;
> + start <<= PAGE_SHIFT;
> + end <<= PAGE_SHIFT;
> + end |= (1 << PAGE_SHIFT) - 1;
> +
> + csrow->first_page = start;
> + csrow->last_page = end;
This seems odd to me... I can't believe this is working out properly.
>
> csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
> csrow->grain = 8;
> csrow->mtype = mtype;
>
Lets get some real values on the table for your system so I can get a
sense of what's really going on.
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 18:14 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20090709163900.GA6549@farnsworth.org>
On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> We are seeing an issue w/ld and kernel linking of 32-bit kernels.
>>
>> The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not
>> providing
>> the proper address for _end.
>>
>> Building stock v2.6.30 w/the mpc85xx_defconfig we get:
>>
>> 00001000 A _end
>>
>> Using 2.18.50.20080215 we get:
>>
>> c0680000 A _end
>>
>> If we modify the linker script:
>>
>> _end2 = .;
>> _end3 = ALIGN(4096);
>> _end4 = ALIGN(PAGE_SIZE);
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>>
>> I used an old version of linker (2.18.50.20080215) and re-linked:
>>
>> c067f678 A _end2
>> c0680000 A _end
>> c0680000 A _end3
>> c0680000 A _end4
>>
>> Any ideas?
>
> We have found the following workaround to be useful.
> Thanks to Andrew Jenner at Code Sourcery.
>
> -Dale
>
> Dale Farnsworth
> MontaVista Software
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/
> vmlinux.lds.S
> index acf237f..34b0181 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -282,4 +282,7 @@ SECTIONS
> . = ALIGN(PAGE_SIZE);
> _end = . ;
> PROVIDE32 (end = .);
> +
> +#undef PPC
> + .PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
> }
Is there any plans to fix binutils or is this viewed as not a binutils
regression?
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 18:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <FC7C9C56-A1E7-4A02-BDEA-F55E10567313@kernel.crashing.org>
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>> Hello Kumar,
>>
>> I must not understand something going on here. Your proposed code
>> doesn't work at all on my board. The
>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
>
> What does it come out as? How much memory do you have in the system?
>
The size_mb shows as 0 with your code. See the explanation below. With
my code it shows as 256MB, as expected.
I have 256MB memory in the system.
>> The attached patch DOES work on my board, but I'm confident that it
>> does
>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>> wrong?
>>
>> If I'm reading things correctly:
>> csrow->first_page full address of the first page (NOT pfn)
>> csrow->last_page full address of the last page (NOT pfn)
>> csrow->nr_pages number of pages
>>
>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the size_mb
>> sysfs value.
>>
>> If csrow->first_page and csrow->last_page ARE supposed to be the pfn,
>> then I think the original code got it wrong, and the calculation for
>> csrow->nr_pages needs to be changed.
>>
>> Thanks,
>> Ira
>
> [snip]
>
>> /************************ MC SYSFS parts
>> ***********************************/
>>
>> @@ -790,18 +792,19 @@ static void __devinit mpc85xx_init_csrows(struct
>> mem_ctl_info *mci)
>> csrow = &mci->csrows[index];
>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>> (index * MPC85XX_MC_CS_BNDS_OFS));
>> - start = (cs_bnds & 0xfff0000) << 4;
>> - end = ((cs_bnds & 0xfff) << 20);
>> - if (start)
>> - start |= 0xfffff;
>> - if (end)
>> - end |= 0xfffff;
>
> can you printk what cs_bnds values are in your setup.
>
I am only using a single chip select. CS0_BNDS (register 0xe0002000) is
0x0000000F.
>> +
>> + start = (cs_bnds & 0xffff0000) >> 16;
>> + end = (cs_bnds & 0x0000ffff);
>>
This is the same in both our versions.
start == 0x0
end == 0xF
>> if (start == end)
>> continue; /* not populated */
>>
>> - csrow->first_page = start >> PAGE_SHIFT;
>> - csrow->last_page = end >> PAGE_SHIFT;
>> + start <<= PAGE_SHIFT;
>> + end <<= PAGE_SHIFT;
>> + end |= (1 << PAGE_SHIFT) - 1;
>> +
MY VERSION
start == 0x0
end == 0xffff
first_page == 0x0
last_page == 0xffff
YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
start == 0x0
end == 0xfff
first_page == 0x0
last_page == 0x0
>> + csrow->first_page = start;
>> + csrow->last_page = end;
>
> This seems odd to me... I can't believe this is working out properly.
>
>>
>> csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
The calculation is unchanged here from the original code. Due to the
">> PAGE_SHIFT", nr_pages ends up as 1 in your version.
MY VERSION
nr_pages == 0xffff + 1 - 0 == 0x10000
0x10000 * 4096 / 1024 / 1024 == 256 MB
YOUR VERSION
nr_pages == 0x0 + 1 - 0x0 == 1
0x1 * 4096 / 1024 / 1024 == 0MB
>> csrow->grain = 8;
>> csrow->mtype = mtype;
>>
>
> Lets get some real values on the table for your system so I can get a
> sense of what's really going on.
>
Thanks for the help.
Ira
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-09 18:25 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090709181705.GD29383@ovro.caltech.edu>
On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>> Hello Kumar,
>>>
>>> I must not understand something going on here. Your proposed code
>>> doesn't work at all on my board. The
>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
>>
>> What does it come out as? How much memory do you have in the system?
>>
>
> The size_mb shows as 0 with your code. See the explanation below. With
> my code it shows as 256MB, as expected.
>
> I have 256MB memory in the system.
>
>>> The attached patch DOES work on my board, but I'm confident that it
>>> does
>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>> wrong?
>>>
>>> If I'm reading things correctly:
>>> csrow->first_page full address of the first page (NOT pfn)
>>> csrow->last_page full address of the last page (NOT pfn)
>>> csrow->nr_pages number of pages
>>>
>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>> size_mb
>>> sysfs value.
>>>
>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>> pfn,
>>> then I think the original code got it wrong, and the calculation for
>>> csrow->nr_pages needs to be changed.
>>>
>>> Thanks,
>>> Ira
>>
>> [snip]
>>
>>> /************************ MC SYSFS parts
>>> ***********************************/
>>>
>>> @@ -790,18 +792,19 @@ static void __devinit
>>> mpc85xx_init_csrows(struct
>>> mem_ctl_info *mci)
>>> csrow = &mci->csrows[index];
>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>> - start = (cs_bnds & 0xfff0000) << 4;
>>> - end = ((cs_bnds & 0xfff) << 20);
>>> - if (start)
>>> - start |= 0xfffff;
>>> - if (end)
>>> - end |= 0xfffff;
>>
>> can you printk what cs_bnds values are in your setup.
>>
>
> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
> is
> 0x0000000F.
>
>>> +
>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>> + end = (cs_bnds & 0x0000ffff);
>>>
>
> This is the same in both our versions.
>
> start == 0x0
> end == 0xF
>
>>> if (start == end)
>>> continue; /* not populated */
>>>
>>> - csrow->first_page = start >> PAGE_SHIFT;
>>> - csrow->last_page = end >> PAGE_SHIFT;
>>> + start <<= PAGE_SHIFT;
>>> + end <<= PAGE_SHIFT;
>>> + end |= (1 << PAGE_SHIFT) - 1;
>>> +
>
> MY VERSION
>
> start == 0x0
> end == 0xffff
>
> first_page == 0x0
> last_page == 0xffff
>
> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
With that I think things work out.
- k
>
>
> start == 0x0
> end == 0xfff
>
> first_page == 0x0
> last_page == 0x0
>
>>> + csrow->first_page = start;
>>> + csrow->last_page = end;
>>
>> This seems odd to me... I can't believe this is working out properly.
>>
>>>
>>> csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
>
> The calculation is unchanged here from the original code. Due to the
> ">> PAGE_SHIFT", nr_pages ends up as 1 in your version.
>
> MY VERSION
>
> nr_pages == 0xffff + 1 - 0 == 0x10000
>
> 0x10000 * 4096 / 1024 / 1024 == 256 MB
>
>
> YOUR VERSION
>
> nr_pages == 0x0 + 1 - 0x0 == 1
>
> 0x1 * 4096 / 1024 / 1024 == 0MB
>
>>> csrow->grain = 8;
>>> csrow->mtype = mtype;
>>>
>>
>> Lets get some real values on the table for your system so I can get a
>> sense of what's really going on.
>>
>
> Thanks for the help.
> Ira
^ permalink raw reply
* Questions in spi_mpc83xx.c
From: Mark Bishop @ 2009-07-09 18:16 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
I haven't seen this before - the '##' in the function name. This is ANCII C?
#define MPC83XX_SPI_TX_BUF(type) \
u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi) \
{ \
u32 data; \
....
Also, I have a SPI chip here that will drive MISO high when it is
ready to accept more data. It acts like a hardware handshake. I was
thinking about making changes to the controller source (spi_mpc83xx.c,
in my case) to support this.
This is the only SPI chip contained on this system so I am not worried
about affecting other SPI devices hooked to the controller.
What are people's opinion on this as far as right place to implement,
and I could use a push as to where in the controller to make mods if
appropriate.
And if it isn't obvious already I am still learning a bit as to how
the SPI sub-system is organized. I have taken apart the
documentation in the kernel Documentation/spi directory and am reading
all the code in drivers/spi.
^ permalink raw reply
* [PATCH] powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards
From: Anton Vorontsov @ 2009-07-09 18:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
This patch simply adds four eeprom nodes to MPC8548CDS' device tree.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8548cds.dts | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts
index 475be14..4173af3 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -100,6 +100,21 @@
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
+ eeprom@56 {
+ compatible = "atmel,24c64";
+ reg = <0x56>;
+ };
+
+ eeprom@57 {
+ compatible = "atmel,24c64";
+ reg = <0x57>;
+ };
};
i2c@3100 {
@@ -111,6 +126,11 @@
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
};
dma@21300 {
--
1.6.3.3
^ permalink raw reply related
* Re: binutils 2.19 issue with kernel link
From: Dale Farnsworth @ 2009-07-09 19:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <29A5B467-BD0F-4270-B5A4-EF79D9405E28@kernel.crashing.org>
On Thu, Jul 09, 2009 at 01:14:28PM -0500, Kumar Gala wrote:
> On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
>> We have found the following workaround to be useful.
>> Thanks to Andrew Jenner at Code Sourcery.
>>
>> -Dale
>>
>> Dale Farnsworth
>> MontaVista Software
>>
>> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/
>> vmlinux.lds.S
>> index acf237f..34b0181 100644
>> --- a/arch/powerpc/kernel/vmlinux.lds.S
>> +++ b/arch/powerpc/kernel/vmlinux.lds.S
>> @@ -282,4 +282,7 @@ SECTIONS
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>> +
>> +#undef PPC
>> + .PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
>> }
>
> Is there any plans to fix binutils or is this viewed as not a binutils
> regression?
It sure looks like a regression to me, but I don't have details on
a potential fix.
-Dale
^ permalink raw reply
* Re: [spi-devel-general] Questions in spi_mpc83xx.c
From: Mark Bishop @ 2009-07-09 19:29 UTC (permalink / raw)
To: Baruch Siach; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20090709183855.GS16245@tarshish>
Quoting Baruch Siach <baruch@tkos.co.il>:
> Hi Mark,
>
> On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
>> I haven't seen this before - the '##' in the function name. This
>> is ANCII C?
>
> Of course. See pp. 90-91 in "The C Programming Language" second edition.
>
>>
Wow, thanks. I missed that little nugget of info.
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Edmar Wienskoski-RA8797 @ 2009-07-09 19:31 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, Alan Modra,
bug-binutils
In-Reply-To: <4B3B917C-C8B0-416B-888D-13E6C0645BF8@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
>
>> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>>> To further verify this if I switch the -me500 to -mspe and build things
>>> seem to be ok. This further points at some APU section related bug.
>>
>> Like omitting .PPC.EMB.apuinfo from your kernel link script? See the
>> ld info doc on orphan sections.
>
> Ok, not terribly enlightening, but why would .PPC.EMB.apuinfo sections
> be different than something like .debug sections which we also dont
> list in the linker script.
>
> - k
>
Alan,
I understand your arguments, but there is something inconsistent about this.
If I change the script to be:
_end3 = . ;
. = _end3;
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
}
The result is corrected:
c067f678 A _end3
c0680000 A _end
Why the apuinfo section with zero VMA sometimes interfere with "." and
sometimes not ?
Edmar
^ permalink raw reply
* Re: [spi-devel-general] Questions in spi_mpc83xx.c
From: Baruch Siach @ 2009-07-09 18:38 UTC (permalink / raw)
To: Mark Bishop; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20090709141648.ws3ak25ewwogwsc0@www.bish.net>
Hi Mark,
On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
> I haven't seen this before - the '##' in the function name. This is ANCII C?
Of course. See pp. 90-91 in "The C Programming Language" second edition.
>
> #define MPC83XX_SPI_TX_BUF(type) \
> u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi) \
> { \
> u32 data; \
> ....
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 19:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <A9AC0F1D-255E-4445-BC56-FF4024B91BF0@kernel.crashing.org>
On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>
> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>>> Hello Kumar,
>>>>
>>>> I must not understand something going on here. Your proposed code
>>>> doesn't work at all on my board. The
>>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
>>>
>>> What does it come out as? How much memory do you have in the system?
>>>
>>
>> The size_mb shows as 0 with your code. See the explanation below. With
>> my code it shows as 256MB, as expected.
>>
>> I have 256MB memory in the system.
>>
>>>> The attached patch DOES work on my board, but I'm confident that it
>>>> does
>>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>>> wrong?
>>>>
>>>> If I'm reading things correctly:
>>>> csrow->first_page full address of the first page (NOT pfn)
>>>> csrow->last_page full address of the last page (NOT pfn)
>>>> csrow->nr_pages number of pages
>>>>
>>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>>> size_mb
>>>> sysfs value.
>>>>
>>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>>> pfn,
>>>> then I think the original code got it wrong, and the calculation for
>>>> csrow->nr_pages needs to be changed.
>>>>
>>>> Thanks,
>>>> Ira
>>>
>>> [snip]
>>>
>>>> /************************ MC SYSFS parts
>>>> ***********************************/
>>>>
>>>> @@ -790,18 +792,19 @@ static void __devinit
>>>> mpc85xx_init_csrows(struct
>>>> mem_ctl_info *mci)
>>>> csrow = &mci->csrows[index];
>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>> - if (start)
>>>> - start |= 0xfffff;
>>>> - if (end)
>>>> - end |= 0xfffff;
>>>
>>> can you printk what cs_bnds values are in your setup.
>>>
>>
>> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
>> is
>> 0x0000000F.
>>
>>>> +
>>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>>> + end = (cs_bnds & 0x0000ffff);
>>>>
>>
>> This is the same in both our versions.
>>
>> start == 0x0
>> end == 0xF
>>
>>>> if (start == end)
>>>> continue; /* not populated */
>>>>
>>>> - csrow->first_page = start >> PAGE_SHIFT;
>>>> - csrow->last_page = end >> PAGE_SHIFT;
>>>> + start <<= PAGE_SHIFT;
>>>> + end <<= PAGE_SHIFT;
>>>> + end |= (1 << PAGE_SHIFT) - 1;
>>>> +
>>
>> MY VERSION
>>
>> start == 0x0
>> end == 0xffff
>>
>> first_page == 0x0
>> last_page == 0xffff
>>
>> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
>
> My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
>
> With that I think things work out.
>
Yep, that works out great. This solution is much better than my original
code. The 83xx doesn't need to be special-cased anymore.
I checked the math for a 85xx with 64GB of memory. Assuming it uses 64K
pages (PAGE_SHIFT == 16), then everything works out.
I'll submit a new patch now.
Thanks for the help,
Ira
^ permalink raw reply
* [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 19:40 UTC (permalink / raw)
To: bluesmoke-devel, Dave Jiang, Kumar Gala, linuxppc-dev
Add support for the Freescale MPC83xx memory controller to the existing
driver for the Freescale MPC85xx memory controller. The only difference
between the two processors are in the CS_BNDS register parsing code, which
has been changed so it will work on both processors.
The L2 cache controller does not exist on the MPC83xx, but the OF subsystem
will not use the driver if the device is not present in the OF device tree.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
Kumar, I had to change the nr_pages calculation to make the math work
out. I checked it on my board and did the math by hand for a 64GB 85xx
using 64K pages. In both cases, nr_pages * PAGE_SIZE comes out to the
correct value. Thanks for the help.
v1 -> v2:
* Use PAGE_SHIFT to parse cs_bnds regardless of board type
* Remove special-casing for the 83xx processor
drivers/edac/Kconfig | 6 +++---
drivers/edac/mpc85xx_edac.c | 28 +++++++++++++++++++---------
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 4339b1a..78303f9 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -176,11 +176,11 @@ config EDAC_I5100
San Clemente MCH.
config EDAC_MPC85XX
- tristate "Freescale MPC85xx"
- depends on EDAC_MM_EDAC && FSL_SOC && MPC85xx
+ tristate "Freescale MPC83xx / MPC85xx"
+ depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)
help
Support for error detection and correction on the Freescale
- MPC8560, MPC8540, MPC8548
+ MPC8349, MPC8560, MPC8540, MPC8548
config EDAC_MV64X60
tristate "Marvell MV64x60"
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b4f5c63..ba2a264 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -43,7 +43,9 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
+#ifdef CONFIG_MPC85xx
static u32 orig_hid1[2];
+#endif
/************************ MC SYSFS parts ***********************************/
@@ -790,19 +792,20 @@ static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
csrow = &mci->csrows[index];
cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
(index * MPC85XX_MC_CS_BNDS_OFS));
- start = (cs_bnds & 0xfff0000) << 4;
- end = ((cs_bnds & 0xfff) << 20);
- if (start)
- start |= 0xfffff;
- if (end)
- end |= 0xfffff;
+
+ start = (cs_bnds & 0xffff0000) >> 16;
+ end = (cs_bnds & 0x0000ffff);
if (start == end)
continue; /* not populated */
+ start <<= (24 - PAGE_SHIFT);
+ end <<= (24 - PAGE_SHIFT);
+ end |= (1 << (24 - PAGE_SHIFT)) - 1;
+
csrow->first_page = start >> PAGE_SHIFT;
csrow->last_page = end >> PAGE_SHIFT;
- csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
+ csrow->nr_pages = end + 1 - start;
csrow->grain = 8;
csrow->mtype = mtype;
csrow->dtype = DEV_UNKNOWN;
@@ -986,6 +989,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8560-memory-controller", },
{ .compatible = "fsl,mpc8568-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
+ { .compatible = "fsl,mpc8349-memory-controller", },
{},
};
@@ -1001,13 +1005,13 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
-
+#ifdef CONFIG_MPC85xx
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
}
-
+#endif
static int __init mpc85xx_mc_init(void)
{
@@ -1040,26 +1044,32 @@ static int __init mpc85xx_mc_init(void)
printk(KERN_WARNING EDAC_MOD_STR "PCI fails to register\n");
#endif
+#ifdef CONFIG_MPC85xx
/*
* need to clear HID1[RFXE] to disable machine check int
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT)
on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+#endif
return 0;
}
module_init(mpc85xx_mc_init);
+#ifdef CONFIG_MPC85xx
static void __exit mpc85xx_mc_restore_hid1(void *data)
{
mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
}
+#endif
static void __exit mpc85xx_mc_exit(void)
{
+#ifdef CONFIG_MPC85xx
on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+#endif
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-09 20:15 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090709193519.GE29383@ovro.caltech.edu>
On Jul 9, 2009, at 2:35 PM, Ira W. Snyder wrote:
> On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>>
>> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>>
>>> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>>>> Hello Kumar,
>>>>>
>>>>> I must not understand something going on here. Your proposed code
>>>>> doesn't work at all on my board. The
>>>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out
>>>>> correctly.
>>>>
>>>> What does it come out as? How much memory do you have in the
>>>> system?
>>>>
>>>
>>> The size_mb shows as 0 with your code. See the explanation below.
>>> With
>>> my code it shows as 256MB, as expected.
>>>
>>> I have 256MB memory in the system.
>>>
>>>>> The attached patch DOES work on my board, but I'm confident that
>>>>> it
>>>>> does
>>>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>>>> wrong?
>>>>>
>>>>> If I'm reading things correctly:
>>>>> csrow->first_page full address of the first page (NOT pfn)
>>>>> csrow->last_page full address of the last page (NOT pfn)
>>>>> csrow->nr_pages number of pages
>>>>>
>>>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>>>> size_mb
>>>>> sysfs value.
>>>>>
>>>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>>>> pfn,
>>>>> then I think the original code got it wrong, and the calculation
>>>>> for
>>>>> csrow->nr_pages needs to be changed.
>>>>>
>>>>> Thanks,
>>>>> Ira
>>>>
>>>> [snip]
>>>>
>>>>> /************************ MC SYSFS parts
>>>>> ***********************************/
>>>>>
>>>>> @@ -790,18 +792,19 @@ static void __devinit
>>>>> mpc85xx_init_csrows(struct
>>>>> mem_ctl_info *mci)
>>>>> csrow = &mci->csrows[index];
>>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>>> - if (start)
>>>>> - start |= 0xfffff;
>>>>> - if (end)
>>>>> - end |= 0xfffff;
>>>>
>>>> can you printk what cs_bnds values are in your setup.
>>>>
>>>
>>> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
>>> is
>>> 0x0000000F.
>>>
>>>>> +
>>>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>>>> + end = (cs_bnds & 0x0000ffff);
>>>>>
>>>
>>> This is the same in both our versions.
>>>
>>> start == 0x0
>>> end == 0xF
>>>
>>>>> if (start == end)
>>>>> continue; /* not populated */
>>>>>
>>>>> - csrow->first_page = start >> PAGE_SHIFT;
>>>>> - csrow->last_page = end >> PAGE_SHIFT;
>>>>> + start <<= PAGE_SHIFT;
>>>>> + end <<= PAGE_SHIFT;
>>>>> + end |= (1 << PAGE_SHIFT) - 1;
>>>>> +
>>>
>>> MY VERSION
>>>
>>> start == 0x0
>>> end == 0xffff
>>>
>>> first_page == 0x0
>>> last_page == 0xffff
>>>
>>> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
>>
>> My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
>>
>> With that I think things work out.
>>
>
> Yep, that works out great. This solution is much better than my
> original
> code. The 83xx doesn't need to be special-cased anymore.
>
> I checked the math for a 85xx with 64GB of memory. Assuming it uses
> 64K
> pages (PAGE_SHIFT == 16), then everything works out.
Does the math work for a 64GB system w/4K pages?
- k
^ permalink raw reply
* Bestcomm trouble with NAPI for MPC5200 FEC
From: Wolfgang Grandegger @ 2009-07-09 20:33 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the system. The NAPI
implementation, in principle, is straight forward and works
well under normal and moderate network load. It just calls disable_irq()
in the receive interrupt handler to defer packet processing to the NAPI
poll callback, which calls enable_irq() when it has processed all
packets. Unfortunately, under heavy network load (packet storm),
problems show up:
- With DENX 2.4.25, the Bestcomm RX task gets and remains stopped after
a while under additional system load. I have no idea how and when
Bestcom tasks are stopped. In the auto-start mode, the firmware should
poll forever for the next free descriptor block.
- With 2.6.31-rc2, the RFIFO error occurs quickly which does reset the
FEC and Bestcomm (unfortunately, this does trigger an oops because
it's called from the interrupt context, but that's another issue).
I'm realized that working with Bestcomm is a pain :-( but so far I have
little knowledge of the Bestcomm limitations and quirks. Any idea what
might go wrong or how to implement NAPI for that FEC properly.
TIA,
Wolfgang.
^ permalink raw reply
* Re: Bestcomm trouble with NAPI for MPC5200 FEC
From: Grant Likely @ 2009-07-09 21:22 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev
In-Reply-To: <4A565423.6010207@grandegger.com>
On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandegger<wg@grandegger.com> wrot=
e:
> Hello,
>
> I'm currently trying to implement NAPI for the FEC on the MPC5200 to
> solve the well known problem, that network packet storms can cause
> interrupt flooding, which may totally block the system.
Good to hear it! Thanks for this work.
> The NAPI
> implementation, in principle, is straight forward and works
> well under normal and moderate network load. It just calls disable_irq()
> in the receive interrupt handler to defer packet processing to the NAPI
> poll callback, which calls enable_irq() when it has processed all
> packets. Unfortunately, under heavy network load (packet storm),
> problems show up:
>
> - With DENX 2.4.25, the Bestcomm RX task gets and remains stopped after
> =A0a while under additional system load. I have no idea how and when
> =A0Bestcom tasks are stopped. In the auto-start mode, the firmware should
> =A0poll forever for the next free descriptor block.
>
> - With 2.6.31-rc2, the RFIFO error occurs quickly which does reset the
> =A0FEC and Bestcomm (unfortunately, this does trigger an oops because
> =A0it's called from the interrupt context, but that's another issue).
>
> I'm realized that working with Bestcomm is a pain :-( but so far I have
> little knowledge of the Bestcomm limitations and quirks. Any idea what
> might go wrong or how to implement NAPI for that FEC properly.
Yes, I have a few ideas. First, I suspect that the FEC rx queue isn't
big enough and I wouldn't be surprised if the RFIFO error is occurring
because Bestcomm gets overrun. This scenario needs to be handled more
gracefully.
Second, I think resetting the PHY should be removed from the reset
path. The phy doesn't at all need to be reset and doing this would
avoid the OOPS condition. Also, in the RFIFO error path needs to be
audited to make sure that all the good received packets are processed
correctly before resetting the BCOM engine and to make sure that
skbufs are not getting leaked.
Essentially, I think that the RFIFO error condition is currently
handled in far too heavy handed a manner and it should not be
expensive to recover from.
Thanks for this work!
g..
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <C720C7F4-B3FE-4C98-B04A-EE4F0BD40D5E@kernel.crashing.org>
On Thu, Jul 09, 2009 at 03:15:29PM -0500, Kumar Gala wrote:
>
> On Jul 9, 2009, at 2:35 PM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>>>
>>> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>>>
>>>> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>>>>> Hello Kumar,
>>>>>>
>>>>>> I must not understand something going on here. Your proposed code
>>>>>> doesn't work at all on my board. The
>>>>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out
>>>>>> correctly.
>>>>>
>>>>> What does it come out as? How much memory do you have in the
>>>>> system?
>>>>>
>>>>
>>>> The size_mb shows as 0 with your code. See the explanation below.
>>>> With
>>>> my code it shows as 256MB, as expected.
>>>>
>>>> I have 256MB memory in the system.
>>>>
>>>>>> The attached patch DOES work on my board, but I'm confident
>>>>>> that it
>>>>>> does
>>>>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>>>>> wrong?
>>>>>>
>>>>>> If I'm reading things correctly:
>>>>>> csrow->first_page full address of the first page (NOT pfn)
>>>>>> csrow->last_page full address of the last page (NOT pfn)
>>>>>> csrow->nr_pages number of pages
>>>>>>
>>>>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>>>>> size_mb
>>>>>> sysfs value.
>>>>>>
>>>>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>>>>> pfn,
>>>>>> then I think the original code got it wrong, and the
>>>>>> calculation for
>>>>>> csrow->nr_pages needs to be changed.
>>>>>>
>>>>>> Thanks,
>>>>>> Ira
>>>>>
>>>>> [snip]
>>>>>
>>>>>> /************************ MC SYSFS parts
>>>>>> ***********************************/
>>>>>>
>>>>>> @@ -790,18 +792,19 @@ static void __devinit
>>>>>> mpc85xx_init_csrows(struct
>>>>>> mem_ctl_info *mci)
>>>>>> csrow = &mci->csrows[index];
>>>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>>>> - if (start)
>>>>>> - start |= 0xfffff;
>>>>>> - if (end)
>>>>>> - end |= 0xfffff;
>>>>>
>>>>> can you printk what cs_bnds values are in your setup.
>>>>>
>>>>
>>>> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
>>>> is
>>>> 0x0000000F.
>>>>
>>>>>> +
>>>>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>>>>> + end = (cs_bnds & 0x0000ffff);
>>>>>>
>>>>
>>>> This is the same in both our versions.
>>>>
>>>> start == 0x0
>>>> end == 0xF
>>>>
>>>>>> if (start == end)
>>>>>> continue; /* not populated */
>>>>>>
>>>>>> - csrow->first_page = start >> PAGE_SHIFT;
>>>>>> - csrow->last_page = end >> PAGE_SHIFT;
>>>>>> + start <<= PAGE_SHIFT;
>>>>>> + end <<= PAGE_SHIFT;
>>>>>> + end |= (1 << PAGE_SHIFT) - 1;
>>>>>> +
>>>>
>>>> MY VERSION
>>>>
>>>> start == 0x0
>>>> end == 0xffff
>>>>
>>>> first_page == 0x0
>>>> last_page == 0xffff
>>>>
>>>> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
>>>
>>> My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
>>>
>>> With that I think things work out.
>>>
>>
>> Yep, that works out great. This solution is much better than my
>> original
>> code. The 83xx doesn't need to be special-cased anymore.
>>
>> I checked the math for a 85xx with 64GB of memory. Assuming it uses
>> 64K
>> pages (PAGE_SHIFT == 16), then everything works out.
>
> Does the math work for a 64GB system w/4K pages?
>
Yes, the math works there too. I just double-checked by hand. The v2
patch should work fine on both the 83xx and 85xx (both 4K and 64K
pages).
Thanks again for the help on this one.
Ira
^ 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