On Wed, Mar 07, 2018 at 07:02:05PM +0000, Luis R. Rodriguez wrote:
> On Tue, Mar 06, 2018 at 09:01:10PM +0000, French, Nicholas A. wrote:
> > any reason why PAT can't be enabled for ivtvfb as simply as in the attached
> > patch?
> Prior to your change the OSD buffer was obtained using the itv->dec_mem +
> given itv->dec_mem was initialized via [...]
> itv->dec_mem = ioremap_nocache(itv->base_addr + IVTV_DECODER_OFFSET -
Ah, I see. So my proposed ioremap_wc call was only "working" by aliasing the
ioremap_nocache()'d mem area and not actually using write combining at all.
> So what I'd do is change the ioremap_nocache()'d size by substracting
> oi->video_buffer_size -- but then you have to ask yourself how you'd get
> that size. If its something you can figure out then great.
Size is easy since its hardcoded, but unfortunately getting the offset of the
framebuffer inside the decoders memory to remove from the ioremap_nocache call
is a chicken and egg problem: the offset is determined by querying the firmware
that has been loaded to the decoder. the firmware itself will be loaded after
the ioremap_nocache call at an offset from the address it returns.
So unless there is a io-re-remap to change the caching status of a subset of
the decoder's memory once we find out what the framebuffer offset is inside the
original iremap_nocache'd area, then its a no go for write combining to the
framebuffer with PAT.
On the other hand, it works fine for me with a nocache'd framebuffer. It's
certainly better for me personally to have a nocache framebuffer with
PAT-enabled than the framebuffer completely disabled with PAT-enabled, but I
don't think I would even propose to rollback the x86 nopat requirement in
general. Apparently the throngs of people using this super-popular driver
feature haven't complained in the last couple years, so maybe its OK for me to
just patch the pat-enabled guard out and deal with a nocache'd framebuffer.