I did a clean build, and now I'm not seeing the problem, so it must have
been something I messed up in my build.  Not sure what I did to cause
it; so, this patch should be discarded.  Interesting to me though that
the  "dma_sync_single_for_cpu" is generally doing nothing on MIPS.

Nathan

On Tue, 2013-02-12 at 03:10 +0100, Andreas Mohr wrote:
> Hi,
> 
> On Mon, Feb 11, 2013 at 12:00:01PM +0100, 
> [email protected] wrote:
> > Date: Sun, 10 Feb 2013 22:40:12 -0800
> > From: Nathan Hintz <[email protected]>
> 
> 
> > +-static inline int cpu_is_noncoherent_r10000(struct device *dev)
> > ++static inline int cpu_is_noncoherent(struct device *dev)
> > + {
> > +   return !plat_device_is_coherent(dev) &&
> > +          (current_cpu_type() == CPU_R10000 ||
> > +-         current_cpu_type() == CPU_R12000);
> > ++         current_cpu_type() == CPU_R12000 ||
> > ++         current_cpu_type() == CPU_74K);
> > + }
> 
> Would this also (not yet??) apply to
> 
> # cat /proc/cpuinfo 
> system type           : Broadcom BCM47XX
> processor             : 0
> cpu model             : Broadcom BCM3302 V2.9
> BogoMIPS              : 239.20
> wait instruction      : yes
> microsecond timers    : yes
> tlb_entries           : 32
> extra interrupt vector        : yes
> hardware watchpoint   : no
> ASEs implemented      : mips16
> shadow register sets  : 1
> core                  : 0
> VCED exceptions               : not available
> VCEI exceptions               : not available
> 
> 
> Linux version 2.6.34.5 (andi@note) (gcc version 4.3.3 (GCC) ) #2 Fri Sep
> 17 01:28:35 CEST 2010
> CPU revision is: 00029029 (Broadcom BCM3302)
> 
> 
> (ASUS WL-500gP V2; yeah, that installation is ooold...)
> 
> This system is noncoherent, right? (judging from earlier discussions,
> but perhaps that's wrong)
> If it is, then it would have to be marked, but I just cannot really
> figure out the actual cputype setting from the myriads of cputype
> assignments in cpu-probe.c, to see whether cpu_is_noncoherent() already
> includes the cputype which this system ends up with...
> At least it's PRID_COMP_BROADCOM, judging from CPU revision 00029029.
> 
> 
> It might also be a useful idea to add some per-cputype comments to this
> helper why (or why not) a certain CPU is thought to be (non-)coherent
> (with a most authoritative reference added each if available, ideally!).
> 
> Thanks,
> 
> Andreas Mohr
> 


_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to