RE: MPC8313e RDB rev A4 and rev C network throughput

[Liu Dave-R63238]

One possible cause is the two board has different RCW.
So that the freq of core/csb/ Is different. 

> -Original Message-
> From: 
> linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org 
> [mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlab
> s.org] On Behalf Of RONETIX - Asen Dimov
> Sent: Tuesday, December 22, 2009 6:28 AM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: MPC8313e RDB rev A4 and rev C network throughput
> 
> Hello all,
> I have made some test on network throughput with MPC8313e RDB 
> revA4 and revC.
> Some have mentioned that CSB(Coherent System Bus) frequency 
> or untuned TCP/IP stack, could cause decrease of network throughput.
> 
> **Test results
> 
> -on MPC8313e RDB revA4 with kernel 2.6.20 and u-boot 1.1.6 
> created with
> ltib-mpc8313erdb-20070824
> iperf -c 172.16.0.1 -l 2m -w 256k -throughput is 510Mbps
> 
> 
> -on MPC8313e RDB revA4 with kernel 2.6.23 and u-boot 1.3.0 generated 
> with ltib-mpc8313erdb-20081222
> iperf -c 172.16.0.1 -l 2m -w 256k
> -throughput is 510Mbps
> 
> 
> -on MPC8313e RDB revC with kernel 2.6.23 (the same u-boot, kernel and 
> rootfs as in rev A4, only dtb file differs)
> iperf -c 172.16.0.1 -l 2m -w 256k
> -throughput is 360Mbps.
> 
> 
> Have someone made such measurements? Any ideas why MPC8313e RDB revC 
> gives worser throughput than revA4?
> 
> ** Notes
> *The PC (CPU:Intel(R) Core(TM)2 Duo CPU, E8400 @ 3.00GHz;
>  RAM:  2x2G DDR2 @ 800Mhz ;
>  NIC: R8168B PCI Express Gigabit Ethernet controller, driver 
> 8.014.00-NAPI;
>  OS: Fedora release 10 (Cambridge) with kernel: 
> 2.6.27.38-170.2.113.fc10.i686.PAE #1 SMP )
> *Commnads to set PC
> 
> ethtool -s eth0 autoneg off speed 1000 duplex full
> ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 1
> echo 131071 > /proc/sys/net/core/rmem_max
> echo 131071 > /proc/sys/net/core/wmem_max
> echo "40961048576   8388608" > /proc/sys/net/ipv4/tcp_rmem
> echo "40961048576   8388608" > /proc/sys/net/ipv4/tcp_wmem
> iperf -s -l 2m -w 70k
> 
> 
> *The MPC8313e RDB(CPU: 333Mhz; CSB: 166Mhz) revA4 and 
> revC(using PHY not 
> switch)
> *Commnads to set a board before using iperf
> 
> ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 1
> #The PC  lan card is set to advertise 1000Mbps only, so the 
> board switches to 1000Mbps too.
> echo 131071 > /proc/sys/net/core/rmem_max
> echo 131071 > /proc/sys/net/core/wmem_max
> echo "40961048576   8388608" > /proc/sys/net/ipv4/tcp_rmem
> echo "40961048576   8388608" > /proc/sys/net/ipv4/tcp_wmem
> 
> Regards,
> Asen
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: ucc_geth: Fix the wrong the Rx/Tx FIFO size

[Liu Dave-R63238]

> On Fri, Nov 27, 2009 at 04:16:43PM +0800, Dave Liu wrote:
> > current the Rx/Tx FIFO size settings cause problem
> > when four UEC ethernets work simultaneously.
> > 
> > eg: GETH1, UEM-J15, GETH2, UEC-J5 on 8569MDS board
> > 
> >  $ ifconfig eth0 10.193.20.166
> >  $ ifconfig eth1 10.193.20.167
> >  $ ifconfig eth2 10.193.20.168
> >  then
> >  $ ifconfig eth3 10.193.20.169
> > 
> > The fourth ethernet will cause all of interface broken,
> > you cann't ping successfully any more.
> > The patch fix this issue for MPC8569 Rev1.0 and Rev2.0
> > 
> > Signed-off-by: Dave Liu 
> 
> Acked-by: Anton Vorontsov 
> 
> Thanks Dave! I see that the new values actually match the QEIWRM
> spec (except UTFS... spec recommends 2048, but it also says that
> it might differ for different memory setups, though that's a
> separate issue).
> 
> And FWIW, I did some quick netperf tests on MPC8360, and the
> patch doesn't cause any problems.

David,

How about this patch? Please consider to pick it up to your tree.

Thanks, Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [U-Boot-Users] MPC83xx - previous patch to set MBAR

[Liu Dave-r63238]

> > The end result simply adds a line to set MBAR to match IMMRBAR.
> > 
> > lis r3, [EMAIL PROTECTED]
> > ori r3, r3, [EMAIL PROTECTED]
> > stw r3, IMMRBAR(r4)
> > +   mtspr   MBAR, r3
> > 
> > Are these patches routinely added to the mainstream u-boot code? 
> > 
> > Is there any reason why this fix is not a good idea?
> > 
> does setting MBAR really fix anything?
> 
> MBAR doesn't live up to its name.  It's a general-purpose scratch
> register - the hardware doesn't do anything with it.  So, wrt 

Kim is right.

MBAR setting is added by two years ago, it is not really fix anything.

I set the MBAR to be easier to use the CodeWarriror. The CodeWarrior
must set the MBAR first, then it will be able to access the IMMR.

Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP]
and PEX_RDMA_CTRL[SNOOP]?

What is the freq settings? CORE/CSB bus.

Thanks, Dave



From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org] On Behalf
Of Ben Menchaca
Sent: Friday, March 06, 2009 12:33 PM
To: linuxppc-dev@ozlabs.org
Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited


I am working on a Freescale 8314e design, and the embedded
device is configured as a PCI-e endpoint running a 2.6.27-5 kernel.  For
context, we have written a kernel module which, among other things, uses
the RDMA/WDMA engine in the PCI-e IP block.  On the host side, these
DMAs are coherent.  However, on the embedded side, things are quite a
bit less rosy; we must manually flush/invalidate cache lines for
WDMA/RDMAs to occur successfully.  After speaking with (several) FAEs at
Freescale, we believe there is a configuration issue that is the cause,
but we have yet to have anyone successfully point to it.  

Disabling the data cache altogether resolves the issue entirely,
but of course, also completely tanks performance.  As a temporary
workaround, I would like to simply mark the pages (obtained currently
via dma_alloc_coherent) involved as cache-inhibited.  I have attempted
to do this via some snippets remaining in fec.c (va_to_pte, uncache_pte
to set _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is
almost certainly braindead; va_to_pte is not a part of the 83xx source,
as far as I can tell; 8xx only.

A quick pointer in the correct direction for marking pages as
cache-inhibited on a 2.6.27-5 kernel would be appreciated, or if my
approach to a workaround is flawed, a pointer to the correct way would
be great.

Ben Menchaca


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

and what settings  is DMA description bit 3?

> -Original Message-
> From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org 
> [mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org]
>  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
> 
> Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and 
> PEX_RDMA_CTRL[SNOOP]?
> 
> What is the freq settings? CORE/CSB bus.
> 
> Thanks, Dave
> 
> 
> 
>   From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009 12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited
>   
>   
>   I am working on a Freescale 8314e design, and the 
> embedded device is configured as a PCI-e endpoint running a 
> 2.6.27-5 kernel.  For context, we have written a kernel 
> module which, among other things, uses the RDMA/WDMA engine 
> in the PCI-e IP block.  On the host side, these DMAs are 
> coherent.  However, on the embedded side, things are quite a 
> bit less rosy; we must manually flush/invalidate cache lines 
> for WDMA/RDMAs to occur successfully.  After speaking with 
> (several) FAEs at Freescale, we believe there is a 
> configuration issue that is the cause, but we have yet to 
> have anyone successfully point to it.  
>   
>   Disabling the data cache altogether resolves the issue 
> entirely, but of course, also completely tanks performance.  
> As a temporary workaround, I would like to simply mark the 
> pages (obtained currently via dma_alloc_coherent) involved as 
> cache-inhibited.  I have attempted to do this via some 
> snippets remaining in fec.c (va_to_pte, uncache_pte to set 
> _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is 
> almost certainly braindead; va_to_pte is not a part of the 
> 83xx source, as far as I can tell; 8xx only.
>   
>   A quick pointer in the correct direction for marking 
> pages as cache-inhibited on a 2.6.27-5 kernel would be 
> appreciated, or if my approach to a workaround is flawed, a 
> pointer to the correct way would be great.
>   
>   Ben Menchaca
>   
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

what is the value of ACR register?




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010, and covers all 64M
2.  PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020
3.  PEX_xDMA_CTRL is set to 0x0401 at the initiation of the
DMA.
4.  OWAR0 is set to 0xF005, so NSNP is 0.
5.  The DMA descriptor (randomly chosen when I hit a
trigger...just ignore the size...) contains 0002AFF3 at offset 0, so
nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238
 wrote:


and what settings  is DMA description bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]

>  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or Allocating Pages as
Cache-Inhibited
>
> Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP]
and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB bus.
>
> Thanks, Dave
>
> 
>
>   From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009 12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or Allocating Pages as
Cache-Inhibited
>
>
>   I am working on a Freescale 8314e design, and
the
> embedded device is configured as a PCI-e endpoint
running a
> 2.6.27-5 kernel.  For context, we have written a
kernel
> module which, among other things, uses the RDMA/WDMA
engine
> in the PCI-e IP block.  On the host side, these DMAs
are
> coherent.  However, on the embedded side, things are
quite a
> bit less rosy; we must manually flush/invalidate cache
lines
> for WDMA/RDMAs to occur successfully.  After speaking
with
> (several) FAEs at Freescale, we believe there is a
> configuration issue that is the cause, but we have yet
to
> have anyone successfully point to it.
>
>   Disabling the data cache altogether resolves the
issue
> entirely, but of course, also completely tanks
performance.
> As a temporary workaround, I would like to simply mark
the
> pages (obtained currently via dma_alloc_coherent)
involved as
> cache-inhibited.  I have attempted to do this via some
> snippets remaining in fec.c (va_to_pte, uncache_pte to
set
> _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but
this is
> almost certainly braindead; va_to_pte is not a part of
the
> 83xx source, as far as I can tell; 8xx only.
>
>   A quick pointer in the correct direction for
marking
> pages as cache-inhibited on a 2.6.27-5 kernel would be
> appreciated, or if my approach to a workaround is
flawed, a
> pointer to the correct way would be great.
>
>   Ben Menchaca
>
>

> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

could you try to set '1' to DMA description bit3?




    From: Liu Dave-R63238 
Sent: Friday, March 06, 2009 1:41 PM
To: 'Ben Menchaca'
Cc: linuxppc-dev@ozlabs.org
Subject: RE: 83xx: Marking or Allocating Pages as
Cache-Inhibited


what is the value of ACR register?




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
        To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010, and covers all
64M
2.  PEX_DEVICE_CONTROL in PCI-E Config Space (0x54):
0x1020
3.  PEX_xDMA_CTRL is set to 0x0401 at the initiation
of the DMA.
4.  OWAR0 is set to 0xF005, so NSNP is 0.
5.  The DMA descriptor (randomly chosen when I hit a
trigger...just ignore the size...) contains 0002AFF3 at offset 0, so
nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238
 wrote:


and what settings  is DMA description bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]

        >  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or Allocating Pages
as Cache-Inhibited
>
> Did you enable the snoop bit at
PEX_WDMA_CTRL[SNOOP] and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB bus.
>
> Thanks, Dave
>
> 
>
>   From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009 12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or Allocating
Pages as Cache-Inhibited
>
>
>   I am working on a Freescale 8314e
design, and the
> embedded device is configured as a PCI-e
endpoint running a
> 2.6.27-5 kernel.  For context, we have written
a kernel
> module which, among other things, uses the
RDMA/WDMA engine
> in the PCI-e IP block.  On the host side,
these DMAs are
> coherent.  However, on the embedded side,
things are quite a
> bit less rosy; we must manually
flush/invalidate cache lines
> for WDMA/RDMAs to occur successfully.  After
speaking with
> (several) FAEs at Freescale, we believe there
is a
> configuration issue that is the cause, but we
have yet to
> have anyone successfully point to it.
>
>   Disabling the data cache altogether
resolves the issue
> entirely, but of course, also completely tanks
performance.
> As a temporary workaround, I would like to
simply mark the
> pages (obtained currently via
dma_alloc_coherent) involved as
> cache-inhibited.  I have attempted to do this
via some
> snippets remaining in fec.c (va_to_pte,
uncache_pte to set
> _PAGE_NO_CACHE, flush_tlb_page, then
unmap_pte), but this is
> almost certainly braindead; va_to_pte is not a
part of the
> 83xx source, as far as I can tell; 8xx only.
>
>   A quick pointer in the correct

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

Did you enable the descriptor bit 3 to have a try?




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 2:10 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


I can look at ACR morning...although I can say with a fair
amount of certainty that I have not changed it from the POR value.

I will try enabling No Snoop for CSB in the descriptor (bit 3,
yes?)...this seems a bit counterintuitive to me.

What is the hope regarding these two?  Some combination I am not
seeing?



On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238
 wrote:


what is the value of ACR register?




From: Ben Menchaca
[mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages
as Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010, and
covers all 64M
2.  PEX_DEVICE_CONTROL in PCI-E Config Space
(0x54): 0x1020
3.  PEX_xDMA_CTRL is set to 0x0401 at the
initiation of the DMA.
4.  OWAR0 is set to 0xF005, so NSNP is 0.
5.  The DMA descriptor (randomly chosen when I
hit a trigger...just ignore the size...) contains 0002AFF3 at offset 0,
so nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238
 wrote:


and what settings  is DMA description
bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]

>  On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca;
linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
> Did you enable the snoop bit at
PEX_WDMA_CTRL[SNOOP] and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB
bus.
>
> Thanks, Dave
>
> 
>
>   From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]
>  On Behalf Of Ben Menchaca
>   Sent: Friday, March 06, 2009
12:33 PM
>   To: linuxppc-dev@ozlabs.org
>   Subject: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
>
>   I am working on a Freescale
8314e design, and the
> embedded device is configured as a
PCI-e endpoint running a
> 2.6.27-5 kernel.  For context, we have
written a kernel
> module which, among other things, uses
the RDMA/WDMA engine
> in the PCI-e IP block.  On the host
side, these DMAs are
> coherent.  However, on the embedded
side, things are quite a
> bit less rosy; we must manually
flush/invalidate cache lines
> for WDMA/RDMAs to occur successfully.
After speaking with
> (several) FAEs at Freescale, we
believe there is a
> configurati

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

Timur,

See the section 14.7.1 DMA Description Format at page 14-112
of MPC8315ERM rev.1.


> -Original Message-
> From: timur.t...@gmail.com [mailto:timur.t...@gmail.com] On 
> Behalf Of Tabi Timur-B04825
> Sent: Sunday, March 08, 2009 11:20 PM
> To: Liu Dave-R63238
> Cc: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
> 
> On Fri, Mar 6, 2009 at 12:49 AM, Liu Dave-R63238 
>  wrote:
> > could you try to set '1' to DMA description bit3?
> 
> Dave,
> 
> I'm looking at the 8315e reference manual.  What is "DMA 
> description bit 3"?
> 
> --
> Timur Tabi
> Linux kernel developer at Freescale
> 
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

Hi Ben,
 
The second issue. you told me "some hosts" has problem,
and some hosts worked well.
 
what is the problem-hosts?
 
The issue seems like the hosts did set the NO SNOOP attribute
bit at TLP.
 
The PEX_DEVICE_CONTROL is standard PCI configuration space
register, it controls the behavior of the initiator's transaction.
For 8315, it is outbound, not inbound transaction.
 
Thanks, Dave




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Saturday, March 07, 2009 12:30 AM
    To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


Thank you for your help!  That bit resolved all of the RDMA/WDMA
coherency issues on the CSB side...except:

We expose a 1MB region of memory from CSB via a BAR (BAR1, if it
matters) to the Host.  This region is also not behaving correctly with
respect to coherency on SOME hosts; again, disabling our cache makes it
work correctly on all hosts.  We have set PEX_DEVICE_CONTROL in PCI-E
Config Space (0x54) to 0x2010 (sorry about the endianness below).  We
thought that CLEARING the no-snoop bit here would indicate that snooping
was required for this region...is this a similar issue?

- Ben


On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca
 wrote:


Testing now...it looks like it (almost) works, though!
Why does setting no-snoop cause snooping to work?  More on the effect on
setting that bit in a few minutes...need more testing.
 
ACR is 0x00030300.

- Ben 


On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238
 wrote:


Did you enable the descriptor bit 3 to have a
try?





From: Ben Menchaca
[mailto:ben.mench...@gmail.com] 

Sent: Friday, March 06, 2009 2:10 PM 

        To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited


I can look at ACR morning...although I
can say with a fair amount of certainty that I have not changed it from
the POR value.

I will try enabling No Snoop for CSB in
the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me.

What is the hope regarding these two?
Some combination I am not seeing?



On Thu, Mar 5, 2009 at 11:40 PM, Liu
Dave-R63238  wrote:


what is the value of ACR register?




From: Ben Menchaca
[mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
        To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010,
and covers all 64M
2.  PEX_DEVICE_CONTROL in PCI-E Config
Space (0x54): 0x1020
3.  PEX_xDMA_CTRL is set to 0x0401
at the initiation of the DMA.
4.  OWAR0 is set to 0xF005, so NSNP
is 0.
5.  The DMA descriptor (randomly chosen
when I hit a trigger...just ignore the size...) contains 0002AFF3 at
offset 0, so nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu
Dave-R63238  wrote:


and what settings  is DMA description
bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]

      

RE: 83xx: Marking or Allocating Pages as Cache-Inhibited

[Liu Dave-R63238]

Hi Ben,
 
The second issue. you told me "some hosts" has problem,
and some hosts worked well.
 
what is the problem-hosts?
 
The issue seems like the hosts did set the NO SNOOP attribute
bit at TLP.
 
The PEX_DEVICE_CONTROL is standard PCI configuration space
register, it controls the behavior of the initiator's transaction.
For 8315, it is outbound, not inbound transaction.
 
Thanks, Dave




From: Ben Menchaca [mailto:ben.mench...@gmail.com] 
Sent: Saturday, March 07, 2009 12:30 AM
    To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited


Thank you for your help!  That bit resolved all of the RDMA/WDMA
coherency issues on the CSB side...except:

We expose a 1MB region of memory from CSB via a BAR (BAR1, if it
matters) to the Host.  This region is also not behaving correctly with
respect to coherency on SOME hosts; again, disabling our cache makes it
work correctly on all hosts.  We have set PEX_DEVICE_CONTROL in PCI-E
Config Space (0x54) to 0x2010 (sorry about the endianness below).  We
thought that CLEARING the no-snoop bit here would indicate that snooping
was required for this region...is this a similar issue?

- Ben


On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca
 wrote:


Testing now...it looks like it (almost) works, though!
Why does setting no-snoop cause snooping to work?  More on the effect on
setting that bit in a few minutes...need more testing.
 
ACR is 0x00030300.

- Ben 


On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238
 wrote:


Did you enable the descriptor bit 3 to have a
try?





From: Ben Menchaca
[mailto:ben.mench...@gmail.com] 

Sent: Friday, March 06, 2009 2:10 PM 

        To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited


I can look at ACR morning...although I
can say with a fair amount of certainty that I have not changed it from
the POR value.

I will try enabling No Snoop for CSB in
the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me.

What is the hope regarding these two?
Some combination I am not seeing?



On Thu, Mar 5, 2009 at 11:40 PM, Liu
Dave-R63238  wrote:


what is the value of ACR register?




From: Ben Menchaca
[mailto:ben.mench...@gmail.com] 
Sent: Friday, March 06, 2009 1:38 PM
        To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited


1.  BAT2 in linux is set to WIMG=0010,
and covers all 64M
2.  PEX_DEVICE_CONTROL in PCI-E Config
Space (0x54): 0x1020
3.  PEX_xDMA_CTRL is set to 0x0401
at the initiation of the DMA.
4.  OWAR0 is set to 0xF005, so NSNP
is 0.
5.  The DMA descriptor (randomly chosen
when I hit a trigger...just ignore the size...) contains 0002AFF3 at
offset 0, so nosnoops are cleared.  

Core is 400MHz, and CSB is 133MHz.

- Ben


On Thu, Mar 5, 2009 at 11:27 PM, Liu
Dave-R63238  wrote:


and what settings  is DMA description
bit 3?


> -Original Message-
> From:
linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale@ozlabs.org]

      

Re: [PATCH] powerpc: Add support for CoreInt delivery of interrupts onMPIC

[Liu Dave-R63238]

--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -22,6 +22,7 @@
 #define MPIC_GREG_FEATURE_10x00010
 #define MPIC_GREG_GLOBAL_CONF_00x00020
 #defineMPIC_GREG_GCONF_RESET   0x8000
+#defineMPIC_GREG_GCONF_COREINT 0x4000
 #defineMPIC_GREG_GCONF_8259_PTHROU_DIS 0x2000
 #defineMPIC_GREG_GCONF_NO_BIAS 0x1000
 #defineMPIC_GREG_GCONF_BASE_MASK   0x000f


according to the latest UM, the MPIC_GREG_GCONF_COREINT should be
0x6000.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Interrupt ID number on mpc8347

[Liu Dave-R63238]

> It's because the irqs are remapped by the kernel, the number in the
> device tree is a hardware irq number. The number you're printing out is
> a virtual irq number.

> of_irq_to_resource() is doing the remapping for you.

> You can turn on CONFIG_VIRQ_DEBUG and you'll get a file in debugfs that
> shows the mapping between hardware numbers and virtual numbers.

Guys,

I notice many people happened same issue to use the interrupt in powerpc
with DTS.
Could somebody write one documentation for interrupt system on powerpc arch,
 - how to remap irq
 - what is the virq? h/w irq.
 - show the mapping virt->h/w..
etc..
I think if have this docs, it will be helpful.

Thanks, Dave

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Potential performance issue on DMA_FROM_DEVICE

[Liu Dave-R63238]

Guys,

The commit 03d70617 is using the dcbf for all of unaligned start
or non-multi cache line of size. It will cause performance lost
due to dcbf all M-state cache line in the whole address range
(start->end). It causes unnecessary bus traffic (when the mid part
of range with M-state).

However, we actually need care for only unaligned head part and
unaligned tail part of range (start->end).

Patch welcomed.

Thanks, Dave

Ps:
/*
 * make an area consistent.
 */
void __dma_sync(void *vaddr, size_t size, int direction)
{
unsigned long start = (unsigned long)vaddr;
unsigned long end   = start + size;

switch (direction) {
case DMA_NONE:
BUG();
case DMA_FROM_DEVICE:
/*
 * invalidate only when cache-line aligned otherwise
there is
 * the potential for discarding uncommitted data from
the cache
 */
if ((start & (L1_CACHE_BYTES - 1)) || (size &
(L1_CACHE_BYTES - 1)))
flush_dcache_range(start, end);
else
invalidate_dcache_range(start, end);
break;
case DMA_TO_DEVICE: /* writeback only */
clean_dcache_range(start, end);
break;
case DMA_BIDIRECTIONAL: /* writeback and invalidate */
flush_dcache_range(start, end);
break;
}
}
EXPORT_SYMBOL(__dma_sync);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH v3] powerpc/85xx: Add P2020DS board support

[Liu Dave-R63238]

> + L2: l2-cache-control...@2 {
> + compatible = "fsl,p2020-l2-cache-controller";
> + reg = <0x2 0x1000>;
> + cache-line-size = <32>; // 32 bytes
> + cache-size = <0x10>; // L2, 1M
> + interrupt-parent = <&mpic>;
> + interrupts = <16 2>;
> + };

One nit --here should be 512KB L2 cache

> + u...@22000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl-usb2-mph";
> + reg = <0x22000 0x1000>;
> + interrupt-parent = <&mpic>;
> + interrupts = <28 0x2>;
> + phy_type = "ulpi";
> + };

It should be "fsl-usb2-dr"
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: freeze when reading a PCI bridge register

[Liu Dave-R63238]

> I' am trying to configure a PCI bridge on a private board, with a 
> powerpc . In a first time, I tried to get informations about PCI 
> devices, in order to be sure  that  my read  and write methods work ( 
> using 2 configuration registers, like on an x86 architecture.) . 2 
> configuration registers  are used, for example we  write  an encoded 
> address (it is a request to a PCI device) in the first and 
> the answer of 
> the PCI device can be read in the second register (it is a 
> configuration 
> cycle)
> Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
> 
> For example, the code used under u-boot:
> 
> volatile u32* addr;
> u32 vendor_device_ID;
> 
> puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
> addr=CFG_ADDR_PCI1;
> *addr=0x80007800;
> 
> addr= CFG_DATA_PCI1;
> vendor_device_ID= *addr;
> printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x  \n" ,vendor_device_ID);
> 
> 
> Therefore, when I do the same thing under Linux, the system 
> crash when I 
> try to read the second register...
> Linux is frozen, and there is no error message.
> Under Linux, I made an ioremap before use the registers and access to 
> these registers thanks to  functions  "in_be32" and "out_be32".
> I tried with different endianness to avoid an error of this type.
> 
> If I understand, the main difference between u-boot and Linux (about 
> registers access) is the activation of the MMU.
> So I thought that  problem could come from it. 
> I think the problem could came from the configuration of DBAT 
> and IBATS 
> registers of the MMU, but I didn't found any information 
> about the MMU 
> configuration under Linux.
> So after this novel, I have some questions:
> 
> -Is the MMU configuration generic under Linux?
> -Does somebody think that the problem doesn't come from MMU?
> -How does work ioremap? Is it a fully software function, or does it 
> speaks to MMU to get the effective address from physical address?
> -Does somebody have an idea, or a documentation about MMU 
> configuration 
> under linux?
> -Do you think that my MMU is under the control of an evil spirit? ^^
> 
What is the PowerPC you are using?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: freeze when reading a PCI bridge register

[Liu Dave-R63238]

So the host bridge is important, what is the bridge?
Marvell or Tundra chipset?
 




From: Nicolas Lavocat [mailto:nicolas.lavo...@fr.thalesgroup.com] 
Sent: Wednesday, April 22, 2009 4:32 PM
To: Liu Dave-R63238
Cc: linuxppc-dev
Subject: Re: freeze when reading a PCI bridge register


a 7448

Liu Dave-R63238 a écrit : 

I' am trying to configure a PCI bridge on a private 
board, with a 
powerpc . In a first time, I tried to get informations 
about PCI 
devices, in order to be sure  that  my read  and write 
methods work ( 
using 2 configuration registers, like on an x86 
architecture.) . 2 
configuration registers  are used, for example we  
write  an encoded 
address (it is a request to a PCI device) in the first 
and 
the answer of 
the PCI device can be read in the second register (it 
is a 
configuration 
cycle)
Firstly, I did it by JTAG: it works. Then, under uboot, 
it is ok.

For example, the code used under u-boot:

volatile u32* addr;
u32 vendor_device_ID;

puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
addr=CFG_ADDR_PCI1;
*addr=0x80007800;

addr= CFG_DATA_PCI1;
vendor_device_ID= *addr;
printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x  \n" 
,vendor_device_ID);


Therefore, when I do the same thing under Linux, the 
system 
crash when I 
try to read the second register...
Linux is frozen, and there is no error message.
Under Linux, I made an ioremap before use the registers 
and access to 
these registers thanks to  functions  "in_be32" and 
"out_be32".
I tried with different endianness to avoid an error of 
this type.

If I understand, the main difference between u-boot and 
Linux (about 
registers access) is the activation of the MMU.
So I thought that  problem could come from it. 
I think the problem could came from the configuration 
of DBAT 
and IBATS 
registers of the MMU, but I didn't found any 
information 
about the MMU 
configuration under Linux.
So after this novel, I have some questions:

-Is the MMU configuration generic under Linux?
-Does somebody think that the problem doesn't come from 
MMU?
-How does work ioremap? Is it a fully software 
function, or does it 
speaks to MMU to get the effective address from 
physical address?
-Does somebody have an idea, or a documentation about 
MMU 
configuration 
under linux?
-Do you think that my MMU is under the control of an 
evil spirit? ^^



What is the PowerPC you are using?

  

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] fsldma: use PCI Read Multiple command

[Liu Dave-R63238]

> By default, the Freescale 83xx DMA controller uses the PCI Read Line
> command when reading data over the PCI bus. Setting the 
> controller to use the PCI Read Multiple command instead allows the
> controller to read much larger bursts of data, which provides a
drastic
> speed increase.

IIRC, the default for 83xx DMA controller uses the PCI mem read
command, not mem read line.

You are assuming the PCI memory space is prefetchable( no side effect)
for DMA.
Is it possible that DMA is from non-prefetchable memory space?

> The slowdown due to using PCI Read Line was only observed 
> when a PCI-to-PCI bridge was between the devices trying to
communicate.
> 
> A simple test driver showed an increase from 4MB/sec to 116MB/sec when
> performing DMA over the PCI bus. Using DMA to transfer between blocks
> of local SDRAM showed no change in performance with this patch. 
> The dmatest driver was also used to verify the correctness of the
transfers,
> and showed no errors.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] fsldma: use PCI Read Multiple command

[Liu Dave-R63238]

> > You are assuming the PCI memory space is prefetchable( no 
> > side effect) for DMA.
> > Is it possible that DMA is from non-prefetchable memory space?
> 
> This should be a safe assumption for this driver.  Remember, this
> driver just does offload memcpy, from one region to another.  So the
> PCI memory that you are reading from should be just a buffer of data,
> and there should be side-effect of reading it.
> 
> However, I would like to see a comment at the top of the file warning
> people that copying from PCI memory will result in prefetched reads.

How about FIFO RAM case?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] fsldma: use PCI Read Multiple command

[Liu Dave-R63238]

> Here's a few results from DMA tests between two
> MPC8349EA boards housed in a CPCI chassis.
> 
> 1. DMA mode register (DMAMRn)
> PCI read command (PRC, bits 11:10)
> 
> a) DMAMRn[PRC] = 00 = PCI Read
> 
>The PCI read command is 6h on the PCI bus.
>For DMA lengths of less than 1 cache line (32-bytes)
>the DMA controller will generate a PCI 6h command.
>However, for lengths of 32-bytes and higher, the
>DMA controller actually generates a PCI Read Line (Eh)
>command.
> 
>Freescale indicated that this 'change of PCI command code'
>functionality is an undocumented 'feature', there to
>improve performance for longer read lengths.
> 
> b) DMAMRn[PRC] = 01 = PCI Read Line
> 
>Generated the PCI command code for PCI read line (Eh),
>regardless of DMA length.
> 
> c) DMAMRn[PRC] = 10 = PCI Read Multiple
> 
>Generated the PCI command code for PCI Read Multiple (Ch),
>regardless of DMA length.

Good summary!

For the DMA PCI read/line/multi-line is outbound transaction.
So according to your experiment, the 8349 PCI controller(as master)
attemp to streaming/combining the outbound transaction(treated as
prefetchable
space). 
IIRC, the early 8349EUM has the bit[2]-SE in the POCMRn
register, and is removed now. Not sure if it does function.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] fsldma: use PCI Read Multiple command

[Liu Dave-R63238]

> >> You can mark the pci inbound window on the 83xx as 
> >> non-prefetchable(assuming 83xx is host). On a x86 host
> >> I doubt there is any easy way to get non-prefetchable memory.

> One more note; we don't have access to a host-mode MPC8349EA,
> our boards are all targets.

Actually we also can use the inbound window(w/wo prefetchable)
in the agent mode. It doesn't care if it is host or agent.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH 2/2] powerpc/85xx: Add new LAW & MCM device tree nodes for all85xx systems

[Liu Dave-R63238]

> Subject: [PATCH 2/2] powerpc/85xx: Add new LAW & MCM device 
> tree nodes for all85xx systems

One nit/typo, the tittle of the two patches should be "ECM"
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] fsldma: use PCI Read Multiple command

[Liu Dave-R63238]

>> You are assuming the PCI memory space is prefetchable( no side effect)
>> for DMA.
>> Is it possible that DMA is from non-prefetchable memory space?

> This should be a safe assumption for this driver.  Remember, this
> driver just does offload memcpy, from one region to another.  So the
> PCI memory that you are reading from should be just a buffer of data,
> and there should be side-effect of reading it.

How about one FIFO buffer?

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Does U-BOOT (MPC8560) support Micron MT18VDD12872DG

[Liu Dave-R63238]

> I have a custom board similar to MPC8560ADS board with 1GB 
> DDR SDRAM. The DDR SDRAM Make
> is MT18VDDF12872DG-335D3. In U-BOOT (2009.01) config file I 
> have enabled CONFIG_SPD_EEPROM
> so U-boot configures MPC8560ADS DDR controller with the 
> values read from SPD_EEPROM (i2c
> address 0x51) 
> 
> After card reset U-BOOT runs from BOOT Flash and debug prints 
> start coming on SCC1 port
> But after configuring the MPC8560 DDR controller the U-BOOT 
> HANGS when it tries to run
> from RAM locations after relocation from BOOT Flash. 
> 
> Somewhere I read that it is due to failure of Burst Mode 
> access of RAM. But DDR SDRAM 
> inherently work in Burst Mode only. Moreover U-BBOT  
> initialized the DDR SDRAM Mode
> config register using SPD EEPROM values . The value indicate 
> that SDRAM is in Burst Mode
> 
> MPC8560 CPU Version is 2.0.2
> 
> Please help in understanding the issue here
> 
> The U-BOOT Details are
> --
> ---
> U-Boot 2009.01 (Apr 27 2009 - 14:17:09)
> 
> 
> CPU:   8560, Version: 2.0, (0x80700020)
> Core:  E500, Version: 2.0, (0x80200020)
> Clock Configuration:
>CPU:660  MHz, CCB:264  MHz,
>DDR:132  MHz (264 MT/s data rate), LBC:66   MHz
> CPM:   264 MHz
> L1:D-cache 32 kB enabled
>I-cache 32 kB enabled
> Board: ADS
> PCI1: 32 bit, 33 MHz (compiled)
> I2C:   ready
> DRAM:  Initializing
> SDRAM SPD EEPROM
> starting at step 1 (STEP_GET_SPD)
> 
>  MEM TYPE 0x7DDR: DDR I rank density = 0x2000
> mclk_ps = 7580
> i=0, x = 0, lowest_tCKmin_found = 0
> i=1, x = 7500, lowest_tCKmin_found = 0
> i=2, x = 6000, lowest_tCKmin_found = 7500
> i=3, x = 5000, lowest_tCKmin_found = 7500
> lowest_tCKmin_CL = 2
> Computing lowest common DIMM parameters for memctl=0
> using mclk_ps = 7580
> checking common caslat = 3
> CL = 3 ok on DIMM 0 at tCK=7580 ps with its tCKmin_X_ps of 6000
> checking common caslat = 2
> CL = 2 ok on DIMM 0 at tCK=7580 ps with its 
> tCKmin_X_minus_1_ps of 7500
> lowest common SPD-defined CAS latency = 2
> highest common dereated CAS latency = 2
> all DIMMs ECC capable
> Reloading memory controller configuration options for memctl=0
> mclk_ps = 7580 ps
> FSL Memory ctrl cg register computation
> FSLDDR: cs[0]_bnds = 0x001f
> FSLDDR: cs[0]_config = 0x80010103
> FSLDDR: cs[0]_config_2 = 0x
> FSLDDR: cs[1]_bnds = 0x0020003f
> FSLDDR: cs[1]_config = 0x80010103
> FSLDDR: cs[1]_config_2 = 0x
> FSLDDR: timing_cfg_3 = 0x
> FSLDDR: timing_cfg_1 = 0x36332422
> FSLDDR: timing_cfg_2 = 0x6482
> FSLDDR: ddr_sdram_cfg = 0xe200
> FSLDDR: ddr_sdram_cfg_2 = 0x20401000
> FSLDDR: ddr_sdram_mode = 0x0022
> FSLDDR: ddr_sdram_mode_2 = 0x
> FSLDDR: ddr_sdram_interval = 0x04060100
> FSLDDR: timing_cfg_4 = 0x
> FSLDDR: timing_cfg_5 = 0x
> 
> ...
> ...
> Some stack location related prints 
> ...
>  here   < checked with emulator its somewhere in 
> RAM but no prints coming

Have a try change clk_adjust, cpo_override, write_data_delay
in the board/freescale/mpc8560ads/ddr.c for your DIMMs.

Thanks, Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Net: ucc_geth ethernet driver optimization space

[Liu Dave-R63238]

Guys,

The ucc_geth ethernet driver have dozens of strong sync read/write
operation, such as in_be32/16/8, out_be32/16/8.

all of them is sync read/write, it is very expensive for performance.

For the critical patch, we can remove some unnecessary in_be(x),
out_be(x) with normal memory operation, and keep some necessary
memory barrier.

eg: BD access in the interrupt handler and start_xmit.

The BD operation only need the memory barrier between length/buffer
and status.

struct buffer descriptor {
u16 status;
u16 length;
u32 buffer;
} __attribute__ ((packed));

struct buffer descriptor *BD;

BD->length = ;
BD->buffer = ;
wmb();
BD->status = ;

For powerpc, eieio is enough for 60x, mbar 1 is enough for e500.
Of couse, also need the memory clobber to avoid the compiler
reorder between them.

Thanks, Dave


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH] pte_fsl_booke: fix instruction TLB error permission check

[Liu Dave-R63238]

> I've updated the commit message to be a bit more clear on why 
> we need to do this.

I'm curious why the _PAGE_EXEC have different definition in pte-book3e.h
and pte-fsl-booke.h?

It is UX permission in pte-book3e, but is SX permission in
pte-fsl-booke.h.

Thanks, Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] pte_fsl_booke: fix instruction TLB error permission check

[Liu Dave-R63238]

> Not looking at the code right now ... but do we have the same 
> issue on 64e ?

Aaron pointed the issue on FSL BookE.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079738.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] pte_fsl_booke: fix instruction TLB error permission check

[Liu Dave-R63238]

> > Aaron pointed the issue on FSL BookE.
> > 
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079738.htm
> > l
> 
> Right, but I think 64-bit BookE has the same issue. We can 
> fix that later tho.

Ben,

We also find the _PAGE_USER is different between pte-book3e and old
fsl-booke
It is UR in old fsl-booke, and is _PAGE_BAP_UR | _PAGE_BAP_SR in
pte-book3e,
which will cause the ioremap_flags issue.

Did you have a test your commit
[ea3cc330ac0cd521ff07c7cd432a1848c19a7e92]?

Thanks, Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] powerpc: Fix GENERIC_ISA_DMA dependency

[Liu Dave-R63238]

> On PowerPC we should always use generic ISA DMA API implementation
> as there is simply no other implementation exist.
> 
> Without this patch, the following build error pops up:
> 
>   sound/built-in.o: In function 'snd_dma_pointer':
>   (.text+0x74ae): undefined reference to 'dma_spin_lock'
>   ...
>   make: *** [.tmp_vmlinux1] Error 1
> 
> This is PPC_85xx, SMP and some sound drivers set to =y.
> 
> Signed-off-by: Anton Vorontsov 

Acked-by: Dave Liu 

I happened this issue when I developed P1022DS BSP.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: Problem with memcpy on ppc8536

[Liu Dave-R63238]

I believe the question should be sent to u-b...@lists.denx.de,
not linuxppc-dev list.

What is the TLB settings for NAND FCM buffer? Pay attention
to set the TLB as cache inhibited and guarded attribute.

If not set the guarded bit, it is possible to cause the speculate
load from FCM buffer below the cmplwi and blt inst.

IIRC, the FCM buffer only has the 4KB. So if it has one speculated
Load above the 4KB, it will run into problem.

The 0x700 is not alignment exception, it is program exception.

If you can dump the exception error information from console
to us, maybe we can give better help.

Thanks, Dave



From:
linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org] On
Behalf Of Fahd Abidi
Sent: Friday, June 19, 2009 4:34 AM
To: linuxppc-...@ozlabs.org
Subject: Problem with memcpy on ppc8536


Hello, 

I am trying to debug a crash during memcpy while copying data
from the FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy
enough through my BDI3000 to see that the entire contents of the fcm
buffer I want moved are actually moved off to memory location I specify.
The crash comes after it memcpy finishes copying and performs the
instruction "2: cmplwi 0,r5,4": 

memcpy: 
rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */ 
addi r6,r3,-4 
addi r4,r4,-4 
beq 2f /* if less than 8 bytes to do */ 
andi. r0,r6,3 /* get dest word aligned */ 
mtctr r7 
bne 5f 
1: lwz r7,4(r4) 
lwzu r8,8(r4) 
stw r7,4(r6) 
stwu r8,8(r6) 
bdnz 1b 
andi. r5,r5,7 
2: cmplwi 0,r5,4 

contents of r5 are 0x0 showing that the entire 0x1000 size
transfer I specified correctly finished. At this point I can check the
memory contents through my BDI and verify all the data is in the ddr as
I expect. Now the strange thing happens, if I execute the "cmplwi
0,r5,4" the program takes an exception and eventually gets struck at
exception vector 0x700 which I saw from start.S is an "Alignment"
exception. I am not sure what this exception means, can someone help me
understand what is happening? 

Does this exception somehow mean that memcpy did not move all
the data? Does memcpy expect contents of r5 to be 4 and not 0 when it
hits the cmplwi instruction? 


Fahd Abidi
Product Manager - Technical Tools and Development
Ultimate Solutions, Inc.

Your Single Source for Professional Development Tools and
Embedded Solutions
Ph: 978-455-3383 x255
Fx: 978-926-3091
Email: fab...@ultsol.com
Visit: http://www.ultsol.com   

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: MPC8313 performance evaluation

[Liu Dave-R63238]

> > On Aug 6, 2009, at 1:00 PM, Lutz Jaenicke wrote:
> >> With the mpc8...@400mhz I get a throughput of approx. 
> 24500 frames/s
> >> using the predefined firewall rules.
> 
> >> With the MPC8313 I get a significantly lower value:
> >> mpc8...@250mhz  12500fps
> >> mpc8...@333mhz  14500fps
> >> mpc8...@416mhz  15500fps  (333MHz type, overclocked)
> 
> > What DDR frequencies (and width) are you running the 8343 
> vs 8313 at.   
> > This can have a significant impact on performance.
> 
> The 8343 is running DDR2 32bit at 266MHz (CSB 266MHz)
> The 8313 is running DDR2 32bit at 333MHz (CSB 166MHz)
> 
> The test were performed with 128byte frames so that the overall
> bandwidth needed is far below even 100Mbit/s.

The CSB bus freq is key for the throught.
CSB freq of 8313 is lower than 8343, it will cause the performance
degrade.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: MPC8313 performance evaluation

[Liu Dave-R63238]

> Some discussion with the the freescale rep. lead to the CSB frequency
> of the 8313 (166MHz) being significantly lower than that of the 8343.
> Is the CSB the critical point here?

I believe the CSB is critical point here. They are right.

> Note: the IXP42x uses an internal bus speed of 133MHz and operates
> at frame rates similar to the 8343...

It is possible, IXP42x has the differenet SoC architecture with 83xx.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev