On Thu, Mar 08, 2018 at 04:14:11AM +0000, Luis R. Rodriguez wrote: > On Thu, Mar 08, 2018 at 04:06:01AM +0000, Luis R. Rodriguez wrote: > > On Thu, Mar 08, 2018 at 03:16:29AM +0000, French, Nicholas A. wrote: > > > > > > 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. > > > > There are some debugging PAT toys out there I think but I haven't played with > > them yet or I forgot how to to confirm or deny this sort of effort, but > > likeley. > > In fact come to think of it I believe some neurons are telling me that if > two type does not match we'd get an error? I based my guess on some text i read in "PATting Linux" [1]: "ioremap interfaces will succeed if there is an existing, more lenient mapping. Example: If there is an existing uncached mapping to a physical range, any request for write-back or write-combine mapping will succeed, but will eventually map the memory as uncached" But I will try to get some debugpat going to confirm. [1] = https://www.kernel.org/doc/ols/2008/ols2008v2-pages-135-144.pdf > > 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. > > No what if the framebuffer driver is just requested as a secondary step > after firmware loading? Its a possibility. The decoder firmware gets loaded at the beginning of the decoder memory range and we know its length, so its possible to ioremap_nocache enough room for the firmware only on init and then ioremap the remaining non-firmware decoder memory areas appropriately after the firmware load succeeds... > > > 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. > > > > Nope, best you add a feature to just let you disable wc stuff, to enable > > life with PAT. I'm not sure I understand what you mean. 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"? - Nick
