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 + > oi->video_rbase > given itv->dec_mem was initialized via [...] > itv->dec_mem = ioremap_nocache(itv->base_addr + IVTV_DECODER_OFFSET - > oi->video_buffer_size, > IVTV_DECODER_SIZE);
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. - Nick
