* Re: [PATCH] powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllers
From: Anton Vorontsov @ 2009-12-09 16:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, B.J. Buchalter
In-Reply-To: <20091207225435.GA18485@oksana.dev.rtsoft.ru>
On Tue, Dec 08, 2009 at 01:54:35AM +0300, Anton Vorontsov wrote:
> It appears that we wrongly calculate dev_base for type1 config cycles.
> The thing is: we shouldn't subtract hose->first_busno because PCI core
> sets PCI primary, secondary and subordinate bus numbers, and PCIe
> controller actually takes the registers into account. So we should use
> just bus->number.
>
> Also, according to MPC8315 reference manual, primary bus number should
> always remain 0. We have PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS quirk
> in indirect_pci.c, but since 83xx is somewhat special, it doesn't use
> indirect_pci.c routines, so we have to implement the quirk specifically
> for 83xx PCIe controllers.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> This fixes the issue similar to http://www.pubbs.net/linuxppc/200908/22024/
> i.e. lspci reports:
>
> 0000:00:00.0 Power PC: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:02:00.0 PCI bridge: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:01.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:02.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> ...
>
> While it should be:
>
> 0000:00:00.0 Power PC: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:02:00.0 PCI bridge: Freescale Semiconductor Inc Device 00b4 (rev 11)
> 0002:03:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03)
> 0002:04:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01)
Just for the reference... I found and tested a PLX bridge, and
it works OK as well:
0002:03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
0002:04:00.0 USB Controller: NEC Corporation USB (rev 43)
0002:04:00.1 USB Controller: NEC Corporation USB (rev 43)
0002:04:00.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
0002:04:01.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr (rev 01)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC PATCH v2 2/6] powerpc: wii: bootwrapper bits
From: Segher Boessenkool @ 2009-12-09 16:23 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1259880447-5008-3-git-send-email-albert_herranz@yahoo.es>
> Add support for the Nintendo Wii video game console to the powerpc
> bootwrapper.
>
> dtbImage.wii is a wrapped image that contains a flat device tree,
> an entry point compatible with the Homebrew Channel and BootMii,
> and an optional initrd.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH 6/8] Use proper types for do_div
From: Anton Vorontsov @ 2009-12-09 16:09 UTC (permalink / raw)
To: Mark Wielaard; +Cc: linuxppc-dev, systemtap
In-Reply-To: <1260374194.31018.11.camel@springer.wildebeest.org>
On Wed, Dec 09, 2009 at 04:56:34PM +0100, Mark Wielaard wrote:
> On Sat, 2009-11-28 at 01:33 +0300, Anton Vorontsov wrote:
> > do_div accepts unsigned 64-bit integer type for dividend, signed types
> > would cause do_div's typecheck fail:
> >
> > stat-common.c: In function 'needed_space':
> > stat-common.c:50: error: comparison of distinct pointer types lacks a cast
> > ...same errors in time.c and tapset-timers.cxx's generated code...
> >
> I don't immediately see anything wrong with the code. But on x86_64 this
> does cause some regression test failures in testsuite/systemtap.maps. In
> particular the following tests now fail (they all pass with this one
> patch reverted):
>
> Running /home/mark/src/systemtap/testsuite/systemtap.maps/elision.exp ...
> FAIL: elision-1
[...]
> Running /home/mark/src/systemtap/testsuite/systemtap.maps/log_edge.exp ...
> FAIL: systemtap.maps/log_edge.stp
>
> Could you have a look?
I think this should be fixed by this patch:
http://sourceware.org/ml/systemtap/2009-q4/msg00800.html
Can you try it? With this patch I see no new regressions on x86_64.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/8] Use proper types for do_div
From: Mark Wielaard @ 2009-12-09 15:56 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, systemtap
In-Reply-To: <20091127223347.GF21805@oksana.dev.rtsoft.ru>
Hi Anton,
On Sat, 2009-11-28 at 01:33 +0300, Anton Vorontsov wrote:
> do_div accepts unsigned 64-bit integer type for dividend, signed types
> would cause do_div's typecheck fail:
>
> stat-common.c: In function 'needed_space':
> stat-common.c:50: error: comparison of distinct pointer types lacks a cast
> ...same errors in time.c and tapset-timers.cxx's generated code...
>
> A fix for time.c is special, on ppc32 cycles_t is 32-bit, so technically
> we don't need do_div, but since the whole _stp_gettimeofday_ns() operates
> on 64-bit types we'd better be safe and use uint64_t for the math.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> runtime/stat-common.c | 8 ++++----
> runtime/time.c | 3 ++-
> tapset-timers.cxx | 2 +-
> 3 files changed, 7 insertions(+), 6 deletions(-)
I don't immediately see anything wrong with the code. But on x86_64 this
does cause some regression test failures in testsuite/systemtap.maps. In
particular the following tests now fail (they all pass with this one
patch reverted):
Running /home/mark/src/systemtap/testsuite/systemtap.maps/elision.exp ...
FAIL: elision-1
FAIL: elision0
FAIL: elision1
FAIL: elision2
FAIL: elision3
Running /home/mark/src/systemtap/testsuite/systemtap.maps/ix.exp ...
FAIL: systemtap.maps/ix.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_large_neg.exp ...
FAIL: systemtap.maps/linear_large_neg.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_overunder.exp ...
FAIL: systemtap.maps/linear_overunder.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/linear_under.exp ...
FAIL: systemtap.maps/linear_under.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/log.exp ...
FAIL: systemtap.maps/log.stp
Running /home/mark/src/systemtap/testsuite/systemtap.maps/log_edge.exp ...
FAIL: systemtap.maps/log_edge.stp
Could you have a look?
Thanks,
Mark
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Torsten Fleischer @ 2009-12-09 15:49 UTC (permalink / raw)
To: Grant Likely; +Cc: avorontsov
In-Reply-To: <fa686aa40911261117y4744e56bmf4d1d8260c7a51d0@mail.gmail.com>
On Thu, Nov 26, 2009 at 20:17:35, Grant Likely wrote:
[...]
> spi-cs-high is definitely not a complete solution, but it isn't
> actively evil either. Plus it is documented and (presumably) in
> active use. so support for it should not be dropped.
>
> Regardless, there needs to be a library function for parsing all the
> SPI child nodes and returning the active state for each GPIO chip
> select. All the code for parsing the old spi-cs-high properties can
> be contained in the same place as a new yet-to-be-defined bus node cs
> polarity property. The rework to the driver itself is not ugly.
>
The following patch adds a function to get the active state of the chip select
of a SPI device by looking for the 'spi-cs-high' property in the associated device
tree node.
This function is used by the spi_mpc8xxx driver to set a proper initial value
to the associated GPIOs.
Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
---
diff -ruN linux-2.6.32_orig//drivers/of/of_spi.c linux-2.6.32/drivers/of/of_spi.c
--- linux-2.6.32_orig//drivers/of/of_spi.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/of/of_spi.c 2009-12-09 12:37:01.000000000 +0100
@@ -10,6 +10,49 @@
#include <linux/device.h>
#include <linux/spi/spi.h>
#include <linux/of_spi.h>
+#include <linux/errno.h>
+
+/**
+ * of_get_spi_cs_active_state - Gets the chip select's active state of a SPI
+ * child devices.
+ * @np: parent node of the SPI device nodes
+ * @index: index/address of the SPI device (refers to the 'reg' property)
+ * @cs_active: pointer to return the chip select's active state
+ * (true = active high; false = active low)
+ *
+ * Returns 0 on success; negative errno on failure
+ */
+int of_get_spi_cs_active_state(struct device_node *np, int index, bool *cs_active)
+{
+ struct device_node *child;
+ const int *prop;
+ int len;
+ bool active = 0;
+
+ /* search for the matching SPI device */
+ for_each_child_of_node(np, child) {
+ prop = of_get_property(child, "reg", &len);
+ if (!prop || len < sizeof(*prop)) {
+ /* property 'reg' not available (not an error) */
+ continue;
+ }
+
+ if ( *prop == index ) {
+ /* matching device found */
+ if (of_find_property(child, "spi-cs-high", NULL))
+ active = 1;
+
+ if (cs_active)
+ *cs_active = active;
+
+ return 0;
+ }
+ }
+
+ return -ENODEV;
+}
+EXPORT_SYMBOL(of_get_spi_cs_active_state);
+
/**
* of_register_spi_devices - Register child devices onto the SPI bus
diff -ruN linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.32/drivers/spi/spi_mpc8xxx.c
--- linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/spi/spi_mpc8xxx.c 2009-12-09 12:50:36.000000000 +0100
@@ -705,6 +705,7 @@
for (; i < ngpios; i++) {
int gpio;
enum of_gpio_flags flags;
+ bool astate;
gpio = of_get_gpio_flags(np, i, &flags);
if (!gpio_is_valid(gpio)) {
@@ -721,8 +722,15 @@
pinfo->gpios[i] = gpio;
pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+ ret = of_get_spi_cs_active_state(np, i, &astate);
+ if (ret) {
+ dev_err(dev, "can't get cs active state of device "
+ "#%d: %d\n", i, ret);
+ goto err_loop;
+ }
+
ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
+ pinfo->alow_flags[i] ^ !astate);
if (ret) {
dev_err(dev, "can't set output direction for gpio "
"#%d: %d\n", i, ret);
diff -ruN linux-2.6.32_orig//include/linux/of_spi.h linux-2.6.32/include/linux/of_spi.h
--- linux-2.6.32_orig//include/linux/of_spi.h 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/include/linux/of_spi.h 2009-12-09 12:36:48.000000000 +0100
@@ -15,4 +15,7 @@
extern void of_register_spi_devices(struct spi_master *master,
struct device_node *np);
+extern int of_get_spi_cs_active_state(struct device_node *np,
+ int index, bool *cs_active);
+
#endif /* __LINUX_OF_SPI */
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Josh Boyer @ 2009-12-09 15:47 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091209103645.01058e79@opus.seanm.ca>
On Wed, Dec 09, 2009 at 10:36:45AM -0500, Sean MacLennan wrote:
>On Wed, 9 Dec 2009 09:40:55 -0500
>Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
>> How does that impact the older revisions? You're using a cuImage
>> with Warp, so the device tree is bundled with that. If you boot a
>> new kernel with this change to the DTS on a older board revision,
>> will it do bad things?
>
>The new SD driver takes care of that. If you use the new kernel with an
>old FPGA you reserve more space than you need, but the driver will not
>touch it.
>
>And if you somehow end up with the new DTS on an older kernel, the old
>SD driver will not use the space anyway since the buffer is limited to
>one block.
>
>The SD driver is not in the kernel proper because it was implemented in
>the FPGA and has a non-standard interface. It requires a change to the
>SD core to run. But it is GPLed, so if anybody wants to see it, just
>ask.
OK thanks. I figured something like that would be the case, but wanted to
verify first.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Sean MacLennan @ 2009-12-09 15:36 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
In-Reply-To: <20091209144055.GS2937@zod.rchland.ibm.com>
On Wed, 9 Dec 2009 09:40:55 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> How does that impact the older revisions? You're using a cuImage
> with Warp, so the device tree is bundled with that. If you boot a
> new kernel with this change to the DTS on a older board revision,
> will it do bad things?
The new SD driver takes care of that. If you use the new kernel with an
old FPGA you reserve more space than you need, but the driver will not
touch it.
And if you somehow end up with the new DTS on an older kernel, the old
SD driver will not use the space anyway since the buffer is limited to
one block.
The SD driver is not in the kernel proper because it was implemented in
the FPGA and has a non-standard interface. It requires a change to the
SD core to run. But it is GPLed, so if anybody wants to see it, just
ask.
Cheers,
Sean
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Wolfram Sang @ 2009-12-09 14:57 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <200912091529.13913.roman.fietze@telemotive.de>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hello Roman,
> I would be interested in your opinion, maybe Wolfgang could make some
> comments, because he is involved in the U-Boot a lot as well.
Do you have a way to measure performance penalties? I know that stability comes
before performance, still I am wondering as it looks to me that the most
interesting features are simply switched off.
Regrads,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Increase warp SD buffer
From: Josh Boyer @ 2009-12-09 14:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091209000437.78794a8f@opus.seanm.ca>
On Wed, Dec 09, 2009 at 12:04:37AM -0500, Sean MacLennan wrote:
>Newer revs of the FPGA have a larger SD buffer.
How does that impact the older revisions? You're using a cuImage with Warp,
so the device tree is bundled with that. If you boot a new kernel with this
change to the DTS on a older board revision, will it do bad things?
josh
^ permalink raw reply
* MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Roman Fietze @ 2009-12-09 14:29 UTC (permalink / raw)
To: linuxppc-dev
Hallo,
I had a discussion with some Freescale support people about the
constant RFIFO Event errors or PATA hard disk crashes when stressing a
board with (very) high loads, in my case even with some additional
traffic from an FPGA (or just the FLASH) via the SCLPC FIFO using the
BestComm.
The latest recommendation from Freescale was to set BSDIS and PLDIS
and to clear SE, resulting in a XLB config register value of
0x80012006, at least for my MPC5200B PVR/SVR of
0x80822014/0x80110022. If I am correct, the current XLB config setting
using the current U-Boot and kernel is 0x0000a006.
In order to get cache coherency I had to set
CONFIG_NOT_COHERENT_CACHE=3Dy for the MPC5200B boards. Please correct me
if I am wrong with this assumption.
With this setup, XLB config and kernel config, I do no longer have any
PATA crashes, I do no longer have any FEC RFIFO errors, and my SCLPC
driver runs w/o problems, too.
I would be interested in your opinion, maybe Wolfgang could make some
comments, because he is involved in the U-Boot a lot as well.
Here is the original text from the Freescale support person:
=2D- snippety snip --
Dear Roman Fietze,=20
In reply to your message regarding Service Request SR 1-597437219:
Disable pipelining also. Test your software using the following
setting of the XLB arbiter: 0x80012006.
We have request from a customer with similar problem. Problem
disappeared if XLB pipelining and BestComm snooping were disabled.
Should you need to contact us with regard to this message, please see
the notes below.
Best Regards,=20
Pavel=20
Technical Support
=46reescale Semiconductor
=2D- snappety snap --
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* RE: [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: Kumar Gopalpet-B05799 @ 2009-12-09 13:55 UTC (permalink / raw)
To: avorontsov; +Cc: David Miller, linuxppc-dev, netdev
In-Reply-To: <20091209.025245.152622485.davem@davemloft.net>
=20
>From: Anton Vorontsov <avorontsov@ru.mvista.com>
>Date: Wed, 9 Dec 2009 13:44:27 +0300
>
>> commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add=20
>> Multiple group Support") introduced the following build error with=20
>> CONFIG_NET_POLL_CONTROLLER=3Dy:
> ...
>> This patch fixes the issue.
>>=20
>> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
Thanks Anton !
^ permalink raw reply
* Re: 2.6.33 -next tree
From: Grant Likely @ 2009-12-09 13:40 UTC (permalink / raw)
To: Luotao Fu; +Cc: linuxppc-dev
In-Reply-To: <4B1F6D3A.3030500@pengutronix.de>
On Wed, Dec 9, 2009 at 2:26 AM, Luotao Fu <l.fu@pengutronix.de> wrote:
> Hi Grant,
>
> Grant Likely wrote:
>> Hi Ben, Stephen.
>>
>> I just prepared my next branch for 2.6.33:
>> git://git.secretlab.ca/git/linux-2.6 next
>>
>
> Just for curiosity: I noticed that you keep so far the further patches for the
> dedicated spi controller on mpc5200 in the next-spi tree. Any plan when they
> will be merged to the -next tree? Like mentioned before, some of them are
> essential, without which the driver doesn't work (at least on my board)
I based the next-spi tree on my regular next tree (which was
convenient, but lead to it looking like I had inappropriate stuff in
my spi tree). Once Ben asks Linus to pull his tree it will all look
correct. I'll ask Linux to pull my next-spi tree directly after Ben's
tree is in.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: David Miller @ 2009-12-09 10:52 UTC (permalink / raw)
To: avorontsov; +Cc: Sandeep.Kumar, linuxppc-dev, netdev
In-Reply-To: <20091209104427.GA25526@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed, 9 Dec 2009 13:44:27 +0300
> commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add
> Multiple group Support") introduced the following build error
> with CONFIG_NET_POLL_CONTROLLER=y:
...
> This patch fixes the issue.
>
> Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, but this shows that netconsole needs some serious
testing with this drive now :-/
Thanks.
^ permalink raw reply
* [PATCH] gianfar: Fix build with CONFIG_NET_POLL_CONTROLLER=y
From: Anton Vorontsov @ 2009-12-09 10:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Sandeep Gopalpet, netdev, linuxppc-dev, David Miller
In-Reply-To: <1260341804.16132.22.camel@pasglop>
commit 46ceb60ca80fa07703bc6eb8f4651f900dff5a82 ("gianfar: Add
Multiple group Support") introduced the following build error
with CONFIG_NET_POLL_CONTROLLER=y:
CC ggianfar.o
ggianfar.c: In function 'gfar_netpoll':
ggianfar.c:2653: error: invalid storage class for function 'gfar_interrupt'
ggianfar.c:2652: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:2681: error: invalid storage class for function 'adjust_link'
ggianfar.c:2764: error: invalid storage class for function 'gfar_set_multi'
ggianfar.c:2855: error: invalid storage class for function 'gfar_clear_exact_match'
ggianfar.c:2877: error: invalid storage class for function 'gfar_set_hash_for_addr'
ggianfar.c:2898: error: invalid storage class for function 'gfar_set_mac_for_addr'
ggianfar.c:2922: error: invalid storage class for function 'gfar_error'
ggianfar.c:3020: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:3032: error: invalid storage class for function 'gfar_init'
ggianfar.c:3037: error: invalid storage class for function 'gfar_exit'
ggianfar.c:3041: error: initializer element is not constant
ggianfar.c:3042: error: initializer element is not constant
ggianfar.c:3042: warning: ISO C90 forbids mixed declarations and code
ggianfar.c:3042: error: expected declaration or statement at end of input
make[1]: *** [ggianfar.o] Error 1
This patch fixes the issue.
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Wed, Dec 09, 2009 at 05:56:44PM +1100, Benjamin Herrenschmidt wrote:
> In my next (not pushed out yet as I'm writing this but will be by the
> time you read it hopefully), I get a build failure:
>
> /home/benh/linux-powerpc-test/drivers/net/gianfar.c: In function ‘gfar_netpoll’:
> /home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653: error: invalid storage class for function ‘gfar_interrupt’
[...]
> make[3]: *** [drivers/net/gianfar.o] Error 1
>
> Stephen says that breakage has been in -next for some time...
>
> Can you guys sort it out ?
drivers/net/gianfar.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 16def13..6850dc0 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2644,6 +2644,7 @@ static void gfar_netpoll(struct net_device *dev)
gfar_interrupt(priv->gfargrp[i].interruptTransmit,
&priv->gfargrp[i]);
enable_irq(priv->gfargrp[i].interruptTransmit);
+ }
}
}
#endif
--
1.6.3.3
^ permalink raw reply related
* Problem in setting timeout from user space for MPC 83x watchdog timer
From: Aswathi C @ 2009-12-09 9:41 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
I am using MPC 8323E processor and linux-2.6.24 kernel.
I tried to set watchdog timer from user space using ioctl with the case
WDIOC_SETTIMEOUT.
I am getting timeout value as seconds and calculating corresponding modulus
for the WDT.
After that I am setting SWTC of SWCRR and writing service sequence to SWSRR.
But SWCNR is setting back to 0xffff after service sequence written into
SWSRR, means it is not setting with configured SWTC.
Can anyone tell what is the problem?
Please suggest solution..
Regards,
Aswathi
[-- Attachment #2: Type: text/html, Size: 561 bytes --]
^ permalink raw reply
* RE: gianfar breaking builds
From: Benjamin Herrenschmidt @ 2009-12-09 9:34 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: linuxppc-dev
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BA08A6F@zin33exm22.fsl.freescale.net>
On Wed, 2009-12-09 at 15:02 +0530, Kumar Gopalpet-B05799 wrote:
>
> I din't notice that netpoll wa enabled in your compilation.
> This is also not wotking on net-next tree.
>
> Will send out a patch today in some time.
Ah yes, this is something close to a 6xx_defconfig. Thanks.
Cheers,
Ben.
^ permalink raw reply
* RE: gianfar breaking builds
From: Kumar Gopalpet-B05799 @ 2009-12-09 9:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260350780.16132.40.camel@pasglop>
=20
>
>This is powerpc-next which contains the current Linus stuff=20
>plus the pending powerpc stuff. If that's fixed in net-next=20
>then we shall wait for Dave to merge it I suppose.
>
I din't notice that netpoll wa enabled in your compilation.
This is also not wotking on net-next tree.
Will send out a patch today in some time.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2009-12-09 9:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1260348995.16132.37.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 09/12/2009 09:56:35:
>
> On Wed, 2009-12-09 at 08:39 +0100, Joakim Tjernlund wrote:
> > The later isn't as simple :) I believe the bulk of such code in
> > entry_32.S.
>
> Yeah but it would be useful for hash I suppose if one really wants to
> boot with nobats. Though at least on hash most of the time we have ways
> to recover by mean of MSR:RI being cleared, which your TLB miss code
> doesn't check...
Never looked at this so I cannot comment.
>
> > Anyhow, the config option is still valid as if enabled
> > it will pin several DTLB's too. Scott had some concerns about removing
> > the config option completely so this was the next best thing.
>
> Well, if you want to pin at least one entry, then just remove the #if
> completely but don't leave a #if 1 :-)
I could, but I wanted to have an easy way back to the old way if
the need arises.
Anyway, I am rather busy ATM with more pressing matters so I would
appreciate if you could take the patch as is.
Jocke
^ permalink raw reply
* RE: gianfar breaking builds
From: Benjamin Herrenschmidt @ 2009-12-09 9:26 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: linuxppc-dev
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81BA08A66@zin33exm22.fsl.freescale.net>
On Wed, 2009-12-09 at 14:20 +0530, Kumar Gopalpet-B05799 wrote:
> Hi Ben,
>
> Can you point to me from where you cloned the tree.
>
> Also, net-next-2.6 tree was building for me.
This is powerpc-next which contains the current Linus stuff plus the
pending powerpc stuff. If that's fixed in net-next then we shall wait
for Dave to merge it I suppose.
Cheers,
Ben.
> --
> Thanks
> Sandeep
>
> >-----Original Message-----
> >From:
> >linuxppc-dev-bounces+sandeep.kumar=freescale.com@lists.ozlabs.o
> >rg
> >[mailto:linuxppc-dev-bounces+sandeep.kumar=freescale.com@lists.
> >ozlabs.org] On Behalf Of Benjamin Herrenschmidt
> >Sent: Wednesday, December 09, 2009 12:27 PM
> >To: Kumar Gala
> >Cc: linuxppc-dev
> >Subject: gianfar breaking builds
> >
> >In my next (not pushed out yet as I'm writing this but will be
> >by the time you read it hopefully), I get a build failure:
> >
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c: In
> >function 'gfar_netpoll':
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653:
> >error: invalid storage class for function 'gfar_interrupt'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2652:
> >warning: ISO C90 forbids mixed declarations and code
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2681:
> >error: invalid storage class for function 'adjust_link'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2764:
> >error: invalid storage class for function 'gfar_set_multi'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2855:
> >error: invalid storage class for function 'gfar_clear_exact_match'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2877:
> >error: invalid storage class for function 'gfar_set_hash_for_addr'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2898:
> >error: invalid storage class for function 'gfar_set_mac_for_addr'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2922:
> >error: invalid storage class for function 'gfar_error'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3017:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3032:
> >error: invalid storage class for function 'gfar_init'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3037:
> >error: invalid storage class for function 'gfar_exit'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:
> >error: invalid storage class for function '__inittest'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >error: invalid storage class for function '__exittest'
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >warning: ISO C90 forbids mixed declarations and code
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >warning: 'alias' attribute ignored
> >/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:
> >error: expected declaration or statement at end of input
> >make[3]: *** [drivers/net/gianfar.o] Error 1
> >
> >Stephen says that breakage has been in -next for some time...
> >
> >Can you guys sort it out ?
> >
> >Cheers,
> >Ben.
> >
> >
> >_______________________________________________
> >Linuxppc-dev mailing list
> >Linuxppc-dev@lists.ozlabs.org
> >https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
^ permalink raw reply
* Re: 2.6.33 -next tree
From: Luotao Fu @ 2009-12-09 9:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911042210q5bbbca2fi82911b7245d17588@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> Hi Ben, Stephen.
>
> I just prepared my next branch for 2.6.33:
> git://git.secretlab.ca/git/linux-2.6 next
>
Just for curiosity: I noticed that you keep so far the further patches for the
dedicated spi controller on mpc5200 in the next-spi tree. Any plan when they
will be merged to the -next tree? Like mentioned before, some of them are
essential, without which the driver doesn't work (at least on my board)
sorry for nagging. ;-)
thanks
cheers
Luotao Fu
--
Pengutronix e.K. | Dipl.-Ing. Luotao Fu |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/3] show_interrupts: use irq_chip::name if available
From: Peter Korsgaard @ 2009-12-09 9:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260349142.16132.39.camel@pasglop>
>>>>> "Benjamin" == Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
Benjamin> On Wed, 2009-12-09 at 08:32 +0100, Peter Korsgaard wrote:
>> >>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
>>
Peter> struct irq_chip::typename is going away (replaced by name). Use name if
Peter> set instead of typename in show_interrupt to make ease transition.
>>
>> Comments?
Benjamin> Hi Peter !
Benjamin> There's already a patch in my -next tree from Thomas Gleixner
Benjamin> that fixes that up along with a few others in arch/powerpc.
Ahh, ok - Hadn't noticed - Sorry.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/3] show_interrupts: use irq_chip::name if available
From: Benjamin Herrenschmidt @ 2009-12-09 8:59 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87y6lcmwkk.fsf@macbook.be.48ers.dk>
On Wed, 2009-12-09 at 08:32 +0100, Peter Korsgaard wrote:
> >>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
>
> Peter> struct irq_chip::typename is going away (replaced by name). Use name if
> Peter> set instead of typename in show_interrupt to make ease transition.
>
> Comments?
Hi Peter !
There's already a patch in my -next tree from Thomas Gleixner that fixes
that up along with a few others in arch/powerpc.
Cheers,
Ben.
> Peter> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> Peter> ---
> Peter> arch/powerpc/kernel/irq.c | 3 ++-
> Peter> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> Peter> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> Peter> index e5d1211..33e1130 100644
> Peter> --- a/arch/powerpc/kernel/irq.c
> Peter> +++ b/arch/powerpc/kernel/irq.c
> Peter> @@ -203,7 +203,8 @@ int show_interrupts(struct seq_file *p, void *v)
> Peter> seq_printf(p, "%10u ", kstat_irqs(i));
> Peter> #endif /* CONFIG_SMP */
> Peter> if (desc->chip)
> Peter> - seq_printf(p, " %s ", desc->chip->typename);
> Peter> + seq_printf(p, " %s ", desc->chip->name ?
> Peter> + desc->chip->name : desc->chip->typename);
> Peter> else
> Peter> seq_puts(p, " None ");
> Peter> seq_printf(p, "%s", (desc->status & IRQ_LEVEL) ? "Level " : "Edge ");
> Peter> --
> Peter> 1.6.5
>
>
^ permalink raw reply
* Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
From: Benjamin Herrenschmidt @ 2009-12-09 8:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OFB03B60EA.0352DA78-ONC1257687.002955A6-C1257687.002A145F@transmode.se>
On Wed, 2009-12-09 at 08:39 +0100, Joakim Tjernlund wrote:
> The later isn't as simple :) I believe the bulk of such code in
> entry_32.S.
Yeah but it would be useful for hash I suppose if one really wants to
boot with nobats. Though at least on hash most of the time we have ways
to recover by mean of MSR:RI being cleared, which your TLB miss code
doesn't check...
> Anyhow, the config option is still valid as if enabled
> it will pin several DTLB's too. Scott had some concerns about removing
> the config option completely so this was the next best thing.
Well, if you want to pin at least one entry, then just remove the #if
completely but don't leave a #if 1 :-)
Cheers,
Ben.
^ permalink raw reply
* RE: gianfar breaking builds
From: Kumar Gopalpet-B05799 @ 2009-12-09 8:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260341804.16132.22.camel@pasglop>
Hi Ben,
Can you point to me from where you cloned the tree.
Also, net-next-2.6 tree was building for me.
--
Thanks
Sandeep
>-----Original Message-----
>From:=20
>linuxppc-dev-bounces+sandeep.kumar=3Dfreescale.com@lists.ozlabs.o
>rg=20
>[mailto:linuxppc-dev-bounces+sandeep.kumar=3Dfreescale.com@lists.
>ozlabs.org] On Behalf Of Benjamin Herrenschmidt
>Sent: Wednesday, December 09, 2009 12:27 PM
>To: Kumar Gala
>Cc: linuxppc-dev
>Subject: gianfar breaking builds
>
>In my next (not pushed out yet as I'm writing this but will be=20
>by the time you read it hopefully), I get a build failure:
>
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c: In=20
>function 'gfar_netpoll':
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2653:=20
>error: invalid storage class for function 'gfar_interrupt'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2652:=20
>warning: ISO C90 forbids mixed declarations and code
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2681:=20
>error: invalid storage class for function 'adjust_link'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2764:=20
>error: invalid storage class for function 'gfar_set_multi'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2855:=20
>error: invalid storage class for function 'gfar_clear_exact_match'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2877:=20
>error: invalid storage class for function 'gfar_set_hash_for_addr'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2898:=20
>error: invalid storage class for function 'gfar_set_mac_for_addr'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:2922:=20
>error: invalid storage class for function 'gfar_error'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3017:=20
>warning: 'alias' attribute ignored
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3032:=20
>error: invalid storage class for function 'gfar_init'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3037:=20
>error: invalid storage class for function 'gfar_exit'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:=20
>error: invalid storage class for function '__inittest'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3041:=20
>warning: 'alias' attribute ignored
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>error: invalid storage class for function '__exittest'
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>warning: ISO C90 forbids mixed declarations and code
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>warning: 'alias' attribute ignored
>/home/benh/linux-powerpc-test/drivers/net/gianfar.c:3042:=20
>error: expected declaration or statement at end of input
>make[3]: *** [drivers/net/gianfar.o] Error 1
>
>Stephen says that breakage has been in -next for some time...
>
>Can you guys sort it out ?
>
>Cheers,
>Ben.
>
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2009-12-09 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1260332399.16132.7.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 09/12/2009 05:19:59:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> To: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Cc: Scott Wood <scottwood@freescale.com>, "linuxppc-dev@ozlabs.org" <linuxppc-
> dev@ozlabs.org>, Rex Feany <RFeany@mrv.com>
> Date: 09/12/2009 05:20
> Subject: Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB
>
> On Fri, 2009-11-20 at 11:21 +0100, Joakim Tjernlund wrote:
> > Various kernel asm modifies SRR0/SRR1 just before executing
> > a rfi. If such code crosses a page boundary you risk a TLB miss
> > which will clobber SRR0/SRR1. Avoid this by always pinning
> > kernel instruction TLB space.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > ---
> > arch/powerpc/kernel/head_8xx.S | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
> > index a9f1ace..e70503d 100644
> > --- a/arch/powerpc/kernel/head_8xx.S
> > +++ b/arch/powerpc/kernel/head_8xx.S
> > @@ -705,7 +705,7 @@ start_here:
> > */
> > initial_mmu:
> > tlbia /* Invalidate all TLB entries */
> > -#ifdef CONFIG_PIN_TLB
> > +#if 1 /* CONFIG_PIN_TLB */
> > lis r8, MI_RSV4I@h
> > ori r8, r8, 0x1c00
> > #else
>
> Not nice. Either remove the config option or make sure all those code
> sequences are appropriately aligned so it doesn't happen. I recommend
> the later :-)
The later isn't as simple :) I believe the bulk of such code in entry_32.S.
Anyhow, the config option is still valid as if enabled
it will pin several DTLB's too. Scott had some concerns about removing the
config option completely so this was the next best thing.
>
> I'll apply the other patches.
OK, great.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox