svn commit: r310650 - in head/sys/mips: include mips

[Alexander Kabaev]

On Tue, 27 Dec 2016 21:50:32 -0800
Adrian Chadd <adrian.chadd at gmail.com> wrote:

> hiya,
> 
> so I dug into the mips24k definition of this. It says this:
> 
> "
> 3.4.3 Uncached accelerated writes
> The 24K core permits memory regions to be marked as "uncached
> accelerated". This type of region is useful to hard-
> ware which is "write only" - perhaps video frame buffers, or some
> other hardware stream. Sequential word stores in
> such regions are gathered into cache-line-sized chunks, before being
> written with a single burst cycle on the CPU
> interface.
> Such regions are uncached for read, and partial-word or
> out-of-sequence writes have "unpredictable" effects - don't
> do them. The burst write is normally performed when software writes to
> the last location in the memory block or does
> an uncached-accelerated write to some other block; but it can also be
> triggered by a
> sync instruction, a pref nudge, a matching load or any exception. If
> the block is not completely written by the time it's pushed out, it
> will be written using a series of doubleword or smaller write cycles
> over the 24K core's 64-bit memory interface.
> "
> 
> So, question is - is our write combining page attribute in the VM
> suitable for this? Is it defined as "only do full sequential word
> writes"? Or do we risk having some other platform use it in a less
> "don't do this" way and then MIPS is the one at fault again? :)
> 
> 
> -adrian
> 
> 

FWIW, this is more or less standard verbiage for memory mapped devices
and devices is where one would expect framebuffer to reside, so I would
not read too much into it. I committed change that does not map UA to
WC unconditionally and will let people who need write combining to
enable it on a case by case basis. For now, only Ingenic XBursts are
doing so as these are ones I have tested.


-- 
Alexander Kabaev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 963 bytes
Desc: ???????????????? ?????????????? OpenPGP
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20161228/1ae6c25d/attachment.sig>