Hi,
On Mon, 2018-11-12 at 18:05 -0300, Ezequiel Garcia wrote:
> On Mon, 12 Nov 2018 at 13:52, Paul Kocialkowski
> wrote:
> > Hi,
> >
> > On Sun, 2018-11-11 at 18:26 -0300, Ezequiel Garcia wrote:
> > > On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote:
> > > > This series goal is to avoid
Hi,
On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote:
> This series goal is to avoid drivers from having ad-hoc code
> to call .device_run in non-atomic context. Currently, .device_run
> can be called via v4l2_m2m_job_finish(), not only running
> in interrupt context, but also creating a
On Mon, 12 Nov 2018 at 13:52, Paul Kocialkowski
wrote:
>
> Hi,
>
> On Sun, 2018-11-11 at 18:26 -0300, Ezequiel Garcia wrote:
> > On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote:
> > > This series goal is to avoid drivers from having ad-hoc code
> > > to call .device_run in non-atomic
Hi,
On Sun, 2018-11-11 at 18:26 -0300, Ezequiel Garcia wrote:
> On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote:
> > This series goal is to avoid drivers from having ad-hoc code
> > to call .device_run in non-atomic context. Currently, .device_run
> > can be called via
On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote:
> This series goal is to avoid drivers from having ad-hoc code
> to call .device_run in non-atomic context. Currently, .device_run
> can be called via v4l2_m2m_job_finish(), not only running
> in interrupt context, but also creating a nasty
This series goal is to avoid drivers from having ad-hoc code
to call .device_run in non-atomic context. Currently, .device_run
can be called via v4l2_m2m_job_finish(), not only running
in interrupt context, but also creating a nasty re-entrant
path into mem2mem drivers.
The proposed solution is
