* [PATCH] mpc85xx_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Shaveta Leekha @ 2012-03-17 9:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index abdcd31..f95b302 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -118,6 +118,7 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_QE=m
CONFIG_NVRAM=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
CONFIG_SPI=y
--
1.5.5.6
^ permalink raw reply related
* [PATCH]corenet32_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Shaveta Leekha @ 2012-03-17 9:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index f8aef20..91db656 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -116,6 +116,7 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MPC=y
CONFIG_SPI=y
CONFIG_SPI_GPIO=y
--
1.5.5.6
^ permalink raw reply related
* Re: issues calling of_platform_bus_probe() twice
From: Tabi Timur-B04825 @ 2012-03-17 13:35 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <20120317072717.738953E08CE@localhost>
Grant Likely wrote:
>>> > > Are you aware of any reason that we can't call of_platform_bus_pr=
obe()
>>> > > or multiple times. Timur's run into an issue in which all device=
s
>>> > > don't get registered properly if we call of_platform_bus_probe() =
times
>>> > > with different of_device_id struct's.
>> >
>> > Nothing comes to mind... Grant ?
> Neither for me. Should work.
I posted a work-around patch here:
http://patchwork.ozlabs.org/patch/128533/
Without this patch, drivers cannot probe on DMA *channels*, or any other=20
grandchildren of the root node.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] mpc85xx_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Tabi Timur-B04825 @ 2012-03-17 15:47 UTC (permalink / raw)
To: Leekha Shaveta-B20052; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1331974801-15845-1-git-send-email-shaveta@freescale.com>
On Sat, Mar 17, 2012 at 4:00 AM, Shaveta Leekha <shaveta@freescale.com> wro=
te:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
Where's the patch description? You need to explain WHY this change is
a good idea.
And you should change all defconfigs in one patch.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Problem with framebuffer mmap on platforms with large addressing
From: Dmitry Eremin-Solenikov @ 2012-03-17 16:04 UTC (permalink / raw)
To: linux-fbdev-devel, linuxppc-dev, Florian Tobias Schandinat,
Josh Boyer, Matt Porter
Hello,
I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
The peculiarity of this platform is the fact that it has
sizeof(unsigned long) = 4,
but physical address on it is 36 bits width. It is a common to various pieces
of the code to expect that unsigned long variable is able to contain physical
address. Most of those places are easy to fix.
The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
it uses information from struct fb_fix_screeninfo provided by the driver.
This structure uses two unsigned long fields to hold physical addresses
(smem_start and mmio_start). It would be easy to change that structure
to use phys_addr_t instead of unsigned long, but this structure is a part
of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
And now I'm stuck with it.
In my driver code I have just overwritten the fb_mmap function with
driver-private
fb_mmap callback supporting 64-bit addressing, but this doesn't look like
a generic and correct solution.
What is the best way to fix this problem? Should we break ABI with the goal
of correctness? Should we add new FBIOGET_FSCREENINFO2, which will
return a correct structure with phys_addr_t (or simply u64) fields and make
FBIOGET_FSCREENINFO a wrapper returning partially bogus structure
(with smem_start and mmio_start fields being truncated to just unsigned long)?
What would developers recommend?
Thank you.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] Device Tree Bindings for Freescale TDM controller
From: Tabi Timur-B04825 @ 2012-03-17 16:04 UTC (permalink / raw)
To: Aggrwal Poonam-B10812
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org, Singh Sandeep-B37400
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D09D518@039-SN2MPN1-013.039d.mgd.msft.net>
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812
<B10812@freescale.com> wrote:
>
>> > + =A0- clock-frequency
>> > + =A0 =A0 =A0Usage: optional
>> > + =A0 =A0 =A0Value type: <u32>
>> > + =A0 =A0 =A0Definition: The frequency at which the TDM block is opera=
ting.
>>
>> Will this frequency ever need to be > 4GHz?
> Don't think so, at max this will be CCB, not sure if CCB on our platforms=
may get bigger than 4G ever.
Apparently, 4GB is the new 640K.
In Poonam's defense, every clock frequency property in the device tree
is a 32-bit integer. I've never seen a 64-bit one.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] Device Tree Bindings for Freescale TDM controller
From: Tabi Timur-B04825 @ 2012-03-17 16:07 UTC (permalink / raw)
To: Aggrwal Poonam-B10812
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org, Singh Sandeep-B37400
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D09D518@039-SN2MPN1-013.039d.mgd.msft.net>
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812
<B10812@freescale.com> wrote:
>
>> > + =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,p1010-tdm", "fsl,mpc8315-tdm=
";
>> > + =A0 =A0 =A0 =A0 =A0 reg =3D <0x16000 0x200 0x2c000 0x2000>;
>> > + =A0 =A0 =A0 =A0 =A0 clock-frequency =3D <0>;
>>
>> Show a real clock-frequency, perhaps with a comment saying it's typicall=
y
>> filled in by boot software.
> Okay.
Scott, are you suggesting that Poonam put a non-zero number in the DTS
for clock-frequency? If so, then I don't think that's a good idea, if
U-Boot will always override it.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: fsl pci edac patches
From: Dmitry Eremin-Solenikov @ 2012-03-17 17:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: Lan Chunhe-B25806, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <31B0E63E-923D-4022-8B27-76CFF2189817@kernel.crashing.org>
Hello,
On Sat, Mar 17, 2012 at 1:13 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Guys,
>
> I'm not sure what the state of the EDAC patches and latest kernel are.. I'm going to mark the ones in patch works as 'dead' and hopefully you guys will resend if there is still an interest.
I don't have mpc85xx hardware to test at this point, so probably I
don't care about 85xx EDAC binding right now.
Strictly speaking I forgot about these patches :(
--
With best wishes
Dmitry
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Benjamin Herrenschmidt @ 2012-03-17 23:29 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <4F649304.9010001@freescale.com>
On Sat, 2012-03-17 at 13:35 +0000, Tabi Timur-B04825 wrote:
> >>> > > Are you aware of any reason that we can't call
> of_platform_bus_probe()
> >>> > > or multiple times. Timur's run into an issue in which all
> devices
> >>> > > don't get registered properly if we call
> of_platform_bus_probe() times
> >>> > > with different of_device_id struct's.
> >> >
> >> > Nothing comes to mind... Grant ?
> > Neither for me. Should work.
>
> I posted a work-around patch here:
>
> http://patchwork.ozlabs.org/patch/128533/
>
> Without this patch, drivers cannot probe on DMA *channels*, or any
> other
> grandchildren of the root node.
Why don't you track down the actual bug instead ?
Cheers,
Ben.
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Tabi Timur-B04825 @ 2012-03-17 23:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <1332026973.3105.191.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Why don't you track down the actual bug instead ?
I was hoping that someone who is very familiar with the code would take a=20
look. I don't know the OF layer that well.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-03-18 0:46 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-fbdev-devel, Florian Tobias Schandinat, Tony Breeds,
linuxppc-dev
In-Reply-To: <CALT56yO05UBY6=KqK94=_sC4hd3ranj5J5CXOAo5hSjVAdkgkA@mail.gmail.com>
On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
>
> The peculiarity of this platform is the fact that it has
> sizeof(unsigned long) = 4,
> but physical address on it is 36 bits width. It is a common to various pieces
> of the code to expect that unsigned long variable is able to contain physical
> address. Most of those places are easy to fix.
Yes. In fact, Tony (CC) has some patches to fix a lot of the DRM
infrastructure (we have radeon KMS working on a similar platform).
> The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
> it uses information from struct fb_fix_screeninfo provided by the driver.
> This structure uses two unsigned long fields to hold physical addresses
> (smem_start and mmio_start). It would be easy to change that structure
> to use phys_addr_t instead of unsigned long, but this structure is a part
> of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
> And now I'm stuck with it.
It's an old problem, which I think we described a while back on the
list. Back then the conclusion was to make a new version with a proper
__u64, a new ioctl to access is, and a "compatible" ioctl that blanks
the address fields (or fails) if they contain a value >32-bit.
We just never got to actually implement it.
In fact, we could make the new structure such that it doesn't break
userspace compatibility with 64-bit architectures at all, ie, the "new"
and "compat" ioctl could remain entirely equivalent on 64-bit.
> In my driver code I have just overwritten the fb_mmap function with
> driver-private
> fb_mmap callback supporting 64-bit addressing, but this doesn't look like
> a generic and correct solution.
>
> What is the best way to fix this problem? Should we break ABI with the goal
> of correctness? Should we add new FBIOGET_FSCREENINFO2, which will
> return a correct structure with phys_addr_t (or simply u64) fields and make
> FBIOGET_FSCREENINFO a wrapper returning partially bogus structure
> (with smem_start and mmio_start fields being truncated to just unsigned long)?
> What would developers recommend?
Cheers,
Ben.
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Grant Likely @ 2012-03-18 9:08 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <4F649304.9010001@freescale.com>
On Sat, 17 Mar 2012 13:35:02 +0000, Tabi Timur-B04825 <B04825@freescale.com> wrote:
> Grant Likely wrote:
> >>> > > Are you aware of any reason that we can't call of_platform_bus_probe()
> >>> > > or multiple times. Timur's run into an issue in which all devices
> >>> > > don't get registered properly if we call of_platform_bus_probe() times
> >>> > > with different of_device_id struct's.
> >> >
> >> > Nothing comes to mind... Grant ?
> > Neither for me. Should work.
>
> I posted a work-around patch here:
>
> http://patchwork.ozlabs.org/patch/128533/
>
> Without this patch, drivers cannot probe on DMA *channels*, or any other
> grandchildren of the root node.
That's because you're using it wrong. of_platform_bus_probe() creates
platform devices at the starting level and every level below it as
described by the bus ids. It is illegal to call of_platform_bus_probe()
twice at the same level in the DT.
g.
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Dmitry Eremin-Solenikov @ 2012-03-18 14:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <1332031585.3105.197.camel@pasglop>
On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:
>> Hello,
>>
>> I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
>>
>> The peculiarity of this platform is the fact that it has
>> sizeof(unsigned long) = 4,
>> but physical address on it is 36 bits width. It is a common to various pieces
>> of the code to expect that unsigned long variable is able to contain physical
>> address. Most of those places are easy to fix.
>
> Yes. In fact, Tony (CC) has some patches to fix a lot of the DRM
> infrastructure (we have radeon KMS working on a similar platform).
That is interesting! Are those patches published or otherwise available
somewhere? We are also very interested in enabling Canyonlands
with Radeon KMS!
>
>> The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
>> it uses information from struct fb_fix_screeninfo provided by the driver.
>> This structure uses two unsigned long fields to hold physical addresses
>> (smem_start and mmio_start). It would be easy to change that structure
>> to use phys_addr_t instead of unsigned long, but this structure is a part
>> of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
>> And now I'm stuck with it.
>
> It's an old problem, which I think we described a while back on the
> list. Back then the conclusion was to make a new version with a proper
> __u64, a new ioctl to access is, and a "compatible" ioctl that blanks
> the address fields (or fails) if they contain a value >32-bit.
>
> We just never got to actually implement it.
I see. I will try to prepare patches.
>
> In fact, we could make the new structure such that it doesn't break
> userspace compatibility with 64-bit architectures at all, ie, the "new"
> and "compat" ioctl could remain entirely equivalent on 64-bit.
I remember stuff about compat_ioctl, but I have never used/implemented
that. Are there any details of requirements for the structures being passed?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Tabi Timur-B04825 @ 2012-03-18 16:14 UTC (permalink / raw)
To: Grant Likely
Cc: dbaryshkov@gmail.com, devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <20120318090804.C70493E060A@localhost>
Grant Likely wrote:
> That's because you're using it wrong. of_platform_bus_probe() creates
> platform devices at the starting level and every level below it as
> described by the bus ids. It is illegal to call of_platform_bus_probe()
> twice at the same level in the DT.
Well, *I* am not using it wrong. Notice that my patch fixes (or works=20
around) the commit that *did* do it wrong:
http://patchwork.ozlabs.org/patch/126289/
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH net-next 0/3] Gianfar byte queue limits
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
The BQL support here is unchanged from what I posted earlier as an
RFC[1] -- with the exception of the fact that I'm now happier with
the runtime testing vs. the simple "hey it boots" that I'd done
for the RFC. Plus I added a couple trivial cleanup patches.
For testing, I made a couple spiders homeless by reviving an ancient
10baseT hub. I connected an sbc8349 into that, and connected the
yellowing hub into a GigE 16port, which was also connected to the
recipient x86 box.
Gianfar saw the interface as follows:
fsl-gianfar e0024000.ethernet: eth0: mac: 00:a0:1e:a0:26:5a
fsl-gianfar e0024000.ethernet: eth0: Running with NAPI enabled
fsl-gianfar e0024000.ethernet: eth0: RX BD ring size for Q[0]: 256
fsl-gianfar e0024000.ethernet: eth0: TX BD ring size for Q[0]: 256
PHY: mdio@e0024520:19 - Link is Up - 10/Half
With the sbc8349 being diskless, I simply used an scp of /proc/kcore
to the connected x86 box as a rudimentary Tx heavy workload.
BQL data was collected by changing into the dir:
/sys/devices/e0000000.soc8349/e0024000.ethernet/net/eth0/queues/tx-0/byte_queue_limits
and running the following:
for i in * ; do echo -n $i": " ; cat $i ; done
Running with the defaults, data like below was typical:
hold_time: 1000
inflight: 4542
limit: 3456
limit_max: 1879048192
limit_min: 0
hold_time: 1000
inflight: 4542
limit: 3378
limit_max: 1879048192
limit_min: 0
i.e. 2 or 3 MTU sized packets in flight and the limit value lying
somewhere between those two values.
The interesting thing is that the interactive speed reported by scp
seemed somewhat erratic, ranging from ~450 to ~700kB/s. (This was
the only traffic on the old junk - perhaps expected oscillations such
as those seen in isolated ARED tests?) Average speed for 100M was:
104857600 bytes (105 MB) copied, 172.616 s, 607 kB/s
Anyway, back to BQL testing; setting the values as follows:
hold_time: 1000
inflight: 1514
limit: 1400
limit_max: 1400
limit_min: 1000
had the effect of serializing the interface to a single packet, and
the crusty old hub seemed much happier with this arrangement, keeping
a constant speed and achieving the following on a 100MB Tx block:
104857600 bytes (105 MB) copied, 112.52 s, 932 kB/s
It might be interesting to know more about why the defaults suffer
the slowdown, but the hub could possibly be ancient spec violating
trash. Definitely something that nobody would ever use for anything
today. (aside from contrived tests like this)
But it did give me an example of where I could see the effects of
changing the BQL settings, and I'm reasonably confident they are
working as expected.
Paul.
---
[1] http://lists.openwall.net/netdev/2012/01/06/64
Paul Gortmaker (3):
gianfar: Add support for byte queue limits.
gianfar: constify giant block of status descriptor strings
gianfar: delete orphaned version strings and dead macros
drivers/net/ethernet/freescale/gianfar.c | 22 ++++++++++++++++------
drivers/net/ethernet/freescale/gianfar.h | 3 ---
drivers/net/ethernet/freescale/gianfar_ethtool.c | 2 +-
3 files changed, 17 insertions(+), 10 deletions(-)
--
1.7.9.1
^ permalink raw reply
* [PATCH net-next 1/3] gianfar: Add support for byte queue limits.
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
In-Reply-To: <1332089787-24086-1-git-send-email-paul.gortmaker@windriver.com>
Add support for byte queue limits (BQL), based on the similar
modifications made to intel/igb/igb_main.c from Eric Dumazet
in commit bdbc063129e811264cd6c311d8c2d9b95de01231
"igb: Add support for byte queue limits."
A local variable for tx_queue->qindex was introduced in
gfar_clean_tx_ring, since it is now used often enough to warrant it,
and it cleans up the readability somewhat as well.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/freescale/gianfar.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index adb0ae4..a4c934b 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1755,9 +1755,12 @@ static void free_skb_resources(struct gfar_private *priv)
/* Go through all the buffer descriptors and free their data buffers */
for (i = 0; i < priv->num_tx_queues; i++) {
+ struct netdev_queue *txq;
tx_queue = priv->tx_queue[i];
+ txq = netdev_get_tx_queue(tx_queue->dev, tx_queue->qindex);
if(tx_queue->tx_skbuff)
free_skb_tx_queue(tx_queue);
+ netdev_tx_reset_queue(txq);
}
for (i = 0; i < priv->num_rx_queues; i++) {
@@ -2217,6 +2220,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
lstatus |= BD_LFLAG(TXBD_CRC | TXBD_READY) | skb_headlen(skb);
}
+ netdev_tx_sent_queue(txq, skb->len);
+
/*
* We can work in parallel with gfar_clean_tx_ring(), except
* when modifying num_txbdfree. Note that we didn't grab the lock
@@ -2460,6 +2465,7 @@ static void gfar_align_skb(struct sk_buff *skb)
static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
{
struct net_device *dev = tx_queue->dev;
+ struct netdev_queue *txq;
struct gfar_private *priv = netdev_priv(dev);
struct gfar_priv_rx_q *rx_queue = NULL;
struct txbd8 *bdp, *next = NULL;
@@ -2471,10 +2477,13 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
int frags = 0, nr_txbds = 0;
int i;
int howmany = 0;
+ int tqi = tx_queue->qindex;
+ unsigned int bytes_sent = 0;
u32 lstatus;
size_t buflen;
- rx_queue = priv->rx_queue[tx_queue->qindex];
+ rx_queue = priv->rx_queue[tqi];
+ txq = netdev_get_tx_queue(dev, tqi);
bdp = tx_queue->dirty_tx;
skb_dirtytx = tx_queue->skb_dirtytx;
@@ -2533,6 +2542,8 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
bdp = next_txbd(bdp, base, tx_ring_size);
}
+ bytes_sent += skb->len;
+
/*
* If there's room in the queue (limit it to rx_buffer_size)
* we add this skb back into the pool, if it's the right size
@@ -2557,13 +2568,15 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
}
/* If we freed a buffer, we can restart transmission, if necessary */
- if (__netif_subqueue_stopped(dev, tx_queue->qindex) && tx_queue->num_txbdfree)
- netif_wake_subqueue(dev, tx_queue->qindex);
+ if (__netif_subqueue_stopped(dev, tqi) && tx_queue->num_txbdfree)
+ netif_wake_subqueue(dev, tqi);
/* Update dirty indicators */
tx_queue->skb_dirtytx = skb_dirtytx;
tx_queue->dirty_tx = bdp;
+ netdev_tx_completed_queue(txq, howmany, bytes_sent);
+
return howmany;
}
--
1.7.9.1
^ permalink raw reply related
* [PATCH net-next 2/3] gianfar: constify giant block of status descriptor strings
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
In-Reply-To: <1332089787-24086-1-git-send-email-paul.gortmaker@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/freescale/gianfar_ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index 5a78d55..8d74efd 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -58,7 +58,7 @@ static void gfar_gringparam(struct net_device *dev, struct ethtool_ringparam *rv
static int gfar_sringparam(struct net_device *dev, struct ethtool_ringparam *rvals);
static void gfar_gdrvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo);
-static char stat_gstrings[][ETH_GSTRING_LEN] = {
+static const char stat_gstrings[][ETH_GSTRING_LEN] = {
"rx-dropped-by-kernel",
"rx-large-frame-errors",
"rx-short-frame-errors",
--
1.7.9.1
^ permalink raw reply related
* [PATCH net-next 3/3] gianfar: delete orphaned version strings and dead macros
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
In-Reply-To: <1332089787-24086-1-git-send-email-paul.gortmaker@windriver.com>
There were two version strings, and neither one was being used.
Also in the same proximity were some unused #define that were
left over from the past. Delete them all.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/freescale/gianfar.c | 3 ---
drivers/net/ethernet/freescale/gianfar.h | 3 ---
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index a4c934b..6e66cc3 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -104,10 +104,7 @@
#include "fsl_pq_mdio.h"
#define TX_TIMEOUT (1*HZ)
-#undef BRIEF_GFAR_ERRORS
-#undef VERBOSE_GFAR_ERRORS
-const char gfar_driver_name[] = "Gianfar Ethernet";
const char gfar_driver_version[] = "1.3";
static int gfar_enet_open(struct net_device *dev);
diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
index 4fe0f34..fc2488a 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -78,11 +78,8 @@ struct ethtool_rx_list {
#define INCREMENTAL_BUFFER_SIZE 512
#define PHY_INIT_TIMEOUT 100000
-#define GFAR_PHY_CHANGE_TIME 2
-#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.2, "
#define DRV_NAME "gfar-enet"
-extern const char gfar_driver_name[];
extern const char gfar_driver_version[];
/* MAXIMUM NUMBER OF QUEUES SUPPORTED */
--
1.7.9.1
^ permalink raw reply related
* Re: issues calling of_platform_bus_probe() twice
From: Grant Likely @ 2012-03-18 18:22 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: dbaryshkov@gmail.com, devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <4F6609DE.2050001@freescale.com>
On Sun, 18 Mar 2012 16:14:23 +0000, Tabi Timur-B04825 <B04825@freescale.com> wrote:
> Grant Likely wrote:
> > That's because you're using it wrong. of_platform_bus_probe() creates
> > platform devices at the starting level and every level below it as
> > described by the bus ids. It is illegal to call of_platform_bus_probe()
> > twice at the same level in the DT.
>
> Well, *I* am not using it wrong. Notice that my patch fixes (or works
> around) the commit that *did* do it wrong:
>
> http://patchwork.ozlabs.org/patch/126289/
Fair enough; I just wanted to point out that there it can only dig as
deep into the tree as is specified by the bus ids. The exact problem
wasn't calling the function twice, but rather trying to call the
function twice from the same level of the tree.
BTW, I also recommend moving to of_platform_populate() for new code.
I think the behaviour is more consistent for fdt platforms and it
is more convenient for devices that are children of the root.
g.
^ permalink raw reply
* Re: [PATCH net-next 1/3] gianfar: Add support for byte queue limits.
From: Eric Dumazet @ 2012-03-18 20:20 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, linuxppc-dev, davem, therbert
In-Reply-To: <1332089787-24086-2-git-send-email-paul.gortmaker@windriver.com>
Le dimanche 18 mars 2012 à 12:56 -0400, Paul Gortmaker a écrit :
...
> * we add this skb back into the pool, if it's the right size
> @@ -2557,13 +2568,15 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
> }
>
> /* If we freed a buffer, we can restart transmission, if necessary */
> - if (__netif_subqueue_stopped(dev, tx_queue->qindex) && tx_queue->num_txbdfree)
> - netif_wake_subqueue(dev, tx_queue->qindex);
> + if (__netif_subqueue_stopped(dev, tqi) && tx_queue->num_txbdfree)
> + netif_wake_subqueue(dev, tqi);
>
You can use netif_tx_queue_stopped(txq) here instead of
__netif_subqueue_stopped(dev, tqi)
> /* Update dirty indicators */
> tx_queue->skb_dirtytx = skb_dirtytx;
> tx_queue->dirty_tx = bdp;
>
> + netdev_tx_completed_queue(txq, howmany, bytes_sent);
> +
> return howmany;
> }
>
^ permalink raw reply
* Re: [PATCH net-next 0/3] Gianfar byte queue limits
From: Eric Dumazet @ 2012-03-18 20:30 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, linuxppc-dev, davem, therbert
In-Reply-To: <1332089787-24086-1-git-send-email-paul.gortmaker@windriver.com>
Le dimanche 18 mars 2012 à 12:56 -0400, Paul Gortmaker a écrit :
> The BQL support here is unchanged from what I posted earlier as an
> RFC[1] -- with the exception of the fact that I'm now happier with
> the runtime testing vs. the simple "hey it boots" that I'd done
> for the RFC. Plus I added a couple trivial cleanup patches.
>
> For testing, I made a couple spiders homeless by reviving an ancient
> 10baseT hub. I connected an sbc8349 into that, and connected the
> yellowing hub into a GigE 16port, which was also connected to the
> recipient x86 box.
>
> Gianfar saw the interface as follows:
>
> fsl-gianfar e0024000.ethernet: eth0: mac: 00:a0:1e:a0:26:5a
> fsl-gianfar e0024000.ethernet: eth0: Running with NAPI enabled
> fsl-gianfar e0024000.ethernet: eth0: RX BD ring size for Q[0]: 256
> fsl-gianfar e0024000.ethernet: eth0: TX BD ring size for Q[0]: 256
> PHY: mdio@e0024520:19 - Link is Up - 10/Half
>
> With the sbc8349 being diskless, I simply used an scp of /proc/kcore
> to the connected x86 box as a rudimentary Tx heavy workload.
>
> BQL data was collected by changing into the dir:
>
> /sys/devices/e0000000.soc8349/e0024000.ethernet/net/eth0/queues/tx-0/byte_queue_limits
>
> and running the following:
>
> for i in * ; do echo -n $i": " ; cat $i ; done
>
> Running with the defaults, data like below was typical:
>
> hold_time: 1000
> inflight: 4542
> limit: 3456
> limit_max: 1879048192
> limit_min: 0
>
> hold_time: 1000
> inflight: 4542
> limit: 3378
> limit_max: 1879048192
> limit_min: 0
>
> i.e. 2 or 3 MTU sized packets in flight and the limit value lying
> somewhere between those two values.
>
> The interesting thing is that the interactive speed reported by scp
> seemed somewhat erratic, ranging from ~450 to ~700kB/s. (This was
> the only traffic on the old junk - perhaps expected oscillations such
> as those seen in isolated ARED tests?) Average speed for 100M was:
>
> 104857600 bytes (105 MB) copied, 172.616 s, 607 kB/s
>
Still half duplex, or full duplex ?
Limiting to one packet on half duplex might avoid collisions :)
> Anyway, back to BQL testing; setting the values as follows:
>
> hold_time: 1000
> inflight: 1514
> limit: 1400
> limit_max: 1400
> limit_min: 1000
>
> had the effect of serializing the interface to a single packet, and
> the crusty old hub seemed much happier with this arrangement, keeping
> a constant speed and achieving the following on a 100MB Tx block:
>
> 104857600 bytes (105 MB) copied, 112.52 s, 932 kB/s
>
> It might be interesting to know more about why the defaults suffer
> the slowdown, but the hub could possibly be ancient spec violating
> trash. Definitely something that nobody would ever use for anything
> today. (aside from contrived tests like this)
>
> But it did give me an example of where I could see the effects of
> changing the BQL settings, and I'm reasonably confident they are
> working as expected.
>
Seems pretty good to me !
^ permalink raw reply
* Re: [PATCH net-next 0/3] Gianfar byte queue limits
From: Paul Gortmaker @ 2012-03-18 20:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linuxppc-dev, davem, therbert
In-Reply-To: <1332102634.3647.1.camel@edumazet-laptop>
On Sun, Mar 18, 2012 at 4:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrot=
e:
> Le dimanche 18 mars 2012 =E0 12:56 -0400, Paul Gortmaker a =E9crit :
>> The BQL support here is unchanged from what I posted earlier as an
>> RFC[1] -- with the exception of the fact that I'm now happier with
>> the runtime testing vs. the simple "hey it boots" that I'd done
>> for the RFC. =A0Plus I added a couple trivial cleanup patches.
>>
>> For testing, I made a couple spiders homeless by reviving an ancient
>> 10baseT hub. =A0I connected an sbc8349 into that, and connected the
>> yellowing hub into a GigE 16port, which was also connected to the
>> recipient x86 box.
>>
>> Gianfar saw the interface as follows:
>>
>> fsl-gianfar e0024000.ethernet: eth0: mac: 00:a0:1e:a0:26:5a
>> fsl-gianfar e0024000.ethernet: eth0: Running with NAPI enabled
>> fsl-gianfar e0024000.ethernet: eth0: RX BD ring size for Q[0]: 256
>> fsl-gianfar e0024000.ethernet: eth0: TX BD ring size for Q[0]: 256
>> PHY: mdio@e0024520:19 - Link is Up - 10/Half
>>
>> With the sbc8349 being diskless, I simply used an scp of /proc/kcore
>> to the connected x86 box as a rudimentary Tx heavy workload.
>>
>> BQL data was collected by changing into the dir:
>>
>> =A0 /sys/devices/e0000000.soc8349/e0024000.ethernet/net/eth0/queues/tx-0=
/byte_queue_limits
>>
>> and running the following:
>>
>> =A0 for i in * ; do echo -n $i": " ; cat $i ; done
>>
>> Running with the defaults, data like below was typical:
>>
>> hold_time: 1000
>> inflight: 4542
>> limit: 3456
>> limit_max: 1879048192
>> limit_min: 0
>>
>> hold_time: 1000
>> inflight: 4542
>> limit: 3378
>> limit_max: 1879048192
>> limit_min: 0
>>
>> i.e. 2 or 3 MTU sized packets in flight and the limit value lying
>> somewhere between those two values.
>>
>> The interesting thing is that the interactive speed reported by scp
>> seemed somewhat erratic, ranging from ~450 to ~700kB/s. (This was
>> the only traffic on the old junk - perhaps expected oscillations such
>> as those seen in isolated ARED tests?) =A0Average speed for 100M was:
>>
>> 104857600 bytes (105 MB) copied, 172.616 s, 607 kB/s
>>
>
> Still half duplex, or full duplex ?
>
> Limiting to one packet on half duplex might avoid collisions :)
Ah yes. It was even in the text I'd had above!
PHY: mdio@e0024520:19 - Link is Up - 10/Half
Now the slowdown makes sense to me.
Thanks for the review as well.
Paul.
>
>> Anyway, back to BQL testing; setting the values as follows:
>>
>> hold_time: 1000
>> inflight: 1514
>> limit: 1400
>> limit_max: 1400
>> limit_min: 1000
>>
>> had the effect of serializing the interface to a single packet, and
>> the crusty old hub seemed much happier with this arrangement, keeping
>> a constant speed and achieving the following on a 100MB Tx block:
>>
>> 104857600 bytes (105 MB) copied, 112.52 s, 932 kB/s
>>
>> It might be interesting to know more about why the defaults suffer
>> the slowdown, but the hub could possibly be ancient spec violating
>> trash. =A0Definitely something that nobody would ever use for anything
>> today. (aside from contrived tests like this)
>>
>> But it did give me an example of where I could see the effects of
>> changing the BQL settings, and I'm reasonably confident they are
>> working as expected.
>>
>
> Seems pretty good to me !
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-03-18 20:49 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <CALT56yOaxfWYwxvBDbo9dpWo9y37dO0iGge4x6kciZp1oXXHVw@mail.gmail.com>
On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:
> On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:
> >> Hello,
> >>
> >> I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
> >>
> >> The peculiarity of this platform is the fact that it has
> >> sizeof(unsigned long) = 4,
> >> but physical address on it is 36 bits width. It is a common to various pieces
> >> of the code to expect that unsigned long variable is able to contain physical
> >> address. Most of those places are easy to fix.
> >
> > Yes. In fact, Tony (CC) has some patches to fix a lot of the DRM
> > infrastructure (we have radeon KMS working on a similar platform).
>
> That is interesting! Are those patches published or otherwise available
> somewhere? We are also very interested in enabling Canyonlands
> with Radeon KMS!
You will run into additional problems with 460 due to the fact that it's
not cache coherent for DMA. Tony patches don't address that part of the
problem (they were used on a 476 based platform).
> > In fact, we could make the new structure such that it doesn't break
> > userspace compatibility with 64-bit architectures at all, ie, the "new"
> > and "compat" ioctl could remain entirely equivalent on 64-bit.
>
> I remember stuff about compat_ioctl, but I have never used/implemented
> that. Are there any details of requirements for the structures being passed?
In that specific case, I meant something else. IE. The old ioctl could
remain unchanged, and the new ioctl make the same as the old one on
64-bit platforms.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH net-next 1/3] gianfar: Add support for byte queue limits.
From: Paul Gortmaker @ 2012-03-18 21:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linuxppc-dev, davem, therbert
In-Reply-To: <1332102032.3722.53.camel@edumazet-laptop>
On Sun, Mar 18, 2012 at 4:20 PM, Eric Dumazet <eric.dumazet@gmail.com> wrot=
e:
> Le dimanche 18 mars 2012 =E0 12:56 -0400, Paul Gortmaker a =E9crit :
>
> ...
>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* we add this skb back into the pool, if =
it's the right size
>> @@ -2557,13 +2568,15 @@ static int gfar_clean_tx_ring(struct gfar_priv_t=
x_q *tx_queue)
>> =A0 =A0 =A0 }
>>
>> =A0 =A0 =A0 /* If we freed a buffer, we can restart transmission, if nec=
essary */
>> - =A0 =A0 if (__netif_subqueue_stopped(dev, tx_queue->qindex) && tx_queu=
e->num_txbdfree)
>> - =A0 =A0 =A0 =A0 =A0 =A0 netif_wake_subqueue(dev, tx_queue->qindex);
>> + =A0 =A0 if (__netif_subqueue_stopped(dev, tqi) && tx_queue->num_txbdfr=
ee)
>> + =A0 =A0 =A0 =A0 =A0 =A0 netif_wake_subqueue(dev, tqi);
>>
>
> You can use netif_tx_queue_stopped(txq) here instead of
> __netif_subqueue_stopped(dev, tqi)
Yes, and it looks better too. I will do it as a patch #4 since I think
there is some small value in leaving the above patch chunk alone,
since it makes it clear that it was just the introduction of a local
variable and the code was otherwise unchanged here.
Will resend shortly....
Thanks,
Paul.
---
>
>> =A0 =A0 =A0 /* Update dirty indicators */
>> =A0 =A0 =A0 tx_queue->skb_dirtytx =3D skb_dirtytx;
>> =A0 =A0 =A0 tx_queue->dirty_tx =3D bdp;
>>
>> + =A0 =A0 netdev_tx_completed_queue(txq, howmany, bytes_sent);
>> +
>> =A0 =A0 =A0 return howmany;
>> =A0}
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] net, phy: am79c874 support
From: Anatolij Gustschin @ 2012-03-18 21:13 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <4E2E48A8.6070108@denx.de>
Hello Heiko,
On Tue, 26 Jul 2011 06:55:04 +0200
Heiko Schocher <hs@denx.de> wrote:
> Hello,
>
> Heiko Schocher wrote:
> > Signed-off-by: Heiko Schocher <hs@denx.de>
> > cc: linux-netdev@vger.kernel.org
> > cc: Wolfgang Denk <wd@denx.de>
> > ---
> > drivers/net/phy/Kconfig | 5 ++
> > drivers/net/phy/Makefile | 1 +
> > drivers/net/phy/amd79.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 115 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/net/phy/amd79.c
>
> Are there some more comments or is this patch ready for going
> to mainline?
This patch is not ready yet and it seems it didn't reach the netdev
list, probably because of wrong netdev address. I reworked it a bit
and have sent a new version to the netdev list.
Thanks,
Anatolij
^ 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