On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote:

On 12/19/2017 05:02 PM, Daniel Vetter wrote:

quoted

On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt [off-list ref] wrote:

quoted

On 12/19/2017 02:57 PM, Daniel Vetter wrote:

quoted

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch