* Re: [PATCH] ucc_geth: Add support for skb recycling
From: Anton Vorontsov @ 2009-07-07 20:37 UTC (permalink / raw)
To: Rick Jones
Cc: netdev, linuxppc-dev, Andy Fleming, Li Yang, David Miller,
Lennert Buytenhek
In-Reply-To: <4A53984A.4050002@hp.com>
On Tue, Jul 07, 2009 at 11:47:38AM -0700, Rick Jones wrote:
> Anton Vorontsov wrote:
> >We can reclaim transmitted skbs to use in the receive path, so-called
> >skb recycling support.
> >
> >Also reorder ucc_geth_poll() steps, so that we'll clean tx ring firstly,
> >thus maybe reclaim some skbs for rx.
>
> Admittedly, all the world is not TCP, but a big chunk is, so are you
> likely to have reference counts go to zero on the tx queue for
> anything other than small standalone TCP ACK segments?
That's a generic question wrt skb recycling, right? Whether we can
always recycle transmitted skbs. No, sometimes (or mostly) we can't.
Initially, I was quite puzzled by this support... looking at how
gianfar driver works (it has the same support as of 0fd56bb5be6455d0),
I noticed that skb_recycle_check() always returns 0, and so we
don't recycle the skbs.
Though, things change when the kernel starts packets forwarding,
*then* skb recycling path actually triggers.
Lennert (skb recycling author) hints us that the gain is indeed
in forwarding/routing workload:
http://kerneltrap.org/mailarchive/linux-netdev/2008/9/28/3433514
Hope I understood everything correctly. :-)
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] ucc_geth: Add support for skb recycling
From: Rick Jones @ 2009-07-07 18:47 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev, Li Yang, Andy Fleming, David Miller, linuxppc-dev
In-Reply-To: <20090707183842.GA8425@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> We can reclaim transmitted skbs to use in the receive path, so-called
> skb recycling support.
>
> Also reorder ucc_geth_poll() steps, so that we'll clean tx ring firstly,
> thus maybe reclaim some skbs for rx.
Admittedly, all the world is not TCP, but a big chunk is, so are you likely to
have reference counts go to zero on the tx queue for anything other than small
standalone TCP ACK segments?
rick jones
^ permalink raw reply
* [PATCH] ucc_geth: Add support for skb recycling
From: Anton Vorontsov @ 2009-07-07 18:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Li Yang, Andy Fleming, linuxppc-dev
We can reclaim transmitted skbs to use in the receive path, so-called
skb recycling support.
Also reorder ucc_geth_poll() steps, so that we'll clean tx ring firstly,
thus maybe reclaim some skbs for rx.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 40 ++++++++++++++++++++++++++++------------
drivers/net/ucc_geth.h | 2 ++
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 40c6eba..beaa329 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -209,9 +209,10 @@ static struct sk_buff *get_new_skb(struct ucc_geth_private *ugeth,
{
struct sk_buff *skb = NULL;
- skb = dev_alloc_skb(ugeth->ug_info->uf_info.max_rx_buf_length +
- UCC_GETH_RX_DATA_BUF_ALIGNMENT);
-
+ skb = __skb_dequeue(&ugeth->rx_recycle);
+ if (!skb)
+ skb = dev_alloc_skb(ugeth->ug_info->uf_info.max_rx_buf_length +
+ UCC_GETH_RX_DATA_BUF_ALIGNMENT);
if (skb == NULL)
return NULL;
@@ -1986,6 +1987,8 @@ static void ucc_geth_memclean(struct ucc_geth_private *ugeth)
iounmap(ugeth->ug_regs);
ugeth->ug_regs = NULL;
}
+
+ skb_queue_purge(&ugeth->rx_recycle);
}
static void ucc_geth_set_multi(struct net_device *dev)
@@ -2202,6 +2205,8 @@ static int ucc_struct_init(struct ucc_geth_private *ugeth)
return -ENOMEM;
}
+ skb_queue_head_init(&ugeth->rx_recycle);
+
return 0;
}
@@ -3208,8 +3213,10 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
if (netif_msg_rx_err(ugeth))
ugeth_err("%s, %d: ERROR!!! skb - 0x%08x",
__func__, __LINE__, (u32) skb);
- if (skb)
- dev_kfree_skb_any(skb);
+ if (skb) {
+ skb->data = skb->head + NET_SKB_PAD;
+ __skb_queue_head(&ugeth->rx_recycle, skb);
+ }
ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = NULL;
dev->stats.rx_dropped++;
@@ -3267,6 +3274,8 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
/* Normal processing. */
while ((bd_status & T_R) == 0) {
+ struct sk_buff *skb;
+
/* BD contains already transmitted buffer. */
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
@@ -3276,9 +3285,16 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
dev->stats.tx_packets++;
- /* Free the sk buffer associated with this TxBD */
- dev_kfree_skb(ugeth->
- tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
+ skb = ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
+
+ if (skb_queue_len(&ugeth->rx_recycle) < RX_BD_RING_LEN &&
+ skb_recycle_check(skb,
+ ugeth->ug_info->uf_info.max_rx_buf_length +
+ UCC_GETH_RX_DATA_BUF_ALIGNMENT))
+ __skb_queue_head(&ugeth->rx_recycle, skb);
+ else
+ dev_kfree_skb(skb);
+
ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]] = NULL;
ugeth->skb_dirtytx[txQ] =
(ugeth->skb_dirtytx[txQ] +
@@ -3307,16 +3323,16 @@ static int ucc_geth_poll(struct napi_struct *napi, int budget)
ug_info = ugeth->ug_info;
- howmany = 0;
- for (i = 0; i < ug_info->numQueuesRx; i++)
- howmany += ucc_geth_rx(ugeth, i, budget - howmany);
-
/* Tx event processing */
spin_lock(&ugeth->lock);
for (i = 0; i < ug_info->numQueuesTx; i++)
ucc_geth_tx(ugeth->ndev, i);
spin_unlock(&ugeth->lock);
+ howmany = 0;
+ for (i = 0; i < ug_info->numQueuesRx; i++)
+ howmany += ucc_geth_rx(ugeth, i, budget - howmany);
+
if (howmany < budget) {
napi_complete(napi);
setbits32(ugeth->uccf->p_uccm, UCCE_RX_EVENTS | UCCE_TX_EVENTS);
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 195ab26..cfb31af 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1212,6 +1212,8 @@ struct ucc_geth_private {
/* index of the first skb which hasn't been transmitted yet. */
u16 skb_dirtytx[NUM_TX_QUEUES];
+ struct sk_buff_head rx_recycle;
+
struct ugeth_mii_info *mii_info;
struct phy_device *phydev;
phy_interface_t phy_interface;
--
1.6.3.3
^ permalink raw reply related
* Re: MTD OF parser problem
From: Scott Wood @ 2009-07-07 17:31 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <200907071545.30121.roman.fietze@telemotive.de>
On Tue, Jul 07, 2009 at 03:45:29PM +0200, Roman Fietze wrote:
> Hallo,
>
> I tried to define my MTD partitions in a device tree as
> documented. The function of_flash_probe() inside teh file physmap_of.c
> never compiled the code below
>
> #ifdef CONFIG_MTD_OF_PARTS
>
> because when the MTD subsystem is compiled as a module I can only find
> CONFIG_MTD_OF_PARTS_MODULE beeing defined somewhere below my build
> directory.
>
> If I change the above define to
>
> #if defined(CONFIG_MTD_OF_PARTS) || defined(CONFIG_MTD_OF_PARTS_MODULE)
>
> everything is fine and MTD partition work as expected.
>
> My fault? Other solution?
That would break if MTD_PHYSMAP_OF (or any other user) is built-in but
MTD_OF_PARTS is a module.
Perhaps there's some way we could hook OF partitions into the normal
partition probing, so we don't have to refer to it by symbol? The main
obstacle would be communicating the device node.
Or we could just disallow MTD_OF_PARTS from being modularized -- like
MTD_PARTITIONS.
-Scott
^ permalink raw reply
* Re: dma_ops->map_page == NULL
From: Kumar Gala @ 2009-07-07 15:45 UTC (permalink / raw)
To: Kári Davíðsson
Cc: Mark Nelson, linuxppc-dev@ozlabs.org, Kumar Gala
In-Reply-To: <4A5368C7.9020202@marel.com>
On Jul 7, 2009, at 10:24 AM, K=E1ri Dav=ED=F0sson wrote:
> Yes the device pointer was invalid.
>
> I was passing the of_device pointer instead of
> the address of of_device->dev.
>
> But I am sure this was working (passing of_device pointer) with
> earlier kernels.
>
> Thanks for the help.
>
> rg
> kd
earlier kernels didn't care if the dev pointer was valid and thus let =20=
it pass if you didn't give the proper thing.
- k=
^ permalink raw reply
* Re: Chipselect in SPI binding with mpc5200-psc-spi
From: Grant Likely @ 2009-07-07 15:57 UTC (permalink / raw)
To: Henk Stegeman; +Cc: linuxppc-dev
In-Reply-To: <ae4f76fd0907070731p473fef56wdd410db43f6c4c8a@mail.gmail.com>
On Tue, Jul 7, 2009 at 8:31 AM, Henk Stegeman<henk.stegeman@gmail.com> wrot=
e:
> I tried to make use of the irq-controller mode of the GPT as
> suggested, however I'm not getting the IRQ.
> Does anyone have an idea what I could be missing? (I've been testing
> with 2.6.30).
Make sure the 5200 general purpose timer driver is compiled in (not a modul=
e).
>
>
> The driver reports from it's probe:
> [ =A0 =A01.502853] spi_master spi32766.0 Unable to get sample IRQ from of
>
> My driver has:
> =A0 =A0 =A0 =A0pdata->sample_irq =3D irq_of_parse_and_map(np, 0);
> =A0 =A0 =A0 =A0if (pdata->sample_irq =3D=3D NO_IRQ) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D pdata->sample_irq;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_err(dev, "Unable to get sample IRQ fro=
m of\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0..
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
>
> My dts has:
> =A0 =A0 =A0 =A0gpt6: timer@660 { =A0 =A0 =A0 // General Purpose Timer GPT=
6 in GPIO mode for
> SMC4000IO sample irq.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-controller;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#interrupt-cells =3D <1>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc5200b-gpt","fsl,mpc=
5200-gpt";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x660 0x10>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <1 15 0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <&mpc5200_pic>;
> =A0 =A0 =A0 =A0};
>
>
> =A0 =A0 =A0 =A0io-controller@0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "microkey,smc4000io";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0linux,modalias =3D "of_smc4000io";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spi-max-frequency =3D <800000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spi-cpha;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0word-delay-us =3D <30>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-controller =3D <&gpt6>; // Use G=
PT6 as the IRQ controller
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <2>; // And make it edge fa=
lling
> =A0 =A0 =A0 =A0};
>
>
> Thanks in advance,
>
> Henk.
>
> On Fri, Feb 13, 2009 at 5:19 PM, Grant Likely<grant.likely@secretlab.ca> =
wrote:
>> On Fri, Feb 13, 2009 at 3:40 AM, Henk Stegeman <henk.stegeman@gmail.com>=
wrote:
>>> I'm busy adding support for slave deviced behind mpc52xx-psc-spi.
>>> One complication I have is that my SPI slave device has an interrupt ou=
tput
>>> to the CPU.
>>> My idea is to add it as a gpios property in the slave device's
>>> configuration:
>>>
>>> =A0 =A0 =A0 =A0 spi@2400 { =A0 =A0 =A0 =A0// PSC3 (SPI IF to the IO-con=
troller )
>>> =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "spi";
>>> =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <0>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,mpc5200-psc-spi","fsl,mpc52=
00b-psc-spi";
>>> =A0 =A0 =A0 =A0 =A0 =A0 cell-index =3D <2>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x2400 0x100>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 interrupts =3D <2 3 0>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 interrupt-parent =3D <&mpc5200_pic>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 gpios =3D <&gpt4 0 0>;
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 io-controller@0 {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "microkey,smc4000io";
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spi-max-frequency =3D <1000000>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // gpios: first is IRQ to cpu
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gpios =3D <&gpt6 0 0>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 };
>>
>> There is a better way to do this, and driver support for it is
>> currently merged into Ben Herrenschmidt's -next tree.
>>
>> Do this instead:
>> =A0 =A0 =A0 =A0io-controller@0 {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "microkey,smc4000io";
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spi-max-frequency =3D <1000000>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-controller =3D < &gpt6 >; =A0 =
=A0 // Use GPT6 as
>> the IRQ controller
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D < 1 >; =A0 =A0// And make =
it rising edge.
>> =A0 =A0 =A0 =A0};
>>
>> Then add these two properties to the GPT node:
>>
>> =A0 =A0 =A0 =A0interrupt-controller;
>> =A0 =A0 =A0 =A0#interrupt-cells =3D <1>;
>>
>> Then you can use normal irq_of_parse_and_map() to set up your handler.
>>
>>> How should I then register my spi slave driver? My smc4000io_probe func=
tion
>>> gets called correctly by of_spi support but when I register as follows:
>>>
>>> static struct spi_driver smc4000io_driver =3D {
>>> =A0 =A0 .driver =3D {
>>> =A0 =A0 =A0 =A0 .name =A0 =A0=3D "smc4000io",
>>> =A0 =A0 =A0 =A0 .bus =A0 =A0=3D &spi_bus_type,
>>> =A0 =A0 =A0 =A0 .owner =A0 =A0=3D THIS_MODULE,
>>> =A0 =A0 },
>>> =A0 =A0 .probe =A0 =A0 =A0 =A0=3D smc4000io_probe,
>>> =A0 =A0 .remove =A0 =A0 =A0 =A0=3D __devexit_p(smc4000io_remove),
>>> };
>>>
>>> static int __init smc4000io_init(void)
>>> {
>>> =A0 =A0 return spi_register_driver(&smc4000io_driver);
>>> }
>>>
>>> static void __exit smc4000io_exit(void)
>>> {
>>> =A0 =A0 spi_unregister_driver(&smc4000io_driver);
>>> }
>>>
>>> module_init(smc4000io_init);
>>
>> Yes, this is right. =A0The psc_spi driver automatically registers all
>> spi children that it finds in the device tree onto the SPI bus.
>> Therefore registering an spi_driver() is the right thing to do.
>>
>>> But when I do:
>>>
>>> static struct of_platform_driver smc4000_spi_of_driver =3D {
>>> =A0 =A0 .name =3D "smc4000io",
>>> =A0 =A0 .match_table =3D smc4000io_of_match,
>>> =A0 =A0 .probe =3D smc4000io_of_probe,
>>> =A0 =A0 .remove =A0 =A0 =A0 =A0=3D __devexit_p(smc4000io_of_remove),
>>> };
>>>
>>> static int __init smc4000io_init(void)
>>> {
>>> =A0 =A0 return of_register_platform_driver(&smc4000_spi_of_driver);
>>> }
>>> module_init(smc4000io_init);
>>>
>>> Then my smc4000io_of_probe function never gets called.
>>
>> Correct. =A0of_platform_driver isn't useful in this case because the
>> device cannot exist independently of the SPI bus. =A0Plus an
>> of_platform_device doesn't provide any information about the SPI bus
>> itself.
>>
>> g.
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: dma_ops->map_page == NULL
From: Becky Bruce @ 2009-07-07 15:49 UTC (permalink / raw)
To: Kumar Gala
Cc: Mark Nelson, Kári Davíðsson, Kumar Gala,
linuxppc-dev@ozlabs.org
In-Reply-To: <A0ABEB1B-3A7A-4068-88EC-33D6D663C87A@kernel.crashing.org>
On Jul 7, 2009, at 9:37 AM, Kumar Gala wrote:
>
> On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>>>
>>> When the 32 and 64bit DMA code was merged in .28 , map_/
>>> unmap_page() was
>>> added in favour of map_/unmap_single() (which was later removed
>>> in .29)
>>> so you'll have to replace your calls to dma_map_single() with
>>> dma_map_page(). Just pass it the page and offset rather than the
>>> address.
>>
>> Wait a minute ... dma_map_single() should still work, it will just
>> call
>> dma_map_page() underneath. All dma_ops should have a ->map page
>> callback.
>>
>>
>> Do you have any dma_ops set for your device at all ? I wonder how we
>> set the dma_ops for platform devices nowadays ... We use to have this
>> fallback to direct ops when the dma_ops are NULL but that is gone and
>> I see no suitable replacement to set them on platform devices for
>> embedded archs ... oops...
There is a platform/of bus notifier that sets the dma_ops to a default
value in arch/powerpc/kernel/setup-common.c.
>>
>>
>> Kumar, Becky, what's the situation there ?
>>
>> Cheers,
>> Ben.
>
> Is it possible the dev pointer is not valid? I can't remember if
> that was a .29 or .30 change that requires us to start passing a
> valid dev pointer to get the proper dma_ops.
I'm pretty sure that went into .29. And invalid dev pointer is the
most likely culprit. IIRC, the usual cause of this is that you're
passing in the *wrong* dev pointer. There are often struct
hierarchies with, confusingly, multiple struct device pointers. You
need the one which has archdata dma_ops setup properly. For an of
device, you want the dev pointer that is part of the of_device struct.
If this isn't your problem, then please post some code so we can look
at this further, and post a log of what's happening.
Cheers,
Becky
^ permalink raw reply
* Re: dma_ops->map_page == NULL
From: Kári Davíðsson @ 2009-07-07 15:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: Mark Nelson, linuxppc-dev@ozlabs.org, Kumar Gala
In-Reply-To: <A0ABEB1B-3A7A-4068-88EC-33D6D663C87A@kernel.crashing.org>
Yes the device pointer was invalid.
I was passing the of_device pointer instead of
the address of of_device->dev.
But I am sure this was working (passing of_device pointer) with
earlier kernels.
Thanks for the help.
rg
kd
Kumar Gala wrote:
> On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>>> When the 32 and 64bit DMA code was merged in .28 , map_/
>>> unmap_page() was
>>> added in favour of map_/unmap_single() (which was later removed in .
>>> 29)
>>> so you'll have to replace your calls to dma_map_single() with
>>> dma_map_page(). Just pass it the page and offset rather than the
>>> address.
>> Wait a minute ... dma_map_single() should still work, it will just
>> call
>> dma_map_page() underneath. All dma_ops should have a ->map page
>> callback.
>>
>> Do you have any dma_ops set for your device at all ? I wonder how we
>> set the dma_ops for platform devices nowadays ... We use to have this
>> fallback to direct ops when the dma_ops are NULL but that is gone and
>> I see no suitable replacement to set them on platform devices for
>> embedded archs ... oops...
>>
>> Kumar, Becky, what's the situation there ?
>>
>> Cheers,
>> Ben.
>
> Is it possible the dev pointer is not valid? I can't remember if that
> was a .29 or .30 change that requires us to start passing a valid dev
> pointer to get the proper dma_ops.
>
> - k
^ permalink raw reply
* Re: [PATCH] net: fix OF fixed-link property handling on Freescale network device drivers
From: Anton Vorontsov @ 2009-07-07 15:12 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, leoli, afleming, davem, linuxppc-dev
In-Reply-To: <20090703221851.23909.923.stgit@localhost.localdomain>
On Fri, Jul 03, 2009 at 04:20:19PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> The MDIO rework patches broke the handling of fixed MII links.
[...]
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Anton, can you please review, comment and test? I've tested it on an
> mpc8349 board, but that is the only hardware that I have. I've also
> probably made mistakes and it needs to be split up into separate patches,
> but this is probably a sufficient form for first review. I'll also give
> it another once over tomorrow when after I've had a decent night sleep.
fs_enet this time...
[..]
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index b892c3a..39244b2 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -722,8 +722,6 @@ static void generic_adjust_link(struct net_device *dev)
> } else if (fep->oldlink) {
> new_state = 1;
> fep->oldlink = 0;
> - fep->oldspeed = 0;
> - fep->oldduplex = -1;
> }
>
> if (new_state && netif_msg_link(fep))
> @@ -749,25 +747,21 @@ static void fs_adjust_link(struct net_device *dev)
> static int fs_init_phy(struct net_device *dev)
> {
> struct fs_enet_private *fep = netdev_priv(dev);
> - struct phy_device *phydev;
>
> - fep->oldlink = 0;
> - fep->oldspeed = 0;
> - fep->oldduplex = -1;
> + /* If a link is already flagged, then set up initial state */
> + if (fep->oldlink) {
> + netif_carrier_on(dev);
> + fep->ops->restart(dev);
->restart() will dereference phydev, which is NULL.
grep for 'phydev' in fs_enet/mac-*.c.
Unable to handle kernel paging request for data at address 0x000000d0
Faulting instruction address: 0xc01842cc
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [c01842cc] restart+0x3ac/0x434
LR [c0184260] restart+0x340/0x434
Call Trace:
[c3825e60] [c0184260] restart+0x340/0x434 (unreliable)
[c3825e80] [c018231c] fs_init_phy+0x3c/0xbc
[c3825e90] [c01838a4] fs_enet_open+0x110/0x1cc
[c3825eb0] [c01b19b0] dev_open+0xcc/0x130
[c3825ed0] [c01b0100] dev_change_flags+0xb8/0x18c
[c3825ef0] [c030c4e4] ic_open_devs+0x188/0x284
[c3825f30] [c030d770] ip_auto_config+0x7c/0x278
[c3825f60] [c000393c] do_one_initcall+0x58/0x19c
[c3825fd0] [c02f62e4] do_initcalls+0x30/0x50
[c3825fe0] [c02f6374] kernel_init+0x38/0x94
[c3825ff0] [c0010824] kernel_thread+0x4c/0x68
Instruction dump:
901e0004 801c0060 2f800000 419e0020 7c0004ac 801e0004 0c000000 4c00012c
64000002 7c0004ac 901e0004 813d0110 <800900d0> 2f800000 419e0024 7c0004ac
---[ end trace 1ae193a95823d5e4 ]---
And the same comment regarding link speed/duplex reporting for
userspace:
# ethtool eth1
Settings for eth1:
Cannot get device settings: No such device
Current message level: 0x00000000 (0)
Link detected: yes
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Chipselect in SPI binding with mpc5200-psc-spi
From: Henk Stegeman @ 2009-07-07 14:31 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev
In-Reply-To: <fa686aa40902130719k1d16f936o4776cff371db16ae@mail.gmail.com>
I tried to make use of the irq-controller mode of the GPT as
suggested, however I'm not getting the IRQ.
Does anyone have an idea what I could be missing? (I've been testing
with 2.6.30).
The driver reports from it's probe:
[ 1.502853] spi_master spi32766.0 Unable to get sample IRQ from of
My driver has:
pdata->sample_irq =3D irq_of_parse_and_map(np, 0);
if (pdata->sample_irq =3D=3D NO_IRQ) {
ret =3D pdata->sample_irq;
dev_err(dev, "Unable to get sample IRQ from of\n");
..
}
My dts has:
gpt6: timer@660 { // General Purpose Timer GPT6 in GPIO mode for
SMC4000IO sample irq.
interrupt-controller;
#interrupt-cells =3D <1>;
compatible =3D "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
reg =3D <0x660 0x10>;
interrupts =3D <1 15 0>;
interrupt-parent =3D <&mpc5200_pic>;
};
io-controller@0 {
compatible =3D "microkey,smc4000io";
linux,modalias =3D "of_smc4000io";
spi-max-frequency =3D <800000>;
spi-cpha;
reg =3D <0>;
word-delay-us =3D <30>;
interrupt-controller =3D <&gpt6>; // Use GPT6 as the IRQ controller
interrupts =3D <2>; // And make it edge falling
};
Thanks in advance,
Henk.
On Fri, Feb 13, 2009 at 5:19 PM, Grant Likely<grant.likely@secretlab.ca> wr=
ote:
> On Fri, Feb 13, 2009 at 3:40 AM, Henk Stegeman <henk.stegeman@gmail.com> =
wrote:
>> I'm busy adding support for slave deviced behind mpc52xx-psc-spi.
>> One complication I have is that my SPI slave device has an interrupt out=
put
>> to the CPU.
>> My idea is to add it as a gpios property in the slave device's
>> configuration:
>>
>> =A0 =A0 =A0 =A0 spi@2400 { =A0 =A0 =A0 =A0// PSC3 (SPI IF to the IO-cont=
roller )
>> =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "spi";
>> =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
>> =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <0>;
>> =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,mpc5200-psc-spi","fsl,mpc520=
0b-psc-spi";
>> =A0 =A0 =A0 =A0 =A0 =A0 cell-index =3D <2>;
>> =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x2400 0x100>;
>> =A0 =A0 =A0 =A0 =A0 =A0 interrupts =3D <2 3 0>;
>> =A0 =A0 =A0 =A0 =A0 =A0 interrupt-parent =3D <&mpc5200_pic>;
>> =A0 =A0 =A0 =A0 =A0 =A0 gpios =3D <&gpt4 0 0>;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 io-controller@0 {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "microkey,smc4000io";
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spi-max-frequency =3D <1000000>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // gpios: first is IRQ to cpu
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 gpios =3D <&gpt6 0 0>;
>> =A0 =A0 =A0 =A0 =A0 =A0 };
>
> There is a better way to do this, and driver support for it is
> currently merged into Ben Herrenschmidt's -next tree.
>
> Do this instead:
> =A0 =A0 =A0 =A0io-controller@0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "microkey,smc4000io";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spi-max-frequency =3D <1000000>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-controller =3D < &gpt6 >; =A0 =
=A0 // Use GPT6 as
> the IRQ controller
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D < 1 >; =A0 =A0// And make i=
t rising edge.
> =A0 =A0 =A0 =A0};
>
> Then add these two properties to the GPT node:
>
> =A0 =A0 =A0 =A0interrupt-controller;
> =A0 =A0 =A0 =A0#interrupt-cells =3D <1>;
>
> Then you can use normal irq_of_parse_and_map() to set up your handler.
>
>> How should I then register my spi slave driver? My smc4000io_probe funct=
ion
>> gets called correctly by of_spi support but when I register as follows:
>>
>> static struct spi_driver smc4000io_driver =3D {
>> =A0 =A0 .driver =3D {
>> =A0 =A0 =A0 =A0 .name =A0 =A0=3D "smc4000io",
>> =A0 =A0 =A0 =A0 .bus =A0 =A0=3D &spi_bus_type,
>> =A0 =A0 =A0 =A0 .owner =A0 =A0=3D THIS_MODULE,
>> =A0 =A0 },
>> =A0 =A0 .probe =A0 =A0 =A0 =A0=3D smc4000io_probe,
>> =A0 =A0 .remove =A0 =A0 =A0 =A0=3D __devexit_p(smc4000io_remove),
>> };
>>
>> static int __init smc4000io_init(void)
>> {
>> =A0 =A0 return spi_register_driver(&smc4000io_driver);
>> }
>>
>> static void __exit smc4000io_exit(void)
>> {
>> =A0 =A0 spi_unregister_driver(&smc4000io_driver);
>> }
>>
>> module_init(smc4000io_init);
>
> Yes, this is right. =A0The psc_spi driver automatically registers all
> spi children that it finds in the device tree onto the SPI bus.
> Therefore registering an spi_driver() is the right thing to do.
>
>> But when I do:
>>
>> static struct of_platform_driver smc4000_spi_of_driver =3D {
>> =A0 =A0 .name =3D "smc4000io",
>> =A0 =A0 .match_table =3D smc4000io_of_match,
>> =A0 =A0 .probe =3D smc4000io_of_probe,
>> =A0 =A0 .remove =A0 =A0 =A0 =A0=3D __devexit_p(smc4000io_of_remove),
>> };
>>
>> static int __init smc4000io_init(void)
>> {
>> =A0 =A0 return of_register_platform_driver(&smc4000_spi_of_driver);
>> }
>> module_init(smc4000io_init);
>>
>> Then my smc4000io_of_probe function never gets called.
>
> Correct. =A0of_platform_driver isn't useful in this case because the
> device cannot exist independently of the SPI bus. =A0Plus an
> of_platform_device doesn't provide any information about the SPI bus
> itself.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
^ permalink raw reply
* Re: dma_ops->map_page == NULL
From: Kumar Gala @ 2009-07-07 14:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mark Nelson, Kári Davíðsson, Kumar Gala,
linuxppc-dev@ozlabs.org
In-Reply-To: <1246964905.6066.41.camel@pasglop>
On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>>
>> When the 32 and 64bit DMA code was merged in .28 , map_/
>> unmap_page() was
>> added in favour of map_/unmap_single() (which was later removed in .
>> 29)
>> so you'll have to replace your calls to dma_map_single() with
>> dma_map_page(). Just pass it the page and offset rather than the
>> address.
>
> Wait a minute ... dma_map_single() should still work, it will just
> call
> dma_map_page() underneath. All dma_ops should have a ->map page
> callback.
>
> Do you have any dma_ops set for your device at all ? I wonder how we
> set the dma_ops for platform devices nowadays ... We use to have this
> fallback to direct ops when the dma_ops are NULL but that is gone and
> I see no suitable replacement to set them on platform devices for
> embedded archs ... oops...
>
> Kumar, Becky, what's the situation there ?
>
> Cheers,
> Ben.
Is it possible the dev pointer is not valid? I can't remember if that
was a .29 or .30 change that requires us to start passing a valid dev
pointer to get the proper dma_ops.
- k
^ permalink raw reply
* Re: [PATCH] net: fix OF fixed-link property handling on Freescale network device drivers
From: Anton Vorontsov @ 2009-07-07 14:35 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, leoli, afleming, davem, linuxppc-dev
In-Reply-To: <20090703221851.23909.923.stgit@localhost.localdomain>
On Fri, Jul 03, 2009 at 04:20:19PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> The MDIO rework patches broke the handling of fixed MII links.
[...]
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Anton, can you please review, comment and test? I've tested it on an
> mpc8349 board, but that is the only hardware that I have. I've also
> probably made mistakes and it needs to be split up into separate patches,
> but this is probably a sufficient form for first review. I'll also give
> it another once over tomorrow when after I've had a decent night sleep.
Did some tests for ucc geth...
Will get to fs_enet a bit later.
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 40c6eba..c216cd5 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -1443,6 +1443,53 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
> return 0;
> }
>
> +static void ugeth_set_link(struct net_device *dev)
> +{
> + struct ucc_geth_private *ugeth = netdev_priv(dev);
> + struct phy_device *phydev = ugeth->phydev;
> + struct ucc_geth __iomem *ug_regs = ugeth->ug_regs;
> + struct ucc_fast __iomem *uf_regs = ugeth->uccf->uf_regs;
In fixed-link case you'll call set_link() before ucc_struct_init,
so these *_regs are NULL, following oops pops up:
Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xc01d6228
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [c01d6228] ugeth_set_link+0x20/0x158
LR [c01d723c] init_phy+0xa8/0xdc
Call Trace:
[cf831e40] [84042028] 0x84042028 (unreliable)
[cf831e60] [c01d723c] init_phy+0xa8/0xdc
[cf831e80] [c01d8fb8] ucc_geth_open+0x2c/0x2b0
[cf831ea0] [c02040a8] dev_open+0xfc/0x134
[cf831ec0] [c0202670] dev_change_flags+0x84/0x1ac
[cf831ee0] [c03b0cfc] ic_open_devs+0x168/0x2cc
[cf831f20] [c03b20f8] ip_auto_config+0x90/0x2a4
[cf831f60] [c0003894] do_one_initcall+0x34/0x1a8
[cf831fd0] [c03922f8] do_initcalls+0x38/0x58
[cf831fe0] [c0392388] kernel_init+0x38/0x98
[cf831ff0] [c0011b78] kernel_thread+0x4c/0x68
> + u32 tempval = in_be32(&ug_regs->maccfg2);
> + u32 upsmr = in_be32(&uf_regs->upsmr);
[...]
> + default:
> + if (netif_msg_link(ugeth))
> + ugeth_warn("%s: Ack! Speed (%d) is not 10/100/1000!",
> + dev->name, phydev->speed);
You may dereference NULL here.
> + break;
> + }
> +
> + out_be32(&ug_regs->maccfg2, tempval);
(while you're at it, maybe s/tempval/maccfg2/ ?)
> + out_be32(&uf_regs->upsmr, upsmr);
> +}
> +
[...]
> @@ -3708,15 +3710,19 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
>
> ug_info->uf_info.regs = res.start;
> ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
> - fixed_link = of_get_property(np, "fixed-link", NULL);
> - if (fixed_link) {
> - phy = NULL;
> - } else {
> - phy = of_parse_phandle(np, "phy-handle", 0);
> - if (phy == NULL)
> - return -ENODEV;
> +
> + /* Setup the initial link state */
> + prop = of_get_property(np, "fixed-link", &prop_sz);
> + if (prop && prop_sz >= sizeof(*prop) * 3) {
> + ugeth->oldlink = 1;
'ugeth' is NULL at this point, causes this:
Unable to handle kernel paging request for data at address 0x000002c4
Faulting instruction address: 0xc01da0d8
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [c01da0d8] ucc_geth_probe+0x218/0x530
LR [c01da0c0] ucc_geth_probe+0x200/0x530
Call Trace:
[cf831e00] [c01da0c0] ucc_geth_probe+0x200/0x530 (unreliable)
[cf831e60] [c01eddc4] of_platform_device_probe+0x5c/0x84
[cf831e80] [c019bfd4] really_probe+0x78/0x1a0
[cf831ea0] [c019c1c4] __driver_attach+0xa4/0xa8
[cf831ec0] [c019b3ec] bus_for_each_dev+0x60/0x9c
[cf831ef0] [c019be18] driver_attach+0x24/0x34
[cf831f00] [c019badc] bus_add_driver+0xb4/0x1c4
> + ugeth->oldduplex = prop[1];
> + ugeth->oldspeed = prop[2];
> }
> - ug_info->phy_node = phy;
> +
> + /* Find the phy. Bail if there is no phy and no initial link speed */
> + ug_info->phy_node = of_parse_phandle(np, "phy-handle", 0);
> + if (!ug_info->phy_node && !ugeth->oldlink)
> + return -ENODEV;
>
> /* Find the TBI PHY node. If it's not there, we don't support SGMII */
> ug_info->tbi_node = of_parse_phandle(np, "tbi-handle", 0);
> @@ -3725,7 +3731,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
> prop = of_get_property(np, "phy-connection-type", NULL);
> if (!prop) {
> /* handle interface property present in old trees */
> - prop = of_get_property(phy, "interface", NULL);
> + prop = of_get_property(ug_info->phy_node, "interface", NULL);
> if (prop != NULL) {
> phy_interface = enet_to_phy_interface[*prop];
> max_speed = enet_to_speed[*prop];
>
There is another oops, if interface is down:
# ethtool -S eth1
Unable to handle kernel paging request for data at address 0x00000180
Faulting instruction address: 0xc01da7f4
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [c01da7f4] uec_get_ethtool_stats+0x3c/0x14c
LR [c0207484] ethtool_get_stats+0xfc/0x23c
Call Trace:
[cfb2ddf0] [c0207464] ethtool_get_stats+0xdc/0x23c (unreliable)
[cfb2de30] [c0207b24] dev_ethtool+0x324/0x5a8
[cfb2de60] [c0204ad4] dev_ioctl+0x290/0x320
[cfb2deb0] [c01ef9ac] sock_ioctl+0x80/0x2f4
[cfb2ded0] [c0090814] vfs_ioctl+0x34/0x98
[cfb2dee0] [c009103c] do_vfs_ioctl+0x84/0x2cc
[cfb2df10] [c00912c4] sys_ioctl+0x40/0x74
[cfb2df40] [c0011d54] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff64820
LR = 0xffec848
Instruction dump:
80c901b8 70c00001 41820058 8123004c 7cab2b78 39000000 38000000 38e90180
39200012 7d2903a6 5400103a 7c0004ac <7d27002e> 0c090000 4c00012c 7d2a4b78
---[ end trace 7b7ae7cbafe6f2ba ]---
Segmentation fault
Also, now userspace has no chance to know link speed:
# ifconfig eth1 up
# ethtool eth1
Settings for eth1:
Cannot get device settings: No such device
Current message level: 0x0000003f (63)
Link detected: yes
#
(You need to tech *_ethtool.c to report speed/duplex for fixed-link
cases).
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ehca: use port autodetect mode as default
From: Alexander Schmidt @ 2009-07-07 14:06 UTC (permalink / raw)
To: Roland Dreier
Cc: of-ewg, lkml, linuxppc-dev, Christoph Raisch, of-general,
Hoang-Nam Nguyen, Stefan Roscher
This patch sets the port autodetect mode as default for the ehca driver. The
autodetect code has been in the kernel for several releases now and has
proved to be stable.
---
Roland, please queue this change for 2.6.32 if you are okay with it.
drivers/infiniband/hw/ehca/ehca_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- infiniband.git.orig/drivers/infiniband/hw/ehca/ehca_main.c
+++ infiniband.git/drivers/infiniband/hw/ehca/ehca_main.c
@@ -52,7 +52,7 @@
#include "ehca_tools.h"
#include "hcp_if.h"
-#define HCAD_VERSION "0028"
+#define HCAD_VERSION "0029"
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Christoph Raisch <raisch@de.ibm.com>");
@@ -64,7 +64,7 @@ static int ehca_hw_level = 0;
static int ehca_poll_all_eqs = 1;
int ehca_debug_level = 0;
-int ehca_nr_ports = 2;
+int ehca_nr_ports = -1;
int ehca_use_hp_mr = 0;
int ehca_port_act_time = 30;
int ehca_static_rate = -1;
@@ -95,8 +95,8 @@ MODULE_PARM_DESC(hw_level,
"Hardware level (0: autosensing (default), "
"0x10..0x14: eHCA, 0x20..0x23: eHCA2)");
MODULE_PARM_DESC(nr_ports,
- "number of connected ports (-1: autodetect, 1: port one only, "
- "2: two ports (default)");
+ "number of connected ports (-1: autodetect (default), "
+ "1: port one only, 2: two ports)");
MODULE_PARM_DESC(use_hp_mr,
"Use high performance MRs (default: no)");
MODULE_PARM_DESC(port_act_time,
^ permalink raw reply
* MTD OF parser problem
From: Roman Fietze @ 2009-07-07 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hallo,
I tried to define my MTD partitions in a device tree as
documented. The function of_flash_probe() inside teh file physmap_of.c
never compiled the code below
#ifdef CONFIG_MTD_OF_PARTS
because when the MTD subsystem is compiled as a module I can only find
CONFIG_MTD_OF_PARTS_MODULE beeing defined somewhere below my build
directory.
If I change the above define to
#if defined(CONFIG_MTD_OF_PARTS) || defined(CONFIG_MTD_OF_PARTS_MODULE)
everything is fine and MTD partition work as expected.
My fault? Other solution?
If not, I can submit that tiny patch.
Thanks
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
^ permalink raw reply
* Re: Inline assembly queries [2]
From: Gabriel Paubert @ 2009-07-07 13:46 UTC (permalink / raw)
To: Andreas Schwab; +Cc: gcc-help, kernel mailz, linux-kernel, linuxppc-dev
In-Reply-To: <m37hykis4d.fsf@hase.home>
On Tue, Jul 07, 2009 at 02:40:02PM +0200, Andreas Schwab wrote:
> Gabriel Paubert <paubert@iram.es> writes:
>
> > On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
> >> The 'Z' constraint is required for a memory operand for insns that don't
> >> have an update form (which would be selected by the %U modifier).
> >
> > Hmmm, I believed that it was for instructions that only have an indexed
> > form (all Altivec, byte reverse, and l?arx/st?cx for atomic operations).
> >
> > Of course none of these instructions have an update form, but they don't
> > have an offset encoded in the instruction either.
>
> Yes, you are right. IIRC there are either all u/x/ux forms or only the
> x form.
AFAIR IBM (probably) managed to screw up by making an exception for lwa:
lwa, lwax and lwaux exist, but not lwau!
Gabriel
^ permalink raw reply
* Re: dma_ops->map_page == NULL
From: Jon Smirl @ 2009-07-07 12:50 UTC (permalink / raw)
To: Kári Davíðsson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4A523984.2080904@marel.com>
On Mon, Jul 6, 2009 at 1:51 PM, K=E1ri Dav=ED=F0sson<kari.davidsson@marel.c=
om> wrote:
> I am doing a driver that uses dma_map_single().
>
> After changing to to linux 2.6.29.3 I am getting
> segfaults in dma_map_single() because dma_ops->map_page is NULL.
> Actually dma_ops looks funky too.
>
> The driver is an of_platform_driver which is declared as an child of
> the lbp (fsl,lpb) node of the device tree.
>
> This is on powerpc 5200b platform.
I have hit this before, in my case the driver pointer was null. It
faulted on dma_ops->map_page which had nothing to do with the real
problem which was the null driver pointer. I spent a long time looking
at this until I figured out that the reported error was bogus compared
to the actual problem.
>
> rg
> kd
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Inline assembly queries [2]
From: Andreas Schwab @ 2009-07-07 12:40 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: gcc-help, kernel mailz, linux-kernel, linuxppc-dev
In-Reply-To: <20090706065627.GA12499@iram.es>
Gabriel Paubert <paubert@iram.es> writes:
> On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
>> The 'Z' constraint is required for a memory operand for insns that don't
>> have an update form (which would be selected by the %U modifier).
>
> Hmmm, I believed that it was for instructions that only have an indexed
> form (all Altivec, byte reverse, and l?arx/st?cx for atomic operations).
>
> Of course none of these instructions have an update form, but they don't
> have an offset encoded in the instruction either.
Yes, you are right. IIRC there are either all u/x/ux forms or only the
x form.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: dma_ops->map_page == NULL
From: Benjamin Herrenschmidt @ 2009-07-07 11:08 UTC (permalink / raw)
To: Mark Nelson
Cc: Kári Davíðsson, linuxppc-dev@ozlabs.org,
Kumar Gala
In-Reply-To: <200907071015.24097.markn@au1.ibm.com>
On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>
> When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
> added in favour of map_/unmap_single() (which was later removed in .29)
> so you'll have to replace your calls to dma_map_single() with
> dma_map_page(). Just pass it the page and offset rather than the address.
Wait a minute ... dma_map_single() should still work, it will just call
dma_map_page() underneath. All dma_ops should have a ->map page
callback.
Do you have any dma_ops set for your device at all ? I wonder how we
set the dma_ops for platform devices nowadays ... We use to have this
fallback to direct ops when the dma_ops are NULL but that is gone and
I see no suitable replacement to set them on platform devices for
embedded archs ... oops...
Kumar, Becky, what's the situation there ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: Fix MPIC_BROKEN_REGREAD on non broken MPICs
From: Olof Johansson @ 2009-07-07 8:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1246926753.4449.1.camel@concordia>
On Tue, Jul 07, 2009 at 10:32:33AM +1000, Michael Ellerman wrote:
> I was also wondering, was this workaround ever required in a released
> chip - or was it just dev samples? If it's the latter, do we still need
> to carry it at all?
It's needed on all versions of hardware but for slightly different
reasons.
I had to research it when the discussion came up, since the first time
I used this workaround it was needed for a different erratum. But yes,
it is there in shipping products -- I was usually pretty careful not to
merge unneeded patches.
-Olof
^ permalink raw reply
* [PATCH] mmc: add quirk for controller that doesn't have highspeed bit in host control reg
From: Kevin Hao @ 2009-07-07 2:04 UTC (permalink / raw)
To: avorontsov, pierre, sdhci-devel, linuxppc-dev
FSL eSDHC controller doesn't have highspeed bit in its host control reg.
And the corresponding bit is used to set up the bus width. So add a
quirk to avoid set this bit. Tested on a mpc8377 RDB board.
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
---
drivers/mmc/host/sdhci-of.c | 3 ++-
drivers/mmc/host/sdhci.c | 10 ++++++----
drivers/mmc/host/sdhci.h | 2 ++
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index d79fa55..1377ec8 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -173,7 +173,8 @@ static struct sdhci_of_data sdhci_esdhc = {
SDHCI_QUIRK_NONSTANDARD_CLOCK |
SDHCI_QUIRK_PIO_NEEDS_DELAY |
SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET |
- SDHCI_QUIRK_NO_CARD_NO_RESET,
+ SDHCI_QUIRK_NO_CARD_NO_RESET |
+ SDHCI_QUIRK_NO_HIGHSPEED_BIT,
.ops = {
.readl = esdhc_readl,
.readw = esdhc_readw,
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 6779b4e..a08fa28 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1143,10 +1143,12 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
else
ctrl &= ~SDHCI_CTRL_4BITBUS;
- if (ios->timing == MMC_TIMING_SD_HS)
- ctrl |= SDHCI_CTRL_HISPD;
- else
- ctrl &= ~SDHCI_CTRL_HISPD;
+ if (!(host->quirks | SDHCI_QUIRK_NO_HIGHSPEED_BIT)) {
+ if (ios->timing == MMC_TIMING_SD_HS)
+ ctrl |= SDHCI_CTRL_HISPD;
+ else
+ ctrl &= ~SDHCI_CTRL_HISPD;
+ }
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 831ddf7..404bb5f 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -232,6 +232,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_FORCE_1_BIT_DATA (1<<22)
/* Controller needs 10ms delay between applying power and clock */
#define SDHCI_QUIRK_DELAY_AFTER_POWER (1<<23)
+/* Controller doesn't have highspeed bit in host control reg */
+#define SDHCI_QUIRK_NO_HIGHSPEED_BIT (1<<24)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] net: fix OF fixed-link property handling on Freescale network device drivers
From: David Miller @ 2009-07-07 2:07 UTC (permalink / raw)
To: grant.likely; +Cc: netdev, afleming, leoli, linuxppc-dev
In-Reply-To: <20090703221851.23909.923.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Fri, 03 Jul 2009 16:20:19 -0600
> Anton, can you please review, comment and test? I've tested it on an
> mpc8349 board, but that is the only hardware that I have. I've also
> probably made mistakes and it needs to be split up into separate patches,
> but this is probably a sufficient form for first review. I'll also give
> it another once over tomorrow when after I've had a decent night sleep.
Can we get some review and testing of this patch going so we
can fix this regression as soon as possible?
Thanks.
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: Fix MPIC_BROKEN_REGREAD on non broken MPICs
From: Michael Ellerman @ 2009-07-07 0:32 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20090706135926.GA16205@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
On Mon, 2009-07-06 at 08:59 -0500, Olof Johansson wrote:
> On Mon, Jul 06, 2009 at 12:08:52PM +1000, Michael Ellerman wrote:
> > The workaround enabled by CONFIG_MPIC_BROKEN_REGREAD does not work
> > on non-broken MPICs. The symptom is no interrupts being received.
> >
> > The fix is twofold. Firstly the code was broken for multiple isus,
> > we need to index into the shadow array with the src_no, not the idx.
> > Secondly, we always do the read, but only use the VECPRI_MASK and
> > VECPRI_ACTIVITY bits from the hardware, the rest of "val" comes
> > from the shadow.
>
> I'm travelling without remote access to a machine to test this on. Given
> that it changes the errata workaround (subtly), I'd appreciate the chance
> to give it a go before it gets merged.
Sure.
I was also wondering, was this workaround ever required in a released
chip - or was it just dev samples? If it's the latter, do we still need
to carry it at all?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: dma_ops->map_page == NULL
From: Mark Nelson @ 2009-07-07 0:15 UTC (permalink / raw)
To: Kári Davíðsson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4A523984.2080904@marel.com>
On Tuesday 07 July 2009 03:51:00 K=E1ri Dav=ED=F0sson wrote:
> I am doing a driver that uses dma_map_single().
>=20
> After changing to to linux 2.6.29.3 I am getting
> segfaults in dma_map_single() because dma_ops->map_page is NULL.
> Actually dma_ops looks funky too.
When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
added in favour of map_/unmap_single() (which was later removed in .29)
so you'll have to replace your calls to dma_map_single() with
dma_map_page(). Just pass it the page and offset rather than the address.
Hope that helps!
Mark.
>=20
> The driver is an of_platform_driver which is declared as an child of
> the lbp (fsl,lpb) node of the device tree.
>=20
> This is on powerpc 5200b platform.
>=20
> rg
> kd
^ permalink raw reply
* Re: Delay on intialization ide subsystem(most likely)
From: Benjamin Herrenschmidt @ 2009-07-06 23:23 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-ide, Andrey Gusev, petkovbb, David Miller, linuxppc-dev
In-Reply-To: <200907061704.38539.bzolnier@gmail.com>
On Mon, 2009-07-06 at 17:04 +0200, Bartlomiej Zolnierkiewicz wrote:
> > Delay is fixed itself in 2.6.31-rc2. Most likely it was platform specific issue. But lost interrupt still exists.
> > There is log of 2.6.31-rc2:
>
> Thanks for letting us know. When it comes to the lost interrupt issue
> I still suspect that this is pmac specific problem (though Dave may have
> some fresh idea about it).
Hard to tell. Those things generally work... maybe something is wrong
with that disk vs. that timing. Does it work if you move it to the other
controller (the one to which the CD drive is connected ?)
Cheers,
Ben.
> > [ 1.595268] MacIO PCI driver attached to Keylargo chipset
> > [ 1.597024] irq: irq 32 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 32
> > [ 1.597988] irq: irq 19 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 19
> > [ 1.598024] irq: irq 11 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 16
> > [ 1.598365] irq: irq 20 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 20
> > [ 1.598401] irq: irq 12 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 17
> > [ 1.598762] irq: irq 5 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 18
> > [ 1.598797] irq: irq 6 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 21
> > [ 1.599264] irq: irq 7 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 24
> > [ 1.599300] irq: irq 8 on host /pci@f2000000/mac-io@17/interrupt-controller@40000 mapped to virtual irq 29
> > [ 1.601336] Uniform Multi-Platform E-IDE driver
> > [ 1.602201] ide-pmac 0002:20:0d.0: enabling device (0000 -> 0002)
> > [ 2.630651] ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
> > [ 2.630767] Probing IDE interface ide0...
> > [ 2.930834] hda: IBM-IC35L060AVVA07-0, ATA DISK drive
> > [ 3.290646] hdb: QUANTUM FIREBALLP LM20.5, ATA DISK drive
> > [ 3.291087] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> > [ 3.291264] hda: UDMA/100 mode selected
> > [ 3.291473] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> > [ 3.291720] hdb: UDMA/66 mode selected
> > [ 3.292118] ide0 at 0xf10c2000-0xf10c2070,0xf10c2160 on irq 39
> > [ 4.320649] ide-pmac: Found Apple KeyLargo ATA-4 controller (macio), bus ID 2, irq 19
> > [ 4.320753] Probing IDE interface ide1...
> > [ 4.921004] ide1 at 0xf10ba000-0xf10ba070,0xf10ba160 on irq 19
> > [ 5.950647] ide-pmac: Found Apple KeyLargo ATA-3 controller (macio), bus ID 0, irq 20
> > [ 5.950743] Probing IDE interface ide2...
> > [ 6.370828] hde: PHILIPS CDD5101, ATAPI CD/DVD-ROM drive
> > [ 6.730948] hde: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> > [ 6.731332] hde: MWDMA2 mode selected
> > [ 6.731832] ide2 at 0xf10be000-0xf10be070,0xf10be160 on irq 20
> > [ 6.732558] ide-gd driver 1.18
> > [ 6.732735] hda: max request size: 128KiB
> > [ 6.763392] hda: 120103200 sectors (61492 MB) w/1863KiB Cache, CHS=65535/16/63
> > [ 6.763741] hda: cache flushes supported
> > [ 6.764277] hda: [mac] hda1 hda2 hda3 hda4
> > [ 6.770469] hdb: max request size: 128KiB
> > [ 6.803427] hdb: Host Protected Area detected.
> > [ 6.803431] current capacity is 40130390 sectors (20546 MB)
> > [ 6.803435] native capacity is 40132503 sectors (20547 MB)
> > [ 6.803590] hdb: 40130390 sectors (20546 MB) w/1900KiB Cache, CHS=39811/16/63
> > [ 6.803684] hdb: cache flushes not supported
> > [ 6.803910] hdb:
> > [ 26.800743] ide-pmac lost interrupt, dma status: 8480
> > [ 26.800809] hdb: lost interrupt
> > [ 26.800850] hdb: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> > [ 26.800976] hdb: possibly failed opcode: 0xc8
> > [ 26.803449] hda: DMA disabled
> > [ 26.805664] hdb: DMA disabled
> > [ 26.900633] ide0: reset: success
> > [ 26.949147] hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
> > [ 27.007890] ide-cd driver 5.00
> > [ 27.011728] ide-cd: hde: ATAPI 32X DVD-ROM CD-R/RW drive, 8192kB Cache
> > [ 27.014163] Uniform CD-ROM driver Revision: 3.20
> >
^ permalink raw reply
* Re: RAMDISK on EP88xc
From: Mikhail Zaturenskiy @ 2009-07-06 20:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4A525C12.3090804@freescale.com>
On Mon, Jul 6, 2009 at 3:18 PM, Scott Wood<scottwood@freescale.com> wrote:
> Try omitting the spaces around the equal sign.
AHA! Lesson learned :) =A0thanks Scott! That did it.
^ 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