[RFC PATCH] ipa: rkisp1: Initialize lsc tables on first frame

Laurent Pinchart laurent.pinchart at ideasonboard.com
Tue Dec 17 18:04:51 CET 2024


On Tue, Dec 17, 2024 at 04:29:38PM +0000, Kieran Bingham wrote:
> Quoting Stefan Klug (2024-12-16 15:33:02)
> > When sending the parameters for lens shading correction to the ISP on
> > frame x (in the test mostly frame 4) stalls of the ISP were observed.
> > From userland the symptom is that no buffers get returned anymore.
> > Kernel wise the ISP constantly produces interrupts with
> > RKISP1_CIF_ISP_V_START being set but no interrupts with
> > RKISP1_CIF_ISP_FRAME. It turned out that this behavior wasn't observed
> > when the lens shading correction parameters were written before
> > receiving the first frame. Ensure that behavior in the lsc algorithm by
> > unconditionally filling the params buffer on frame 0.
> > 
> > Unfortunately there were also cases were no stalls were observed even
> > though the lsc tables were not written on frame 0. So it is not clear
> > if this fix fixes the actual root cause.
> > 
> > Another reason for that change is that it is sensible to write the lsc
> > data on frame 0, to minimize the flicker in the image when the first
> > statistics come in (where they would have been written otherwise).
> 
> I think it's reasonable to write an LSC calibration table from the
> start. It might be difficult to ascertain 'which one' if we have an
> option to interpolate this based on color temperature, but I would
> suspect any of the pre-calibrated tables with the wrong temperature are
> better than an identity mapping for the starting configuration.

I agree. However, I'm concerned that the kernel makes it possible to
hand the ISP so easily.

> > Signed-off-by: Stefan Klug <stefan.klug at ideasonboard.com>
> > ---
> > 
> >  src/ipa/rkisp1/algorithms/lsc.cpp | 12 ++++++++++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/ipa/rkisp1/algorithms/lsc.cpp b/src/ipa/rkisp1/algorithms/lsc.cpp
> > index e47aa2f0727e..15a43799ae27 100644
> > --- a/src/ipa/rkisp1/algorithms/lsc.cpp
> > +++ b/src/ipa/rkisp1/algorithms/lsc.cpp
> > @@ -410,12 +410,20 @@ void LensShadingCorrection::prepare(IPAContext &context,
> >                                     RkISP1Params *params)
> >  {
> >         uint32_t ct = context.activeState.awb.temperatureK;
> 
> On frame zero - what is this initialised to ? Is it something sane? Is
> it '0' ? And mostly is it something that won't badly affect the code below?
> 
> If the LSC interpolations get clamped to sane ranges, then I would be
> happy with this - but I can't tell from the context of this patch alone,
> however I do suspect that's the case so:
> 
> 
> Reviewed-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
> 
> > -       if (std::abs(static_cast<int>(ct) - static_cast<int>(lastAppliedCt_)) <
> > +       /*
> > +        * The ISP in the imx8mp using linux 6.12 has a high probability for a

s/imx8mp/i.MX8MP/
s/linux/Linux/

> > +        * stall when the lsc module isn't configured in the first frame.

s/lsc/LSC/

Maybe expand it to "is configured after starting the ISP if it hasn't
previously been configured for the first frame".

> > +        * Therefore ensure that a lsc table is written unconditionally at the

Ditto.

> > +        * first frame.
> > +       */
> > +       if (frame > 0 &&
> > +           std::abs(static_cast<int>(ct) - static_cast<int>(lastAppliedCt_)) <
> >             kColourTemperatureChangeThreshhold)
> >                 return;
> > +
> >         unsigned int quantizedCt;
> >         const Components &set = sets_.getInterpolated(ct, &quantizedCt);
> > -       if (lastAppliedQuantizedCt_ == quantizedCt)
> > +       if (frame > 0 && lastAppliedQuantizedCt_ == quantizedCt)
> >                 return;
> >  
> >         auto config = params->block<BlockType::Lsc>();

-- 
Regards,

Laurent Pinchart


More information about the libcamera-devel mailing list