Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

[Tomasz Figa]

On Tue, Sep 8, 2020 at 11:58 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
>
> Hi Hans, Mauro,
>
> On Tue, Sep 1, 2020 at 5:02 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
> >
> > On Tue, Sep 1, 2020 at 1:06 PM Christoph Hellwig <hch@xxxxxx> wrote:
> > >
> > > On Thu, Aug 20, 2020 at 07:33:48PM +0200, Tomasz Figa wrote:
> > > > > It wasn't meant to be too insulting, but I found this out when trying
> > > > > to figure out how to just disable it.  But it also ends up using
> > > > > the actual dma attr flags for it's own consistency checks, so just
> > > > > not setting the flag did not turn out to work that easily.
> > > > >
> > > >
> > > > Yes, sadly the videobuf2 ended up becoming quite counterintuitive
> > > > after growing for the long years and that is reflected in the design
> > > > of this feature as well. I think we need to do something about it.
> > >
> > > So I'm about to respin the series and wonder how we should proceed.
> > > I've failed to come up with a clean patch to keep the flag and make
> > > it a no-op.  Can you or your team give it a spin?
> > >
> >
> > Okay, I'll take a look.
> >
> > > Also I wonder if the flag should be renamed from NON_CONSISTENT
> > > to NON_COHERENT - the consistent thing is a weird wart from the times
> > > the old PCI DMA API that is mostly gone now.
> >
> > It originated from the DMA_ATTR_NON_CONSISTENT flag, but agreed that
> > NON_COHERENT would be more consistent (pun not intended) with the rest
> > of the DMA API given the removal of that flag. Let me see if we can
> > still change it.
>
> Given the above, we would like to make changes that affect the UAPI.
> Would you still be able to revert this series?

Sorry, I just realized that this isn't the original series that
introduced the thing, but rather a patch that does a partial revert. I
think it could be also applied as an alternative for the revert, but
perhaps a full series revert is just safer at this point?

For reference, the series in question is:
https://patchwork.linuxtv.org/project/linux-media/cover/20200514160153.3646-1-sergey.senozhatsky@xxxxxxxxx/

Best regards,
tomasz