On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote:
On 12/19/2017 05:02 PM, Daniel Vetter wrote:
On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt mstaudt@suse.de wrote:
On 12/19/2017 02:57 PM, Daniel Vetter wrote:
The problem is that defio is totally not how a real driver works.
But they do exist and I can't ignore them.
I'm afraid I don't understand - why are those, such as xenfb, not real drivers?
I mean kms drivers. The problem is that the magic mapping that fbdev expects is real pain. Everyone else, including kms, expects an explicit flush operation. So instead of hacking around even more with the defio corner cases that don't work, I'm suggesting we just add that flush operation. At least internally.
Fixing kms drivers to implement a better defio is probably not a reasonable investement of time.
Ah yes, I understand now, you mean that KMS drivers have explicit flush, and defio is a hack to retrofit such drivers to an API that never supported a flush operation (the fbdev API), but always used to expose the video memory directly. Right?
If yes, then I agree. Fixing the defio in the KMS drivers wouldn't even solve my problem - I'd still need to implement flush. So might as well care about the flush straight away, yep!
Yup.
I'll leave the more fundamental discussion to the other thread on the cover letter. -Daniel