On Sun, Mar 11, 2018 at 11:24:38PM +, Ian Armstrong wrote:
> On Sat, 10 Mar 2018 16:57:41 +
> "French, Nicholas A." wrote:
>
> > > > No what if the framebuffer driver is just requested as a
> > > > secondary step after firmware loading?
> > >
> > > Its a possibility. The decoder firmwar
On Sun, Mar 11, 2018 at 01:19:03PM -0700, Andy Lutomirski wrote:
> From memory, I see two potentially reasonable real fixes. One is to find a
> way to punch a hole in an ioremap.
> So you’d find the framebuffer, remove it from theproblematic mapping, and
> then make a new mapping.
> The second i
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
wc caching on all systems.
Signed-off-by: Nick French
---
Changes in v2:
- Add wording to Kconfig parameter to memorialize the reasoning
this driver cannot easily be upgraded to use ioremap_wc()
drivers/media/pci/ivtv/Kconfig | 23 ---
drivers/media/pci/ivtv/ivt
uration is not necessary.
Add force_pat module parameter and a corresponding kernel
configuration parameter to optionally force initialization
on PAT-enabled x86 systems with a warning about the lack of
write-combined caching.
Signed-off-by: Nick French
---
drivers/media/pci/ivtv/Kco
5 matches
Mail list logo
