RF_CACHEABLE flag

Adrian Chadd adrian.chadd at gmail.com
Wed Feb 24 17:14:22 UTC 2016


On 24 February 2016 at 02:27, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Tue, Feb 23, 2016 at 02:19:57PM -0600, Justin Hibbits wrote:
>> This really isn't much different from bus_space_map() conceptually.
>> The work involved is pretty much the same, and if this route is deemed
>> the Wrong Way(TM), I'll go that route.
>>
>> Grepping through sys/, only x86 currently implements
>> pmap_change_attr(), and arm has the declaration but no definition that
>> I could see.  Writing it wouldn't be difficult of course, there's just
>> not much compelling case for it right now.  But, yes, either of these
>> alternatives are acceptable, and I had explored it.  Seeing John
>> Baldwin's comment on the phab review, it looks like he wants to go a
>> different (parallel) direction.
>
> If this was not clear from my reply, I did not objected against RF_CACHEABLE,
> but was more to highlight weird needs of seemingly simple architecture,
> which are close to RF_CACHEABLE stuff.  And, I think that architectures
> that care about caching modes, should do provide real pmap_change_attr()
> implementation.  This might be important e.g. if drm is brought up on
> these platforms.

heh, on ARM it's not "when". For MIPS it's also now "when". So I guess
yeah, we should implement it.



-a

> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"


More information about the freebsd-arch mailing list