tag:old.nabble.com,2006:forum-15993
Nabble - linuxppc
2009-12-07T08:23:18Z
Linux for PowerPC
tag:old.nabble.com,2006:post-26679709
Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
2009-12-07T08:23:18Z
2009-12-07T08:23:18Z
Peter Tyser
Hi Anton,
<br>I've CC-ed devicetree-discuss. The original patch is at
<br><a href="http://patchwork.ozlabs.org/patch/40361/" target="_top" rel="nofollow">http://patchwork.ozlabs.org/patch/40361/</a> for reference.
<br><br>On Sat, 2009-12-05 at 23:51 +0300, Anton Vorontsov wrote:
<div class='shrinkable-quote'><br>> On Sat, Dec 05, 2009 at 01:32:32PM -0600, Peter Tyser wrote:
<br>> [...]
<br>> > > > Adding a new "fsl,gpio-mask" device tree property allows a dts file to
<br>> > > > accurately describe what GPIO pins are available for use on a given
<br>> > > > board.
<br>> > >
<br>> > > I don't see any real usage for this. If device tree specifies a wrong
<br>> > > gpio in the gpios = <> property, then it's a bug in the device tree
<br>> > > and should be fixed (or workarounded in the platform code).
<br>> > >
<br>> > > If a user fiddles with unknown gpios via sysfs interface, then it's
<br>> > > user's problem.
<br>> >
<br>> > Its the sysfs case that I'm concerned about. Primarily because:
<br>> > 1. Users scratch their head when they see that the "ngpio" sysfs value
<br>> > doesn't match their CPU manual or board vendor's manual, and
<br>> > subsequently ask their board vendor's engineers (ie me:) what's up.
<br>>
<br>> I don't think that adding code and device tree entries just for
<br>> documentation purposes is a good idea.
</div><br>Its not just for documentation purposes. Right now, the sysfs "ngpio"
<br>value is flat out wrong for some processors, regardless of
<br>documentation. Granted its not a critical bug, but I'd still consider
<br>it a bug.
<br><br>> > 2. Improperly using GPIO pins could damage hardware for some boards.
<br>>
<br>> Well, your initial patch tried to solve a different problem: to not
<br>> let users to request non-existent GPIOs, which is usually safe.
<br><br>I can update the commit message with this rational if it makes a
<br>difference.
<br><br>> [...]
<br>> > #2 could be worked around by exporting GPIO pins in platform code so
<br>> > that they are not available via sysfs.
<br>>
<br>> Yes, badly designed hardware deserves ugly hacks in the platform
<br>> code. ;-) So for this problem, just request these gpios in the
<br>> platform code.
<br><br>I'd wager lots of boards have GPIO pins that a user shouldn't play
<br>around with once Linux boots up. Like GPIO pins used to program an
<br>FPGA, or control a PLL, etc. 1 device tree property is nicer than
<br>hacking up lots of platform code...
<br><div class='shrinkable-quote'><br>> > Would it be any more acceptable to instead add
<br>> > a "fsl,num-gpio" property so that "ngpio" actually reported an accurate
<br>> > value and non-existent GPIO pins couldn't be used/exported?
<br>>
<br>> I'd think it's actually less acceptable. fsl,gpio-mask is more generic,
<br>> since from gpio-mask you can deduce ngpio. But it's still ugly.
<br>>
<br>> What would be OK to do is to describe in the device tree every
<br>> device that is using some GPIO, and then let the userspace request
<br>> *only* gpios that are described in the device-tree. That way you
<br>> can automatically exclude not-existent gpios.
<br>> And if some gpios are just headers on the board, you can still
<br>> describe them in the device tree via "gpio-header" nodes.
<br>>
<br>> Still, a lot of efforts for no real gain...
</div><br>Agreed. Seems like a clean solution, but is a chunk of work.
<br><br>In any case, my high-level thought process is:
<br>1. Currently, the "ngpio" value is wrong for some processors and should
<br>be fixed.
<br>2. Adding a new "fsl,gpio-mask" gpio solves #1, and has the benefit of
<br>allowing the device tree to easily reserve GPIO pins which should not be
<br>used in Linux.
<br><br>I guess I'm not seeing the big downside of a new "fsl,gpio-mask"
<br>property. Its the device tree's job to describe the hardware. The
<br>change is pretty minimal (~15 lines), and the property can be made
<br>optional.
<br><br>Or is there another suggestion on how to resolve #1 above? I consider
<br>it a bug and would like to fix it.
<br><br>Best,
<br>Peter
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26679709&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26679694
Re: MACE DMA problem on Powermac 7300
2009-12-07T08:22:23Z
2009-12-07T08:22:23Z
Risto Suominen
Hi, Ben,
<br><br>2009/12/7, Benjamin Herrenschmidt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26679694&i=0" target="_top" rel="nofollow">benh@...</a>>:
<br>>
<br>> Cache coherency bugs in the chipset or HW bugs in DBDMA, we've been
<br>> seeing those on/off on those old apple chipsets...
<br>>
<br>> Try forcing a 32 bytes alignment ?
<br>>
<br>You're thinking of placing the DMA descriptors on different cache lines?
<br><br>That's excactly what I did with de2104x. But it was easier, I think.
<br>The chip handled its own DMA, and by writing a skip value to a
<br>register... I don't know this GC DMA controller well enough and
<br>haven't found the documentation either...
<br><br>But I tried the de21041 board with unmodified driver on this 7300, and
<br>it works. The problem was on a 5500.
<br><br>Risto
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26679694&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26672967
[PATCH] offb: add support for framebuffer handoff to offb.
2009-12-06T22:01:26Z
2009-12-06T22:01:26Z
Dave Airlie
From: Dave Airlie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26672967&i=0" target="_top" rel="nofollow">airlied@...</a>>
<br><br>This allows offb to be used for initial framebuffer,
<br>and a kms driver to take over later in the boot sequence.
<br><br>Signed-off-by: Dave Airlie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26672967&i=1" target="_top" rel="nofollow">airlied@...</a>>
<br>---
<br> drivers/video/offb.c | 15 ++++++++++++++-
<br> 1 files changed, 14 insertions(+), 1 deletions(-)
<br><br>diff --git a/drivers/video/offb.c b/drivers/video/offb.c
<br>index 4d8c54c..b043ac8 100644
<br>--- a/drivers/video/offb.c
<br>+++ b/drivers/video/offb.c
<br>@@ -282,8 +282,17 @@ static int offb_set_par(struct fb_info *info)
<br> return 0;
<br> }
<br>
<br>+static void offb_destroy(struct fb_info *info)
<br>+{
<br>+ if (info->screen_base)
<br>+ iounmap(info->screen_base);
<br>+ release_mem_region(info->aperture_base, info->aperture_size);
<br>+ framebuffer_release(info);
<br>+}
<br>+
<br> static struct fb_ops offb_ops = {
<br> .owner = THIS_MODULE,
<br>+ .fb_destroy = offb_destroy,
<br> .fb_setcolreg = offb_setcolreg,
<br> .fb_set_par = offb_set_par,
<br> .fb_blank = offb_blank,
<br>@@ -482,10 +491,14 @@ static void __init offb_init_fb(const char *name, const char *full_name,
<br> var->sync = 0;
<br> var->vmode = FB_VMODE_NONINTERLACED;
<br>
<br>+ /* set offb aperture size for generic probing */
<br>+ info->aperture_base = address;
<br>+ info->aperture_size = fix->smem_len;
<br>+
<br> info->fbops = &offb_ops;
<br> info->screen_base = ioremap(address, fix->smem_len);
<br> info->pseudo_palette = (void *) (info + 1);
<br>- info->flags = FBINFO_DEFAULT | foreign_endian;
<br>+ info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE | foreign_endian;
<br>
<br> fb_alloc_cmap(&info->cmap, 256, 0);
<br>
<br>--
<br>1.6.5.rc2
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26672967&i=2" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26671516
Re: MACE DMA problem on Powermac 7300
2009-12-06T18:03:44Z
2009-12-06T18:03:44Z
Benjamin Herrenschmidt
On Mon, 2009-12-07 at 00:36 +0200, Risto Suominen wrote:
<div class='shrinkable-quote'><br>> I post this in hope that somebody could shed some light on how should
<br>> the DMA work in conjunction with the MACE ethernet controller. I find
<br>> difficult to understand why it does not work in my case:
<br>>
<br>> What happens? First two bytes of a received frame are not what they
<br>> should be in more than 50% of frames. This can be avoided by receiving
<br>> the frame on a word boundary, but with the usual skb_reserve(..., 2)
<br>> (to make the IP header land on word boundary), it won't work.
<br>>
<br>> So, I can make the driver work by receiving at 0 offset, and then
<br>> moving the data 2 bytes up, before handing it over to upper layers.
<br>>
<br>> This used to work with a 2.4.27 kernel, obviously the Grand Central
<br>> DBDMA controller can receive on non-word boundaries. Now I have
<br>> 2.6.15.7.
<br>>
<br>> Any ideas, what could cause this kind of behaviour (and regression)?
</div><br>Cache coherency bugs in the chipset or HW bugs in DBDMA, we've been
<br>seeing those on/off on those old apple chipsets...
<br><br>Try forcing a 32 bytes alignment ?
<br><br>Cheers,
<br>Ben.
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26671516&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26671169
Re: using different format for hugetlbfs
2009-12-06T17:04:37Z
2009-12-06T17:04:37Z
Benjamin Herrenschmidt
<br>>
<br>> Even than, does that preclude the format I suggested? I'm assuming
<br>> that pgd_t/pud_t/pmd_t are always a double word so the low order 4-
<br>> bits should be 0 (on 64-bit), so using the lsb as the flag between
<br>> hugetlb and normal pointer should still work.
<br><br>Might do, depends if David has enough bits ... David ?
<br><br>Cheers,
<br>Ben.
<br><br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26671169&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26669898
MACE DMA problem on Powermac 7300
2009-12-06T14:36:15Z
2009-12-06T14:36:15Z
Risto Suominen
Hi, everybody,
<br><br>I post this in hope that somebody could shed some light on how should
<br>the DMA work in conjunction with the MACE ethernet controller. I find
<br>difficult to understand why it does not work in my case:
<br><br>What happens? First two bytes of a received frame are not what they
<br>should be in more than 50% of frames. This can be avoided by receiving
<br>the frame on a word boundary, but with the usual skb_reserve(..., 2)
<br>(to make the IP header land on word boundary), it won't work.
<br><br>So, I can make the driver work by receiving at 0 offset, and then
<br>moving the data 2 bytes up, before handing it over to upper layers.
<br><br>This used to work with a 2.4.27 kernel, obviously the Grand Central
<br>DBDMA controller can receive on non-word boundaries. Now I have
<br>2.6.15.7.
<br><br>Any ideas, what could cause this kind of behaviour (and regression)?
<br><br>Best regards,
<br>Risto Suominen
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26669898&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26664266
[RFC] doc/powerpc: try to explain why the interrupt numbers are off by 16
2009-12-06T03:32:47Z
2009-12-06T03:32:47Z
Sebastian Andrzej Siewior
Signed-off-by: Sebastian Andrzej Siewior <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26664266&i=0" target="_top" rel="nofollow">sebastian@...</a>>
<br>---
<br> Documentation/powerpc/dts-bindings/fsl/mpic.txt | 42 +++++++++++++++++++++++
<br> 1 files changed, 42 insertions(+), 0 deletions(-)
<br> create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt
<br><br>diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
<br>new file mode 100644
<br>index 0000000..71e39cf
<br>--- /dev/null
<br>+++ b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
<br>@@ -0,0 +1,42 @@
<br>+* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
<br>+
<br>+The OpenPIC specification does not specify which interrupt source has to
<br>+become which interrupt number. This is up to the software implementation
<br>+of the interrupt controller. The only requirement is that every
<br>+interrupt source has to have an unique interrupt number / vector number.
<br>+To accomplish this the current implementation assigns the number zero to
<br>+the first source, the number one to the second source and so on until
<br>+all interrupt sources have their unique number.
<br>+Usually the assigned vector number equals the interrupt number mentioned
<br>+in the documentation for a given core / CPU. This is however not true
<br>+for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
<br>+between internal and external interrupt sources and starts counting at
<br>+zero for both of them.
<br>+
<br>+So what to write for external interrupt source X or internal interrupt
<br>+source Y into the device tree? Here is an example:
<br>+
<br>+The memory map for the interrupt controller in the MPC8544[0] shows,
<br>+that the first interrupt source starts at 0x5_0000 (PIC Register Address
<br>+Map-Interrupt Source Configuration Registers). This source becomes the
<br>+number zero therefore:
<br>+ External interrupt 0 = interrupt number 0
<br>+ External interrupt 1 = interrupt number 1
<br>+ External interrupt 2 = interrupt number 2
<br>+ ...
<br>+Every interrupt number allocates 0x20 bytes register space. So to get
<br>+its number it is sufficient to shift the lower 16bits to right by five.
<br>+So for the external interrupt 10 we have:
<br>+ 0x0140 >> 5 = 10
<br>+
<br>+After the external sources, the internal sources follow. The in core I2C
<br>+controller on the MPC8544 for instance has the internal source number
<br>+27. Oo obtain its interrupt number we take the lower 16bits of its memory
<br>+address (0x5_0560) and shift it right:
<br>+ 0x0560 >> 5 = 43
<br>+
<br>+Therefore the I2C device node for the MPC8544 CPU has to have the
<br>+interrupt number 43 specified in the device tree.
<br>+
<br>+[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
<br>+ MPC8544ERM Rev. 1 10/2007
<br>--
<br>1.6.5.3
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26664266&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26661831
Re: using different format for hugetlbfs
2009-12-05T19:05:01Z
2009-12-05T19:05:01Z
Kumar Gala-3
<br>On Dec 4, 2009, at 3:25 PM, Benjamin Herrenschmidt wrote:
<br><div class='shrinkable-quote'><br>> On Fri, 2009-12-04 at 08:09 -0600, Kumar Gala wrote:
<br>>> On Dec 4, 2009, at 2:58 AM, Benjamin Herrenschmidt wrote:
<br>>>
<br>>>> On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
<br>>>>> Ben, David,
<br>>>>>
<br>>>>> If we want to support true 4G/4G split on ppc32 using the MSB of
<br>>>>> the
<br>>>>> address to determine of the pgd_t is for hugetlbfs isn't going to
<br>>>>> work. Since every pointer in the pgd_t -> pud_t -> pmd_t is
<br>>>>> point to
<br>>>>> at least a 4K page I would think the low order 12-bits should
<br>>>>> always
<br>>>>> be 0.
<br>>>>
<br>>>> On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
<br>>>> want to have a different encoding for both types though.
<br>>>
<br>>> What do you mean they can be smaller? We have some scenario when we
<br>>> dont allocate a full page? I agree having the encodings be different
<br>>> would be bad. I'm trying to avoid having it be different between 32
<br>>> bit and 64 (but maybe that will be impossible).
<br>>
<br>> Yes. The intermediary levels are smaller on 64-bit. Also, with
<br>> hugetlbfs
<br>> it can create special levels of various sizes depending on the
<br>> requirements to fit a given huge page size. And that would be true of
<br>> both 32 and 64-bit in fact.
</div><br>Even than, does that preclude the format I suggested? I'm assuming
<br>that pgd_t/pud_t/pmd_t are always a double word so the low order 4-
<br>bits should be 0 (on 64-bit), so using the lsb as the flag between
<br>hugetlb and normal pointer should still work.
<br><br>- k
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26661831&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26659219
Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
2009-12-05T12:51:49Z
2009-12-05T12:51:49Z
Anton Vorontsov-2
On Sat, Dec 05, 2009 at 01:32:32PM -0600, Peter Tyser wrote:
<br>[...]
<div class='shrinkable-quote'><br>> > > Adding a new "fsl,gpio-mask" device tree property allows a dts file to
<br>> > > accurately describe what GPIO pins are available for use on a given
<br>> > > board.
<br>> >
<br>> > I don't see any real usage for this. If device tree specifies a wrong
<br>> > gpio in the gpios = <> property, then it's a bug in the device tree
<br>> > and should be fixed (or workarounded in the platform code).
<br>> >
<br>> > If a user fiddles with unknown gpios via sysfs interface, then it's
<br>> > user's problem.
<br>>
<br>> Its the sysfs case that I'm concerned about. Primarily because:
<br>> 1. Users scratch their head when they see that the "ngpio" sysfs value
<br>> doesn't match their CPU manual or board vendor's manual, and
<br>> subsequently ask their board vendor's engineers (ie me:) what's up.
</div><br>I don't think that adding code and device tree entries just for
<br>documentation purposes is a good idea.
<br><br>> 2. Improperly using GPIO pins could damage hardware for some boards.
<br><br>Well, your initial patch tried to solve a different problem: to not
<br>let users to request non-existent GPIOs, which is usually safe.
<br><br>[...]
<br>> #2 could be worked around by exporting GPIO pins in platform code so
<br>> that they are not available via sysfs.
<br><br>Yes, badly designed hardware deserves ugly hacks in the platform
<br>code. ;-) So for this problem, just request these gpios in the
<br>platform code.
<br><br>> Would it be any more acceptable to instead add
<br>> a "fsl,num-gpio" property so that "ngpio" actually reported an accurate
<br>> value and non-existent GPIO pins couldn't be used/exported?
<br><br>I'd think it's actually less acceptable. fsl,gpio-mask is more generic,
<br>since from gpio-mask you can deduce ngpio. But it's still ugly.
<br><br>What would be OK to do is to describe in the device tree every
<br>device that is using some GPIO, and then let the userspace request
<br>*only* gpios that are described in the device-tree. That way you
<br>can automatically exclude not-existent gpios.
<br>And if some gpios are just headers on the board, you can still
<br>describe them in the device tree via "gpio-header" nodes.
<br><br>Still, a lot of efforts for no real gain...
<br><br>--
<br>Anton Vorontsov
<br>email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26659219&i=0" target="_top" rel="nofollow">cbouatmailru@...</a>
<br>irc://irc.freenode.net/bd2
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26659219&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26658970
Re: [PATCH] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2009-12-05T12:25:56Z
2009-12-05T12:25:56Z
Benjamin Herrenschmidt
On Fri, 2009-12-04 at 14:20 -0700, Grant Likely wrote:
<div class='shrinkable-quote'><br>> From: Asier Llano Palacios <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26658970&i=0" target="_top" rel="nofollow">asierllano@...</a>>
<br>>
<br>> net/mpc5200: Fix locking on fec_mpc52xx driver
<br>>
<br>> Fix the locking scheme on the fec_mpc52xx driver. This device can
<br>> receive IRQs from three sources; the FEC itself, the tx DMA, and the
<br>> rx DMA. Mutual exclusion was handled by taking a spin_lock() in the
<br>> critical regions, but because the handlers are run with IRQs enabled,
<br>> spin_lock() is insufficient and the driver can end up interrupting
<br>> a critical region anyway from another IRQ.
</div><br> .../...
<br><br>I would suggest a simpler locking strategy.
<br><br>The network stack is going to provide you with a lock already which is
<br>the tx queue lock. It's going to be taken for you in start_xmit.
<br><br>That gives you a simple locking against tx using existing network stack
<br>lock unlock primitives
<br><br>Everything else should happen within NAPI poll.
<br><br>The trick then is to not need locking in your interrupt handlers. You
<br>shouldn't need locking to schedule NAPI which is all they should do for
<br>normal tx/rx interrupts. For errors, just kick a workqueue.
<br><br>>From that work queue, you can stop NAPI and stop the TX while you do
<br>your chip reset etc...
<br><br>Something like what tg3 does:
<br><br>static inline void tg3_netif_stop(struct tg3 *tp)
<br>{
<br> tp->dev->trans_start = jiffies; /* prevent tx timeout */
<br> tg3_napi_disable(tp);
<br> netif_tx_disable(tp->dev);
<br>}
<br><br>You may want to be careful about potential calls to some of your other
<br>network callbacks tho, such as set_multicast.. I don't think the
<br>network stack will shield you there and set_multicast, last I looked,
<br>was called in a context where you can't use a mutex. But that gives you
<br>the basic locking strategy for your driver without adding an unnecessary
<br>spinlock to your fast path.
<br><br>Cheers,
<br>Ben.
<br><div class='shrinkable-quote'><br>> Asier Llano discovered that this occurs when an error IRQ is raised
<br>> in the middle of handling rx irqs which resulted in an sk_buff memory
<br>> leak.
<br>>
<br>> In addition, locking is spotty at best in the driver and inspection
<br>> revealed quite a few places with insufficient locking.
<br>>
<br>> This patch is based on Asier's initial work, but reworks a number of
<br>> things so that locks are held for as short a time as possible, so
<br>> that spin_lock_irqsave() is used everywhere, and so the locks are
<br>> dropped when calling into the network stack (because the lock only
<br>> protects the hardware interface; not the network stack).
<br>>
<br>> Boot tested on a lite5200 with an NFS root. Has not been performance
<br>> tested.
<br>>
<br>> Signed-off-by: Asier Llano <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26658970&i=1" target="_top" rel="nofollow">a.llano@...</a>>
<br>> Signed-off-by: Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26658970&i=2" target="_top" rel="nofollow">grant.likely@...</a>>
<br>> ---
<br>>
<br>> Asier, can you please test this? It took me a while to respond to
<br>> your initial post because I was concerned about some of the latency
<br>> issues, and I was concerned about disabling IRQs for long periods in
<br>> the RX handler. I think it should be good now, but it needs testing.
<br>>
<br>> Cheers,
<br>> g.
<br>>
<br>> drivers/net/fec_mpc52xx.c | 121 +++++++++++++++++++++++----------------------
<br>> 1 files changed, 62 insertions(+), 59 deletions(-)
<br>>
<br>> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
<br>> index 66dace6..4889b4d 100644
<br>> --- a/drivers/net/fec_mpc52xx.c
<br>> +++ b/drivers/net/fec_mpc52xx.c
<br>> @@ -85,11 +85,15 @@ MODULE_PARM_DESC(debug, "debugging messages level");
<br>>
<br>> static void mpc52xx_fec_tx_timeout(struct net_device *dev)
<br>> {
<br>> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + unsigned long flags;
<br>> +
<br>> dev_warn(&dev->dev, "transmit timed out\n");
<br>>
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> mpc52xx_fec_reset(dev);
<br>> -
<br>> dev->stats.tx_errors++;
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> netif_wake_queue(dev);
<br>> }
<br>> @@ -135,28 +139,32 @@ static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct bcom_task
<br>> }
<br>> }
<br>>
<br>> +static void
<br>> +mpc52xx_fec_rx_submit(struct net_device *dev, struct sk_buff *rskb)
<br>> +{
<br>> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + struct bcom_fec_bd *bd;
<br>> +
<br>> + bd = (struct bcom_fec_bd *) bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>> + bd->status = FEC_RX_BUFFER_SIZE;
<br>> + bd->skb_pa = dma_map_single(dev->dev.parent, rskb->data,
<br>> + FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> + bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>> +}
<br>> +
<br>> static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct bcom_task *rxtsk)
<br>> {
<br>> - while (!bcom_queue_full(rxtsk)) {
<br>> - struct sk_buff *skb;
<br>> - struct bcom_fec_bd *bd;
<br>> + struct sk_buff *skb;
<br>>
<br>> + while (!bcom_queue_full(rxtsk)) {
<br>> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>> - if (skb == NULL)
<br>> + if (!skb)
<br>> return -EAGAIN;
<br>>
<br>> /* zero out the initial receive buffers to aid debugging */
<br>> memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
<br>> -
<br>> - bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
<br>> -
<br>> - bd->status = FEC_RX_BUFFER_SIZE;
<br>> - bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>> - FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> -
<br>> - bcom_submit_next_buffer(rxtsk, skb);
<br>> + mpc52xx_fec_rx_submit(dev, skb);
<br>> }
<br>> -
<br>> return 0;
<br>> }
<br>>
<br>> @@ -328,13 +336,12 @@ static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
<br>> DMA_TO_DEVICE);
<br>>
<br>> bcom_submit_next_buffer(priv->tx_dmatsk, skb);
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> if (bcom_queue_full(priv->tx_dmatsk)) {
<br>> netif_stop_queue(dev);
<br>> }
<br>>
<br>> - spin_unlock_irqrestore(&priv->lock, flags);
<br>> -
<br>> return NETDEV_TX_OK;
<br>> }
<br>>
<br>> @@ -359,9 +366,9 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br>> {
<br>> struct net_device *dev = dev_id;
<br>> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + unsigned long flags;
<br>>
<br>> - spin_lock(&priv->lock);
<br>> -
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> while (bcom_buffer_done(priv->tx_dmatsk)) {
<br>> struct sk_buff *skb;
<br>> struct bcom_fec_bd *bd;
<br>> @@ -372,11 +379,10 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br>>
<br>> dev_kfree_skb_irq(skb);
<br>> }
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> netif_wake_queue(dev);
<br>>
<br>> - spin_unlock(&priv->lock);
<br>> -
<br>> return IRQ_HANDLED;
<br>> }
<br>>
<br>> @@ -384,67 +390,60 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
<br>> {
<br>> struct net_device *dev = dev_id;
<br>> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + struct sk_buff *rskb; /* received sk_buff */
<br>> + struct sk_buff *skb; /* new sk_buff to enqueue in its place */
<br>> + struct bcom_fec_bd *bd;
<br>> + u32 status, physaddr;
<br>> + int length;
<br>> + unsigned long flags;
<br>> +
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>>
<br>> while (bcom_buffer_done(priv->rx_dmatsk)) {
<br>> - struct sk_buff *skb;
<br>> - struct sk_buff *rskb;
<br>> - struct bcom_fec_bd *bd;
<br>> - u32 status;
<br>>
<br>> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
<br>> - (struct bcom_bd **)&bd);
<br>> - dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
<br>> - DMA_FROM_DEVICE);
<br>> + (struct bcom_bd **)&bd);
<br>> + physaddr = bd->skb_pa;
<br>>
<br>> /* Test for errors in received frame */
<br>> if (status & BCOM_FEC_RX_BD_ERRORS) {
<br>> /* Drop packet and reuse the buffer */
<br>> - bd = (struct bcom_fec_bd *)
<br>> - bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>> -
<br>> - bd->status = FEC_RX_BUFFER_SIZE;
<br>> - bd->skb_pa = dma_map_single(dev->dev.parent,
<br>> - rskb->data,
<br>> - FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> -
<br>> - bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>> -
<br>> + mpc52xx_fec_rx_submit(dev, rskb);
<br>> dev->stats.rx_dropped++;
<br>> -
<br>> continue;
<br>> }
<br>>
<br>> /* skbs are allocated on open, so now we allocate a new one,
<br>> * and remove the old (with the packet) */
<br>> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>> - if (skb) {
<br>> - /* Process the received skb */
<br>> - int length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>> -
<br>> - skb_put(rskb, length - 4); /* length without CRC32 */
<br>> -
<br>> - rskb->dev = dev;
<br>> - rskb->protocol = eth_type_trans(rskb, dev);
<br>> -
<br>> - netif_rx(rskb);
<br>> - } else {
<br>> + if (!skb) {
<br>> /* Can't get a new one : reuse the same & drop pkt */
<br>> - dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
<br>> + dev_notice(&dev->dev, "Low memory - dropped packet.\n");
<br>> + mpc52xx_fec_rx_submit(dev, rskb);
<br>> dev->stats.rx_dropped++;
<br>> -
<br>> - skb = rskb;
<br>> + continue;
<br>> }
<br>>
<br>> - bd = (struct bcom_fec_bd *)
<br>> - bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>> + /* Enqueue the new sk_buff back on the hardware */
<br>> + mpc52xx_fec_rx_submit(dev, skb);
<br>>
<br>> - bd->status = FEC_RX_BUFFER_SIZE;
<br>> - bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>> - FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> + /* Process the received skb - Drop the spin lock while
<br>> + * calling into the network stack */
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> - bcom_submit_next_buffer(priv->rx_dmatsk, skb);
<br>> + dma_unmap_single(dev->dev.parent, physaddr, rskb->len,
<br>> + DMA_FROM_DEVICE);
<br>> + length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>> + skb_put(rskb, length - 4); /* length without CRC32 */
<br>> + rskb->dev = dev;
<br>> + rskb->protocol = eth_type_trans(rskb, dev);
<br>> + netif_rx(rskb);
<br>> +
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> }
<br>>
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>> +
<br>> return IRQ_HANDLED;
<br>> }
<br>>
<br>> @@ -454,6 +453,7 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br>> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> struct mpc52xx_fec __iomem *fec = priv->fec;
<br>> u32 ievent;
<br>> + unsigned long flags;
<br>>
<br>> ievent = in_be32(&fec->ievent);
<br>>
<br>> @@ -471,9 +471,10 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br>> if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
<br>> dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
<br>>
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> mpc52xx_fec_reset(dev);
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> - netif_wake_queue(dev);
<br>> return IRQ_HANDLED;
<br>> }
<br>>
<br>> @@ -768,6 +769,8 @@ static void mpc52xx_fec_reset(struct net_device *dev)
<br>> bcom_enable(priv->tx_dmatsk);
<br>>
<br>> mpc52xx_fec_start(dev);
<br>> +
<br>> + netif_wake_queue(dev);
<br>> }
<br>>
<br>>
<br>>
<br>> _______________________________________________
<br>> Linuxppc-dev mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26658970&i=3" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br>> <a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a></div><br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26658970&i=4" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26658474
Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
2009-12-05T11:32:32Z
2009-12-05T11:32:32Z
Peter Tyser
Hi Anton,
<br>Thanks for the feedback.
<br><div class='shrinkable-quote'><br>> On Fri, Dec 04, 2009 at 01:43:40PM -0600, Peter Tyser wrote:
<br>> > This change resolves 2 issues:
<br>> > - Different chips have a different number of GPIO pins per controller.
<br>> > For example, the MPC8347 has 32, the P2020 16, and the mpc8572 8.
<br>> > Previously, the mpc8xxx_gpio driver assumed every chip had 32 GPIO
<br>> > pins which resulted in some processors reporting an incorrect 'ngpio'
<br>> > field in /sys. Additionally, users could export and "use" 32 GPIO
<br>> > pins, although in reality only a subset of the 32 pins had any real
<br>> > functionality.
<br>> >
<br>> > - Some boards don't utilize all available GPIO pins. Previously,
<br>> > unused GPIO pins could still be exported and "used", even though the
<br>> > pins had no real functionality. This is somewhat confusing to a user
<br>> > and also allow a user to do something "bad", like change an unused
<br>> > floating output into a floating input.
<br>>
<br>> There are hundreds of other ways to screw things up.
<br>>
<br>> Think of /dev/mem, you still able to change the registers.
<br>> Before changing any GPIO (whether it is a normal or reserved GPIO),
<br>> user has to consult with schematics/docs.
</div><br>Agreed. This is an attempt to make it just a little bit harder to
<br>accidentally screw things up and to make the "ngpio" sysfs value
<br>actually contain an accurate value.
<br><div class='shrinkable-quote'><br>> > Adding a new "fsl,gpio-mask" device tree property allows a dts file to
<br>> > accurately describe what GPIO pins are available for use on a given
<br>> > board.
<br>>
<br>> I don't see any real usage for this. If device tree specifies a wrong
<br>> gpio in the gpios = <> property, then it's a bug in the device tree
<br>> and should be fixed (or workarounded in the platform code).
<br>>
<br>> If a user fiddles with unknown gpios via sysfs interface, then it's
<br>> user's problem.
</div><br>Its the sysfs case that I'm concerned about. Primarily because:
<br>1. Users scratch their head when they see that the "ngpio" sysfs value
<br>doesn't match their CPU manual or board vendor's manual, and
<br>subsequently ask their board vendor's engineers (ie me:) what's up.
<br><br>2. Improperly using GPIO pins could damage hardware for some boards.
<br>For example, some of our boards have a voltage regulator controlled via
<br>GPIO pins so that a CPU's core voltage can be changed based on its
<br>frequency, etc. A user could damage their CPU if they aren't careful
<br>with those GPIO pins. For pins like that, it'd be nice to not even let
<br>users play with them.
<br><br>#2 could be worked around by exporting GPIO pins in platform code so
<br>that they are not available via sysfs. And I agree that if a user is
<br>playing with GPIO pins, they had better know what they are doing, so #1
<br>above is my main issue. Would it be any more acceptable to instead add
<br>a "fsl,num-gpio" property so that "ngpio" actually reported an accurate
<br>value and non-existent GPIO pins couldn't be used/exported?
<br><br>With the patch as is, if "fsl,gpio-mask" is not given, the driver
<br>defaults to enabling all 32 gpio pins. Would it be any better if I
<br>respun the patch to only add the "fsl,gpio-mask" property for the
<br>mpc8572, p2020, and mpc8379 boards which have less than 32 gpio pins and
<br>document the dts property as optional?
<br><br>Thanks,
<br>Peter
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26658474&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26657768
Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
2009-12-05T09:56:14Z
2009-12-05T09:56:14Z
Anton Vorontsov-2
Hi Peter,
<br><br>On Fri, Dec 04, 2009 at 01:43:40PM -0600, Peter Tyser wrote:
<div class='shrinkable-quote'><br>> This change resolves 2 issues:
<br>> - Different chips have a different number of GPIO pins per controller.
<br>> For example, the MPC8347 has 32, the P2020 16, and the mpc8572 8.
<br>> Previously, the mpc8xxx_gpio driver assumed every chip had 32 GPIO
<br>> pins which resulted in some processors reporting an incorrect 'ngpio'
<br>> field in /sys. Additionally, users could export and "use" 32 GPIO
<br>> pins, although in reality only a subset of the 32 pins had any real
<br>> functionality.
<br>>
<br>> - Some boards don't utilize all available GPIO pins. Previously,
<br>> unused GPIO pins could still be exported and "used", even though the
<br>> pins had no real functionality. This is somewhat confusing to a user
<br>> and also allow a user to do something "bad", like change an unused
<br>> floating output into a floating input.
</div><br>There are hundreds of other ways to screw things up.
<br><br>Think of /dev/mem, you still able to change the registers.
<br>Before changing any GPIO (whether it is a normal or reserved GPIO),
<br>user has to consult with schematics/docs.
<br><br>> Adding a new "fsl,gpio-mask" device tree property allows a dts file to
<br>> accurately describe what GPIO pins are available for use on a given
<br>> board.
<br><br>I don't see any real usage for this. If device tree specifies a wrong
<br>gpio in the gpios = <> property, then it's a bug in the device tree
<br>and should be fixed (or workarounded in the platform code).
<br><br>If a user fiddles with unknown gpios via sysfs interface, then it's
<br>user's problem.
<br><br>FWIW, we don't have any masks for reserved IRQs.
<br><br>Thanks,
<br><br>--
<br>Anton Vorontsov
<br>email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26657768&i=0" target="_top" rel="nofollow">cbouatmailru@...</a>
<br>irc://irc.freenode.net/bd2
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26657768&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26652947
[PATCH/REPOST] net/mpc5200: Fix locking on fec_mpc52xx driver
2009-12-04T20:33:13Z
2009-12-04T20:33:13Z
Grant Likely-2
From: Asier Llano Palacios <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652947&i=0" target="_top" rel="nofollow">asierllano@...</a>>
<br><br>Fix the locking scheme on the fec_mpc52xx driver. This device can
<br>receive IRQs from three sources; the FEC itself, the tx DMA, and the
<br>rx DMA. Mutual exclusion was handled by taking a spin_lock() in the
<br>critical regions, but because the handlers are run with IRQs enabled,
<br>spin_lock() is insufficient and the driver can end up interrupting
<br>a critical region anyway from another IRQ.
<br><br>Asier Llano discovered that this occurs when an error IRQ is raised
<br>in the middle of handling rx irqs which resulted in an sk_buff memory
<br>leak.
<br><br>In addition, locking is spotty at best in the driver and inspection
<br>revealed quite a few places with insufficient locking.
<br><br>This patch is based on Asier's initial work, but reworks a number of
<br>things so that locks are held for as short a time as possible, so
<br>that spin_lock_irqsave() is used everywhere, and so the locks are
<br>dropped when calling into the network stack (because the lock only
<br>protects the hardware interface; not the network stack).
<br><br>Boot tested on a lite5200 with an NFS root. Has not been performance
<br>tested.
<br><br>Signed-off-by: Asier Llano <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652947&i=1" target="_top" rel="nofollow">a.llano@...</a>>
<br>Signed-off-by: Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652947&i=2" target="_top" rel="nofollow">grant.likely@...</a>>
<br>---
<br><br>Reposting due to messing up both subject line and davem's email addr.
<br><br> drivers/net/fec_mpc52xx.c | 121 +++++++++++++++++++++++----------------------
<br> 1 files changed, 62 insertions(+), 59 deletions(-)
<br><br>diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
<br>index 66dace6..4889b4d 100644
<br>--- a/drivers/net/fec_mpc52xx.c
<br>+++ b/drivers/net/fec_mpc52xx.c
<br>@@ -85,11 +85,15 @@ MODULE_PARM_DESC(debug, "debugging messages level");
<br>
<br> static void mpc52xx_fec_tx_timeout(struct net_device *dev)
<br> {
<br>+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ unsigned long flags;
<br>+
<br> dev_warn(&dev->dev, "transmit timed out\n");
<br>
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> mpc52xx_fec_reset(dev);
<br>-
<br> dev->stats.tx_errors++;
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br> netif_wake_queue(dev);
<br> }
<br>@@ -135,28 +139,32 @@ static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct bcom_task
<br> }
<br> }
<br>
<br>+static void
<br>+mpc52xx_fec_rx_submit(struct net_device *dev, struct sk_buff *rskb)
<br>+{
<br>+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ struct bcom_fec_bd *bd;
<br>+
<br>+ bd = (struct bcom_fec_bd *) bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>+ bd->status = FEC_RX_BUFFER_SIZE;
<br>+ bd->skb_pa = dma_map_single(dev->dev.parent, rskb->data,
<br>+ FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>+ bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>+}
<br>+
<br> static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct bcom_task *rxtsk)
<br> {
<br>- while (!bcom_queue_full(rxtsk)) {
<br>- struct sk_buff *skb;
<br>- struct bcom_fec_bd *bd;
<br>+ struct sk_buff *skb;
<br>
<br>+ while (!bcom_queue_full(rxtsk)) {
<br> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>- if (skb == NULL)
<br>+ if (!skb)
<br> return -EAGAIN;
<br>
<br> /* zero out the initial receive buffers to aid debugging */
<br> memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
<br>-
<br>- bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
<br>-
<br>- bd->status = FEC_RX_BUFFER_SIZE;
<br>- bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>-
<br>- bcom_submit_next_buffer(rxtsk, skb);
<br>+ mpc52xx_fec_rx_submit(dev, skb);
<br> }
<br>-
<br> return 0;
<br> }
<br>
<br>@@ -328,13 +336,12 @@ static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
<br> DMA_TO_DEVICE);
<br>
<br> bcom_submit_next_buffer(priv->tx_dmatsk, skb);
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br> if (bcom_queue_full(priv->tx_dmatsk)) {
<br> netif_stop_queue(dev);
<br> }
<br>
<br>- spin_unlock_irqrestore(&priv->lock, flags);
<br>-
<br> return NETDEV_TX_OK;
<br> }
<br>
<br>@@ -359,9 +366,9 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br> {
<br> struct net_device *dev = dev_id;
<br> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ unsigned long flags;
<br>
<br>- spin_lock(&priv->lock);
<br>-
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> while (bcom_buffer_done(priv->tx_dmatsk)) {
<br> struct sk_buff *skb;
<br> struct bcom_fec_bd *bd;
<br>@@ -372,11 +379,10 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br>
<br> dev_kfree_skb_irq(skb);
<br> }
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br> netif_wake_queue(dev);
<br>
<br>- spin_unlock(&priv->lock);
<br>-
<br> return IRQ_HANDLED;
<br> }
<br>
<br>@@ -384,67 +390,60 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
<br> {
<br> struct net_device *dev = dev_id;
<br> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ struct sk_buff *rskb; /* received sk_buff */
<br>+ struct sk_buff *skb; /* new sk_buff to enqueue in its place */
<br>+ struct bcom_fec_bd *bd;
<br>+ u32 status, physaddr;
<br>+ int length;
<br>+ unsigned long flags;
<br>+
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br>
<br> while (bcom_buffer_done(priv->rx_dmatsk)) {
<br>- struct sk_buff *skb;
<br>- struct sk_buff *rskb;
<br>- struct bcom_fec_bd *bd;
<br>- u32 status;
<br>
<br> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
<br>- (struct bcom_bd **)&bd);
<br>- dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
<br>- DMA_FROM_DEVICE);
<br>+ (struct bcom_bd **)&bd);
<br>+ physaddr = bd->skb_pa;
<br>
<br> /* Test for errors in received frame */
<br> if (status & BCOM_FEC_RX_BD_ERRORS) {
<br> /* Drop packet and reuse the buffer */
<br>- bd = (struct bcom_fec_bd *)
<br>- bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>-
<br>- bd->status = FEC_RX_BUFFER_SIZE;
<br>- bd->skb_pa = dma_map_single(dev->dev.parent,
<br>- rskb->data,
<br>- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>-
<br>- bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>-
<br>+ mpc52xx_fec_rx_submit(dev, rskb);
<br> dev->stats.rx_dropped++;
<br>-
<br> continue;
<br> }
<br>
<br> /* skbs are allocated on open, so now we allocate a new one,
<br> * and remove the old (with the packet) */
<br> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>- if (skb) {
<br>- /* Process the received skb */
<br>- int length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>-
<br>- skb_put(rskb, length - 4); /* length without CRC32 */
<br>-
<br>- rskb->dev = dev;
<br>- rskb->protocol = eth_type_trans(rskb, dev);
<br>-
<br>- netif_rx(rskb);
<br>- } else {
<br>+ if (!skb) {
<br> /* Can't get a new one : reuse the same & drop pkt */
<br>- dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
<br>+ dev_notice(&dev->dev, "Low memory - dropped packet.\n");
<br>+ mpc52xx_fec_rx_submit(dev, rskb);
<br> dev->stats.rx_dropped++;
<br>-
<br>- skb = rskb;
<br>+ continue;
<br> }
<br>
<br>- bd = (struct bcom_fec_bd *)
<br>- bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>+ /* Enqueue the new sk_buff back on the hardware */
<br>+ mpc52xx_fec_rx_submit(dev, skb);
<br>
<br>- bd->status = FEC_RX_BUFFER_SIZE;
<br>- bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>+ /* Process the received skb - Drop the spin lock while
<br>+ * calling into the network stack */
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br>- bcom_submit_next_buffer(priv->rx_dmatsk, skb);
<br>+ dma_unmap_single(dev->dev.parent, physaddr, rskb->len,
<br>+ DMA_FROM_DEVICE);
<br>+ length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>+ skb_put(rskb, length - 4); /* length without CRC32 */
<br>+ rskb->dev = dev;
<br>+ rskb->protocol = eth_type_trans(rskb, dev);
<br>+ netif_rx(rskb);
<br>+
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> }
<br>
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>+
<br> return IRQ_HANDLED;
<br> }
<br>
<br>@@ -454,6 +453,7 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br> struct mpc52xx_fec __iomem *fec = priv->fec;
<br> u32 ievent;
<br>+ unsigned long flags;
<br>
<br> ievent = in_be32(&fec->ievent);
<br>
<br>@@ -471,9 +471,10 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br> if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
<br> dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
<br>
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> mpc52xx_fec_reset(dev);
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br>- netif_wake_queue(dev);
<br> return IRQ_HANDLED;
<br> }
<br>
<br>@@ -768,6 +769,8 @@ static void mpc52xx_fec_reset(struct net_device *dev)
<br> bcom_enable(priv->tx_dmatsk);
<br>
<br> mpc52xx_fec_start(dev);
<br>+
<br>+ netif_wake_queue(dev);
<br> }
<br>
<br>
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652947&i=3" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26652589
Re: [PATCH] MAINTAINERS: Add PowerPC patterns
2009-12-04T18:59:49Z
2009-12-04T18:59:49Z
Olof Johansson-2
On Fri, Dec 04, 2009 at 09:16:59AM -0800, Joe Perches wrote:
<div class='shrinkable-quote'><br>> On Fri, 2009-12-04 at 20:59 +1100, Benjamin Herrenschmidt wrote:
<br>> > On Fri, 2009-12-04 at 10:34 +0100, Jean Delvare wrote:
<br>> > > I've sent it to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652589&i=0" target="_top" rel="nofollow">linuxppc-dev@...</a> on October 14th. This is the
<br>> > > address which is listed 22 times in MAINTAINERS. If it isn't correct,
<br>> > > then please update MAINTAINERS.
<br>> > No it's fine both shoul work. Your patches are there, just waiting for
<br>> > me to pick them up, I was just firing a reminder to the rest of the CC
<br>> > list :-) (and I do remember fwd'ing a couple of your patches to the
<br>> > list, for some reason they didn't make it to patchwork back then, that
<br>> > was a few month ago).
<br>> > Anyways, I've been stretched thin with all sort of stuff lately, so bear
<br>> > with me if I'm a bit slow at taking or testing stuff, I'm doing my best.
<br>>
<br>> Adding patterns to the PowerPC sections of MAINTAINERS is useful.
<br>>
<br>> Signed-off-by: Joe Perches <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652589&i=1" target="_top" rel="nofollow">joe@...</a>>
</div><br>Acked-by: Olof Johansson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652589&i=2" target="_top" rel="nofollow">olof@...</a>>
<br><br>There are a few other files under arch/powerpc that's not under platforms
<br>that belongs to the pasemi code but it's not a big deal to not include
<br>them. This goes most of the way.
<br><br><br>-Olof
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652589&i=3" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26652140
Re: MPC8343EA Linux DTS file
2009-12-04T17:44:32Z
2009-12-04T17:44:32Z
Kim Phillips
On Fri, 4 Dec 2009 15:43:18 -0800
<br>Junita Ajith <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652140&i=0" target="_top" rel="nofollow">ajijuni@...</a>> wrote:
<br><br>please keep the list on the cc:, and don't top-post.
<br><br>> This is the entire DTS file:
<br>> /dts-v1/;
<br>>
<br>> / {
<br>> model = "SC3000";
<br>> compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
<br><br>you don't mention the u-boot and kernel version numbers: does your
<br>linux kernel check for these compatibles? If yes, then use a debugger
<br>to find out exactly where else the kernel could be dying.
<br><br>Kim
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652140&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26651027
Re: MPC8343EA Linux DTS file
2009-12-04T15:39:32Z
2009-12-04T15:39:32Z
Kim Phillips
On Fri, 4 Dec 2009 14:56:25 -0800
<br>agnel <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26651027&i=0" target="_top" rel="nofollow">ajijuni@...</a>> wrote:
<br><br>> We have an MPC8343EA based custom board.
<br>>
<br>> I am not able to get Linux up and running in this. No serial output to debug
<br>> further.
<br>> U-boot shows correct 'bdinfo' & 'clocks' output.
<br>>
<br>> I doubt the DTS file in Linux. anyone has DTS file for MPC8343??
<br>>
<br>> My current DTS file
<br><br>well, for one, the dts you provide doesn't include a node for the ipic
<br>interrupt controller.
<br><br>Kim
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26651027&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26645258
MPC8343EA Linux DTS file
2009-12-04T14:56:22Z
2009-12-04T14:56:22Z
agnel
<br>Hi
<br><br>We have an MPC8343EA based custom board.
<br><br>I am not able to get Linux up and running in this. No serial output to debug further.
<br> U-boot shows correct 'bdinfo' & 'clocks' output.
<br><br>I doubt the DTS file in Linux. anyone has DTS file for MPC8343??
<br><br>My current DTS file
<br>/dts-v1/;
<br><br>/ {
<br> model = "MPC8343";
<br> compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
<br> linux,phandle = <0x100>;
<br> #size-cells = <0x1>;
<br> #address-cells = <0x1>;
<br><br> aliases {
<br> ethernet0 = &enet0;
<br> ethernet1 = &enet1;
<br> serial0 = &serial0;
<br> serial1 = &serial1;
<br> pci0 = &pci0;
<br> pci1 = &pci1;
<br> };
<br> cpus {
<br> linux,phandle = <0x200>;
<br> #cpus = <0x1>;
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br><br> PowerPC,8343EA@0 {
<br> device_type = "cpu";
<br> reg = <0x0>;
<br> d-cache-line-size = <20>;
<br> i-cache-line-size = <20>;
<br> d-cache-size = <8000>;
<br> i-cache-size = <8000>;
<br> timebase-frequency = <0>; // from bootloader
<br> bus-frequency = <0>; // from bootloader
<br> clock-frequency = <0>; // from bootloader
<br> 32-bit;
<br> };
<br> };
<br><br><br> memory {
<br> device_type = "memory";
<br> reg = <0x00000000 0x10000000>; // 256MB at 0
<br> };
<br><br> bcsr@e2400000 {
<br> device_type = "board-control";
<br> reg = <0xe2400000 0x8000>;
<br> };
<br> soc8343@e0000000 {
<br> bus-frequency = <0x1>;
<br> reg = <0xe0000000 0x200>;
<br> ranges = <0x0 0xe0000000 0x100000>;
<br> device_type = "soc";
<br> #interrupt-cells = <0x2>;
<br> #size-cells = <0x1>;
<br> #address-cells = <0x1>;
<br><br> wdt@200 {
<br> device_type = "watchdog";
<br> compatible = "mpc83xx_wdt";
<br> reg = <0x200 0x100>;
<br> };
<br><br>i2c@3000 {
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> cell-index = <0>;
<br> compatible = "fsl-i2c";
<br> reg = <0x3000 0x100>;
<br> interrupts = <14 0x8>;
<br> interrupt-parent = <&ipic>;
<br> dfsrr;
<br><br> rtc@68 {
<br> compatible = "dallas,ds1374";
<br> reg = <0x68>;
<br> };
<br> };
<br><br> i2c@3100 {
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> cell-index = <1>;
<br> compatible = "fsl-i2c";
<br> reg = <0x3100 0x100>;
<br> interrupts = <15 0x8>;
<br> interrupt-parent = <&ipic>;
<br> dfsrr;
<br> };
<br><br> spi@7000 {
<br> cell-index = <0>;
<br> compatible = "fsl,spi";
<br> reg = <0x7000 0x1000>;
<br> interrupts = <16 0x8>;
<br> interrupt-parent = <&ipic>;
<br> mode = "cpu";
<br> };
<br><br>dma@82a8 {
<br> #address-cells = <1>;
<br> #size-cells = <1>;
<br> compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
<br> reg = <0x82a8 4>;
<br> ranges = <0 0x8100 0x1a8>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> cell-index = <0>;
<br> dma-channel@0 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0 0x80>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> dma-channel@80 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0x80 0x80>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> dma-channel@100 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0x100 0x80>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> dma-channel@180 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0x180 0x28>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> };
<br>/* phy type (ULPI or SERIAL) are only types supported for MPH */
<br> /* port = 0 or 1 */
<br> usb@22000 {
<br> compatible = "fsl-usb2-mph";
<br> reg = <0x22000 0x1000>;
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <39 0x8>;
<br> phy_type = "ulpi";
<br> port1;
<br> };
<br> /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
<br> usb@23000 {
<br> compatible = "fsl-usb2-dr";
<br> reg = <0x23000 0x1000>;
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <38 0x8>;
<br> dr_mode = "otg";
<br> phy_type = "ulpi";
<br> };
<br><br> mdio@24520 {
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> compatible = "fsl,gianfar-mdio";
<br> reg = <0x24520 0x20>;
<br><br> phy0: ethernet-phy@0 {
<br> interrupt-parent = <&ipic>;
<br> interrupts = <17 0x8>;
<br> reg = <0x0>;
<br> device_type = "ethernet-phy";
<br> };
<br> phy1: ethernet-phy@1 {
<br> interrupt-parent = <&ipic>;
<br> interrupts = <18 0x8>;
<br> reg = <0x1>;
<br> device_type = "ethernet-phy";
<br> };
<br>enet0: ethernet@24000 {
<br> cell-index = <0>;
<br> device_type = "network";
<br> model = "TSEC";
<br> compatible = "gianfar";
<br> reg = <0x24000 0x1000>;
<br> local-mac-address = [ 00 00 00 00 00 00 ];
<br> interrupts = <32 0x8 33 0x8 34 0x8>;
<br> interrupt-parent = <&ipic>;
<br> phy-handle = <&phy0>;
<br> linux,network-index = <0>;
<br> };
<br><br> enet1: ethernet@25000 {
<br> cell-index = <1>;
<br> device_type = "network";
<br> model = "TSEC";
<br> compatible = "gianfar";
<br> reg = <0x25000 0x1000>;
<br> local-mac-address = [ 00 00 00 00 00 00 ];
<br> interrupts = <35 0x8 36 0x8 37 0x8>;
<br> interrupt-parent = <&ipic>;
<br> phy-handle = <&phy1>;
<br> linux,network-index = <1>;
<br> };
<br><br>serial0: serial@4500 {
<br> cell-index = <0>;
<br> device_type = "serial";
<br> compatible = "ns16550";
<br> reg = <0x4500 0x100>;
<br> clock-frequency = <0>;
<br> interrupts = <9 0x8>;
<br> interrupt-parent = <&ipic>;
<br> };
<br><br> serial1: serial@4600 {
<br> cell-index = <1>;
<br> device_type = "serial";
<br> compatible = "ns16550";
<br> reg = <0x4600 0x100>;
<br> clock-frequency = <0>;
<br> interrupts = <10 0x8>;
<br> interrupt-parent = <&ipic>;
<br> };
<br><br> crypto@30000 {
<br> compatible = "fsl,sec2.0";
<br> reg = <0x30000 0x10000>;
<br> interrupts = <11 0x8>;
<br> interrupt-parent = <&ipic>;
<br> fsl,num-channels = <4>;
<br> fsl,channel-fifo-len = <24>;
<br> fsl,exec-units-mask = <0x7e>;
<br> fsl,descriptor-types-mask = <0x01010ebf>;
<br> };
<br><br>Thanks,
<br>agnel
<br><br><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26645256
MPC8343EA Linux DTS file
2009-12-04T14:55:39Z
2009-12-04T14:55:39Z
agnel
<br>Hi
<br><br>We have an MPC8343EA based custom board.
<br><br>I am not able to get Linux up and running in this. No serial output to debug further.
<br> U-boot shows correct 'bdinfo' & 'clocks' output.
<br><br>I doubt the DTS file in Linux. anyone has DTS file for MPC8343??
<br><br>My current DTS file
<br>/dts-v1/;
<br><br>/ {
<br> model = "Silvus-SC3000";
<br> compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
<br> linux,phandle = <0x100>;
<br> #size-cells = <0x1>;
<br> #address-cells = <0x1>;
<br><br> aliases {
<br> ethernet0 = &enet0;
<br> ethernet1 = &enet1;
<br> serial0 = &serial0;
<br> serial1 = &serial1;
<br> pci0 = &pci0;
<br> pci1 = &pci1;
<br> };
<br> cpus {
<br> linux,phandle = <0x200>;
<br> #cpus = <0x1>;
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br><br> PowerPC,8343EA@0 {
<br> device_type = "cpu";
<br> reg = <0x0>;
<br> d-cache-line-size = <20>;
<br> i-cache-line-size = <20>;
<br> d-cache-size = <8000>;
<br> i-cache-size = <8000>;
<br> timebase-frequency = <0>; // from bootloader
<br> bus-frequency = <0>; // from bootloader
<br> clock-frequency = <0>; // from bootloader
<br> 32-bit;
<br> };
<br> };
<br><br><br> memory {
<br> device_type = "memory";
<br> reg = <0x00000000 0x10000000>; // 256MB at 0
<br> };
<br><br> bcsr@e2400000 {
<br> device_type = "board-control";
<br> reg = <0xe2400000 0x8000>;
<br> };
<br> soc8343@e0000000 {
<br> bus-frequency = <0x1>;
<br> reg = <0xe0000000 0x200>;
<br> ranges = <0x0 0xe0000000 0x100000>;
<br> device_type = "soc";
<br> #interrupt-cells = <0x2>;
<br> #size-cells = <0x1>;
<br> #address-cells = <0x1>;
<br><br> wdt@200 {
<br> device_type = "watchdog";
<br> compatible = "mpc83xx_wdt";
<br> reg = <0x200 0x100>;
<br> };
<br><br>i2c@3000 {
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> cell-index = <0>;
<br> compatible = "fsl-i2c";
<br> reg = <0x3000 0x100>;
<br> interrupts = <14 0x8>;
<br> interrupt-parent = <&ipic>;
<br> dfsrr;
<br><br> rtc@68 {
<br> compatible = "dallas,ds1374";
<br> reg = <0x68>;
<br> };
<br> };
<br><br> i2c@3100 {
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> cell-index = <1>;
<br> compatible = "fsl-i2c";
<br> reg = <0x3100 0x100>;
<br> interrupts = <15 0x8>;
<br> interrupt-parent = <&ipic>;
<br> dfsrr;
<br> };
<br><br> spi@7000 {
<br> cell-index = <0>;
<br> compatible = "fsl,spi";
<br> reg = <0x7000 0x1000>;
<br> interrupts = <16 0x8>;
<br> interrupt-parent = <&ipic>;
<br> mode = "cpu";
<br> };
<br><br>dma@82a8 {
<br> #address-cells = <1>;
<br> #size-cells = <1>;
<br> compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
<br> reg = <0x82a8 4>;
<br> ranges = <0 0x8100 0x1a8>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> cell-index = <0>;
<br> dma-channel@0 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0 0x80>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> dma-channel@80 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0x80 0x80>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> dma-channel@100 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0x100 0x80>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> dma-channel@180 {
<br> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
<br> reg = <0x180 0x28>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <71 8>;
<br> };
<br> };
<br>/* phy type (ULPI or SERIAL) are only types supported for MPH */
<br> /* port = 0 or 1 */
<br> usb@22000 {
<br> compatible = "fsl-usb2-mph";
<br> reg = <0x22000 0x1000>;
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <39 0x8>;
<br> phy_type = "ulpi";
<br> port1;
<br> };
<br> /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
<br> usb@23000 {
<br> compatible = "fsl-usb2-dr";
<br> reg = <0x23000 0x1000>;
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> interrupt-parent = <&ipic>;
<br> interrupts = <38 0x8>;
<br> dr_mode = "otg";
<br> phy_type = "ulpi";
<br> };
<br><br> mdio@24520 {
<br> #address-cells = <1>;
<br> #size-cells = <0>;
<br> compatible = "fsl,gianfar-mdio";
<br> reg = <0x24520 0x20>;
<br><br> phy0: ethernet-phy@0 {
<br> interrupt-parent = <&ipic>;
<br> interrupts = <17 0x8>;
<br> reg = <0x0>;
<br> device_type = "ethernet-phy";
<br> };
<br> phy1: ethernet-phy@1 {
<br> interrupt-parent = <&ipic>;
<br> interrupts = <18 0x8>;
<br> reg = <0x1>;
<br> device_type = "ethernet-phy";
<br> };
<br>enet0: ethernet@24000 {
<br> cell-index = <0>;
<br> device_type = "network";
<br> model = "TSEC";
<br> compatible = "gianfar";
<br> reg = <0x24000 0x1000>;
<br> local-mac-address = [ 00 00 00 00 00 00 ];
<br> interrupts = <32 0x8 33 0x8 34 0x8>;
<br> interrupt-parent = <&ipic>;
<br> phy-handle = <&phy0>;
<br> linux,network-index = <0>;
<br> };
<br><br> enet1: ethernet@25000 {
<br> cell-index = <1>;
<br> device_type = "network";
<br> model = "TSEC";
<br> compatible = "gianfar";
<br> reg = <0x25000 0x1000>;
<br> local-mac-address = [ 00 00 00 00 00 00 ];
<br> interrupts = <35 0x8 36 0x8 37 0x8>;
<br> interrupt-parent = <&ipic>;
<br> phy-handle = <&phy1>;
<br> linux,network-index = <1>;
<br> };
<br><br>serial0: serial@4500 {
<br> cell-index = <0>;
<br> device_type = "serial";
<br> compatible = "ns16550";
<br> reg = <0x4500 0x100>;
<br> clock-frequency = <0>;
<br> interrupts = <9 0x8>;
<br> interrupt-parent = <&ipic>;
<br> };
<br><br> serial1: serial@4600 {
<br> cell-index = <1>;
<br> device_type = "serial";
<br> compatible = "ns16550";
<br> reg = <0x4600 0x100>;
<br> clock-frequency = <0>;
<br> interrupts = <10 0x8>;
<br> interrupt-parent = <&ipic>;
<br> };
<br><br> crypto@30000 {
<br> compatible = "fsl,sec2.0";
<br> reg = <0x30000 0x10000>;
<br> interrupts = <11 0x8>;
<br> interrupt-parent = <&ipic>;
<br> fsl,num-channels = <4>;
<br> fsl,channel-fifo-len = <24>;
<br> fsl,exec-units-mask = <0x7e>;
<br> fsl,descriptor-types-mask = <0x01010ebf>;
<br> };
<br><br>Thanks,
<br>agnel
<br><br><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26649474
Re: using different format for hugetlbfs
2009-12-04T13:25:42Z
2009-12-04T13:25:42Z
Benjamin Herrenschmidt
On Fri, 2009-12-04 at 08:09 -0600, Kumar Gala wrote:
<div class='shrinkable-quote'><br>> On Dec 4, 2009, at 2:58 AM, Benjamin Herrenschmidt wrote:
<br>>
<br>> > On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
<br>> >> Ben, David,
<br>> >>
<br>> >> If we want to support true 4G/4G split on ppc32 using the MSB of the
<br>> >> address to determine of the pgd_t is for hugetlbfs isn't going to
<br>> >> work. Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
<br>> >> at least a 4K page I would think the low order 12-bits should always
<br>> >> be 0.
<br>> >
<br>> > On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
<br>> > want to have a different encoding for both types though.
<br>>
<br>> What do you mean they can be smaller? We have some scenario when we
<br>> dont allocate a full page? I agree having the encodings be different
<br>> would be bad. I'm trying to avoid having it be different between 32
<br>> bit and 64 (but maybe that will be impossible).
</div><br>Yes. The intermediary levels are smaller on 64-bit. Also, with hugetlbfs
<br>it can create special levels of various sizes depending on the
<br>requirements to fit a given huge page size. And that would be true of
<br>both 32 and 64-bit in fact.
<br><br>Cheers,
<br>Ben.
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649474&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26649448
Re: [PATCH] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2009-12-04T13:24:03Z
2009-12-04T13:24:03Z
Grant Likely-2
Oops, sorry about the messed up subject. that was sloppy. Real
<br>subject should be:
<br><br>net/mpc5200: Fix locking on fec_mpc52xx driver
<br><br>On Fri, Dec 4, 2009 at 2:20 PM, Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649448&i=0" target="_top" rel="nofollow">grant.likely@...</a>> wrote:
<div class='shrinkable-quote'><br>> From: Asier Llano Palacios <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649448&i=1" target="_top" rel="nofollow">asierllano@...</a>>
<br>>
<br>> net/mpc5200: Fix locking on fec_mpc52xx driver
<br>>
<br>> Fix the locking scheme on the fec_mpc52xx driver. This device can
<br>> receive IRQs from three sources; the FEC itself, the tx DMA, and the
<br>> rx DMA. Mutual exclusion was handled by taking a spin_lock() in the
<br>> critical regions, but because the handlers are run with IRQs enabled,
<br>> spin_lock() is insufficient and the driver can end up interrupting
<br>> a critical region anyway from another IRQ.
<br>>
<br>> Asier Llano discovered that this occurs when an error IRQ is raised
<br>> in the middle of handling rx irqs which resulted in an sk_buff memory
<br>> leak.
<br>>
<br>> In addition, locking is spotty at best in the driver and inspection
<br>> revealed quite a few places with insufficient locking.
<br>>
<br>> This patch is based on Asier's initial work, but reworks a number of
<br>> things so that locks are held for as short a time as possible, so
<br>> that spin_lock_irqsave() is used everywhere, and so the locks are
<br>> dropped when calling into the network stack (because the lock only
<br>> protects the hardware interface; not the network stack).
<br>>
<br>> Boot tested on a lite5200 with an NFS root. Has not been performance
<br>> tested.
<br>>
<br>> Signed-off-by: Asier Llano <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649448&i=2" target="_top" rel="nofollow">a.llano@...</a>>
<br>> Signed-off-by: Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649448&i=3" target="_top" rel="nofollow">grant.likely@...</a>>
<br>> ---
<br>>
<br>> Asier, can you please test this? It took me a while to respond to
<br>> your initial post because I was concerned about some of the latency
<br>> issues, and I was concerned about disabling IRQs for long periods in
<br>> the RX handler. I think it should be good now, but it needs testing.
<br>>
<br>> Cheers,
<br>> g.
<br>>
<br>> drivers/net/fec_mpc52xx.c | 121 +++++++++++++++++++++++----------------------
<br>> 1 files changed, 62 insertions(+), 59 deletions(-)
<br>>
<br>> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
<br>> index 66dace6..4889b4d 100644
<br>> --- a/drivers/net/fec_mpc52xx.c
<br>> +++ b/drivers/net/fec_mpc52xx.c
<br>> @@ -85,11 +85,15 @@ MODULE_PARM_DESC(debug, "debugging messages level");
<br>>
<br>> static void mpc52xx_fec_tx_timeout(struct net_device *dev)
<br>> {
<br>> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + unsigned long flags;
<br>> +
<br>> dev_warn(&dev->dev, "transmit timed out\n");
<br>>
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> mpc52xx_fec_reset(dev);
<br>> -
<br>> dev->stats.tx_errors++;
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> netif_wake_queue(dev);
<br>> }
<br>> @@ -135,28 +139,32 @@ static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct bcom_task
<br>> }
<br>> }
<br>>
<br>> +static void
<br>> +mpc52xx_fec_rx_submit(struct net_device *dev, struct sk_buff *rskb)
<br>> +{
<br>> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + struct bcom_fec_bd *bd;
<br>> +
<br>> + bd = (struct bcom_fec_bd *) bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>> + bd->status = FEC_RX_BUFFER_SIZE;
<br>> + bd->skb_pa = dma_map_single(dev->dev.parent, rskb->data,
<br>> + FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> + bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>> +}
<br>> +
<br>> static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct bcom_task *rxtsk)
<br>> {
<br>> - while (!bcom_queue_full(rxtsk)) {
<br>> - struct sk_buff *skb;
<br>> - struct bcom_fec_bd *bd;
<br>> + struct sk_buff *skb;
<br>>
<br>> + while (!bcom_queue_full(rxtsk)) {
<br>> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>> - if (skb == NULL)
<br>> + if (!skb)
<br>> return -EAGAIN;
<br>>
<br>> /* zero out the initial receive buffers to aid debugging */
<br>> memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
<br>> -
<br>> - bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
<br>> -
<br>> - bd->status = FEC_RX_BUFFER_SIZE;
<br>> - bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>> - FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> -
<br>> - bcom_submit_next_buffer(rxtsk, skb);
<br>> + mpc52xx_fec_rx_submit(dev, skb);
<br>> }
<br>> -
<br>> return 0;
<br>> }
<br>>
<br>> @@ -328,13 +336,12 @@ static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
<br>> DMA_TO_DEVICE);
<br>>
<br>> bcom_submit_next_buffer(priv->tx_dmatsk, skb);
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> if (bcom_queue_full(priv->tx_dmatsk)) {
<br>> netif_stop_queue(dev);
<br>> }
<br>>
<br>> - spin_unlock_irqrestore(&priv->lock, flags);
<br>> -
<br>> return NETDEV_TX_OK;
<br>> }
<br>>
<br>> @@ -359,9 +366,9 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br>> {
<br>> struct net_device *dev = dev_id;
<br>> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + unsigned long flags;
<br>>
<br>> - spin_lock(&priv->lock);
<br>> -
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> while (bcom_buffer_done(priv->tx_dmatsk)) {
<br>> struct sk_buff *skb;
<br>> struct bcom_fec_bd *bd;
<br>> @@ -372,11 +379,10 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br>>
<br>> dev_kfree_skb_irq(skb);
<br>> }
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> netif_wake_queue(dev);
<br>>
<br>> - spin_unlock(&priv->lock);
<br>> -
<br>> return IRQ_HANDLED;
<br>> }
<br>>
<br>> @@ -384,67 +390,60 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
<br>> {
<br>> struct net_device *dev = dev_id;
<br>> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> + struct sk_buff *rskb; /* received sk_buff */
<br>> + struct sk_buff *skb; /* new sk_buff to enqueue in its place */
<br>> + struct bcom_fec_bd *bd;
<br>> + u32 status, physaddr;
<br>> + int length;
<br>> + unsigned long flags;
<br>> +
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>>
<br>> while (bcom_buffer_done(priv->rx_dmatsk)) {
<br>> - struct sk_buff *skb;
<br>> - struct sk_buff *rskb;
<br>> - struct bcom_fec_bd *bd;
<br>> - u32 status;
<br>>
<br>> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
<br>> - (struct bcom_bd **)&bd);
<br>> - dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
<br>> - DMA_FROM_DEVICE);
<br>> + (struct bcom_bd **)&bd);
<br>> + physaddr = bd->skb_pa;
<br>>
<br>> /* Test for errors in received frame */
<br>> if (status & BCOM_FEC_RX_BD_ERRORS) {
<br>> /* Drop packet and reuse the buffer */
<br>> - bd = (struct bcom_fec_bd *)
<br>> - bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>> -
<br>> - bd->status = FEC_RX_BUFFER_SIZE;
<br>> - bd->skb_pa = dma_map_single(dev->dev.parent,
<br>> - rskb->data,
<br>> - FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> -
<br>> - bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>> -
<br>> + mpc52xx_fec_rx_submit(dev, rskb);
<br>> dev->stats.rx_dropped++;
<br>> -
<br>> continue;
<br>> }
<br>>
<br>> /* skbs are allocated on open, so now we allocate a new one,
<br>> * and remove the old (with the packet) */
<br>> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>> - if (skb) {
<br>> - /* Process the received skb */
<br>> - int length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>> -
<br>> - skb_put(rskb, length - 4); /* length without CRC32 */
<br>> -
<br>> - rskb->dev = dev;
<br>> - rskb->protocol = eth_type_trans(rskb, dev);
<br>> -
<br>> - netif_rx(rskb);
<br>> - } else {
<br>> + if (!skb) {
<br>> /* Can't get a new one : reuse the same & drop pkt */
<br>> - dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
<br>> + dev_notice(&dev->dev, "Low memory - dropped packet.\n");
<br>> + mpc52xx_fec_rx_submit(dev, rskb);
<br>> dev->stats.rx_dropped++;
<br>> -
<br>> - skb = rskb;
<br>> + continue;
<br>> }
<br>>
<br>> - bd = (struct bcom_fec_bd *)
<br>> - bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>> + /* Enqueue the new sk_buff back on the hardware */
<br>> + mpc52xx_fec_rx_submit(dev, skb);
<br>>
<br>> - bd->status = FEC_RX_BUFFER_SIZE;
<br>> - bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>> - FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>> + /* Process the received skb - Drop the spin lock while
<br>> + * calling into the network stack */
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> - bcom_submit_next_buffer(priv->rx_dmatsk, skb);
<br>> + dma_unmap_single(dev->dev.parent, physaddr, rskb->len,
<br>> + DMA_FROM_DEVICE);
<br>> + length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>> + skb_put(rskb, length - 4); /* length without CRC32 */
<br>> + rskb->dev = dev;
<br>> + rskb->protocol = eth_type_trans(rskb, dev);
<br>> + netif_rx(rskb);
<br>> +
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> }
<br>>
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>> +
<br>> return IRQ_HANDLED;
<br>> }
<br>>
<br>> @@ -454,6 +453,7 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br>> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>> struct mpc52xx_fec __iomem *fec = priv->fec;
<br>> u32 ievent;
<br>> + unsigned long flags;
<br>>
<br>> ievent = in_be32(&fec->ievent);
<br>>
<br>> @@ -471,9 +471,10 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br>> if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
<br>> dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
<br>>
<br>> + spin_lock_irqsave(&priv->lock, flags);
<br>> mpc52xx_fec_reset(dev);
<br>> + spin_unlock_irqrestore(&priv->lock, flags);
<br>>
<br>> - netif_wake_queue(dev);
<br>> return IRQ_HANDLED;
<br>> }
<br>>
<br>> @@ -768,6 +769,8 @@ static void mpc52xx_fec_reset(struct net_device *dev)
<br>> bcom_enable(priv->tx_dmatsk);
<br>>
<br>> mpc52xx_fec_start(dev);
<br>> +
<br>> + netif_wake_queue(dev);
<br>> }
<br>>
<br>>
<br>>
<br>>
</div><br><br><br>--
<br>Grant Likely, B.Sc., P.Eng.
<br>Secret Lab Technologies Ltd.
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649448&i=4" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26649399
[PATCH] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2009-12-04T13:20:00Z
2009-12-04T13:20:00Z
Grant Likely-2
From: Asier Llano Palacios <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649399&i=0" target="_top" rel="nofollow">asierllano@...</a>>
<br><br>net/mpc5200: Fix locking on fec_mpc52xx driver
<br><br>Fix the locking scheme on the fec_mpc52xx driver. This device can
<br>receive IRQs from three sources; the FEC itself, the tx DMA, and the
<br>rx DMA. Mutual exclusion was handled by taking a spin_lock() in the
<br>critical regions, but because the handlers are run with IRQs enabled,
<br>spin_lock() is insufficient and the driver can end up interrupting
<br>a critical region anyway from another IRQ.
<br><br>Asier Llano discovered that this occurs when an error IRQ is raised
<br>in the middle of handling rx irqs which resulted in an sk_buff memory
<br>leak.
<br><br>In addition, locking is spotty at best in the driver and inspection
<br>revealed quite a few places with insufficient locking.
<br><br>This patch is based on Asier's initial work, but reworks a number of
<br>things so that locks are held for as short a time as possible, so
<br>that spin_lock_irqsave() is used everywhere, and so the locks are
<br>dropped when calling into the network stack (because the lock only
<br>protects the hardware interface; not the network stack).
<br><br>Boot tested on a lite5200 with an NFS root. Has not been performance
<br>tested.
<br><br>Signed-off-by: Asier Llano <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649399&i=1" target="_top" rel="nofollow">a.llano@...</a>>
<br>Signed-off-by: Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649399&i=2" target="_top" rel="nofollow">grant.likely@...</a>>
<br>---
<br><br>Asier, can you please test this? It took me a while to respond to
<br>your initial post because I was concerned about some of the latency
<br>issues, and I was concerned about disabling IRQs for long periods in
<br>the RX handler. I think it should be good now, but it needs testing.
<br><br>Cheers,
<br>g.
<br><br> drivers/net/fec_mpc52xx.c | 121 +++++++++++++++++++++++----------------------
<br> 1 files changed, 62 insertions(+), 59 deletions(-)
<br><br>diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
<br>index 66dace6..4889b4d 100644
<br>--- a/drivers/net/fec_mpc52xx.c
<br>+++ b/drivers/net/fec_mpc52xx.c
<br>@@ -85,11 +85,15 @@ MODULE_PARM_DESC(debug, "debugging messages level");
<br>
<br> static void mpc52xx_fec_tx_timeout(struct net_device *dev)
<br> {
<br>+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ unsigned long flags;
<br>+
<br> dev_warn(&dev->dev, "transmit timed out\n");
<br>
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> mpc52xx_fec_reset(dev);
<br>-
<br> dev->stats.tx_errors++;
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br> netif_wake_queue(dev);
<br> }
<br>@@ -135,28 +139,32 @@ static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct bcom_task
<br> }
<br> }
<br>
<br>+static void
<br>+mpc52xx_fec_rx_submit(struct net_device *dev, struct sk_buff *rskb)
<br>+{
<br>+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ struct bcom_fec_bd *bd;
<br>+
<br>+ bd = (struct bcom_fec_bd *) bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>+ bd->status = FEC_RX_BUFFER_SIZE;
<br>+ bd->skb_pa = dma_map_single(dev->dev.parent, rskb->data,
<br>+ FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>+ bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>+}
<br>+
<br> static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct bcom_task *rxtsk)
<br> {
<br>- while (!bcom_queue_full(rxtsk)) {
<br>- struct sk_buff *skb;
<br>- struct bcom_fec_bd *bd;
<br>+ struct sk_buff *skb;
<br>
<br>+ while (!bcom_queue_full(rxtsk)) {
<br> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>- if (skb == NULL)
<br>+ if (!skb)
<br> return -EAGAIN;
<br>
<br> /* zero out the initial receive buffers to aid debugging */
<br> memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
<br>-
<br>- bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
<br>-
<br>- bd->status = FEC_RX_BUFFER_SIZE;
<br>- bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>-
<br>- bcom_submit_next_buffer(rxtsk, skb);
<br>+ mpc52xx_fec_rx_submit(dev, skb);
<br> }
<br>-
<br> return 0;
<br> }
<br>
<br>@@ -328,13 +336,12 @@ static int mpc52xx_fec_start_xmit(struct sk_buff *skb, struct net_device *dev)
<br> DMA_TO_DEVICE);
<br>
<br> bcom_submit_next_buffer(priv->tx_dmatsk, skb);
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br> if (bcom_queue_full(priv->tx_dmatsk)) {
<br> netif_stop_queue(dev);
<br> }
<br>
<br>- spin_unlock_irqrestore(&priv->lock, flags);
<br>-
<br> return NETDEV_TX_OK;
<br> }
<br>
<br>@@ -359,9 +366,9 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br> {
<br> struct net_device *dev = dev_id;
<br> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ unsigned long flags;
<br>
<br>- spin_lock(&priv->lock);
<br>-
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> while (bcom_buffer_done(priv->tx_dmatsk)) {
<br> struct sk_buff *skb;
<br> struct bcom_fec_bd *bd;
<br>@@ -372,11 +379,10 @@ static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
<br>
<br> dev_kfree_skb_irq(skb);
<br> }
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br> netif_wake_queue(dev);
<br>
<br>- spin_unlock(&priv->lock);
<br>-
<br> return IRQ_HANDLED;
<br> }
<br>
<br>@@ -384,67 +390,60 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
<br> {
<br> struct net_device *dev = dev_id;
<br> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br>+ struct sk_buff *rskb; /* received sk_buff */
<br>+ struct sk_buff *skb; /* new sk_buff to enqueue in its place */
<br>+ struct bcom_fec_bd *bd;
<br>+ u32 status, physaddr;
<br>+ int length;
<br>+ unsigned long flags;
<br>+
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br>
<br> while (bcom_buffer_done(priv->rx_dmatsk)) {
<br>- struct sk_buff *skb;
<br>- struct sk_buff *rskb;
<br>- struct bcom_fec_bd *bd;
<br>- u32 status;
<br>
<br> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
<br>- (struct bcom_bd **)&bd);
<br>- dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
<br>- DMA_FROM_DEVICE);
<br>+ (struct bcom_bd **)&bd);
<br>+ physaddr = bd->skb_pa;
<br>
<br> /* Test for errors in received frame */
<br> if (status & BCOM_FEC_RX_BD_ERRORS) {
<br> /* Drop packet and reuse the buffer */
<br>- bd = (struct bcom_fec_bd *)
<br>- bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>-
<br>- bd->status = FEC_RX_BUFFER_SIZE;
<br>- bd->skb_pa = dma_map_single(dev->dev.parent,
<br>- rskb->data,
<br>- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>-
<br>- bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
<br>-
<br>+ mpc52xx_fec_rx_submit(dev, rskb);
<br> dev->stats.rx_dropped++;
<br>-
<br> continue;
<br> }
<br>
<br> /* skbs are allocated on open, so now we allocate a new one,
<br> * and remove the old (with the packet) */
<br> skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
<br>- if (skb) {
<br>- /* Process the received skb */
<br>- int length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>-
<br>- skb_put(rskb, length - 4); /* length without CRC32 */
<br>-
<br>- rskb->dev = dev;
<br>- rskb->protocol = eth_type_trans(rskb, dev);
<br>-
<br>- netif_rx(rskb);
<br>- } else {
<br>+ if (!skb) {
<br> /* Can't get a new one : reuse the same & drop pkt */
<br>- dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
<br>+ dev_notice(&dev->dev, "Low memory - dropped packet.\n");
<br>+ mpc52xx_fec_rx_submit(dev, rskb);
<br> dev->stats.rx_dropped++;
<br>-
<br>- skb = rskb;
<br>+ continue;
<br> }
<br>
<br>- bd = (struct bcom_fec_bd *)
<br>- bcom_prepare_next_buffer(priv->rx_dmatsk);
<br>+ /* Enqueue the new sk_buff back on the hardware */
<br>+ mpc52xx_fec_rx_submit(dev, skb);
<br>
<br>- bd->status = FEC_RX_BUFFER_SIZE;
<br>- bd->skb_pa = dma_map_single(dev->dev.parent, skb->data,
<br>- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
<br>+ /* Process the received skb - Drop the spin lock while
<br>+ * calling into the network stack */
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br>- bcom_submit_next_buffer(priv->rx_dmatsk, skb);
<br>+ dma_unmap_single(dev->dev.parent, physaddr, rskb->len,
<br>+ DMA_FROM_DEVICE);
<br>+ length = status & BCOM_FEC_RX_BD_LEN_MASK;
<br>+ skb_put(rskb, length - 4); /* length without CRC32 */
<br>+ rskb->dev = dev;
<br>+ rskb->protocol = eth_type_trans(rskb, dev);
<br>+ netif_rx(rskb);
<br>+
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> }
<br>
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>+
<br> return IRQ_HANDLED;
<br> }
<br>
<br>@@ -454,6 +453,7 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br> struct mpc52xx_fec_priv *priv = netdev_priv(dev);
<br> struct mpc52xx_fec __iomem *fec = priv->fec;
<br> u32 ievent;
<br>+ unsigned long flags;
<br>
<br> ievent = in_be32(&fec->ievent);
<br>
<br>@@ -471,9 +471,10 @@ static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
<br> if (net_ratelimit() && (ievent & FEC_IEVENT_XFIFO_ERROR))
<br> dev_warn(&dev->dev, "FEC_IEVENT_XFIFO_ERROR\n");
<br>
<br>+ spin_lock_irqsave(&priv->lock, flags);
<br> mpc52xx_fec_reset(dev);
<br>+ spin_unlock_irqrestore(&priv->lock, flags);
<br>
<br>- netif_wake_queue(dev);
<br> return IRQ_HANDLED;
<br> }
<br>
<br>@@ -768,6 +769,8 @@ static void mpc52xx_fec_reset(struct net_device *dev)
<br> bcom_enable(priv->tx_dmatsk);
<br>
<br> mpc52xx_fec_start(dev);
<br>+
<br>+ netif_wake_queue(dev);
<br> }
<br>
<br>
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649399&i=3" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26648130
[PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
2009-12-04T11:43:40Z
2009-12-04T11:43:40Z
Peter Tyser
This change resolves 2 issues:
<br>- Different chips have a different number of GPIO pins per controller.
<br> For example, the MPC8347 has 32, the P2020 16, and the mpc8572 8.
<br> Previously, the mpc8xxx_gpio driver assumed every chip had 32 GPIO
<br> pins which resulted in some processors reporting an incorrect 'ngpio'
<br> field in /sys. Additionally, users could export and "use" 32 GPIO
<br> pins, although in reality only a subset of the 32 pins had any real
<br> functionality.
<br><br>- Some boards don't utilize all available GPIO pins. Previously,
<br> unused GPIO pins could still be exported and "used", even though the
<br> pins had no real functionality. This is somewhat confusing to a user
<br> and also allow a user to do something "bad", like change an unused
<br> floating output into a floating input.
<br><br>Adding a new "fsl,gpio-mask" device tree property allows a dts file to
<br>accurately describe what GPIO pins are available for use on a given
<br>board.
<br><br>Note that the 'ngpio' value reported in /sys will represent the
<br>"highest" gpio pin accessible, not the total number of gpio pins
<br>available. For example, if a device only allowed the use of GPIO pin 3
<br>(fsl,gpio-mask = 0x8), 'ngpio' would be reported as 4, although
<br>only GPIO pin 3 could be exported and used.
<br><br>Signed-off-by: Peter Tyser <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26648130&i=0" target="_top" rel="nofollow">ptyser@...</a>>
<br>---
<br>I don't know which GPIO pins are usable on Freescale boards. Let me
<br>know if the default mask for the reference boards should change.
<br><br>Thanks,
<br>Peter
<br><br> .../powerpc/dts-bindings/fsl/8xxx_gpio.txt | 11 ++++++--
<br> arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +
<br> arch/powerpc/boot/dts/mpc8377_wlan.dts | 2 +
<br> arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +
<br> arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +
<br> arch/powerpc/boot/dts/p2020ds.dts | 1 +
<br> arch/powerpc/boot/dts/p2020rdb.dts | 1 +
<br> arch/powerpc/boot/dts/xcalibur1501.dts | 1 +
<br> arch/powerpc/boot/dts/xpedite5301.dts | 1 +
<br> arch/powerpc/boot/dts/xpedite5330.dts | 1 +
<br> arch/powerpc/boot/dts/xpedite5370.dts | 1 +
<br> arch/powerpc/sysdev/mpc8xxx_gpio.c | 24 ++++++++++++++++---
<br> 12 files changed, 42 insertions(+), 7 deletions(-)
<br><br>diff --git a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
<br>index d015dce..a8fac7f 100644
<br>--- a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
<br>+++ b/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt
<br>@@ -11,9 +11,12 @@ Required properties:
<br> 83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
<br> - #gpio-cells : Should be two. The first cell is the pin number and the
<br> second cell is used to specify optional parameters (currently unused).
<br>- - interrupts : Interrupt mapping for GPIO IRQ (currently unused).
<br>- - interrupt-parent : Phandle for the interrupt controller that
<br>- services interrupts for this device.
<br>+- interrupts : Interrupt mapping for GPIO IRQ (currently unused).
<br>+- interrupt-parent : Phandle for the interrupt controller that
<br>+ services interrupts for this device.
<br>+- fsl,gpio-mask: A bitmask representing which GPIO pins are availabe for
<br>+ use. For example, a value of 0x13 means GPIO pins 0, 1, and 4 are
<br>+ usable.
<br> - gpio-controller : Marks the port as GPIO controller.
<br>
<br> Example of gpio-controller nodes for a MPC8347 SoC:
<br>@@ -24,6 +27,7 @@ Example of gpio-controller nodes for a MPC8347 SoC:
<br> reg = <0xc00 0x100>;
<br> interrupts = <74 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>@@ -33,6 +37,7 @@ Example of gpio-controller nodes for a MPC8347 SoC:
<br> reg = <0xd00 0x100>;
<br> interrupts = <75 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
<br>index 9e2264b..6152bfa 100644
<br>--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
<br>+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
<br>@@ -115,6 +115,7 @@
<br> reg = <0xc00 0x100>;
<br> interrupts = <74 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>@@ -124,6 +125,7 @@
<br> reg = <0xd00 0x100>;
<br> interrupts = <75 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/mpc8377_wlan.dts b/arch/powerpc/boot/dts/mpc8377_wlan.dts
<br>index 9ea7830..a26535c 100644
<br>--- a/arch/powerpc/boot/dts/mpc8377_wlan.dts
<br>+++ b/arch/powerpc/boot/dts/mpc8377_wlan.dts
<br>@@ -105,6 +105,7 @@
<br> reg = <0xc00 0x100>;
<br> interrupts = <74 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>@@ -114,6 +115,7 @@
<br> reg = <0xd00 0x100>;
<br> interrupts = <75 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
<br>index 4e6a1a4..11ba39c 100644
<br>--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
<br>+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
<br>@@ -115,6 +115,7 @@
<br> reg = <0xc00 0x100>;
<br> interrupts = <74 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>@@ -124,6 +125,7 @@
<br> reg = <0xd00 0x100>;
<br> interrupts = <75 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0xffffffff>;
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
<br>index 72336d5..975bdd7 100644
<br>--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
<br>+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
<br>@@ -113,6 +113,7 @@
<br> reg = <0xc00 0x100>;
<br> interrupts = <74 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0x3ffffff>; /* mpc8379 has 26 gpio */
<br> gpio-controller;
<br> };
<br>
<br>@@ -122,6 +123,7 @@
<br> reg = <0xd00 0x100>;
<br> interrupts = <75 0x8>;
<br> interrupt-parent = <&ipic>;
<br>+ fsl,gpio-mask = <0x3ffffff>; /* mpc8379 has 26 gpio */
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/p2020ds.dts b/arch/powerpc/boot/dts/p2020ds.dts
<br>index 1101914..e64a936 100644
<br>--- a/arch/powerpc/boot/dts/p2020ds.dts
<br>+++ b/arch/powerpc/boot/dts/p2020ds.dts
<br>@@ -277,6 +277,7 @@
<br> reg = <0xf000 0x100>;
<br> interrupts = <47 0x2>;
<br> interrupt-parent = <&mpic>;
<br>+ fsl,gpio-mask = <0xffff>; /* p2020 has 16 gpio*/
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
<br>index da4cb0d..53f75ca 100644
<br>--- a/arch/powerpc/boot/dts/p2020rdb.dts
<br>+++ b/arch/powerpc/boot/dts/p2020rdb.dts
<br>@@ -337,6 +337,7 @@
<br> reg = <0xf000 0x100>;
<br> interrupts = <47 0x2>;
<br> interrupt-parent = <&mpic>;
<br>+ fsl,gpio-mask = <0xffff>; /* p2020 has 16 gpio*/
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
<br>index ac0a617..858668c 100644
<br>--- a/arch/powerpc/boot/dts/xcalibur1501.dts
<br>+++ b/arch/powerpc/boot/dts/xcalibur1501.dts
<br>@@ -598,6 +598,7 @@
<br> interrupts = <47 2>;
<br> interrupt-parent = <&mpic>;
<br> #gpio-cells = <2>;
<br>+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/xpedite5301.dts b/arch/powerpc/boot/dts/xpedite5301.dts
<br>index db7faf5..944f08c 100644
<br>--- a/arch/powerpc/boot/dts/xpedite5301.dts
<br>+++ b/arch/powerpc/boot/dts/xpedite5301.dts
<br>@@ -508,6 +508,7 @@
<br> interrupts = <47 2>;
<br> interrupt-parent = <&mpic>;
<br> #gpio-cells = <2>;
<br>+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/xpedite5330.dts b/arch/powerpc/boot/dts/xpedite5330.dts
<br>index c364ca6..1dacacd 100644
<br>--- a/arch/powerpc/boot/dts/xpedite5330.dts
<br>+++ b/arch/powerpc/boot/dts/xpedite5330.dts
<br>@@ -544,6 +544,7 @@
<br> interrupts = <47 2>;
<br> interrupt-parent = <&mpic>;
<br> #gpio-cells = <2>;
<br>+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/boot/dts/xpedite5370.dts b/arch/powerpc/boot/dts/xpedite5370.dts
<br>index 7a8a4af..d783a50 100644
<br>--- a/arch/powerpc/boot/dts/xpedite5370.dts
<br>+++ b/arch/powerpc/boot/dts/xpedite5370.dts
<br>@@ -506,6 +506,7 @@
<br> interrupts = <47 2>;
<br> interrupt-parent = <&mpic>;
<br> #gpio-cells = <2>;
<br>+ fsl,gpio-mask = <0xf0>; /* 4 LEDs */
<br> gpio-controller;
<br> };
<br>
<br>diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
<br>index 103eace..2c07052 100644
<br>--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
<br>+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
<br>@@ -16,8 +16,6 @@
<br> #include <linux/of_gpio.h>
<br> #include <linux/gpio.h>
<br>
<br>-#define MPC8XXX_GPIO_PINS 32
<br>-
<br> #define GPIO_DIR 0x00
<br> #define GPIO_ODR 0x04
<br> #define GPIO_DAT 0x08
<br>@@ -34,11 +32,12 @@ struct mpc8xxx_gpio_chip {
<br> * open drain mode safely
<br> */
<br> u32 data;
<br>+ u32 valid_pins; /* Bitmask of valid gpio pins */
<br> };
<br>
<br> static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
<br> {
<br>- return 1u << (MPC8XXX_GPIO_PINS - 1 - gpio);
<br>+ return 0x80000000 >> gpio;
<br> }
<br>
<br> static inline struct mpc8xxx_gpio_chip *
<br>@@ -111,12 +110,23 @@ static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val
<br> return 0;
<br> }
<br>
<br>+static int mpc8xxx_gpio_request(struct gpio_chip *gc, unsigned int gpio) {
<br>+ struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
<br>+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
<br>+
<br>+ if (mpc8xxx_gc->valid_pins & (1 << gpio))
<br>+ return 0;
<br>+
<br>+ return -1;
<br>+}
<br>+
<br> static void __init mpc8xxx_add_controller(struct device_node *np)
<br> {
<br> struct mpc8xxx_gpio_chip *mpc8xxx_gc;
<br> struct of_mm_gpio_chip *mm_gc;
<br> struct of_gpio_chip *of_gc;
<br> struct gpio_chip *gc;
<br>+ const u32 *prop;
<br> int ret;
<br>
<br> mpc8xxx_gc = kzalloc(sizeof(*mpc8xxx_gc), GFP_KERNEL);
<br>@@ -133,11 +143,17 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
<br>
<br> mm_gc->save_regs = mpc8xxx_gpio_save_regs;
<br> of_gc->gpio_cells = 2;
<br>- gc->ngpio = MPC8XXX_GPIO_PINS;
<br>+ prop = of_get_property(np, "fsl,gpio-mask", NULL);
<br>+ if (prop)
<br>+ mpc8xxx_gc->valid_pins = *prop;
<br>+ else
<br>+ mpc8xxx_gc->valid_pins = 0xffffffff;
<br>+ gc->ngpio = fls(mpc8xxx_gc->valid_pins);
<br> gc->direction_input = mpc8xxx_gpio_dir_in;
<br> gc->direction_output = mpc8xxx_gpio_dir_out;
<br> gc->get = mpc8xxx_gpio_get;
<br> gc->set = mpc8xxx_gpio_set;
<br>+ gc->request = mpc8xxx_gpio_request;
<br>
<br> ret = of_mm_gpiochip_add(np, mm_gc);
<br> if (ret)
<br>--
<br>1.6.2.1
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26648130&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26647114
Re: [PATCH] MAINTAINERS: Add PowerPC patterns
2009-12-04T10:36:03Z
2009-12-04T10:36:03Z
Grant Likely-2
On Fri, Dec 4, 2009 at 10:39 AM, Josh Boyer <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647114&i=0" target="_top" rel="nofollow">jwboyer@...</a>> wrote:
<div class='shrinkable-quote'><br>> On Fri, Dec 04, 2009 at 09:16:59AM -0800, Joe Perches wrote:
<br>>> LINUX FOR POWERPC EMBEDDED PPC4XX
<br>>> M: Josh Boyer <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647114&i=1" target="_top" rel="nofollow">jwboyer@...</a>>
<br>>>@@ -3221,6 +3228,8 @@ W: <a href="http://www.penguinppc.org/" target="_top" rel="nofollow">http://www.penguinppc.org/</a><br>>> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647114&i=2" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br>>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
<br>>> S: Maintained
<br>>>+F: arch/powerpc/platforms/40x/
<br>>>+F: arch/powerpc/platforms/44x/
<br>>
<br>> This is mostly complete. There are a few files under arch/powerpc/sysdev/, and
<br>> arch/powerpc/boot/ as well, but I don't think they're entirely necessary.
<br>>
<br>> For the 4xx parts:
<br>>
<br>> Acked-by: Josh Boyer <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647114&i=3" target="_top" rel="nofollow">jwboyer@...</a>>
</div>Acked-by: Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647114&i=4" target="_top" rel="nofollow">grant.likely@...</a>>
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26647114&i=5" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26646214
Re: [PATCH] MAINTAINERS: Add PowerPC patterns
2009-12-04T09:39:02Z
2009-12-04T09:39:02Z
Josh Boyer-4
On Fri, Dec 04, 2009 at 09:16:59AM -0800, Joe Perches wrote:
<br>> LINUX FOR POWERPC EMBEDDED PPC4XX
<br>> M: Josh Boyer <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646214&i=0" target="_top" rel="nofollow">jwboyer@...</a>>
<br>>@@ -3221,6 +3228,8 @@ W: <a href="http://www.penguinppc.org/" target="_top" rel="nofollow">http://www.penguinppc.org/</a><br>> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646214&i=1" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
<br>> S: Maintained
<br>>+F: arch/powerpc/platforms/40x/
<br>>+F: arch/powerpc/platforms/44x/
<br><br>This is mostly complete. There are a few files under arch/powerpc/sysdev/, and
<br>arch/powerpc/boot/ as well, but I don't think they're entirely necessary.
<br><br>For the 4xx parts:
<br><br>Acked-by: Josh Boyer <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646214&i=2" target="_top" rel="nofollow">jwboyer@...</a>>
<br><br>josh
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26646214&i=3" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26645985
[PATCH] MAINTAINERS: Add PowerPC patterns
2009-12-04T09:16:59Z
2009-12-04T09:16:59Z
Joe Perches
On Fri, 2009-12-04 at 20:59 +1100, Benjamin Herrenschmidt wrote:
<div class='shrinkable-quote'><br>> On Fri, 2009-12-04 at 10:34 +0100, Jean Delvare wrote:
<br>> > I've sent it to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=0" target="_top" rel="nofollow">linuxppc-dev@...</a> on October 14th. This is the
<br>> > address which is listed 22 times in MAINTAINERS. If it isn't correct,
<br>> > then please update MAINTAINERS.
<br>> No it's fine both shoul work. Your patches are there, just waiting for
<br>> me to pick them up, I was just firing a reminder to the rest of the CC
<br>> list :-) (and I do remember fwd'ing a couple of your patches to the
<br>> list, for some reason they didn't make it to patchwork back then, that
<br>> was a few month ago).
<br>> Anyways, I've been stretched thin with all sort of stuff lately, so bear
<br>> with me if I'm a bit slow at taking or testing stuff, I'm doing my best.
</div><br>Adding patterns to the PowerPC sections of MAINTAINERS is useful.
<br><br>Signed-off-by: Joe Perches <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=1" target="_top" rel="nofollow">joe@...</a>>
<br><br>diff --git a/MAINTAINERS b/MAINTAINERS
<br>index 4f96ac8..c7f8e5a 100644
<br>--- a/MAINTAINERS
<br>+++ b/MAINTAINERS
<br>@@ -3193,6 +3193,7 @@ LINUX FOR IBM pSERIES (RS/6000)
<br> M: Paul Mackerras <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=2" target="_top" rel="nofollow">paulus@...</a>>
<br> W: <a href="http://www.ibm.com/linux/ltc/projects/ppc" target="_top" rel="nofollow">http://www.ibm.com/linux/ltc/projects/ppc</a><br> S: Supported
<br>+F: arch/powerpc/boot/rs6000.h
<br>
<br> LINUX FOR POWERPC (32-BIT AND 64-BIT)
<br> M: Benjamin Herrenschmidt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=3" target="_top" rel="nofollow">benh@...</a>>
<br>@@ -3201,18 +3202,24 @@ W: <a href="http://www.penguinppc.org/" target="_top" rel="nofollow">http://www.penguinppc.org/</a><br> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=4" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br> T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
<br> S: Supported
<br>+F: Documentation/powerpc/
<br>+F: arch/powerpc/
<br>
<br> LINUX FOR POWER MACINTOSH
<br> M: Benjamin Herrenschmidt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=5" target="_top" rel="nofollow">benh@...</a>>
<br> W: <a href="http://www.penguinppc.org/" target="_top" rel="nofollow">http://www.penguinppc.org/</a><br> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=6" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br> S: Maintained
<br>+F: arch/powerpc/platforms/powermac/
<br>+F: drivers/macintosh/
<br>
<br> LINUX FOR POWERPC EMBEDDED MPC5XXX
<br> M: Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=7" target="_top" rel="nofollow">grant.likely@...</a>>
<br> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=8" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br> T: git git://git.secretlab.ca/git/linux-2.6.git
<br> S: Maintained
<br>+F: arch/powerpc/platforms/512x/
<br>+F: arch/powerpc/platforms/52xx/
<br>
<br> LINUX FOR POWERPC EMBEDDED PPC4XX
<br> M: Josh Boyer <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=9" target="_top" rel="nofollow">jwboyer@...</a>>
<br>@@ -3221,6 +3228,8 @@ W: <a href="http://www.penguinppc.org/" target="_top" rel="nofollow">http://www.penguinppc.org/</a><br> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=10" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
<br> S: Maintained
<br>+F: arch/powerpc/platforms/40x/
<br>+F: arch/powerpc/platforms/44x/
<br>
<br> LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
<br> M: Grant Likely <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=11" target="_top" rel="nofollow">grant.likely@...</a>>
<br>@@ -3228,6 +3237,8 @@ W: <a href="http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex" target="_top" rel="nofollow">http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex</a><br> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=12" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br> T: git git://git.secretlab.ca/git/linux-2.6.git
<br> S: Maintained
<br>+F: arch/powerpc/*/*virtex*
<br>+F: arch/powerpc/*/*/*virtex*
<br>
<br> LINUX FOR POWERPC EMBEDDED PPC8XX
<br> M: Vitaly Bordug <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=13" target="_top" rel="nofollow">vitb@...</a>>
<br>@@ -3241,12 +3252,16 @@ M: Kumar Gala <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=14" target="_top" rel="nofollow">galak@...</a>>
<br> W: <a href="http://www.penguinppc.org/" target="_top" rel="nofollow">http://www.penguinppc.org/</a><br> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=15" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br> S: Maintained
<br>+F: arch/powerpc/platforms/83xx/
<br>
<br> LINUX FOR POWERPC PA SEMI PWRFICIENT
<br> M: Olof Johansson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=16" target="_top" rel="nofollow">olof@...</a>>
<br> W: <a href="http://www.pasemi.com/" target="_top" rel="nofollow">http://www.pasemi.com/</a><br> L: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=17" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br> S: Supported
<br>+F: arch/powerpc/platforms/pasemi/
<br>+F: drivers/*/*pasemi*
<br>+F: drivers/*/*/*pasemi*
<br>
<br> LINUX SECURITY MODULE (LSM) FRAMEWORK
<br> M: Chris Wright <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=18" target="_top" rel="nofollow">chrisw@...</a>>
<br><br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645985&i=19" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26645277
Re: BUG: Bad page map in process
2009-12-04T08:37:13Z
2009-12-04T08:37:13Z
Sean MacLennan-2
On Fri, 04 Dec 2009 22:18:55 +1100
<br>Benjamin Herrenschmidt <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645277&i=0" target="_top" rel="nofollow">benh@...</a>> wrote:
<br><br>> Ok, I'll have a look next week. In the meantime, Sean, can you give
<br>> me a hint of what you do to trigger it ? Boot time ? specific
<br>> workload ?
<br><br>It hasn't happened that often, but I have been focusing on 2.6.31.
<br><br>So far, it has always happened well after the boot, but not hours. I
<br>haven't worked out a specific workload.
<br><br>Cheers,
<br> Sean
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26645277&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26643164
RE: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
2009-12-04T06:19:16Z
2009-12-04T06:19:16Z
_curtis_
Josh,
<br>Yes, the patch you provided below is exactly what is needed for PCI
<br>functionality.
<br><br>I've verified using a 2 port Silicon Image 3512 PCI to SATA controller
<br>card on Yosemite.
<br><br>-Curtis
<br><br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: Josh Boyer [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26643164&i=0" target="_top" rel="nofollow">jwboyer@...</a>]
<br>> Sent: Friday, December 04, 2009 6:08 AM
<br>> To: Curtis Wald
<br>> Cc: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26643164&i=1" target="_top" rel="nofollow">mporter@...</a>; <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26643164&i=2" target="_top" rel="nofollow">linuxppc-dev@...</a>
<br>> Subject: Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
<br>>
<br>> On Mon, Nov 30, 2009 at 09:25:51AM -0600, Curtis Wald wrote:
<br>> >Josh,
<br>> >Here is a resend of the Yosemite.dts patch, deleting tabs and spaces
<br>> in
<br>> >the IDSEL section that should look better when viewing as 80 column.
<br>>
<br>> Something is still eating your patches when you send them out. They
<br>> get
<br>> corrupted to the point of being unusable as you can see here:
<br>>
<br>> <a href="http://patchwork.ozlabs.org/patch/39810/" target="_top" rel="nofollow">http://patchwork.ozlabs.org/patch/39810/</a><br>>
<br>> However, your intentions are pretty clear. Could you look at the
</div>patch
<div class='shrinkable-quote'><br>> below
<br>> and see if it was what you intended? If so, I'll include it in my
<br>> 'next'
<br>> branch today.
<br>>
<br>> josh
<br>>
<br>> ---
<br>>
<br>> diff --git a/arch/powerpc/boot/dts/yosemite.dts
<br>> b/arch/powerpc/boot/dts/yosemite.dts
<br>> index 1fa3cb4..6492324 100644
<br>> --- a/arch/powerpc/boot/dts/yosemite.dts
<br>> +++ b/arch/powerpc/boot/dts/yosemite.dts
<br>> @@ -282,20 +282,10 @@
<br>> /* Inbound 2GB range starting at 0 */
<br>> dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0
<br>> 0x80000000>;
<br>>
<br>> - /* Bamboo has all 4 IRQ pins tied together per
</div>slot
<div class='shrinkable-quote'><br>> */
<br>> interrupt-map-mask = <0xf800 0x0 0x0 0x0>;
<br>> interrupt-map = <
<br>> - /* IDSEL 1 */
<br>> - 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
<br>> -
<br>> - /* IDSEL 2 */
<br>> - 0x1000 0x0 0x0 0x0 &UIC0 0x1b 0x8
<br>> -
<br>> - /* IDSEL 3 */
<br>> - 0x1800 0x0 0x0 0x0 &UIC0 0x1a 0x8
<br>> -
<br>> - /* IDSEL 4 */
<br>> - 0x2000 0x0 0x0 0x0 &UIC0 0x19 0x8
<br>> + /* IDSEL 12 */
<br>> + 0x6000 0x0 0x0 0x0 &UIC0 0x19 0x8
<br>> >;
<br>> };
<br>> };
</div>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26643164&i=3" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26643084
Re: using different format for hugetlbfs
2009-12-04T06:09:32Z
2009-12-04T06:09:32Z
Kumar Gala-3
<br>On Dec 4, 2009, at 2:58 AM, Benjamin Herrenschmidt wrote:
<br><div class='shrinkable-quote'><br>> On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
<br>>> Ben, David,
<br>>>
<br>>> If we want to support true 4G/4G split on ppc32 using the MSB of the
<br>>> address to determine of the pgd_t is for hugetlbfs isn't going to
<br>>> work. Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
<br>>> at least a 4K page I would think the low order 12-bits should always
<br>>> be 0.
<br>>
<br>> On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
<br>> want to have a different encoding for both types though.
</div><br>What do you mean they can be smaller? We have some scenario when we
<br>dont allocate a full page? I agree having the encodings be different
<br>would be bad. I'm trying to avoid having it be different between 32
<br>bit and 64 (but maybe that will be impossible).
<br><div class='shrinkable-quote'><br>>> Could we use something like:
<br>>>
<br>>> addr[0:51] || shift [52:59] || flags [60:63]
<br>>>
<br>>> with the LSB flag being 'normal pointer' vs 'hugetlbfs mangled
<br>>> pointer'. Seems like shift will at most be 64 so 8-bits should cover
<br>>> it.
<br>>
<br>> Cheers,
<br>> Ben.
<br>>
</div><br>- k
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26643084&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26641660
Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
2009-12-04T04:07:44Z
2009-12-04T04:07:44Z
Josh Boyer-4
On Mon, Nov 30, 2009 at 09:25:51AM -0600, Curtis Wald wrote:
<br>>Josh,
<br>>Here is a resend of the Yosemite.dts patch, deleting tabs and spaces in
<br>>the IDSEL section that should look better when viewing as 80 column.
<br><br>Something is still eating your patches when you send them out. They get
<br>corrupted to the point of being unusable as you can see here:
<br><br><a href="http://patchwork.ozlabs.org/patch/39810/" target="_top" rel="nofollow">http://patchwork.ozlabs.org/patch/39810/</a><br><br>However, your intentions are pretty clear. Could you look at the patch below
<br>and see if it was what you intended? If so, I'll include it in my 'next'
<br>branch today.
<br><br>josh
<br><br>---
<br><br>diff --git a/arch/powerpc/boot/dts/yosemite.dts b/arch/powerpc/boot/dts/yosemite.dts
<br>index 1fa3cb4..6492324 100644
<br>--- a/arch/powerpc/boot/dts/yosemite.dts
<br>+++ b/arch/powerpc/boot/dts/yosemite.dts
<br>@@ -282,20 +282,10 @@
<br> /* Inbound 2GB range starting at 0 */
<br> dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
<br>
<br>- /* Bamboo has all 4 IRQ pins tied together per slot */
<br> interrupt-map-mask = <0xf800 0x0 0x0 0x0>;
<br> interrupt-map = <
<br>- /* IDSEL 1 */
<br>- 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
<br>-
<br>- /* IDSEL 2 */
<br>- 0x1000 0x0 0x0 0x0 &UIC0 0x1b 0x8
<br>-
<br>- /* IDSEL 3 */
<br>- 0x1800 0x0 0x0 0x0 &UIC0 0x1a 0x8
<br>-
<br>- /* IDSEL 4 */
<br>- 0x2000 0x0 0x0 0x0 &UIC0 0x19 0x8
<br>+ /* IDSEL 12 */
<br>+ 0x6000 0x0 0x0 0x0 &UIC0 0x19 0x8
<br> >;
<br> };
<br> };
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26641660&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26641586
Re: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT (v2)
2009-12-04T04:02:52Z
2009-12-04T04:02:52Z
Sachin Sant
David Gibson wrote:
<div class='shrinkable-quote'><br>> Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
<br>> last version. Fixed below.
<br>>
<br>> Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
<br>>
<br>> Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
<br>> of kmem_caches for allocating various levels of pagetables.
<br>> Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
<br>> the latter's cleverly hidden technique of adding some extra allocation
<br>> space to the top level page directory to store the extra information
<br>> it needs.
<br>>
<br>> Since that extra allocation really doesn't fit into the cleaned up
<br>> page directory allocating scheme, this patch alters
<br>> CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
<br>> subpage_prot_table as part of the mm_context_t.
<br>>
<br>> Signed-off-by: David Gibson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26641586&i=0" target="_top" rel="nofollow">david@...</a>>
</div>Ben,
<br><br>Ping on this patch. It is still missing from linux-next.
<br><br>Thanks
<br>-Sachin
<br><br>--
<br><br>---------------------------------
<br>Sachin Sant
<br>IBM Linux Technology Center
<br>India Systems and Technology Labs
<br>Bangalore, India
<br>---------------------------------
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26641586&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26641222
Git tags
2009-12-04T03:27:03Z
2009-12-04T03:27:03Z
Martyn Welch-3
Hi Ben,
<br><br>Could you please pull the git tags from Linus' tree when you pull?
<br><br>It aids a little in quickly seeing how far a tree on kernel has moved
<br>forward, at the moment the last tag on your tree is "v2.6.26-rc9" [1].
<br><br>Martyn
<br><br>[1]
<br><a href="http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/benh/powerpc.git;a=summary" target="_top" rel="nofollow">http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/benh/powerpc.git;a=summary</a><br><br>--
<br>Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
<br>GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
<br>Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
<br>Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26641222&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26641152
Re: BUG: Bad page map in process
2009-12-04T03:18:55Z
2009-12-04T03:18:55Z
Benjamin Herrenschmidt
On Fri, 2009-12-04 at 06:00 -0500, Josh Boyer wrote:
<div class='shrinkable-quote'><br>> On Fri, Dec 04, 2009 at 08:08:27PM +1100, Benjamin Herrenschmidt wrote:
<br>> >On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
<br>> >> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
<br>> >> shown below. I believe these started in 2.6.32-rc8 or possibly
<br>> >> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
<br>> >> on that release, and not really testing the 2.6.32 stream.
<br>> >>
<br>> >> I wish I could give more info, but I don't really even have the time to
<br>> >> write this email :( I am hoping somebody will have a eureka moment.
<br>> >
<br>> >That's a concern. Remind me what CPU / MMU type is Pika using ?
<br>>
<br>> 440EP
</div><br>Ok, I'll have a look next week. In the meantime, Sean, can you give me a
<br>hint of what you do to trigger it ? Boot time ? specific workload ?
<br><br>Cheers,
<br>Ben.
<br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26641152&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26640972
Re: BUG: Bad page map in process
2009-12-04T03:00:56Z
2009-12-04T03:00:56Z
Josh Boyer-3
On Fri, Dec 04, 2009 at 08:08:27PM +1100, Benjamin Herrenschmidt wrote:
<div class='shrinkable-quote'><br>>On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
<br>>> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
<br>>> shown below. I believe these started in 2.6.32-rc8 or possibly
<br>>> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
<br>>> on that release, and not really testing the 2.6.32 stream.
<br>>>
<br>>> I wish I could give more info, but I don't really even have the time to
<br>>> write this email :( I am hoping somebody will have a eureka moment.
<br>>
<br>>That's a concern. Remind me what CPU / MMU type is Pika using ?
</div><br>440EP
<br><br>josh
<br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26640972&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26639626
Re: BUG: Bad page map in process
2009-12-04T01:08:27Z
2009-12-04T01:08:27Z
Benjamin Herrenschmidt
On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
<br>> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
<br>> shown below. I believe these started in 2.6.32-rc8 or possibly
<br>> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
<br>> on that release, and not really testing the 2.6.32 stream.
<br>>
<br>> I wish I could give more info, but I don't really even have the time to
<br>> write this email :( I am hoping somebody will have a eureka moment.
<br><br>That's a concern. Remind me what CPU / MMU type is Pika using ?
<br><br>Cheers,
<br>Ben.
<br><div class='shrinkable-quote'><br>> Cheers,
<br>> Sean
<br>>
<br>>
<br>> [ 147.410448] BUG: Bad page map in process udevd pte:ffffffffffffffff pmd:cd883000
<br>> [ 147.417989] addr:48003000 vm_flags:08000875 anon_vma:(null) mapping:cf4150ac index:3
<br>> [ 147.425837] vma->vm_ops->fault: filemap_fault+0x0/0x410
<br>> [ 147.431101] vma->vm_file->f_op->mmap: nfs_file_mmap+0x0/0x94
<br>> [ 147.436795] Call Trace:
<br>> [ 147.439268] [cf2dbd80] [c00065a4] show_stack+0x48/0x168 (unreliable)
<br>> [ 147.445708] [cf2dbdb0] [c0064ac8] print_bad_pte+0x14c/0x204
<br>> [ 147.451337] [cf2dbde0] [c0064cd4] vm_normal_page+0x90/0x98
<br>> [ 147.456875] [cf2dbdf0] [c0064ee8] unmap_vmas+0x20c/0x638
<br>> [ 147.462239] [cf2dbe80] [c0069194] exit_mmap+0xc8/0x170
<br>> [ 147.467441] [cf2dbea0] [c001caa4] mmput+0x50/0xf4
<br>> [ 147.472195] [cf2dbeb0] [c0020808] exit_mm+0x100/0x138
<br>> [ 147.477299] [cf2dbee0] [c00211b0] do_exit+0xb0/0x580
<br>> [ 147.482315] [cf2dbf20] [c00216c4] do_group_exit+0x44/0x9c
<br>> [ 147.487766] [cf2dbf30] [c0021730] sys_exit_group+0x14/0x28
<br>> [ 147.493308] [cf2dbf40] [c000dde4] ret_from_syscall+0x0/0x3c
<br>> _______________________________________________
<br>> Linuxppc-dev mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26639626&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br>> <a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a></div><br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26639626&i=1" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>
tag:old.nabble.com,2006:post-26639604
Re: PCI interrupt question
2009-12-04T01:05:53Z
2009-12-04T01:05:53Z
Benjamin Herrenschmidt
On Thu, 2009-12-03 at 11:52 -0800, David Hawkins wrote:
<br>>
<br>> Really? I thought the pci_dev structures represent the
<br>> devices found on the PCI bus, and the IRQ line in
<br>> that structure was merely copied from the configuration
<br>> space registers.
<br><br>No, it's not. In fact it's mostly irrelevant. It has room for only 8
<br>bits and we commonly manipulate a lot more interrupts on some modern
<br>systems.
<br><br>Linux will obtain from the device-tree the routing for the interrupt
<br>line(s) of the device. If you don't have a node for the device (which is
<br>allowed for PCI), linux will use the INTERRUPT_PIN register to query
<br>which interrupt line is the device output, and will use the host bridge
<br>device-tree node "interrupt-map" property to find where it's connected
<br>to on the PIC.
<br><br>It will then map that to a linux virtual IRQ number which is what you
<br>find in pci_dev. At least that's how it works on powerpc :-)
<br><br>> When you request that interrupt, the
<br>> code would have to remap it to a host IRQ line, which
<br>> it would use the DTS for. (But I'm just speculating).
<br><br>No, it's already remapped in pci_dev. The mapping happen when the PCI
<br>devices are discovered by the kernel.
<br><br>> Bottom line is; if the IRQ field of lspci is 0, then you
<br>> need to figure out that problem first :)
<br><br>I wouldn't trust lspci too much, I'm not sure we bother writing back the
<br>number to the PCI_INTERRUPT_LINE register anymore anyways.
<br><br>If your pci_dev->irq is non-0 then Linux found -something- but it might
<br>not be right, it depends on your device-tree.
<br><br>Cheers,
<br>Ben.
<br><br><br>_______________________________________________
<br>Linuxppc-dev mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26639604&i=0" target="_top" rel="nofollow">Linuxppc-dev@...</a>
<br><a href="https://lists.ozlabs.org/listinfo/linuxppc-dev" target="_top" rel="nofollow">https://lists.ozlabs.org/listinfo/linuxppc-dev</a><br><p>From forum: <a href="http://old.nabble.com/linuxppc-dev-f15995.html" embed="fixTarget[15995]" target="_top" >linuxppc-dev</a></p>