On Tue, Apr 21, 2015 at 06:51:26PM -0400, Andy Walls wrote: > Sorry for the top post; mobile work email account. > > Luis, > > You do the changes to remove MTTR and point me to your dev repo and branch. > Also point me to the new functions/primitives I'll need. There is nothing new actually needed for ivtv, unless of course the ivtv driver is bounded to use a large MTRR that includes the non-framebuffer region, if so then the ioremap_uc() would be needed, and you can just cherry pick that patch: https://marc.info/?l=linux-kernel&m=142964809110516&w=1 I'll bounce that patch to you as well. Might help reading this patch too: https://marc.info/?l=linux-kernel&m=142964809710517&w=1 If your write-combining area is not restricted by size constraints so that it also include the non-framebuffer areas then you can just do a simple conversion of the driver to use ioremap_wc() on the framebuffer followed by arch_phys_wc_add(). An example driver that required changes to split this with size contraints is atyfb, here are the changes for it: https://marc.info/?l=linux-kernel&m=142964818810539&w=1 https://marc.info/?l=linux-kernel&m=142964813610531&w=1 https://marc.info/?l=linux-kernel&m=142964811010524&w=1 https://marc.info/?l=linux-kernel&m=142964814810532&w=1 If you are not constrained by MTRR's limitation on size then a simple trivial driver conversion is sufficient. For example: https://marc.info/?l=linux-kernel&m=142964744610286&w=1 I should also note that we are strivoing to also not use overlapping ioremap() calls as we want to avoid that mess. Overlapping iroemap() calls with different types could in theory work but its best we just design clean drivers and avoid this. As per Andy Lutomirski, what we'd need done on ivtv likely is for it to ioremap() for an initial bring up of the device, then infer the framebuffer offset, and only when that is being used then iounmap and then ioremap() again split areas on the driver, one with ioremap. > I'll do the changes to add write-combining back into ivtv and ivtvfb, test > them with my hardware and push them to my linuxtv.org git repo. Great! The above sounded like a complexity you did not wish to take on, but if you're up for the change, that'd be awesome! > I know there is at least one English speaking user in India using ivtv with > old PVR hardware, and probably folks in less developed places also using it. If the above is too much work for that few amount of users I'd hope we can just have them use older kernels, for the sake of sane APIs and clean driver architecture. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html