by Jernej Škrabec

[permalink] [raw]

Subject: Re: [PATCH 4/7] media: hantro: move postproc enablement for old cores

Hi Ezequiel,

Dne četrtek, 25. november 2021 ob 13:00:24 CET je Ezequiel Garcia napisal(a):
> Hi Jernej,
>
> On Mon, Nov 22, 2021 at 07:46:59PM +0100, Jernej Skrabec wrote:
> > Older G2 cores, like that in Allwinner H6, seem to have issue with
> > latching postproc register values if this is first thing done in job.
> > Moving that to the end solves the issue.
>
> Any idea what exact register should be written before the post-processor
> is enabled, for H6 to work? Also, which of the PP registers need
> to be written "at the end"?

No, there is too much registers to determine this exactly. Vendor library
actually stores register values in buffer and write them all at once in
increasing order. This is probably the reason why HDL engineers missed this
issue...

>
> > Signed-off-by: Jernej Skrabec <[email protected]>
> > ---
> >
> > drivers/staging/media/hantro/hantro_drv.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/hantro/hantro_drv.c
> > b/drivers/staging/media/hantro/hantro_drv.c index
> > 8c3de31f51b3..530994ab3024 100644
> > --- a/drivers/staging/media/hantro/hantro_drv.c
> > +++ b/drivers/staging/media/hantro/hantro_drv.c
> > @@ -130,7 +130,7 @@ void hantro_start_prepare_run(struct hantro_ctx *ctx)
> >
> > v4l2_ctrl_request_setup(src_buf->vb2_buf.req_obj.req,
> >
> > &ctx->ctrl_handler);
> >
> > - if (!ctx->is_encoder) {
> > + if (!ctx->is_encoder && !ctx->dev->variant->legacy_regs) {
>
> To make this less fragile, do you think it would make sense to
> have a dedicated quirk flag, something like "legacy_post_proc",
> instead of overloading the meaning of legacy_regs.

Sure, it can be done :) But then I suggest "late_post_proc" - it better
describes what it does.

Best regards,
Jernej

>
> What do you think?
>
> Thanks,
> Ezequiel
>
> > if (hantro_needs_postproc(ctx, ctx->vpu_dst_fmt))
> >
> > hantro_postproc_enable(ctx);
> >
> > else
> >
> > @@ -142,6 +142,13 @@ void hantro_end_prepare_run(struct hantro_ctx *ctx)
> >
> > {
> >
> > struct vb2_v4l2_buffer *src_buf;
> >
> > + if (ctx->dev->variant->legacy_regs && !ctx->is_encoder) {
> > + if (hantro_needs_postproc(ctx, ctx->vpu_dst_fmt))
> > + hantro_postproc_enable(ctx);
> > + else
> > + hantro_postproc_disable(ctx);
> > + }
> > +
> >
> > src_buf = hantro_get_src_buf(ctx);
> > v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req,
> >
> > &ctx->ctrl_handler);

2021-11-30 10:39:29

by Andrzej Pietrasiewicz

[permalink] [raw]

Subject: Re: [PATCH 1/7] media: hantro: add support for reset lines

Hi Ezequiel,

W dniu 23.11.2021 o 19:07, Ezequiel Garcia pisze:
> Hi all,
>
> Reset logic tends to be highly integration-specific, so it could be more robust
> to deal with this in the machine specific file. I have some vague recollection
> of our experience here when we integrated vc8000 last year, but I cannot recall
> the outcome.
>

Do you mean vpu->variant->init()?

That is the very first thing we do after the devm_*() calls. So any subsequent
initialization that fails would want vpu->variant->deinit(). Maybe at this
moment handling the resets at the common level is simpler? Existing drivers
will get NULL anyway from devm_reset_control_array_get().

Regards,

Andrzej

> I'm Ccing Bob who might remember better.
>
> Thanks,
> Ezequiel
>
>
>
> El mar., nov. 23, 2021 1:46 PM, Jernej Škrabec <[email protected]
> <mailto:[email protected]>> escribió:
>
> Hi all,
>
> Dne torek, 23. november 2021 ob 17:36:57 CET je Andrzej Pietrasiewicz
> napisal(a):
> > Hi Dan, hi Jernej,
> >
> > W dniu 23.11.2021 o 15:59, Dan Carpenter pisze:
> > > On Tue, Nov 23, 2021 at 12:09:03PM +0100, Andrzej Pietrasiewicz wrote:
> > >>> diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/
> media/hantro/hantro_drv.c
> > >>> index ab2467998d29..8c3de31f51b3 100644
> > >>> --- a/drivers/staging/media/hantro/hantro_drv.c
> > >>> +++ b/drivers/staging/media/hantro/hantro_drv.c
> > >>> @@ -905,6 +905,10 @@ static int hantro_probe(struct platform_device
> *pdev)
> > >>> return PTR_ERR(vpu->clocks[0].clk);
> > >>> }
> > >>> + vpu->resets = devm_reset_control_array_get(&pdev->dev, false,
> true);
> > >>> + if (IS_ERR(vpu->resets))
> > >>> + return PTR_ERR(vpu->resets);
> > >>> +
> > >>> num_bases = vpu->variant->num_regs ?: 1;
> > >>> vpu->reg_bases = devm_kcalloc(&pdev->dev, num_bases,
> > >>> sizeof(*vpu->reg_bases),
> GFP_KERNEL);
> > >>> @@ -978,10 +982,16 @@ static int hantro_probe(struct platform_device
> *pdev)
> > >>> pm_runtime_use_autosuspend(vpu->dev);
> > >>> pm_runtime_enable(vpu->dev);
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > It looks like this is the pm stuff that we have to unwind on error
> > >
> > >>> + ret = reset_control_deassert(vpu->resets);
> > >>> + if (ret) {
> > >>> + dev_err(&pdev->dev, "Failed to deassert resets\n");
> > >>> + return ret;
> > > ^^^^^^^^^^
> > > So this return should be a goto undo_pm_stuff
> > >
> > >
> > >>> + }
> > >>> +
> > >>> ret = clk_bulk_prepare(vpu->variant->num_clocks, vpu->clocks);
> > >>> if (ret) {
> > >>> dev_err(&pdev->dev, "Failed to prepare clocks\n");
> > >>> - return ret;
> > >
> > > And this return should also have been a goto so it's a bug in the
> > > original code.
> >
> > So we probably want a separate patch addressing that first, and then
> > the series proper on top of that.
>
> I was just about to suggest that.
>
> Other drivers usually enable PM last, so they don't have PM calls in unwind
> code. However, I think current approach is just as valid (with a fix).
>
> Best regards,
> Jernej
>
> >
> > Regards,
> >
> > Andrzej
> >
> > >
> > >>> + goto err_rst_assert;
> > >>
> > >> Before your patch is applied if clk_bulk_prepare() fails, we
> > >> simply return on the spot. After the patch is applied not only
> > >> do you...
> > >>
> > >>> }
> > >>> ret = v4l2_device_register(&pdev->dev, &vpu->v4l2_dev);
> > >>> @@ -1037,6 +1047,8 @@ static int hantro_probe(struct platform_device
> *pdev)
> > >>> v4l2_device_unregister(&vpu->v4l2_dev);
> > >>> err_clk_unprepare:
> > >>> clk_bulk_unprepare(vpu->variant->num_clocks, vpu->clocks);
> > >>> +err_rst_assert:
> > >>> + reset_control_assert(vpu->resets);
> > >>
> > >> ...revert the effect of reset_control_deassert(), you also...
> > >>
> > >>> pm_runtime_dont_use_autosuspend(vpu->dev);
> > >>> pm_runtime_disable(vpu->dev);
> > >>
> > >> ... do pm_*() stuff. Is there any reason why this is needed?
> > >
> > > So, yes, it's needed, but you're correct to spot that it's not
> > > consistent.
> > >
> > > regards,
> > > dan carpenter
> > >
> >
> >
>
>