[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180311195116.GB4645@tivo.lan>
Date: Sun, 11 Mar 2018 14:51:16 -0500
From: Nick French <naf@...edu>
To: Andy Lutomirski <luto@...capital.net>
Cc: "Luis R. Rodriguez" <mcgrof@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
"hans.verkuil@...co.com" <hans.verkuil@...co.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: Re: ivtv: use arch_phys_wc_add() and require PAT disabled
On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote:
>>> Perhaps the easy answer is to change the fatal is-pat-enabled check to just
>>> a warning like "you have PAT enabled, so wc is disabled for the framebuffer.
>>> if you want wc, use the nopat parameter"?
>>
>> I like this idea more and more. I haven't experience any problems running
>> with PAT-enabled and no write-combining on the framebuffer. Any objections?
>>
>
> None from me.
>
> However, since you have the hardware, you could see if you can use the
> change_page_attr machinery to change the memory type on the framebuffer once
> you figure out where it is.
I am certainly willing to try this, but my understanding of the goal of the
changes that disabled ivtvfb originally is that it was trying to hide the
architecture-specific memory management from the driver.
Wouldn't (figuring out a way to) expose x86/mm/pageattr internals to the
driver be doing the opposite? (or maybe I misunderstand your suggestion)
- Nick
Powered by blists - more mailing lists