On 2013-08-12 1:54 AM, Joe XUE wrote:
> NAND flash has very high possibility to have bad blocks.
>
> Some bootloaders such as u-boot support to skip bad blocks when it read
> the kernel image from NAND falsh.
>
> For now, the mtd just exits when it meets the bad block. That means even
> there is
NAND flash has very high possibility to have bad blocks.
Some bootloaders such as u-boot support to skip bad blocks when it read
the kernel image from NAND falsh.
For now, the mtd just exits when it meets the bad block. That means even
there is one bad block in NAND flash, then we can't use mtd t
On 11 August 2013 22:13, Rafał Miłecki wrote:
> Ah, I'm sorry. I didn't realize that my patches removed memcpy and
> reintroduced unaligned access problem... That problem is pretty
> complex, and that ar71xx don't really make that much easier.
>
That's fine! The complexity is almost certainly wh
2013/8/11 Robert Bradley :
>
> On 11 Aug 2013 18:13, "Rafał Miłecki" wrote:
>>
>> 2013/8/11 Robert Bradley :
>> > it might be worth testing a build with these applied and use Florian's
>> > method instead (pass the current SKB to the stack as-is and create a new
>> > one
>> > for the next DMA read
Hi Rafał:
Should this:
/* Poison the old skb */
rx->len = cpu_to_le16(0xdead);
rx->flags = cpu_to_le16(0xbeef);
Be moved to here:
/* Make the header back accessible to the hardware */
if (resync_skb) {
/* Poison the head
2013/8/11 Nathan Hintz :
> Is there a penalty in synchronizing (DMA) more of the buffer than is needed?
> Here's a modified version of the patch that mostly eliminates the unneeded
> synchronization (there is another 24 bytes of pad in the RX header that could
> be eliminated - in both directio
Is there a penalty in synchronizing (DMA) more of the buffer than is needed?
Here's a modified version of the patch that mostly eliminates the unneeded
synchronization (there is another 24 bytes of pad in the RX header that could
be eliminated - in both directions); this hasn't been tested in a
2013/8/9, José Vázquez :
> 2013/8/4, José Vázquez :
> Finally, my colleague and me tested trunk r37737 enabling FPU
> emulation and switching to kernel 3.10.4 and now we haven't noticed
> nothing strange with jffs2.
> Jonas Gorski told us that would be a good idea make a compilation with
> GCC 4.8-
On 11 Aug 2013 18:13, "Rafał Miłecki" wrote:
>
> 2013/8/11 Robert Bradley :
> > it might be worth testing a build with these applied and use Florian's
> > method instead (pass the current SKB to the stack as-is and create a
new one
> > for the next DMA read).
>
> I already this trick, but it didn'
It makes more sense to allocate new (empty) skb and pass it to the
hardware. That way we avoid copying whole packet into new skb which
should result in better performance.
---
drivers/net/ethernet/broadcom/bgmac.c | 74 -
1 file changed, 54 insertions(+), 20 delet
---
drivers/net/ethernet/broadcom/bgmac.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c
b/drivers/net/ethernet/broadcom/bgmac.c
index 1b8e7a3..e70ee43 100644
--- a/drivers/net/ethernet/broadcom/bgmac
2013/8/11 Robert Bradley :
> it might be worth testing a build with these applied and use Florian's
> method instead (pass the current SKB to the stack as-is and create a new one
> for the next DMA read).
I already this trick, but it didn't help :( See my first e-mail from today.
--
Rafał
__
On 11/08/13 17:41, Rafał Miłecki wrote:
2013/8/11 Robert Bradley :
On 11/08/13 16:08, Rafał Miłecki wrote:
2013/8/9 Florian Fainelli :
I am looking at bgmac_dma_rx_read() and I do not quite understand why
you would need to copy data to the newly allocated SKB as it might
really be killing perf
2013/8/11 Robert Bradley :
> On 11/08/13 16:08, Rafał Miłecki wrote:
>>
>> 2013/8/9 Florian Fainelli :
>>>
>>> I am looking at bgmac_dma_rx_read() and I do not quite understand why
>>> you would need to copy data to the newly allocated SKB as it might
>>> really be killing performance here. Looking
2013/8/11 Rafał Miłecki :
> 2013/8/9 Florian Fainelli :
>> I think you might want to run "perf top" and run a relatively long
>> transfer, say 60 seconds and see what comes up above 5%. On the MIPS
>> platforms that I work with, doing checksum calculation was quite
>> expensive, so if the hardware
On 11/08/13 16:08, Rafał Miłecki wrote:
2013/8/9 Florian Fainelli :
I am looking at bgmac_dma_rx_read() and I do not quite understand why
you would need to copy data to the newly allocated SKB as it might
really be killing performance here. Looking at b44, the code path
doing this is just when t
2013/8/9 Florian Fainelli :
> I think you might want to run "perf top" and run a relatively long
> transfer, say 60 seconds and see what comes up above 5%. On the MIPS
> platforms that I work with, doing checksum calculation was quite
> expensive, so if the hardware can provide you with any kind of
2013/8/9 Florian Fainelli :
> I am looking at bgmac_dma_rx_read() and I do not quite understand why
> you would need to copy data to the newly allocated SKB as it might
> really be killing performance here. Looking at b44, the code path
> doing this is just when the packet is smaller (say less than
18 matches
Mail list logo
