Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Dne sobota, 24. avgust 2019 ob 14:56:12 CEST je Ondřej Jirman napisal(a): > Hi, > > On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a): > > > Hi! > > > > > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > > > > From: Ondrej Jirman > > > > > > > > I went through the datasheets for H6 and H5, and compared the > > > > differences. > > > > RTCs are largely similar, but not entirely compatible. > > > > Incompatibilities > > > > are in details not yet implemented by the rtc driver though. > > > > > > > > I also corrected the clock tree in H6 DTSI. > > > > > > > > This patchset is necessary for implementing the WiFi/Bluetooth support > > > > on boards using H6 SoC. > > > > > > > > There was some discussion previously of describing HOSC, DCXO and XO > > > > oscillators and clocks as part of RTC in DT, but I decided against it > > > > because it's not necessary, becuse information that would be provided > > > > as a part of DT can already be determined at runtime from RTC > > > > registers, > > > > so this woudn't add any value and would only introduce complications > > > > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > > > > > > > Please take a look. > > > > > > > > > > > > Thank you and regards, > > > > > > > > Ondrej Jirman > > > > > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get > > > this in dmesg: > > > > > > [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. > > > [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. > > > > > > Last line is repeated non-stop. > > > > > > Any idea what could be wrong? > > > > Additional info - this is on kernel 5.2.6 with your patches applied. > > Do you have schematics, or a FEX file for the board or any other info on how > the RTC is set up on that board? > > Can you dump the RTC register range? I have only Android DT, but as I already said in latest reply to patch 2, changing switch bypass to bit 14 instead of 15 solved all issues. Best regards, Jernej > > regards, > o. > > > Best regards, > > Jernej > > > > > > > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a): > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a): > > > Hi, > > > > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote: > > > > Hi! > > > > > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com > > > > napisal(a): > > > > > From: Ondrej Jirman > > > > > > > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight > > > > > differences > > > > > mostly in features that are not yet supported by this driver. > > > > > > > > > > Some differences are already stated in the comments in existing > > > > > code. > > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, > > > > > called > > > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator. > > > > > > > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check > > > > > whether > > > > > external low speed oscillator is working correctly. > > > > > > > > > > This patch adds support for enabling LOSC when necessary: > > > > > > > > > > - during reparenting > > > > > - when probing the clock > > > > > > > > > > H6 also has capacbility to automatically reparent RTC clock from > > > > > external crystal oscillator, to internal RC oscillator, if external > > > > > oscillator fails. This is enabled by default. Disable it during > > > > > probe. > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > Reviewed-by: Chen-Yu Tsai > > > > > --- > > > > > > > > > > drivers/rtc/rtc-sun6i.c | 40 > > > > > ++-- > > > > > 1 file changed, 38 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > > > > > index d50ee023b559..b0c3752bed3f 100644 > > > > > --- a/drivers/rtc/rtc-sun6i.c > > > > > +++ b/drivers/rtc/rtc-sun6i.c > > > > > @@ -32,9 +32,11 @@ > > > > > > > > > > /* Control register */ > > > > > #define SUN6I_LOSC_CTRL 0x > > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16) > > > > > > > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15) > > > > > > > > User manual says that above field is bit 14. > > > > > > See the previous discussion, this is from BSP. > > > > I have two versions of BSP (don't ask me which) which have this set as bit > > 14 and changing this to 14 actually solves all my problems with LOSC (no > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as > > parent) on Tanix TX6 box. > > Interesting. Is LOSC fed externally generated clock, or is it setup as a > crystal oscillator on your board? I really don't know, but here is DT: http://ix.io/1ThI > > Anyway, see here: > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649 > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652 Interesting, 4.9 BSP has additional bit definition, which is not documented in manual and 3.10 BSP to which I refer. I was referring to 3.10 BSP, which uses only bit 14. I thought that you named it differently. > > It would be nice to know what's really happening. > > My output is: > > [0.832252] sun6i-rtc 700.rtc: registered as rtc0 > [0.832257] sun6i-rtc 700.rtc: RTC enabled > [1.728968] sun6i-rtc 700.rtc: setting system clock to > 1970-01-01T00:00:07 UTC (7) With change, I get same output. > > I think, you may have just enabled the auto switch feature, and running the > clock from low precision RC oscillator with your patch. True, now I think there is no external crystal, but I'm still not sure how to confirm that. > > The real issue probably is that the mainline driver is missing this: > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n650 > Not sure what you mean by that. ext vs. int source selection? Best regards, Jernej > regards, > o. > > > Best regards, > > Jernej > >
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 15:30:57 CEST je Ondřej Jirman napisal(a): > On Sat, Aug 24, 2019 at 03:16:41PM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a): > > > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote: > > > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a): > > > > > Hi, > > > > > > > > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote: > > > > > > Hi! > > > > > > > > > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com > > > > > > > > napisal(a): > > > > > > > From: Ondrej Jirman > > > > > > > > > > > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight > > > > > > > differences > > > > > > > mostly in features that are not yet supported by this driver. > > > > > > > > > > > > > > Some differences are already stated in the comments in existing > > > > > > > code. > > > > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, > > > > > > > called > > > > > > > EXT_LOSC_EN to enable/disable external low speed crystal > > > > > > > oscillator. > > > > > > > > > > > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check > > > > > > > whether > > > > > > > external low speed oscillator is working correctly. > > > > > > > > > > > > > > This patch adds support for enabling LOSC when necessary: > > > > > > > > > > > > > > - during reparenting > > > > > > > - when probing the clock > > > > > > > > > > > > > > H6 also has capacbility to automatically reparent RTC clock from > > > > > > > external crystal oscillator, to internal RC oscillator, if > > > > > > > external > > > > > > > oscillator fails. This is enabled by default. Disable it during > > > > > > > probe. > > > > > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > > Reviewed-by: Chen-Yu Tsai > > > > > > > --- > > > > > > > > > > > > > > drivers/rtc/rtc-sun6i.c | 40 > > > > > > > ++-- > > > > > > > 1 file changed, 38 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > > > > > > > index d50ee023b559..b0c3752bed3f 100644 > > > > > > > --- a/drivers/rtc/rtc-sun6i.c > > > > > > > +++ b/drivers/rtc/rtc-sun6i.c > > > > > > > @@ -32,9 +32,11 @@ > > > > > > > > > > > > > > /* Control register */ > > > > > > > #define SUN6I_LOSC_CTRL 0x > > > > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa > > > > << 16) > > > > > > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15) > > > > > > > > > > > > User manual says that above field is bit 14. > > > > > > > > > > See the previous discussion, this is from BSP. > > > > > > > > I have two versions of BSP (don't ask me which) which have this set as > > > > bit > > > > 14 and changing this to 14 actually solves all my problems with LOSC > > > > (no > > > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as > > > > parent) on Tanix TX6 box. > > > > > > Interesting. Is LOSC fed externally generated clock, or is it setup as a > > > crystal oscillator on your board? > > > > I really don't know, but here is DT: http://ix.io/1ThI > > > > > Anyway, see here: > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n > > > 649 > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n > > > 652 > > > > Interesting, 4.9 BSP has additional bit definition, which is not > > documented in manual and 3
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 23:27:46 CEST je Ondřej Jirman napisal(a): > Hello Jernej, > > On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote: > > > Visually? > > > > > > That would explain why it doesn't work for you. The mainline RTC driver > > > disables auto-switch feature, and if your board doesn't have a crystal > > > for > > > LOSC, RTC will not generate a clock for the RTC. > > > > > > H6's dtsi describes by default a situatiuon with external 32k crystal > > > oscillator. See ext_osc32k node. That's incorrect for your board if it > > > doesn't have the crystal. You need to fix this in the DTS for your board > > > instead of patching the driver. > > > > I see that reparenting is supported, but I'm not sure how to fix that in > > DT. Any suggestion? > > You may try removing the clocks property from rtc node. I don't think this would work: https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L246 > > > > The driver has parent clock selection logic in case the LOSC crystal is > > > not > > > used. > > > > > > Your patch enables automatic detection of LOSC failure and RTC changes > > > clock to LOSC automatically, despite what's described in the DTS. That > > > may fix the issue, but is not the correct solution. > > > > > > Registers on my board look like this (external 32k osc is used) for > > > reference: > > > > > > LOSC_CTRL_REG[700]: 8011 > > > > > > KEY_FIELD ??? (0) > > > LOSC_AUTO_SWT_BYPASS EN (1) > > > LOSC_AUTO_SWT_EN DIS (0) > > > EXT_LOSC_ENEN (1) > > > EXT_LOSC_GSM LOW (0) > > > BATTERY_DIRDISCHARGE(0) > > > LOSC_SRC_SEL EXT32k (1) > > > > > > LOSC_AUTO_SWT_STA_REG[704]: 1 > > > > > > EXT_LOSC_STA OK (0) > > > LOSC_AUTO_SWT_PEND NOEFF(0) > > > LOSC_SRC_SEL_STA EXT32K (1) > > > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG > > has value 0x4, so there is issue with external crystal (it's missing) and > > RTC switched to internal one. > > > > BTW, what's wrong with automatic switching? Why is it disabled? > > It always was disabled on mainline (bit 14 was set to 0 even before my > patch). H6 just probably has another extra undocummented bit, that's needed > to disables it properly. > > You probably don't want a glitch to switch your RTC from high-precision > clock to a low precision one possibly without any indication in the > userspace or a kernel log. > > Regardless of all this, DTS needs to have a correct description of the HW, > which means if RTC module is not connected to the 32.757kHz crystal/clock, > clocks property should be empty. If we are talking about correct HW description, then clock property should actually have possibility that two clocks are defined - one for internal RC (always present) and one external crystal (optional). In such case I could really just omit external clock and be done with it. But I'm not sure if such solution is acceptable at this point. Best regards, Jernej > > regards, > o. > > > Best regards, > > Jernej > > > > > regards, > > > > > > o. > > > > > > > > The real issue probably is that the mainline driver is missing this: > > > > > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-b > > > > > sp#n > > > > > 650 > > > > > > > > Not sure what you mean by that. ext vs. int source selection? > > > > > > > > > > > > > > > > Best regards, > > > > Jernej > > > > > > > > > regards, > > > > > > > > > > o.
Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
napisal(a):
> Hi Jernej,
>
> On Thu, 22 Aug 2019 21:44:57 +0200
>
> Jernej Skrabec wrote:
> > When codec supports multiple slices in one frame, VPU has to know when
> > first slice of each frame is being processed, presumably to correctly
> > clear/set data in auxiliary buffers.
> >
> > Add first_slice field to cedrus_run structure and set it according to
> > timestamps of capture and output buffers. If timestamps are different,
> > it's first slice and viceversa.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 2f017a651848..32cb38e541c6 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> >
> > struct cedrus_run {
> >
> > struct vb2_v4l2_buffer *src;
> > struct vb2_v4l2_buffer *dst;
> >
> > + bool first_slice;
> >
> > union {
> >
> > struct cedrus_h264_run h264;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > 56ca4c9ad01c..d7b54accfe83 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > + run.first_slice =
> > + run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
>
> Can't we use slice->first_mb_in_slice to determine if a slice is the
> first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> support ASO).
I'm not sure if that is always the case, I would have to check the standard.
Anyway, this method of comparing timestamps was suggested to me a while ago
when we were discussing details on a way forward for multi-slice decoding. I
highly doubt someone would decode slices in mixed order (from different frames)
in same instance.
I can change that in next version if ->first_mb_in_slice == 0 is always true
for the first slice.
Best regards,
Jernej
>
> > /* Apply request(s) controls if needed. */
> > src_req = run.src->vb2_buf.req_obj.req;
Re: [linux-sunxi] Re: [PATCH 4/6] pwm: sun4i: Add support for H6 PWM
Dne ponedeljek, 29. julij 2019 ob 20:51:08 CEST je Uwe Kleine-König
napisal(a):
> On Mon, Jul 29, 2019 at 08:46:25PM +0200, Jernej Škrabec wrote:
> > Dne ponedeljek, 29. julij 2019 ob 20:40:41 CEST je Uwe Kleine-König
> >
> > napisal(a):
> > > On Mon, Jul 29, 2019 at 06:40:15PM +0200, Jernej Škrabec wrote:
> > > > Dne ponedeljek, 29. julij 2019 ob 18:24:28 CEST je Uwe Kleine-König
> > > >
> > > > napisal(a):
> > > > > Hello,
> > > > >
> > > > > On Tue, Jul 30, 2019 at 12:09:40AM +0800, Chen-Yu Tsai wrote:
> > > > > > On Tue, Jul 30, 2019 at 12:07 AM Uwe Kleine-König
> > > > > >
> > > > > > wrote:
> > > > > > > On Mon, Jul 29, 2019 at 05:55:52PM +0200, Jernej Škrabec wrote:
> > > > > > > > Dne ponedeljek, 29. julij 2019 ob 08:40:30 CEST je Uwe
> > > > > > > > Kleine-König
> > > > > > > >
> > > > > > > > napisal(a):
> > > > > > > > > On Fri, Jul 26, 2019 at 08:40:43PM +0200, Jernej Skrabec
wrote:
> > > > > > > > > > --- a/drivers/pwm/pwm-sun4i.c
> > > > > > > > > > +++ b/drivers/pwm/pwm-sun4i.c
> > > > > > > > > > @@ -331,6 +331,13 @@ static const struct sun4i_pwm_data
> > > > > > > > > > sun4i_pwm_single_bypass = {>
> > > > > > > > > >
> > > > > > > > > > .npwm = 1,
> > > > > > > > > >
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > +static const struct sun4i_pwm_data
> > > > > > > > > > sun50i_pwm_dual_bypass_clk_rst
> > > > > > > > > > = {
> > > > > > > > > > + .has_bus_clock = true,
> > > > > > > > > > + .has_prescaler_bypass = true,
> > > > > > > > > > + .has_reset = true,
> > > > > > > > > > + .npwm = 2,
> > > > > > > > > > +};
> > > > > > > > > > +
> > > > > > > > > >
> > > > > > > > > > static const struct of_device_id sun4i_pwm_dt_ids[] = {
> > > > > > > > > >
> > > > > > > > > > {
> > > > > > > > > >
> > > > > > > > > > .compatible = "allwinner,sun4i-a10-pwm",
> > > > > > > > > >
> > > > > > > > > > @@ -347,6 +354,9 @@ static const struct of_device_id
> > > > > > > > > > sun4i_pwm_dt_ids[] =
> > > > > > > > > > {
> > > > > > > > > >
> > > > > > > > > > }, {
> > > > > > > > > >
> > > > > > > > > > .compatible = "allwinner,sun8i-h3-pwm",
> > > > > > > > > > .data = _pwm_single_bypass,
> > > > > > > > > >
> > > > > > > > > > + }, {
> > > > > > > > > > + .compatible = "allwinner,sun50i-h6-pwm",
> > > > > > > > > > + .data = _pwm_dual_bypass_clk_rst,
> > > > > > > > >
> > > > > > > > > If you follow my suggestion for the two previous patches,
> > > > > > > > > you
> > > > > > > > > can
> > > > > > > > > just
> > > > > > > > >
> > > > > > > > > use:
> > > > > > > > > compatible = "allwinner,sun50i-h6-pwm",
> > > > > > > > > "allwinner,sun5i-a10s-pwm";
> > > > > > > > >
> > > > > > > > > and drop this patch.
> > > > > > > >
> > > > > > > > Maxime found out that it's not compatible with A10s due to
> > > > > > > > difference
> > > > > > > > in bypass bit, but yes, I know what you mean.
> > > > > > > >
> > > > > > > > Since H6 requires reset line and bus clock to be specified,
> > > > > > > > it's
&g
Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality
Hi!
Dne torek, 04. junij 2019 ob 11:38:44 CEST je Code Kipper napisal(a):
> On Tue, 4 Jun 2019 at 11:02, Christopher Obbard wrote:
> > On Tue, 4 Jun 2019 at 09:43, Code Kipper wrote:
> > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard
wrote:
> > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekip...@gmail.com wrote:
> > > > > From: Marcus Cooper
> > > > >
> > > > > The i2s block supports multi-lane i2s output however this
> > > > > functionality
> > > > > is only possible in earlier SoCs where the pins are exposed and for
> > > > > the i2s block used for HDMI audio on the later SoCs.
> > > > >
> > > > > To enable this functionality, an optional property has been added to
> > > > > the bindings.
> > > > >
> > > > > Signed-off-by: Marcus Cooper
> > > >
> > > > I'd like to have Mark's input on this, but I'm really worried about
> > > > the interaction with the proper TDM support.
> > > >
> > > > Our fundamental issue is that the controller can have up to 8
> > > > channels, but either on 4 lines (instead of 1), or 8 channels on 1
> > > > (like proper TDM) (or any combination between the two, but that should
> > > > be pretty rare).
> > >
> > > I understand...maybe the TDM needs to be extended to support this to
> > > consider channel mapping and multiple transfer lines. I was thinking
> > > about the later when someone was requesting support on IIRC a while
> > > ago, I thought masking might of been a solution. These can wait as the
> > > only consumer at the moment is LibreELEC and we can patch it there.
> >
> > Hi Marcus,
> >
> > FWIW, the TI McASP driver has support for TDM & (i think?) multiple
> > transfer lines which are called serializers.
> > Maybe this can help with inspiration?
> > see
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/s
> > ound/soc/ti/davinci-mcasp.c sample DTS:
> >
> > {
> >
> > #sound-dai-cells = <0>;
> > status = "okay";
> > pinctrl-names = "default";
> > pinctrl-0 = <_pins>;
> >
> > op-mode = <0>;
> > tdm-slots = <8>;
> > serial-dir = <
> >
> > 2 0 1 0
> > 0 0 0 0
> > 0 0 0 0
> > 0 0 0 0
> > >
> > >;
> >
> > tx-num-evt = <1>;
> > rx-num-evt = <1>;
> >
> > };
> >
> >
> > Cheers!
>
> Thanks, this looks good.
I would really like to see this issue resolved, because HDMI audio support in
mainline Linux for those SoCs is long overdue.
However, there is a possibility to still add HDMI audio suport (stereo only)
even if this issue is not completely solved. If we agree that configuration of
channels would be solved with additional property as Christopher suggested,
support for >2 channels can be left for a later time when support for that
property would be implemented. Currently, stereo HDMI audio support can be
added with a few patches.
I think all I2S cores are really the same, no matter if internally connected
to HDMI controller or routed to pins, so it would make sense to use same
compatible for all of them. It's just that those I2S cores which are routed to
pins can use only one lane and >2 channels can be used only in TDM mode of
operation, if I understand this correctly.
New property would have to be optional, so it's omission would result in same
channel configuration as it is already present, to preserve compatibility with
old device trees. And this mode is already sufficient for stereo HDMI audio
support.
Side note: HDMI audio with current sun4i-i2s driver has a delay (about a
second), supposedly because DW HDMI controller automatically generates CTS
value based on I2S clock (auto CTS value generation is enabled per DesignWare
recomendation for DW HDMI I2S interface). I2S driver from BSP Linux solves
that by having I2S clock output enabled all the time. Should this be flagged
with some additional property in DT?
Best regards,
Jernej
> CK
>
> > > Do you have any ideas Master?
> > > CK
> > >
> > > > You're trying to do the first one, and I'm trying to do the second
> > > > one.
> > > >
> > > > There's a number of assumptions later on that will break the TDM case,
> > > > see below for examples
> > > >
> > > > > ---
> > > > >
> > > > > sound/soc/sunxi/sun4i-i2s.c | 44
> > > > > -
> > > > > 1 file changed, 39 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c
> > > > > b/sound/soc/sunxi/sun4i-i2s.c
> > > > > index bca73b3c0d74..75217fb52bfa 100644
> > > > > --- a/sound/soc/sunxi/sun4i-i2s.c
> > > > > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > > > > @@ -23,7 +23,7 @@
> > > > >
> > > > > #define SUN4I_I2S_CTRL_REG 0x00
> > > > > #define SUN4I_I2S_CTRL_SDO_EN_MASK GENMASK(11, 8)
> > > > >
> > > > > -#define SUN4I_I2S_CTRL_SDO_EN(sdo) BIT(8 + (sdo))
> > > > > +#define SUN4I_I2S_CTRL_SDO_EN(lines) (((1 << lines) - 1) <<
> > > > > 8)
> > > > >
> > > > > #define SUN4I_I2S_CTRL_MODE_MASK
Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
Dne sreda, 14. avgust 2019 ob 15:28:53 CEST je Clément Péron napisal(a):
> Hi,
>
> On Wed, 14 Aug 2019 at 15:20, Corentin Labbe
wrote:
> > On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> > > Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe
napisal(a):
> > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > >
> > > > The only devicetree difference with current pineH64, is the PHY
> > > > regulator.
> > >
> > > I have Model A board which also needs ddc-en-gpios property for HDMI
> > > connector in order for HDMI to work correctly. Otherwise it will just
> > > use 1024x768 resolution. Can you confirm that?
>
> Schematics Rev A:
> http://files.pine64.org/doc/Pine%20H64/Pine%20H64%20Ver1.1-20180104.pdf
>
> Rev B:
> http://files.pine64.org/doc/Pine%20H64/PINE-H6-model-B-20181212-schematic.pd
> f
>
> There is a DDC_EN on REV A not on REV B
>
> Regards,
> Clément
>
> > > Best regards,
> > > Jernej
> >
> > Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
> >
> > Could you send me a patch against my future v2 and I could test
> > with/without.
I don't have access to my Model A board currently, but this should suffice:
{
ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
};
Best regards,
Jernej
> >
> > Regards
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the
> > web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20190814132001.GC24324%40Re
> > d.
Re: [PATCH 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
Dne nedelja, 18. avgust 2019 ob 20:42:49 CEST je kbuild test robot napisal(a): > Hi Jernej, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.3-rc4 next-20190816] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Jernej-Skrabec/dt-bindings-arm-sun > xi-Add-compatible-for-Tanix-TX6-board/20190819-002034 config: > arm64-defconfig (attached as .config) > compiler: aarch64-linux-gcc (GCC) 7.4.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=7.4.0 make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > All errors (new ones prefixed by >>): > >> Error: arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts:83.1-6 Label > >> or path r_ir not found FATAL ERROR: Syntax error parsing input tree Strange, Allwinner tree has commit, which introduces r_ir node: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/? h=sunxi/dt-for-5.4=9267811aad3524c857cf2e16bbadd8c569e15ab9 Maybe kbuild test robot tree doesn't have it? Best regards, Jernej > > --- > 0-DAY kernel test infrastructureOpen Source Technology > Center https://lists.01.org/pipermail/kbuild-all Intel > Corporation
Re: [linux-sunxi] [PATCH] ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix dcdc1 regulator
Dne ponedeljek, 24. avgust 2020 ob 22:54:01 CEST je Pablo Sebastián Greco
napisal(a):
> On 24/8/20 16:36, Jernej Skrabec wrote:
> > DCDC1 regulator powers many different subsystems. While some of them can
> > work at 3.0 V, some of them can not. For example, VCC-HDMI can only work
> > between 3.24 V and 3.36 V. According to OS images provided by the board
> > manufacturer this regulator should be set to 3.3 V.
> >
> > Set DCDC1 and DCDC1SW to 3.3 V in order to fix this.
> >
> > Fixes: da7ac948fa93 ("ARM: dts: sun8i: Add board dts file for Banana Pi M2
> >
> > Ultra")
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> > b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts index
> > 42d62d1ba1dc..ea15073f0c79 100644
> > --- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> > +++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
> > @@ -223,16 +223,16 @@ _aldo3 {
> >
> > };
> >
> > _dc1sw {
> >
> > - regulator-min-microvolt = <300>;
> > - regulator-max-microvolt = <300>;
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> >
> > regulator-name = "vcc-gmac-phy";
> >
> > };
> >
> > _dcdc1 {
> >
> > regulator-always-on;
> >
> > - regulator-min-microvolt = <300>;
> > - regulator-max-microvolt = <300>;
> > - regulator-name = "vcc-3v0";
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> > + regulator-name = "vcc-3v3";
> >
> > };
> >
> > _dcdc2 {
>
> Should this be done also for the bananapi-m2-berry?, it is basically the
> same device
> sun8i-v40-bananapi-m2-berry.dts
I think so but I would rather not do that without testing and I don't have
that board.
Best regards,
Jernej
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: sun8i: r40: Use sigma delta modulation for audio PLL
Dne torek, 25. avgust 2020 ob 16:46:31 CEST je Chen-Yu Tsai napisal(a):
> On Tue, Aug 25, 2020 at 9:11 PM Jernej Skrabec
wrote:
> > Audio cores need specific clock rates which can't be simply obtained by
> > adjusting integer multipliers and dividers. HW for such cases supports
> > delta-sigma modulation which enables fractional multipliers.
> >
> > Port H3 delta-sigma table to R40. They have identical audio PLLs.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 37 ++--
> > 1 file changed, 24 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c index 23bfe1d12f21..84153418453f
> > 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > +++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > @@ -45,18 +45,29 @@ static struct ccu_nkmp pll_cpu_clk = {
> >
> > * the base (2x, 4x and 8x), and one variable divider (the one true
> > * pll audio).
> > *
> >
> > - * We don't have any need for the variable divider for now, so we just
> > - * hardcode it to match with the clock names
> > + * With sigma-delta modulation for fractional-N on the audio PLL,
> > + * we have to use specific dividers. This means the variable divider
> > + * can no longer be used, as the audio codec requests the exact clock
> > + * rates we support through this mechanism. So we now hard code the
> > + * variable divider to 1. This means the clock rates will no longer
> > + * match the clock names.
> >
> > */
> >
> > #define SUN8I_R40_PLL_AUDIO_REG0x008
> >
> > -static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
> > - "osc24M", 0x008,
> > - 8, 7,/* N */
> > - 0, 5,/* M */
> > - BIT(31), /* gate */
> > - BIT(28), /* lock */
> > - CLK_SET_RATE_UNGATE);
> > +static struct ccu_sdm_setting pll_audio_sdm_table[] = {
> > + { .rate = 22579200, .pattern = 0xc0010d84, .m = 8, .n = 7 },
> > + { .rate = 24576000, .pattern = 0xc000ac02, .m = 14, .n = 14 },
>
> The user manual has an additional requirement: 3 <= N/M <= 21.
> Though it then says 72 <= 24*N/P <= 504. Not sure which one is
> right...
>
> Did you run into any glitches or audio distortions?
No, I tested HDMI audio and it seems to work fine.
BSP driver also uses those values:
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
clk/sunxi/clk-sun8iw11.c#L160
Best regards,
Jernej
Re: [PATCH] drm/sun4i: Fix DE2 YVU handling
Dne sreda, 02. september 2020 ob 09:01:17 CEST je Roman Stratiienko
napisal(a):
> ср, 2 сент. 2020 г. в 00:58, Jernej Skrabec :
> > Function sun8i_vi_layer_get_csc_mode() is supposed to return CSC mode
> > but due to inproper return type (bool instead of u32) it returns just 0
> > or 1. Colors are wrong for YVU formats because of that.
> >
> > Fixes: daab3d0e8e2b ("drm/sun4i: de2: csc_mode in de2 format struct is
> > mostly redundant") Reported-by: Roman Stratiienko
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index 22c8c5375d0d..c0147af6a840
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > @@ -211,7 +211,7 @@ static int sun8i_vi_layer_update_coord(struct
> > sun8i_mixer *mixer, int channel,>
> > return 0;
> >
> > }
> >
> > -static bool sun8i_vi_layer_get_csc_mode(const struct drm_format_info
> > *format) +static u32 sun8i_vi_layer_get_csc_mode(const struct
> > drm_format_info *format)>
> > {
> >
> > if (!format->is_yuv)
> >
> > return SUN8I_CSC_MODE_OFF;
> >
> > --
> > 2.28.0
>
> Hi Jernej,
>
> Thank you for the fix.
> I can confirm this patch fixes the issue with wrong colors.
Thanks! Can I assume that this means your Tested-by tag can be added?
>
> Let me share my thoughts:
> I've looked into csc code, and it seems to me reordering U, V offsets
> should be a much simpler solution than applying
> color transformation matrices.It should also simplify adding more
> color encodings in the future.
Switching offsets assumes that you have separate planes for U and V which may
not be true in the future. I agree that CSC matrices are needlessly duplicated
for handling U/V switch. I have a patch which reorganize matrix on the fly when
coefficients are written in registers but since it's a part of a bigger,
unfinished series, I didn't sent it out yet. Only difference in YUV and YVU CSC
matrices are switched 2nd and 3rd column.
Best regards,
Jernej
>
> Regards,
> Roman
Re: [linux-sunxi] [PATCH 05/16] ASoc: sun4i-i2s: Add 20 and 24 bit support
Hi Samuel!
Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a):
> On 7/4/20 6:38 AM, Clément Péron wrote:
> > From: Marcus Cooper
> >
> > Extend the functionality of the driver to include support of 20 and
> > 24 bits per sample.
> >
> > Signed-off-by: Marcus Cooper
> > Signed-off-by: Clément Péron
> > ---
> >
> > sound/soc/sunxi/sun4i-i2s.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> > index f78167e152ce..bc7f9343bc7a 100644
> > --- a/sound/soc/sunxi/sun4i-i2s.c
> > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct
> > snd_pcm_substream *substream,>
> > case 16:
> > width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> > break;
> >
> > + case 32:
> > + width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + break;
>
> This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 for a 32
> bit width, but it needs to return 3.
I'm not sure what has WSS with physical width and DMA?
>
> As a side note, I wonder why we use the physical width (the spacing between
> samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per sample
> in RAM, which we need for DMA. But I don't see why we would want to
> transmit the padding over the wire. I would expect it to be transmitted the
> same as S24_3LE (which has no padding). It did not matter before, because
> the only supported format had no padding.
Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bus
width, so if sample is 24 bits in size, we have no other way but to transmit
padding too.
Best regards,
Jernej
>
> Regards,
> Samuel
>
> > default:
> > dev_err(dai->dev, "Unsupported physical sample width:
%d\n",
> >
> > params_physical_width(params));
> >
> > @@ -1063,6 +1066,10 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai
> > *dai)>
> > return 0;
> >
> > }
> >
> > +#define SUN4I_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
> > +SNDRV_PCM_FMTBIT_S20_LE | \
> > +SNDRV_PCM_FMTBIT_S24_LE)
> > +
> >
> > static struct snd_soc_dai_driver sun4i_i2s_dai = {
> >
> > .probe = sun4i_i2s_dai_probe,
> > .capture = {
> >
> > @@ -1070,14 +1077,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
> >
> > .channels_min = 1,
> > .channels_max = 8,
> > .rates = SNDRV_PCM_RATE_8000_192000,
> >
> > - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> > + .formats = SUN4I_FORMATS,
> >
> > },
> > .playback = {
> >
> > .stream_name = "Playback",
> > .channels_min = 1,
> > .channels_max = 8,
> > .rates = SNDRV_PCM_RATE_8000_192000,
> >
> > - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> > + .formats = SUN4I_FORMATS,
> >
> > },
> > .ops = _i2s_dai_ops,
> > .symmetric_rates = 1,
Re: [linux-sunxi] [PATCH] drm/sun4i: Fix dsi dcs long write function
Dne petek, 28. avgust 2020 ob 13:24:44 CEST je Ondrej Jirman napisal(a):
> It's writing too much data. regmap_bulk_write expects number of
> register sized chunks to write, not a byte sized length of the
> bounce buffer. Bounce buffer needs to be padded too, so that
> regmap_bulk_write will not read past the end of the buffer.
>
> Signed-off-by: Ondrej Jirman
Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller
support")
should be added. Fix will be then automatically picked into stable releases.
Small nit below.
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 7f13f4d715bf..840fad1b68dd
> 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -889,7 +889,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> *dsi, regmap_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(0),
>sun6i_dsi_dcs_build_pkt_hdr(dsi, msg));
>
> - bounce = kzalloc(msg->tx_len + sizeof(crc), GFP_KERNEL);
> + bounce = kzalloc(msg->tx_len + sizeof(crc) + 3, GFP_KERNEL);
It would be nicer to use ALIGN() macro, but I'm fine either way.
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> if (!bounce)
> return -ENOMEM;
>
> @@ -900,7 +900,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> *dsi, memcpy((u8 *)bounce + msg->tx_len, , sizeof(crc));
> len += sizeof(crc);
>
> - regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
len);
> + regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
> DIV_ROUND_UP(len, 4)); regmap_write(dsi->regs, SUN6I_DSI_CMD_CTL_REG, len +
> 4 - 1);
> kfree(bounce);
Re: [linux-sunxi] Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
Dne petek, 28. avgust 2020 ob 14:21:19 CEST je Ondřej Jirman napisal(a): > On Fri, Aug 28, 2020 at 02:16:36PM +0200, Clément Péron wrote: > > Hi Maxime, > > > > On Tue, 25 Aug 2020 at 15:35, Maxime Ripard wrote: > > > Hi Clement, > > > > > > On Mon, Aug 03, 2020 at 09:54:05AM +0200, Clément Péron wrote: > > > > Hi Maxime and All, > > > > > > > > On Sat, 4 Jul 2020 at 16:56, Clément Péron wrote: > > > > > Hi Maxime, > > > > > > > > > > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote: > > > > > > Hi, > > > > > > > > > > > > On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote: > > > > > > > Add an Operating Performance Points table for the GPU to > > > > > > > enable Dynamic Voltage & Frequency Scaling on the H6. > > > > > > > > > > > > > > The voltage range is set with minival voltage set to the target > > > > > > > and the maximal voltage set to 1.2V. This allow DVFS framework > > > > > > > to > > > > > > > work properly on board with fixed regulator. > > > > > > > > > > > > > > Signed-off-by: Clément Péron > > > > > > > > > > > > That patch seems reasonable, why shouldn't we merge it? > > > > > > > > > > I didn't test it a lot and last time I did, some frequencies looked > > > > > unstable. https://lore.kernel.org/patchwork/cover/1239739/ > > > > > > > > > > This series adds regulator support to Panfrost devfreq, I will send > > > > > a > > > > > new one if DVFS on the H6 GPU is stable. > > > > > > > > > > I got this running glmark2 last time > > > > > # glmark2-es2-drm > > > > > === > > > > > > > > > > glmark2 2017.07 > > > > > > > > > > === > > > > > > > > > > OpenGL Information > > > > > GL_VENDOR: Panfrost > > > > > GL_RENDERER: Mali T720 (Panfrost) > > > > > GL_VERSION:OpenGL ES 2.0 Mesa 20.0.5 > > > > > > > > > > === > > > > > > > > > > [ 93.550063] panfrost 180.gpu: GPU Fault 0x0088 (UNKNOWN) > > > > > at > > > > > 0x80117100 > > > > > [ 94.045401] panfrost 180.gpu: gpu sched timeout, js=0, > > > > > config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00, > > > > > sched_job=e3c2132f > > > > > > > > > > [ 328.871070] panfrost 180.gpu: Unhandled Page fault in AS0 at > > > > > VA > > > > > 0x > > > > > [ 328.871070] Reason: TODO > > > > > [ 328.871070] raw fault status: 0xAA0003C2 > > > > > [ 328.871070] decoded fault status: SLAVE FAULT > > > > > [ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > > [ 328.871070] access type 0x3: WRITE > > > > > [ 328.871070] source id 0xAA00 > > > > > [ 329.373327] panfrost 180.gpu: gpu sched timeout, js=1, > > > > > config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900, > > > > > sched_job=7ac31097 > > > > > [ 329.386527] panfrost 180.gpu: js fault, js=0, > > > > > status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00 > > > > > [ 329.396293] panfrost 180.gpu: gpu sched timeout, js=0, > > > > > config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00, > > > > > sched_job=04c90381 > > > > > [ 329.411521] panfrost 180.gpu: Unhandled Page fault in AS0 at > > > > > VA > > > > > 0x > > > > > [ 329.411521] Reason: TODO > > > > > [ 329.411521] raw fault status: 0xAA0003C2 > > > > > [ 329.411521] decoded fault status: SLAVE FAULT > > > > > [ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > > [ 329.411521] access type 0x3: WRITE > > > > > [ 329.411521] source id 0xAA00 > > > > > > > > Just to keep a track of this issue. > > > > > > > > Piotr Oniszczuk give more test and seems to be software related: > > > > https://www.spinics.net/lists/dri-devel/msg264279.html > > > > > > > > Ondrej gave a great explanation about a possible origin of this issue: > > > > https://freenode.irclog.whitequark.org/linux-sunxi/2020-07-11 > > > > > > > > 20:12 looks like gpu pll on H6 is NKMP clock, and those are > > > > implemented in such a way in mainline that they are prone to > > > > overshooting the frequency during output divider reduction > > > > 20:13 so disabling P divider may help > > > > 20:13 or fixing the dividers > > > > 20:14 and just allowing N to change > > > > 20:22 hmm, I haven't looked at this for quite some time, but H6 > > > > BSP way of setting PLL factors actually makes the most sense out of > > > > everything I've seen/tested so far > > > > 20:23 it waits for lock not after setting NK factors, but after > > > > reducing the M factor (pre-divider) > > > > 20:24 I might as well re-run my CPU PLL tester with this > > > > algorithm, to see if it fixes the lockups > > > > 20:26 it makes sense to wait for PLL to stabilize "after" > > > > changing all the factors that actually affect the VCO, and not just > > > > some of them > > > > 20:27 warpme_: ^ > > > > 20:28 it may be the same thing
Re: [PATCH v2 01/14] media: uapi: h264: Update reference lists
Hi! Dne četrtek, 06. avgust 2020 ob 17:47:07 CEST je Paul Kocialkowski napisal(a): > Hi, > > On Thu 06 Aug 20, 12:12, Ezequiel Garcia wrote: > > From: Jernej Skrabec > > > > When dealing with with interlaced frames, reference lists must tell if > > each particular reference is meant for top or bottom field. This info > > is currently not provided at all in the H264 related controls. > > > > Make reference lists hold a structure which will also hold an > > enumerator type along index into DPB array. The enumerator must > > be used to specify if reference is for top or bottom field. > > > > Currently the only user of these lists is Cedrus which is just compile > > fixed here. Actual usage of will come in a following commit. > > Is there a particular reason we are adding this to the ref_pic_list[0-1] > instead of the DPB entries directly? Yes, it is. > > It feels nicer to avoid making the lists structs when the entries they are > referring to are already in a struct. I think this is the approach Kwiboo > took when adding support for fields in references some time ago. > > What do you think? It's different thing. I tried using that, but image wasn't decoded correctly. IMO this is also the same reason why VAAPI doesn't have indices to DPB and instead have full VAPictureH264 structure array for RefPicList0 and RefPicList1. VAAPI has also note here "/* See 8.2.4.2 */" but I need to check it... Best regards, Jernej > > Cheers, > > Paul > > > Signed-off-by: Jernej Skrabec > > Signed-off-by: Ezequiel Garcia > > --- > > v2: > > * As pointed out by Jonas, enum v4l2_h264_dpb_reference here. > > --- > > > > .../media/v4l/ext-ctrls-codec.rst | 44 ++- > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +-- > > include/media/h264-ctrls.h| 23 +++--- > > 3 files changed, 62 insertions(+), 11 deletions(-) > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > > d0d506a444b1..f2b2a381369f 100644 > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > @@ -1843,10 +1843,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type > > -> > > * - __u32 > > > >- ``slice_group_change_cycle`` > >- > > > > -* - __u8 > > +* - struct :c:type:`v4l2_h264_reference` > > > >- ``ref_pic_list0[32]`` > >- Reference picture list after applying the per-slice modifications > > > > -* - __u8 > > +* - struct :c:type:`v4l2_h264_reference` > > > >- ``ref_pic_list1[32]`` > >- Reference picture list after applying the per-slice modifications > > > > * - __u32 > > > > @@ -1926,6 +1926,46 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type > > - > > > >- ``chroma_offset[32][2]`` > >- > > > > +``Picture Reference`` > > + > > +.. c:type:: v4l2_h264_reference > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: struct v4l2_h264_reference > > +:header-rows: 0 > > +:stub-columns: 0 > > +:widths: 1 1 2 > > + > > +* - enum :c:type:`v4l2_h264_dpb_reference` > > + - ``reference`` > > + - Specifies how the DPB entry is referenced. > > +* - __u8 > > + - ``index`` > > + - Index into the :c:type:`v4l2_ctrl_h264_decode_params`.dpb array. > > + > > +.. c:type:: v4l2_h264_dpb_reference > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: > > +:header-rows: 0 > > +:stub-columns: 0 > > +:widths: 1 1 2 > > + > > +* - ``V4L2_H264_DPB_TOP_REF`` > > + - 0x1 > > + - The top field in field pair is used for > > +short-term reference. > > +* - ``V4L2_H264_DPB_BOTTOM_REF`` > > + - 0x2 > > + - The bottom field in field pair is used for > > +short-term reference. > > +* - ``V4L2_H264_DPB_FRAME_REF`` > > + - 0x3 > > + - The frame (or the top/bottom fields, if it's a field pair) > > +is used for short-term reference. > > + > > > > ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)`` > > > > Specifies the decode parameters (as extracted from the bitstream) > > for the associated H264 slice data. This includes the necessary > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index > > 54ee2aa423e2..cce527bbdf86 100644 > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > @@ -166,8 +166,8 @@ static void cedrus_write_frame_list(struct cedrus_ctx > > *ctx,> > > static void _cedrus_write_ref_list(struct cedrus_ctx *ctx, > > > >struct cedrus_run *run, > > > > - const u8 *ref_list, u8 num_ref, > > - enum cedrus_h264_sram_off sram) >
Re: [PATCH 2/2] drm/sun4i: mixer: Extend regmap max_register
>Better guess. Secondary CSC registers are from 0xF. > >Signed-off-by: Martin Cerveny Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 1/2] drm/sun4i: sun8i-csc: Secondary CSC register correction
>"Allwinner V3s" has secondary video layer (VI).
>Decoded video is displayed in wrong colors until
>secondary CSC registers are programmed correctly.
>
>Signed-off-by: Martin Cerveny
Following tag should be added:
Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library")
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH] arm64: dts: allwinner: h5: OrangePi Prime: Fix ethernet node
Dne sreda, 28. oktober 2020 ob 12:58:17 CET je Nenad Peric napisal(a):
> RX and TX delay are provided by ethernet PHY. Reflect that in ethernet
> node.
>
> Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes")
> Signed-off-by: Nenad Peric
Acked-by: Jernej Skrabec
Thanks!
Best regards,
Jernej
Re: Re: [PATCH v2] arm64: dts: allwinner: h6: add eMMC voltage property for Beelink GS1
Dne petek, 09. oktober 2020 ob 09:36:51 CEST je Maxime Ripard napisal(a):
> On Thu, Oct 08, 2020 at 10:00:06PM +0200, Clément Péron wrote:
> > Hi Maxime,
> >
> > Adding linux-sunxi and Jernej Skrabec to this discussion.
> >
> > On Thu, 8 Oct 2020 at 17:10, Maxime Ripard wrote:
> > >
> > > Hi Clément,
> > >
> > > On Mon, Oct 05, 2020 at 08:47:19PM +0200, Clément Péron wrote:
> > > > On Mon, 5 Oct 2020 at 11:21, Maxime Ripard wrote:
> > > > >
> > > > > Hi Clément,
> > > > >
> > > > > On Sat, Oct 03, 2020 at 11:20:01AM +0200, Clément Péron wrote:
> > > > > > Sunxi MMC driver can't distinguish at runtime what's the I/O
voltage
> > > > > > for HS200 mode.
> > > > >
> > > > > Unfortunately, that's not true (or at least, that's not related to
your patch).
> > > > >
> > > > > > Add a property in the device-tree to notify MMC core about this
> > > > > > configuration.
> > > > > >
> > > > > > Fixes: 089bee8dd119 ("arm64: dts: allwinner: h6: Introduce Beelink
GS1 board")
> > > > > > Signed-off-by: Clément Péron
> > > > > > ---
> > > > > > arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-
gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > > > > > index 049c21718846..3f20d2c9 100644
> > > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > > > > > @@ -145,6 +145,7 @@ {
> > > > > > vqmmc-supply = <_bldo2>;
> > > > > > non-removable;
> > > > > > cap-mmc-hw-reset;
> > > > > > + mmc-hs200-1_8v;
> > > > > > bus-width = <8>;
> > > > > > status = "okay";
> > > > > > };
> > > > >
> > > > > I'm not really sure what you're trying to fix here, but as far as MMC
> > > > > goes, eMMC's can support io voltage of 3.3, 1.8 and 1.2V. Modes up
until
> > > > > HS DDR (50MHz in DDR) will use an IO voltage of 3.3V, higher speed
modes
> > > > > (HS200 and HS400) supporting 1.8V and 1.2V.
> > > >
> > > > Some users report that the eMMC is not working properly on their
> > > > Beelink GS1 boards.
> > > >
> > > > > The mmc-hs200-1_8v property states that the MMC controller supports
the
> > > > > HS200 mode at 1.8V. Now, I can only assume that since BLDO2 is set
up at
> > > > > 1.8V then otherwise, the MMC core will rightfully decide to use the
> > > > > highest supported mode. In this case, since the driver sets it, it
would
> > > > > be HS-DDR at 3.3V, which won't work with that fixed regulator.
> > > > >
> > > > > I can only assume that enabling HS200 at 1.8V only fixes the issue
you
> > > > > have because otherwise it would use HS-DDR at 3.3V, ie not actually
> > > > > fixing the issue but sweeping it under the rug.
> > > > >
> > > > > Trying to add mmc-ddr-1_8v would be a good idea
> > > >
> > > > Thanks for the explanation, this is indeed the correct one.
> > > > So It looks like the SDIO controller has an issue on some boards when
> > > > using HS-DDR mode.
> > > >
> > > > Is this patch acceptable with the proper commit log?
> > >
> > > If HS-DDR works, yes, but I assume it doesn't?
> >
> > After discussing with Jernej about this issue, I understood that:
> > - Automatic delay calibration is not implemented
> > - We also miss some handling of DDR related bits in control register
> >
> > So none of H5/H6 boards should actually work.
> > (Some 'lucky' boards seem to work enough to switch to HS200 mode...)
> >
> > To "fix" this the H5 disable the HS-DDR mode in sunxi mmc driver :
> > https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sunxi-mmc.c#L1409
>
> I find it suspicious that some boards would have traces not good enough
> for HS-DDR (50MHz in DDR) but would work fine in HS200 (200MHz in SDR).
> If there's some mismatch on the traces, it will only be worse in HS200.
FYI, similar situation is also with Tanix TX6 board. Mine works well in HS-DDR
mode, but some people reported that it doesn't work for them. The only
possible difference could be different eMMC IC. I'll try to confirm that.
Anyway, I did some tests on OrangePi 3 board which also have eMMC. Both modes
(HS-DDR and HS200) are supported and work well. Interesting observation is
that speed test (hdparm -t) reported 80.58 MB/sec for HS-DDR mode and 43.40
MB/sec for HS200. As it can be seen here, HS-DDR is quicker by a factor of 2,
but it should be the other way around. Reason for this is that both modes use
same base clock and thus HS-DDR produces higher speed.
If I change f_max to 150 MHz (max. per datasheet for SDR @ 1.8 V) then
naturally HS200 mode is faster (124.63 MB/sec) as HS-DDR as it should be. This
would be actually correct test for problematic boards but unfortunately I
don't have it. I also hacked in support for HS400 (~143 MB/s) and this mode is
the only one which really needs calibration on my board.
Two observations from BSP
Re: [PATCH] ARM: dts: sun8i: v40: bananapi-m2-berry: Fix ethernet node
Dne nedelja, 01. november 2020 ob 01:34:17 CET je Pablo Greco napisal(a):
> Ethernet PHY on BananaPi M2 Berry provides RX and TX delays. Fix ethernet
> node to reflect that fact.
>
> Fixes: 27e81e1970a8 ("ARM: dts: sun8i: v40: bananapi-m2-berry: Enable GMAC
ethernet controller")
> Signed-off-by: Pablo Greco
Acked-by: Jernej Skrabec
Thanks!
Jernej
Re: [PATCH] ARM: dts: sun8i: r40: bananapi-m2-berry: Fix dcdc1 regulator
Dne nedelja, 01. november 2020 ob 01:34:16 CET je Pablo Greco napisal(a):
> DCDC1 regulator powers many different subsystems. While some of them can
> work at 3.0 V, some of them can not. For example, VCC-HDMI can only work
> between 3.24 V and 3.36 V. According to OS images provided by the board
> manufacturer this regulator should be set to 3.3 V.
>
> Set DCDC1 and DCDC1SW to 3.3 V in order to fix this.
>
> Fixes: 23edc168bd98 ("ARM: dts: sun8i: Add board dts file for Banana Pi M2
Berry")
> Fixes: 27e81e1970a8 ("ARM: dts: sun8i: v40: bananapi-m2-berry: Enable GMAC
ethernet controller")
> Signed-off-by: Pablo Greco
Acked-by: Jernej Skrabec
Thanks!
Jernej
Re: [PATCH] ARM: dts: sun7i: bananapi: Enable RGMII RX/TX delay on Ethernet PHY
Dne nedelja, 01. november 2020 ob 01:34:15 CET je Pablo Greco napisal(a):
> The Ethernet PHY on the Bananapi M1 has the RX and TX delays enabled on
> the PHY, using pull-ups on the RXDLY and TXDLY pins.
>
> Fix the phy-mode description to correct reflect this so that the
> implementation doesn't reconfigure the delays incorrectly. This
> happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
> rx/tx delay config").
>
> Fixes: 8a5b272fbf44 ("ARM: dts: sun7i: Add Banana Pi board")
> Signed-off-by: Pablo Greco
Acked-by: Jernej Skrabec
Thanks!
Jernej
Re: [PATCH v5 12/20] dt-bindings: rtc: sun6i: Add H616 compatible string
Hi! Dne sreda, 27. januar 2021 ob 18:24:52 CET je Andre Przywara napisal(a): > Add the obvious compatible name to the existing RTC binding, and pair > it with the existing H6 fallback compatible string, as the devices are > compatible. After close lookup I would disagree with this observation. Major difference is that H616 doesn't support usage of external 32768 Hz oscillator. It uses 24 MHz oscillator with divider for that case. Due to that change, whole logic for external oscillator should go out. Additionally, this logic overwrites default value in LOSC_CTRL register, which is not nice (there is no documentation for those bits). Best regards, Jernej > > Signed-off-by: Andre Przywara > Acked-by: Rob Herring > --- > .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31- rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > index b1b0ee769b71..4193e5813344 100644 > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > @@ -26,6 +26,9 @@ properties: >- const: allwinner,sun50i-a64-rtc >- const: allwinner,sun8i-h3-rtc >- const: allwinner,sun50i-h6-rtc > + - items: > + - const: allwinner,sun50i-h616-rtc > + - const: allwinner,sun50i-h6-rtc > >reg: > maxItems: 1 > -- > 2.17.5 > >
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: h6: Use sigma-delta modulation for audio PLL
Dne torek, 17. september 2019 ob 08:54:08 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Sep 14, 2019 at 9:51 PM Jernej Skrabec
wrote:
> > Audio devices needs exact clock rates in order to correctly reproduce
> > the sound. Until now, only integer factors were used to configure H6
> > audio PLL which resulted in inexact rates. Fix that by adding support
> > for fractional factors using sigma-delta modulation look-up table. It
> > contains values for two most commonly used audio base frequencies.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c index d89353a3cdec..ed6338d74474
> > 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > @@ -203,12 +203,21 @@ static struct ccu_nkmp pll_hsic_clk = {
> >
> > * hardcode it to match with the clock names.
> > */
> >
> > #define SUN50I_H6_PLL_AUDIO_REG0x078
> >
> > +
> > +static struct ccu_sdm_setting pll_audio_sdm_table[] = {
> > + { .rate = 541900800, .pattern = 0xc001288d, .m = 1, .n = 22 },
> > + { .rate = 589824000, .pattern = 0xc00126e9, .m = 1, .n = 24 },
> > +};
> > +
> >
> > static struct ccu_nm pll_audio_base_clk = {
> >
> > .enable = BIT(31),
> > .lock = BIT(28),
> > .n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> > .m = _SUNXI_CCU_DIV(1, 1), /* input divider */
> >
> > + .sdm= _SUNXI_CCU_SDM(pll_audio_sdm_table,
> > +BIT(24), 0x178, BIT(31)),
> >
> > .common = {
> >
> > + .features = CCU_FEATURE_SIGMA_DELTA_MOD,
> >
> > .reg= 0x078,
> > .hw.init= CLK_HW_INIT("pll-audio-base", "osc24M",
> >
> > _nm_ops,
> >
> > @@ -753,12 +762,12 @@ static const struct clk_hw *clk_parent_pll_audio[] =
> > {>
> > };
> >
> > /*
> >
> > - * The divider of pll-audio is fixed to 8 now, as pll-audio-4x has a
> > - * fixed post-divider 2.
> > + * The divider of pll-audio is fixed to 24 for now, so 24576000 and
> > 22579200 + * rates can be set exactly in conjunction with sigma-delta
> > modulation.>
> > */
> >
> > static CLK_FIXED_FACTOR_HWS(pll_audio_clk, "pll-audio",
> >
> > clk_parent_pll_audio,
> >
> > - 8, 1, CLK_SET_RATE_PARENT);
> > + 24, 1, CLK_SET_RATE_PARENT);
> >
> > static CLK_FIXED_FACTOR_HWS(pll_audio_2x_clk, "pll-audio-2x",
> >
> > clk_parent_pll_audio,
> > 4, 1, CLK_SET_RATE_PARENT);
>
> You need to fix the factors for the other two outputs as well, since all
> three are derived from pll-audio-base.
Fix how? pll-audio-2x and pll-audio-4x clocks have fixed divider in regards to
pll-audio-base, while pll-audio has not. Unless you mean changing their name?
Best regards,
Jernej
>
> ChenYu
>
> > @@ -1215,12 +1224,12 @@ static int sun50i_h6_ccu_probe(struct
> > platform_device *pdev)>
> > }
> >
> > /*
> >
> > -* Force the post-divider of pll-audio to 8 and the output divider
> > -* of it to 1, to make the clock name represents the real
> > frequency. +* Force the post-divider of pll-audio to 12 and the
> > output divider +* of it to 2, so 24576000 and 22579200 rates can
> > be set exactly.>
> > */
> >
> > val = readl(reg + SUN50I_H6_PLL_AUDIO_REG);
> > val &= ~(GENMASK(21, 16) | BIT(0));
> >
> > - writel(val | (7 << 16), reg + SUN50I_H6_PLL_AUDIO_REG);
> > + writel(val | (11 << 16) | BIT(0), reg + SUN50I_H6_PLL_AUDIO_REG);
> >
> > /*
> >
> > * First clock parent (osc32K) is unusable for CEC. But since
> > there
> >
> > --
> > 2.23.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the
> > web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20190914135100.327412-1-jer
> > nej.skrabec%40siol.net.
Re: [PATCH v2] drm: bridge/dw_hdmi: add audio sample channel status setting
Dne četrtek, 05. september 2019 ob 11:43:25 CEST je Cheng-Yi Chiang
napisal(a):
> From: Yakir Yang
>
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
> Refer to 60958-3 page 10 for frequency, original frequency, and
> wordlength setting.
>
> This fix the issue that audio does not come out on some monitors
> (e.g. LG 22CV241)
>
> Note that these registers are only for interfaces:
> I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> (AHBAUDDMA).
> For S/PDIF interface this information comes from the stream.
>
> Currently this function dw_hdmi_set_channel_status is only called
> from dw-hdmi-i2s-audio in I2S setup.
>
> Signed-off-by: Yakir Yang
> Signed-off-by: Cheng-Yi Chiang
> ---
> Original patch by Yakir Yang is at
>
> https://lore.kernel.org/patchwork/patch/539653/
>
> Change from v1 to v2:
> 1. Remove the version check because this will only be called by
> dw-hdmi-i2s-audio, and the registers are available in I2S setup.
> 2. Set these registers in dw_hdmi_i2s_hw_params.
> 3. Fix the sample width setting so it can use 16 or 24 bits.
>
> .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 70 +++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++
> include/drm/bridge/dw_hdmi.h | 2 +
> 4 files changed, 93 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> 34d8e837555f..b801a28b0f17 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev,
> void *data, }
>
> dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> + dw_hdmi_set_channel_status(hdmi, hparms->sample_width);
> dw_hdmi_set_channel_count(hdmi, hparms->channels);
> dw_hdmi_set_channel_allocation(hdmi, hparms-
>cea.channel_allocation);
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> bd65d0479683..d1daa369c8ae 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -582,6 +582,76 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> unsigned long pixel_clk) return n;
> }
>
> +/*
> + * When transmitting IEC60958 linear PCM audio, these registers allow to
> + * configure the channel status information of all the channel status
> + * bits in the IEC60958 frame. For the moment this configuration is only
> + * used when the I2S audio interface, General Purpose Audio (GPA),
> + * or AHB audio DMA (AHBAUDDMA) interface is active
> + * (for S/PDIF interface this information comes from the stream).
> + */
> +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> + unsigned int sample_width)
> +{
> + u8 aud_schnl_samplerate;
> + u8 aud_schnl_8;
> + u8 word_length_bits;
> +
> + switch (hdmi->sample_rate) {
> + case 32000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> + break;
> + case 44100:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> + break;
> + case 48000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> + break;
> + case 88200:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> + break;
> + case 96000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> + break;
> + case 176400:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> + break;
> + case 192000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> + break;
> + case 768000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> + break;
> + default:
> + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)
\n",
> + hdmi->sample_rate);
> + return;
> + }
> +
> + /* set channel status register */
> + hdmi_modb(hdmi, aud_schnl_samplerate,
HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
> + HDMI_FC_AUDSCHNLS7);
> +
> + /*
> + * Set original frequency to be the same as frequency.
> + * Use one-complement value as stated in IEC60958-3 page 13.
> + */
> + aud_schnl_8 = (~aud_schnl_samplerate) <<
> + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
> +
> + /*
> + * Refer to IEC60958-3 page 12. We can accept 16 bits or 24 bits.
> + * Otherwise, set the register to 0t o indicate using default
value.
Nit: "0t 0" -> "0 to"
With that fixed, this patch is:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> +
Re: [PATCH 2/3] media: cedrus: h264: Properly configure reference field
Dne petek, 05. junij 2020 ob 19:16:35 CEST je Nicolas Dufresne napisal(a):
> Le jeudi 04 juin 2020 à 20:57 +0200, Jernej Skrabec a écrit :
> > When interlaced H264 content is being decoded, references must indicate
> > which field is being referenced. Currently this was done by checking
> > capture buffer flags. However, that is not correct because capture
> > buffer may hold both fields.
> >
> > Fix this by checking newly introduced flags in reference lists.
> >
> > Signed-off-by: Jernej Skrabec
>
> Perhaps an additional patch could cleanup the miss-leading comment in
> v4l2_h264_dpb_entry definition.
I missed that. I think this change actually belongs to patch 1. I'll fix it in
v2.
Best regards,
Jernej
>
> Reviewed-by: Nicolas Dufresne
>
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > cce527bbdf86..c87717d17ec5 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > @@ -183,7 +183,6 @@ static void _cedrus_write_ref_list(struct cedrus_ctx
> > *ctx,>
> > for (i = 0; i < num_ref; i++) {
> >
> > const struct v4l2_h264_dpb_entry *dpb;
> > const struct cedrus_buffer *cedrus_buf;
> >
> > - const struct vb2_v4l2_buffer *ref_buf;
> >
> > unsigned int position;
> > int buf_idx;
> > u8 dpb_idx;
> >
> > @@ -198,12 +197,11 @@ static void _cedrus_write_ref_list(struct cedrus_ctx
> > *ctx,>
> > if (buf_idx < 0)
> >
> > continue;
> >
> > - ref_buf = to_vb2_v4l2_buffer(cap_q->bufs[buf_idx]);
> > - cedrus_buf = vb2_v4l2_to_cedrus_buffer(ref_buf);
> > + cedrus_buf = vb2_to_cedrus_buffer(cap_q->bufs[buf_idx]);
> >
> > position = cedrus_buf->codec.h264.position;
> >
> > sram_array[i] |= position << 1;
> >
> > - if (ref_buf->field == V4L2_FIELD_BOTTOM)
> > + if (ref_list[i].flags &
V4L2_H264_REFERENCE_FLAG_BOTTOM_FIELD)
> >
> > sram_array[i] |= BIT(0);
> >
> > }
Re: [PATCH 1/3] media: uapi: h264: update reference lists
Dne petek, 05. junij 2020 ob 19:13:24 CEST je Nicolas Dufresne napisal(a):
> Sorry, missed one thing.
>
> Le vendredi 05 juin 2020 à 13:08 -0400, Nicolas Dufresne a écrit :
> > Le jeudi 04 juin 2020 à 20:57 +0200, Jernej Skrabec a écrit :
> > > When dealing with with interlaced frames, reference lists must tell if
> > > each particular reference is meant for top or bottom field. This info
> > > is currently not provided at all in the H264 related controls.
> > >
> > > Make reference lists hold a structure which will also hold flags along
> > > index into DPB array. Flags will tell if reference is meant for top or
> > > bottom field.
> > >
> > > Currently the only user of these lists is Cedrus which is just compile
> > > fixed here. Actual usage of newly introduced flags will come in
> > > following commit.
> > >
> > > Signed-off-by: Jernej Skrabec
> >
> > This looks like the right approach to me and is extensible if anything
> > else is needed for MVC and SVC special referencing (at least will be
> > enough for what H.264 actually supports in this regard).
> >
> > Reviewed-by: Nicolas Dufresne
> >
> > > ---
> > >
> > > .../media/v4l/ext-ctrls-codec.rst | 40 ++-
> > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +--
> > > include/media/h264-ctrls.h| 12 +-
> > > 3 files changed, 51 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index
> > > d0d506a444b1..6c36d298db20 100644
> > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > > @@ -1843,10 +1843,10 @@ enum
> > > v4l2_mpeg_video_h264_hierarchical_coding_type -> >
> > > * - __u32
> > >
> > >- ``slice_group_change_cycle``
> > >-
> > >
> > > -* - __u8
> > > +* - struct :c:type:`v4l2_h264_reference`
> > >
> > >- ``ref_pic_list0[32]``
> > >- Reference picture list after applying the per-slice
> > >modifications
> > >
> > > -* - __u8
> > > +* - struct :c:type:`v4l2_h264_reference`
> > >
> > >- ``ref_pic_list1[32]``
> > >- Reference picture list after applying the per-slice
> > >modifications
> > >
> > > * - __u32
> > >
> > > @@ -1926,6 +1926,42 @@ enum
> > > v4l2_mpeg_video_h264_hierarchical_coding_type -
> > >
> > >- ``chroma_offset[32][2]``
> > >-
> > >
> > > +``Picture Reference``
> > > +
> > > +.. c:type:: v4l2_h264_reference
> > > +
> > > +.. cssclass:: longtable
> > > +
> > > +.. flat-table:: struct v4l2_h264_reference
> > > +:header-rows: 0
> > > +:stub-columns: 0
> > > +:widths: 1 1 2
> > > +
> > > +* - __u16
> > > + - ``flags``
> > > + - See :ref:`Picture Reference Flags `
> > > +* - __u8
> > > + - ``index``
> > > + -
> > > +
> > > +.. _h264_reference_flags:
> > > +
> > > +``Picture Reference Flags``
> > > +
> > > +.. cssclass:: longtable
> > > +
> > > +.. flat-table::
> > > +:header-rows: 0
> > > +:stub-columns: 0
> > > +:widths: 1 1 2
> > > +
> > > +* - ``V4L2_H264_REFERENCE_FLAG_TOP_FIELD``
> > > + - 0x0001
> > > + -
> > > +* - ``V4L2_H264_REFERENCE_FLAG_BOTTOM_FIELD``
> > > + - 0x0002
> > > + -
> > > +
> > >
> > > ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
> > >
> > > Specifies the decode parameters (as extracted from the bitstream)
> > > for the associated H264 slice data. This includes the necessary
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > > 54ee2aa423e2..cce527bbdf86 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > > @@ -166,8 +166,8 @@ static void cedrus_write_frame_list(struct
> > > cedrus_ctx *ctx,> >
> > > static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> > >
> > > struct cedrus_run *run,
> > >
> > > -const u8 *ref_list, u8
num_ref,
> > > -enum cedrus_h264_sram_off
sram)
> > > +const struct
v4l2_h264_reference *ref_list,
> > > +u8 num_ref, enum
cedrus_h264_sram_off sram)
> > >
> > > {
> > >
> > > const struct v4l2_ctrl_h264_decode_params *decode =
> > > run->h264.decode_params; struct vb2_queue *cap_q;
> > >
> > > @@ -188,7 +188,7 @@ static void _cedrus_write_ref_list(struct cedrus_ctx
> > > *ctx,> >
> > > int buf_idx;
> > > u8 dpb_idx;
> > >
> > > - dpb_idx = ref_list[i];
> > > + dpb_idx = ref_list[i].index;
> > >
> > > dpb = >dpb[dpb_idx];
> > >
> > > if (!(dpb->flags &
Re: [PATCH v3 06/12] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
Hi, Dne ponedeljek, 29. januar 2018 ob 19:05:26 CET je Rob Herring napisal(a): > On Wed, Jan 17, 2018 at 09:14:15PM +0100, Jernej Skrabec wrote: > > This commit adds all necessary compatibles and descriptions needed to > > implement A83T HDMI pipeline. > > > > Mixer is already properly described, so only compatible is added. > > > > However, A83T TV TCON, which is connected to HDMI, doesn't have channel 0, > > contrary to all TCONs currently described. Because of that, TCON > > documentation is extended. > > > > A83T features Synopsys DW HDMI controller with a custom PHY which looks > > like Synopsys Gen2 PHY with few additions. Since there is no > > documentation, needed properties were found out through experimentation > > and reading BSP code. > > > > At the end, example is added for newer SoCs, which feature DE2 and DW > > HDMI. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > .../bindings/display/sunxi/sun4i-drm.txt | 197 > > - 1 file changed, 190 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > > cd626ee1147a..4fb380f3e53d 100644 > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > @@ -64,6 +64,52 @@ Required properties: > > first port should be the input endpoint. The second should be the > > output, usually to an HDMI connector. > > > > +DWC HDMI TX Encoder > > +--- > > + > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. > > + > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the > > +following device-specific properties. > > + > > +Required properties: > > + > > + - compatible: value must be one of: > > +* "allwinner,sun8i-a83t-dw-hdmi" > > + - reg: base address and size of memory-mapped region > > + - reg-io-width: See dw_hdmi.txt. Shall be 1. > > + - interrupts: HDMI interrupt number > > + - clocks: phandles to the clocks feeding the HDMI encoder > > +* iahb: the HDMI bus clock > > +* isfr: the HDMI register clock > > + - clock-names: the clock names mentioned above > > + - resets: phandle to the reset controller > > + - reset-names: must be "ctrl" > > + - phys: phandle to the DWC HDMI PHY > > + - phy-names: must be "phy" > > + > > + - ports: A ports node with endpoint definitions as defined in > > +Documentation/devicetree/bindings/media/video-interfaces.txt. The > > +first port should be the input endpoint. The second should be the > > +output, usually to an HDMI connector. > > + > > +DWC HDMI PHY > > + > > + > > +Required properties: > > + - compatible: value must be one of: > > +* allwinner,sun8i-a83t-hdmi-phy > > + - reg: base address and size of memory-mapped region > > + - clocks: phandles to the clocks feeding the HDMI PHY > > +* bus: the HDMI PHY interface clock > > +* mod: the HDMI PHY module clock > > +* tmds: TMDS clock > > + - clock-names: the clock names mentioned above > > + - resets: phandle to the reset controller driving the PHY > > + - reset-names: must be "phy" > > + > > > > TV Encoder > > -- > > > > @@ -94,24 +140,23 @@ Required properties: > > * allwinner,sun7i-a20-tcon > > * allwinner,sun8i-a33-tcon > > * allwinner,sun8i-a83t-tcon-lcd > > > > + * allwinner,sun8i-a83t-tcon-tv > > > > * allwinner,sun8i-v3s-tcon > > > > - reg: base address and size of memory-mapped region > > - interrupts: interrupt associated to this IP > > > > - - clocks: phandles to the clocks feeding the TCON. Three are needed: > > > > + - clocks: phandles to the clocks feeding the TCON. One is needed: > > - 'ahb': the interface clocks > > > > - - 'tcon-ch0': The clock driving the TCON channel 0 > > Well, it didn't look right before saying 3 are needed, but listing 2. > However, you can't just change this as it affects all the other SoCs. > This should probably be a separate patch. I had a feeling that all items which are not common to all compatibles should be listed below and explained when they are needed. At least currently it's done this way. > > > - resets: phandles to the reset controllers driving the encoder > > > > - "lcd": the reset line for the TCON channel 0 > > > > - clock-names: the clock names mentioned above > > - reset-names: the reset names mentioned above > > > > - - clock-output-names: Name of the pixel clock created > > Why is this removed? > > > - ports: A ports node with endpoint definitions as defined in > > > >Documentation/devicetree/bindings/media/video-interfaces.txt. The > >first port should be the input endpoint, the
Re: [linux-sunxi] Re: [PATCH v4] ARM: sun8i: h2+: add support for Banana Pi M2 Zero board
Dne četrtek, 08. februar 2018 ob 10:15:35 CET je Icenowy Zheng napisal(a): > 在 2018-02-08 17:00，Maxime Ripard 写道： > > > On Tue, Feb 06, 2018 at 09:16:47PM +0800, Icenowy Zheng wrote: > >> Banana Pi M2 Zero board is a H2+-based board by Sinovoip, with a form > >> factor and GPIO holes similar to Raspberry Pi Zero. > >> > >> It features: > >> - Allwinner H2+ SoC > >> - Single-chip (16-bit) 512MiB DDR3 DRAM > >> - Ampak AP6212 Wi-Fi/Bluetooth module > >> - MicroSD slot > >> - Two MicroUSB Type-B ports (one can only be used to power the board > >> and > >> > >> the other features OTG functionality) > >> > >> - Two keys, a reset and a GPIO-connected key. > >> - HDMI Type-C (miniHDMI) connector connected to the HDMI part of H2+. > >> - CSI connector to connect the camera sensor provided by Sinovoip. > >> > >> Signed-off-by: Icenowy Zheng > >> --- > >> Changes in v4: > >> - Use SPDX license identifier. > >> > >> Changes in v3: > >> - Add comments about Vbus problem in node. > >> > >> Changes in v2: > >> - Use high active SD card detect on the production batch. > >> > >> arch/arm/boot/dts/Makefile | 1 + > >> .../boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts| 126 > >> > >> + > >> > >> 2 files changed, 127 insertions(+) > >> create mode 100644 > >> > >> arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts > >> > >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > >> index ade7a38543dc..d5a17e6e8b0f 100644 > >> --- a/arch/arm/boot/dts/Makefile > >> +++ b/arch/arm/boot/dts/Makefile > >> @@ -974,6 +974,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \ > >> > >>sun8i-a83t-cubietruck-plus.dtb \ > >>sun8i-a83t-tbs-a711.dtb \ > >>sun8i-h2-plus-orangepi-r1.dtb \ > >> > >> + sun8i-h2-plus-bananapi-m2-zero.dtb \ > >> > >>sun8i-h2-plus-orangepi-zero.dtb \ > >>sun8i-h3-bananapi-m2-plus.dtb \ > >>sun8i-h3-beelink-x2.dtb \ > >> > >> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts > >> b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts > >> new file mode 100644 > >> index ..e2ee65a5bf92 > >> --- /dev/null > >> +++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts > >> @@ -0,0 +1,126 @@ > >> +/* > >> + * Copyright (C) 2017 Icenowy Zheng > >> + * > >> + * Based on sun8i-h3-bananapi-m2-plus.dts, which is: > >> + * Copyright (C) 2016 Chen-Yu Tsai > >> + * > >> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) > > > > Sorry to be a bit picky about this, but this should be your very first > > line, see arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts for > > example. > > I think it's also OK here, see > arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts. Lincesing rules [1] says it should be in first possible line which can contain comment. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/ Documentation/process/license-rules.rst#n57 > > > Thanks! > > Maxime > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. To unsubscribe from this group and stop receiving > emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH v3 02/12] clk: sunxi-ng: Change formula for NKMP PLLs
Hi, Dne četrtek, 18. januar 2018 ob 11:58:41 CET je Maxime Ripard napisal(a): > Hi, > > On Wed, Jan 17, 2018 at 09:14:11PM +0100, Jernej Skrabec wrote: > > This commit changes formula from this: > > > > Freq = (parent_freq * N * K) / (M * P) > > > > to this: > > > > Freq = (parent_freq / M) * N * K / P > > > > This improves situation when N is in the range 1-255. PLL parent clock > > is almost always 24 MHz, which means that for N >= 180 original formula > > overflows and result becomes useless. Situation can be improved if M is > > used as predivider as it can be seen in the second formula. That way at > > least M > 1 is considered, but it still leaves small gap for wrong result > > when M = 1 and N >= 180. > > > > Using M as predivider shouldn't cause any issue, because it is in range > > 1-4 at most, so there is no or only minimal rounding error. > > > > Signed-off-by: Jernej Skrabec > > I'd really prefer to stick to the formula documented and that we've > used so far. NKMP clocks are most notably used for the CPU PLLs and > I've debugged way too many cpufreq bugs already :) > > What about using long long types for the parent * n * k result? Yes, using long long is the best possible solution and covers all cases whereas this patch does not. I thought that do_div() would cause a lot of overhead, but I noticed that it's not big if both numbers fit in 32 bit, which in our case is true most of the time. I will make a helper function for calculating rate, since using long long needs more than one line of code. Best regards, Jernej
Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality
Dne sreda, 31. julij 2019 ob 14:29:53 CEST je Maxime Ripard napisal(a):
> On Tue, Jul 30, 2019 at 07:57:10PM +0200, Jernej Škrabec wrote:
> > Dne torek, 04. junij 2019 ob 11:38:44 CEST je Code Kipper napisal(a):
> > > On Tue, 4 Jun 2019 at 11:02, Christopher Obbard
wrote:
> > > > On Tue, 4 Jun 2019 at 09:43, Code Kipper wrote:
> > > > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard
> > > > >
> >
> > wrote:
> > > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekip...@gmail.com
wrote:
> > > > > > > From: Marcus Cooper
> > > > > > >
> > > > > > > The i2s block supports multi-lane i2s output however this
> > > > > > > functionality
> > > > > > > is only possible in earlier SoCs where the pins are exposed and
> > > > > > > for
> > > > > > > the i2s block used for HDMI audio on the later SoCs.
> > > > > > >
> > > > > > > To enable this functionality, an optional property has been
> > > > > > > added to
> > > > > > > the bindings.
> > > > > > >
> > > > > > > Signed-off-by: Marcus Cooper
> > > > > >
> > > > > > I'd like to have Mark's input on this, but I'm really worried
> > > > > > about
> > > > > > the interaction with the proper TDM support.
> > > > > >
> > > > > > Our fundamental issue is that the controller can have up to 8
> > > > > > channels, but either on 4 lines (instead of 1), or 8 channels on 1
> > > > > > (like proper TDM) (or any combination between the two, but that
> > > > > > should
> > > > > > be pretty rare).
> > > > >
> > > > > I understand...maybe the TDM needs to be extended to support this to
> > > > > consider channel mapping and multiple transfer lines. I was thinking
> > > > > about the later when someone was requesting support on IIRC a while
> > > > > ago, I thought masking might of been a solution. These can wait as
> > > > > the
> > > > > only consumer at the moment is LibreELEC and we can patch it there.
> > > >
> > > > Hi Marcus,
> > > >
> > > > FWIW, the TI McASP driver has support for TDM & (i think?) multiple
> > > > transfer lines which are called serializers.
> > > > Maybe this can help with inspiration?
> > > > see
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > > > e/s
> > > > ound/soc/ti/davinci-mcasp.c sample DTS:
> > > >
> > > > {
> > > >
> > > > #sound-dai-cells = <0>;
> > > > status = "okay";
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <_pins>;
> > > >
> > > > op-mode = <0>;
> > > > tdm-slots = <8>;
> > > > serial-dir = <
> > > >
> > > > 2 0 1 0
> > > > 0 0 0 0
> > > > 0 0 0 0
> > > > 0 0 0 0
> > > > >
> > > > >;
> > > >
> > > > tx-num-evt = <1>;
> > > > rx-num-evt = <1>;
> > > >
> > > > };
> > > >
> > > > Cheers!
> > >
> > > Thanks, this looks good.
> >
> > I would really like to see this issue resolved, because HDMI audio support
> > in mainline Linux for those SoCs is long overdue.
> >
> > However, there is a possibility to still add HDMI audio suport (stereo
> > only) even if this issue is not completely solved. If we agree that
> > configuration of channels would be solved with additional property as
> > Christopher suggested, support for >2 channels can be left for a later
> > time when support for that property would be implemented. Currently,
> > stereo HDMI audio support can be added with a few patches.
> >
> > I think all I2S cores are really the same, no matter if internally
> > connected to HDMI controller or routed to pins, so it would make sense to
> > use same compatible for all of them. It's just that those I2S cores which
> > are routed to pins can use only one lane and >2 channels can be used only
> > in TDM mode of operation, if I understand this correctly.
Re: [PATCH 5/6] media: sun4i: Add H3 deinterlace driver
Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:31PM +0200, Jernej Skrabec wrote:
> > + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> > +
_regmap_config);
> > + if (IS_ERR(dev->regmap)) {
> > + dev_err(dev->dev, "Couldn't create deinterlace
regmap\n");
> > +
> > + return PTR_ERR(dev->regmap);
> > + }
> > +
> > + ret = clk_prepare_enable(dev->bus_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable bus clock\n");
> > +
> > + return ret;
> > + }
>
> Do you need to keep the bus clock enabled all the time? Usually, for
> the SoCs that have a reset line, you only need it to read / write to
> the registers, not to have the controller actually running.
>
> If you don't, then regmap_init_mmio_clk will take care of that for
> you.
I just tested and using regmap_init_mmio_clk() with "bus" clock doesn't work.
I guess it has to be enabled whole time. I'll just leave it as-is.
Best regards,
Jernej
>
> > + clk_set_rate(dev->mod_clk, 3);
> > +
> > + ret = clk_prepare_enable(dev->mod_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable mod clock\n");
> > +
> > + goto err_bus_clk;
> > + }
> > +
> > + ret = clk_prepare_enable(dev->ram_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable ram clock\n");
> > +
> > + goto err_mod_clk;
> > + }
> > +
> > + ret = reset_control_reset(dev->rstc);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to apply reset\n");
> > +
> > + goto err_ram_clk;
> > + }
>
> This could be moved to a runtime_pm hook, with get_sync called in the
> open. That way you won't leave the device powered on if it's unused.
>
> > +struct deinterlace_dev {
> > + struct v4l2_device v4l2_dev;
> > + struct video_device vfd;
> > + struct device *dev;
> > + struct v4l2_m2m_dev *m2m_dev;
> > +
> > + /* Device file mutex */
> > + struct mutexdev_mutex;
> > +
> > + void __iomem*base;
> > + struct regmap *regmap;
>
> Do you need to store the base address in that structure if you're
> using the regmap?
>
> Maxime
Re: [PATCH v2 6/6] media: cedrus: Add support for holding capture buffer
Dne ponedeljek, 30. september 2019 ob 10:14:32 CEST je Hans Verkuil
napisal(a):
> On 9/29/19 10:00 PM, Jernej Skrabec wrote:
> > When frame contains multiple slices and driver works in slice mode, it's
> > more efficient to hold capture buffer in queue until all slices of a
> > same frame are decoded.
> >
> > Add support for that to Cedrus driver by exposing and implementing
> > V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +
> > drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 8 +---
> > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 14 ++
> > 3 files changed, 28 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > e49c3396ca4d..67f7d4326fc1 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > +
> > + if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
> > + run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > + }
> > + run.dst->is_held = run.src->flags &
V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
> > +
> >
> > run.first_slice = !run.dst->vb2_buf.copied_timestamp ||
> >
> > run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
> >
> > @@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
> >
> > run.mpeg2.quantization = cedrus_find_control_data(ctx,
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
> >
> > + run.dst->is_held = false;
> >
> > break;
> >
> > case V4L2_PIX_FMT_H264_SLICE:
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c index
> > fc8579b90dab..b466041c25db 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > @@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
> >
> > src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> >
> > - dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > if (!src_buf || !dst_buf) {
> >
> > v4l2_err(>v4l2_dev,
> >
> > @@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > state = VB2_BUF_STATE_DONE;
> >
> > v4l2_m2m_buf_done(src_buf, state);
> >
> > - v4l2_m2m_buf_done(dst_buf, state);
> > -
> > + if (!dst_buf->is_held) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(dst_buf, state);
> > + }
> >
> > v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
> >
> > return IRQ_HANDLED;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c index
> > 3ec3a2db790c..82198b2bb081 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -303,6 +303,17 @@ static int cedrus_s_fmt_vid_out(struct file *file,
> > void *priv,>
> > ctx->src_fmt = f->fmt.pix;
> >
> > + switch (ctx->src_fmt.pixelformat) {
> > + case V4L2_PIX_FMT_H264_SLICE:
> > + vq->subsystem_flags |=
> > + VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
> > + break;
> > + default:
> > + vq->subsystem_flags &=
> > +
(u32)~VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
>
> Why the u32 cast?
To prevent warnings on arm64 such as reported here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1620796.html
But I'm not sure if this aplies for this case. I compiled kernel for arm64 but
there is no warning without this cast with my configuration. I guess I can
remove it.
Best regards,
Jernej
>
> Regards,
>
> Hans
>
> > + break;
> > + }
> > +
> >
> > /* Propagate colorspace information to capture. */
> > ctx->dst_fmt.colorspace = f->fmt.pix.colorspace;
> > ctx->dst_fmt.xfer_func = f->fmt.pix.xfer_func;
> >
> > @@ -336,6 +347,9 @@ const struct v4l2_ioctl_ops cedrus_ioctl_ops = {
> >
> > .vidioc_streamon= v4l2_m2m_ioctl_streamon,
> > .vidioc_streamoff = v4l2_m2m_ioctl_streamoff,
> >
> > + .vidioc_try_decoder_cmd =
Re: [PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames
Dne ponedeljek, 30. september 2019 ob 10:10:48 CEST je Hans Verkuil napisal(a): > On 9/29/19 10:00 PM, Jernej Skrabec wrote: > > This series adds support for decoding multi-slice H264 frames along with > > support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF. > > > > Code was tested by modified ffmpeg, which can be found here: > > https://github.com/jernejsk/FFmpeg, branch mainline-test > > It has to be configured with at least following options: > > --enable-v4l2-request --enable-libudev --enable-libdrm > > > > Samples used for testing: > > http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4 > > http://jernej.libreelec.tv/videos/h264/h264.mp4 > > > > Command line used for testing: > > ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt > > bgra -f fbdev /dev/fb0 > > > > Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm > > not sure how. ffmpeg follows exactly which slice is last in frame > > and sets hold flag accordingly. Improper usage of hold flag would > > corrupt ffmpeg assumptions and it would probably crash. Any ideas > > how to test this are welcome! > > It can be tested partially at least: if ffmpeg tells you it is the last > slice, then queue the slice with the HOLD flag set, then call FLUSH > afterwards. This should clear the HOLD flag again. In this case the queued > buffer is probably not yet processed, so the flag is cleared before the > decode job starts. > > You can also try to add a sleep before calling FLUSH to see what happens > if the last queued buffer is already decoded. Ok, I tried following code: https://github.com/jernejsk/FFmpeg/blob/flush_test/libavcodec/ v4l2_request.c#L220-L233 But results are not good. It seems that out_vb in flush command is always NULL and so it always marks capture buffer as done, which leads to kernel warnings. dmesg output with debugging messages is here: http://ix.io/1Ks8 Currently I'm not sure what is going on. Shouldn't be output buffer queued and waiting to MEDIA_REQUEST_IOC_QUEUE which is executed after flush command as it can be seen from ffmpeg code linked above? Best regards, Jernej > > Regards, > > Hans > > > Thanks to Jonas for adjusting ffmpeg. > > > > Please let me know what you think. > > > > Best regards, > > Jernej > > > > Changes from v1: > > - added Rb tags > > - updated V4L2_DEC_CMD_FLUSH documentation > > - updated first slice detection in Cedrus > > - hold capture buffer flag is set according to source format > > - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers > > > > Hans Verkuil (2): > > vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF > > videodev2.h: add V4L2_DEC_CMD_FLUSH > > > > Jernej Skrabec (4): > > media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers > > media: cedrus: Detect first slice of a frame > > media: cedrus: h264: Support multiple slices per frame > > media: cedrus: Add support for holding capture buffer > > > > Documentation/media/uapi/v4l/buffer.rst | 13 ++ > > .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++- > > .../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++ > > .../media/videodev2.h.rst.exceptions | 1 + > > .../media/common/videobuf2/videobuf2-v4l2.c | 8 +++- > > drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++ > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 11 + > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 11 - > > .../staging/media/sunxi/cedrus/cedrus_hw.c| 8 ++-- > > .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++ > > include/media/v4l2-mem2mem.h | 46 +++ > > include/media/videobuf2-core.h| 3 ++ > > include/media/videobuf2-v4l2.h| 5 ++ > > include/uapi/linux/videodev2.h| 14 -- > > 15 files changed, 175 insertions(+), 11 deletions(-)
Re: [PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames
Dne torek, 01. oktober 2019 ob 00:43:34 CEST je Hans Verkuil napisal(a): > On 10/1/19 12:27 AM, Jernej Škrabec wrote: > > Dne ponedeljek, 30. september 2019 ob 10:10:48 CEST je Hans Verkuil > > > > napisal(a): > >> On 9/29/19 10:00 PM, Jernej Skrabec wrote: > >>> This series adds support for decoding multi-slice H264 frames along with > >>> support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF. > >>> > >>> Code was tested by modified ffmpeg, which can be found here: > >>> https://github.com/jernejsk/FFmpeg, branch mainline-test > >>> It has to be configured with at least following options: > >>> --enable-v4l2-request --enable-libudev --enable-libdrm > >>> > >>> Samples used for testing: > >>> http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4 > >>> http://jernej.libreelec.tv/videos/h264/h264.mp4 > >>> > >>> Command line used for testing: > >>> ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt > >>> bgra -f fbdev /dev/fb0 > >>> > >>> Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm > >>> not sure how. ffmpeg follows exactly which slice is last in frame > >>> and sets hold flag accordingly. Improper usage of hold flag would > >>> corrupt ffmpeg assumptions and it would probably crash. Any ideas > >>> how to test this are welcome! > >> > >> It can be tested partially at least: if ffmpeg tells you it is the last > >> slice, then queue the slice with the HOLD flag set, then call FLUSH > >> afterwards. This should clear the HOLD flag again. In this case the > >> queued > >> buffer is probably not yet processed, so the flag is cleared before the > >> decode job starts. > >> > >> You can also try to add a sleep before calling FLUSH to see what happens > >> if the last queued buffer is already decoded. > > > > Ok, I tried following code: > > https://github.com/jernejsk/FFmpeg/blob/flush_test/libavcodec/ > > v4l2_request.c#L220-L233 > > > > But results are not good. It seems that out_vb in flush command is always > > NULL and so it always marks capture buffer as done, which leads to kernel > > warnings. > > > > dmesg output with debugging messages is here: http://ix.io/1Ks8 > > > > Currently I'm not sure what is going on. Shouldn't be output buffer queued > > and waiting to MEDIA_REQUEST_IOC_QUEUE which is executed after flush > > command as it can be seen from ffmpeg code linked above? > > Argh, I forgot about the fact that this uses requests. > > The FLUSH should happen *after* the MEDIA_REQUEST_IOC_QUEUE ioctl. Otherwise > it has no effect. As long as the request hasn't been queued, the buffer is > also not queued to the driver, so out_vb will indeed be NULL. Well, flush cmd has effect if it is called before MEDIA_REQUEST_IOC_QUEUE ioctl as it can be seen from linked dmesg output. I guess there is nothing that we can do to prevent wrong usage? BTW, if capture buffer is marked as done, shouldn't be also removed from the queue? Best regards, Jernej > > Sorry for the confusion. > > Regards, > > Hans > > > Best regards, > > Jernej > > > >> Regards, > >> > >>Hans > >> > >>> Thanks to Jonas for adjusting ffmpeg. > >>> > >>> Please let me know what you think. > >>> > >>> Best regards, > >>> Jernej > >>> > >>> Changes from v1: > >>> - added Rb tags > >>> - updated V4L2_DEC_CMD_FLUSH documentation > >>> - updated first slice detection in Cedrus > >>> - hold capture buffer flag is set according to source format > >>> - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers > >>> > >>> Hans Verkuil (2): > >>> vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF > >>> videodev2.h: add V4L2_DEC_CMD_FLUSH > >>> > >>> Jernej Skrabec (4): > >>> media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers > >>> media: cedrus: Detect first slice of a frame > >>> media: cedrus: h264: Support multiple slices per frame > >>> media: cedrus: Add support for holding capture buffer > >>> > >>> Documentation/media/uapi/v4l/buffer.rst | 13 ++ > >>> .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++- > >>> .../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++ > >>> .../media/videodev2.h.rst.exceptions | 1 + > >>> .../media/common/videobuf2/videobuf2-v4l2.c | 8 +++- > >>> drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++ > >>> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > >>> .../staging/media/sunxi/cedrus/cedrus_dec.c | 11 + > >>> .../staging/media/sunxi/cedrus/cedrus_h264.c | 11 - > >>> .../staging/media/sunxi/cedrus/cedrus_hw.c| 8 ++-- > >>> .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++ > >>> include/media/v4l2-mem2mem.h | 46 +++ > >>> include/media/videobuf2-core.h| 3 ++ > >>> include/media/videobuf2-v4l2.h| 5 ++ > >>> include/uapi/linux/videodev2.h| 14 -- > >>> 15 files changed, 175 insertions(+), 11 deletions(-)
Re: [PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames
Dne torek, 01. oktober 2019 ob 00:43:34 CEST je Hans Verkuil napisal(a): > On 10/1/19 12:27 AM, Jernej Škrabec wrote: > > Dne ponedeljek, 30. september 2019 ob 10:10:48 CEST je Hans Verkuil > > > > napisal(a): > >> On 9/29/19 10:00 PM, Jernej Skrabec wrote: > >>> This series adds support for decoding multi-slice H264 frames along with > >>> support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF. > >>> > >>> Code was tested by modified ffmpeg, which can be found here: > >>> https://github.com/jernejsk/FFmpeg, branch mainline-test > >>> It has to be configured with at least following options: > >>> --enable-v4l2-request --enable-libudev --enable-libdrm > >>> > >>> Samples used for testing: > >>> http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4 > >>> http://jernej.libreelec.tv/videos/h264/h264.mp4 > >>> > >>> Command line used for testing: > >>> ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt > >>> bgra -f fbdev /dev/fb0 > >>> > >>> Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm > >>> not sure how. ffmpeg follows exactly which slice is last in frame > >>> and sets hold flag accordingly. Improper usage of hold flag would > >>> corrupt ffmpeg assumptions and it would probably crash. Any ideas > >>> how to test this are welcome! > >> > >> It can be tested partially at least: if ffmpeg tells you it is the last > >> slice, then queue the slice with the HOLD flag set, then call FLUSH > >> afterwards. This should clear the HOLD flag again. In this case the > >> queued > >> buffer is probably not yet processed, so the flag is cleared before the > >> decode job starts. > >> > >> You can also try to add a sleep before calling FLUSH to see what happens > >> if the last queued buffer is already decoded. > > > > Ok, I tried following code: > > https://github.com/jernejsk/FFmpeg/blob/flush_test/libavcodec/ > > v4l2_request.c#L220-L233 > > > > But results are not good. It seems that out_vb in flush command is always > > NULL and so it always marks capture buffer as done, which leads to kernel > > warnings. > > > > dmesg output with debugging messages is here: http://ix.io/1Ks8 > > > > Currently I'm not sure what is going on. Shouldn't be output buffer queued > > and waiting to MEDIA_REQUEST_IOC_QUEUE which is executed after flush > > command as it can be seen from ffmpeg code linked above? > > Argh, I forgot about the fact that this uses requests. > > The FLUSH should happen *after* the MEDIA_REQUEST_IOC_QUEUE ioctl. Otherwise > it has no effect. As long as the request hasn't been queued, the buffer is > also not queued to the driver, so out_vb will indeed be NULL. It's better, but still not working. Currently ffmpeg sometimes reports such messages: https://pastebin.com/raw/9tVVtc20 This is dmesg output: http:// ix.io/1L1L It seems to me like a race condition. Sometimes flush works as indendent and sometimes it influences next frame. Best regards, Jernje > > Sorry for the confusion. > > Regards, > > Hans > > > Best regards, > > Jernej > > > >> Regards, > >> > >>Hans > >> > >>> Thanks to Jonas for adjusting ffmpeg. > >>> > >>> Please let me know what you think. > >>> > >>> Best regards, > >>> Jernej > >>> > >>> Changes from v1: > >>> - added Rb tags > >>> - updated V4L2_DEC_CMD_FLUSH documentation > >>> - updated first slice detection in Cedrus > >>> - hold capture buffer flag is set according to source format > >>> - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers > >>> > >>> Hans Verkuil (2): > >>> vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF > >>> videodev2.h: add V4L2_DEC_CMD_FLUSH > >>> > >>> Jernej Skrabec (4): > >>> media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers > >>> media: cedrus: Detect first slice of a frame > >>> media: cedrus: h264: Support multiple slices per frame > >>> media: cedrus: Add support for holding capture buffer > >>> > >>> Documentation/media/uapi/v4l/buffer.rst | 13 ++ > >>> .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++- > >>> .../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++ > >>> .../media/videodev2.h.rst.exceptions | 1 + > >>> .../media/common/videobuf2/videobuf2-v4l2.c | 8 +++- > >>> drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++ > >>> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > >>> .../staging/media/sunxi/cedrus/cedrus_dec.c | 11 + > >>> .../staging/media/sunxi/cedrus/cedrus_h264.c | 11 - > >>> .../staging/media/sunxi/cedrus/cedrus_hw.c| 8 ++-- > >>> .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++ > >>> include/media/v4l2-mem2mem.h | 46 +++ > >>> include/media/videobuf2-core.h| 3 ++ > >>> include/media/videobuf2-v4l2.h| 5 ++ > >>> include/uapi/linux/videodev2.h| 14 -- > >>> 15 files changed, 175 insertions(+), 11 deletions(-)
Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
napisal(a):
> Hi Jernej,
>
> On Thu, 22 Aug 2019 21:44:57 +0200
>
> Jernej Skrabec wrote:
> > When codec supports multiple slices in one frame, VPU has to know when
> > first slice of each frame is being processed, presumably to correctly
> > clear/set data in auxiliary buffers.
> >
> > Add first_slice field to cedrus_run structure and set it according to
> > timestamps of capture and output buffers. If timestamps are different,
> > it's first slice and viceversa.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 2f017a651848..32cb38e541c6 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> >
> > struct cedrus_run {
> >
> > struct vb2_v4l2_buffer *src;
> > struct vb2_v4l2_buffer *dst;
> >
> > + bool first_slice;
> >
> > union {
> >
> > struct cedrus_h264_run h264;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > 56ca4c9ad01c..d7b54accfe83 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > + run.first_slice =
> > + run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
>
> Can't we use slice->first_mb_in_slice to determine if a slice is the
> first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> support ASO).
I looked in all VPU documentation available to me (which isn't much) and there
is no indication if ASO is supported or not. Do you have any sample video with
out-of-order slices? It's my understanding that this is uncommon. If it's
supported, I would leave code as-is.
Best regards,
Jernej
>
> > /* Apply request(s) controls if needed. */
> > src_req = run.src->vb2_buf.req_obj.req;
Re: [PATCH 3/6] ARM: dts: sunxi: h3/h5: Add MBUS controller node
Dne četrtek, 12. september 2019 ob 22:20:57 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:29PM +0200, Jernej Skrabec wrote:
> > Both, H3 and H5, contain MBUS, which is the bus used by DMA devices to
> > access system memory.
> >
> > MBUS controller is responsible for arbitration between channels based
> > on set priority and can do some other things as well, like report
> > bandwidth used. It also maps RAM region to different address than CPU.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index eba190b3f9de..ef1d03812636
> > 100644
> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > @@ -109,6 +109,7 @@
> >
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > + dma-ranges;
> >
> > ranges;
> >
> > display_clocks: clock@100 {
> >
> > @@ -538,6 +539,14 @@
> >
> > };
> >
> > };
> >
> > + mbus: dram-controller@1c62000 {
> > + compatible = "allwinner,sun8i-h3-mbus";
> > + reg = <0x01c62000 0x1000>;
> > + clocks = < 113>;
> > + dma-ranges = <0x 0x4000
0xc000>;
> > + #interconnect-cells = <1>;
> > + };
> > +
>
> If that's easy enough to access, can you also add the references in
> the devices that are already there? (CSI and DE comes to my mind, but
> there might be others).
Strangely, DE2 doesn't use this offset. That was tested on OrangePi Plus2E,
which has 2 GiB of RAM and subtracting this offset causes corrupted image.
But I can add this properties to CSI too. However, wouldn't that need CSI DT
binding expansion with those properties? othetwise DT check will fail.
Best regards,
Jernej
>
> Thanks!
> Maxime
Re: [PATCH 5/6] media: sun4i: Add H3 deinterlace driver
Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:31PM +0200, Jernej Skrabec wrote:
> > + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> > +
_regmap_config);
> > + if (IS_ERR(dev->regmap)) {
> > + dev_err(dev->dev, "Couldn't create deinterlace
regmap\n");
> > +
> > + return PTR_ERR(dev->regmap);
> > + }
> > +
> > + ret = clk_prepare_enable(dev->bus_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable bus clock\n");
> > +
> > + return ret;
> > + }
>
> Do you need to keep the bus clock enabled all the time? Usually, for
> the SoCs that have a reset line, you only need it to read / write to
> the registers, not to have the controller actually running.
>
> If you don't, then regmap_init_mmio_clk will take care of that for
> you.
I'll test that.
>
> > + clk_set_rate(dev->mod_clk, 3);
> > +
> > + ret = clk_prepare_enable(dev->mod_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable mod clock\n");
> > +
> > + goto err_bus_clk;
> > + }
> > +
> > + ret = clk_prepare_enable(dev->ram_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable ram clock\n");
> > +
> > + goto err_mod_clk;
> > + }
> > +
> > + ret = reset_control_reset(dev->rstc);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to apply reset\n");
> > +
> > + goto err_ram_clk;
> > + }
>
> This could be moved to a runtime_pm hook, with get_sync called in the
> open. That way you won't leave the device powered on if it's unused.
Ok.
>
> > +struct deinterlace_dev {
> > + struct v4l2_device v4l2_dev;
> > + struct video_device vfd;
> > + struct device *dev;
> > + struct v4l2_m2m_dev *m2m_dev;
> > +
> > + /* Device file mutex */
> > + struct mutexdev_mutex;
> > +
> > + void __iomem*base;
> > + struct regmap *regmap;
>
> Do you need to store the base address in that structure if you're
> using the regmap?
Probably not. I'll remove it in v2.
Best regards,
Jernej
>
> Maxime
Re: [PATCH 3/6] ARM: dts: sunxi: h3/h5: Add MBUS controller node
Dne četrtek, 12. september 2019 ob 22:34:27 CEST je Maxime Ripard napisal(a):
> On Thu, Sep 12, 2019 at 10:28:37PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 12. september 2019 ob 22:20:57 CEST je Maxime Ripard
napisal(a):
> > > Hi,
> > >
> > > On Thu, Sep 12, 2019 at 07:51:29PM +0200, Jernej Skrabec wrote:
> > > > Both, H3 and H5, contain MBUS, which is the bus used by DMA devices to
> > > > access system memory.
> > > >
> > > > MBUS controller is responsible for arbitration between channels based
> > > > on set priority and can do some other things as well, like report
> > > > bandwidth used. It also maps RAM region to different address than CPU.
> > > >
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > >
> > > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +
> > > > 1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index eba190b3f9de..ef1d03812636
> > > > 100644
> > > > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > @@ -109,6 +109,7 @@
> > > >
> > > > compatible = "simple-bus";
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > >
> > > > + dma-ranges;
> > > >
> > > > ranges;
> > > >
> > > > display_clocks: clock@100 {
> > > >
> > > > @@ -538,6 +539,14 @@
> > > >
> > > > };
> > > >
> > > > };
> > > >
> > > > + mbus: dram-controller@1c62000 {
> > > > + compatible = "allwinner,sun8i-h3-mbus";
> > > > + reg = <0x01c62000 0x1000>;
> > > > + clocks = < 113>;
> > > > + dma-ranges = <0x 0x4000
> >
> > 0xc000>;
> >
> > > > + #interconnect-cells = <1>;
> > > > + };
> > > > +
> > >
> > > If that's easy enough to access, can you also add the references in
> > > the devices that are already there? (CSI and DE comes to my mind, but
> > > there might be others).
> >
> > Strangely, DE2 doesn't use this offset. That was tested on OrangePi
> > Plus2E,
> > which has 2 GiB of RAM and subtracting this offset causes corrupted image.
>
> Ok, weird. But if it was tested then fine by me :)
>
> > But I can add this properties to CSI too. However, wouldn't that need CSI
> > DT binding expansion with those properties? othetwise DT check will fail.
> Oh right, we definitely need to update the binding indeed. The code
> should be able to cope with both cases already.
I guess it's better to handle that with another patch series then? Changing
CSI bindings doesn't fit here.
Best regards,
Jernej
Re: [PATCH 5/6] media: sun4i: Add H3 deinterlace driver
Hi! Dne petek, 13. september 2019 ob 11:11:47 CEST je Maxime Ripard napisal(a): > Hi, > > On Thu, Sep 12, 2019 at 10:43:28PM +0200, Jernej Škrabec wrote: > > Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a): > > > > + clk_set_rate(dev->mod_clk, 3); > > I just realized I missed this too. If you really need the rate to be > fixed, and if the controller cannot operate properly at any other > frequency, you probably want to use clk_set_rate_exclusive there. I don't think that's needed. Parents of deinterlace clock are pll-periph0 and pll-periph1 which both have fixed clock and thus deinterlace clock will never be changed. I just set it to same frequency as it is set in BSP driver. I think it works with 600 MHz too, but that's overkill. Best regards, Jernej
Re: [PATCH 5/6] media: sun4i: Add H3 deinterlace driver
Hi!
Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:31PM +0200, Jernej Skrabec wrote:
> > + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> > +
_regmap_config);
> > + if (IS_ERR(dev->regmap)) {
> > + dev_err(dev->dev, "Couldn't create deinterlace
regmap\n");
> > +
> > + return PTR_ERR(dev->regmap);
> > + }
> > +
> > + ret = clk_prepare_enable(dev->bus_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable bus clock\n");
> > +
> > + return ret;
> > + }
>
> Do you need to keep the bus clock enabled all the time? Usually, for
> the SoCs that have a reset line, you only need it to read / write to
> the registers, not to have the controller actually running.
>
> If you don't, then regmap_init_mmio_clk will take care of that for
> you.
>
> > + clk_set_rate(dev->mod_clk, 3);
> > +
> > + ret = clk_prepare_enable(dev->mod_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable mod clock\n");
> > +
> > + goto err_bus_clk;
> > + }
> > +
> > + ret = clk_prepare_enable(dev->ram_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable ram clock\n");
> > +
> > + goto err_mod_clk;
> > + }
> > +
> > + ret = reset_control_reset(dev->rstc);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to apply reset\n");
> > +
> > + goto err_ram_clk;
> > + }
>
> This could be moved to a runtime_pm hook, with get_sync called in the
> open. That way you won't leave the device powered on if it's unused.
Currently I'm looking at sun4i_csi.c as an example of runtime ops, but it
seems a bit wrong to have suspend and resume function marked with
__maybe_unused because they are the only functions which enable needed clocks.
If CONFIG_PM is not enabled, then this driver simply won't work, because
clocks will never get enabled. I guess I can implement runtime pm ops in the
same way and add additional handling when CONFIG_PM is not enabled, right?
BTW, which callback is get_sync? I don't see it in dev_pm_ops. I suppose I
need only runtime_suspend and runtime_resume.
Off topic: sun6i_csi.c includes linux/pm_runtime.h but it doesn't have any kind
of power management as far as I can see.
Best regards,
Jernej
>
> > +struct deinterlace_dev {
> > + struct v4l2_device v4l2_dev;
> > + struct video_device vfd;
> > + struct device *dev;
> > + struct v4l2_m2m_dev *m2m_dev;
> > +
> > + /* Device file mutex */
> > + struct mutexdev_mutex;
> > +
> > + void __iomem*base;
> > + struct regmap *regmap;
>
> Do you need to store the base address in that structure if you're
> using the regmap?
>
> Maxime
Re: [PATCH v2 2/3] media: cedrus: Fix H264 default reference index count
Dne četrtek, 03. oktober 2019 ob 00:06:50 CEST je Paul Kocialkowski napisal(a): > Hi, > > On Wed 02 Oct 19, 21:35, Jernej Skrabec wrote: > > Reference index count in VE_H264_PPS should come from PPS control. > > However, this is not really important, because reference index count is > > in our case always overridden by that from slice header. > > Thanks for the fixup! > > Our libva userspace and v4l2-request testing tool currently don't provide > this, but I have a pending merge request adding it for the hantro so it's > good to go. Actually, I think this is just cosmetic and it would work even if it would be always 0. We always override this number in SHS2 register with VE_H264_SHS2_NUM_REF_IDX_ACTIVE_OVRD flag and recently there was a patch merged to clarify that value in slice parameters should be the one that's set on default value if override flag is not set in bitstream: https://git.linuxtv.org/media_tree.git/commit/? id=187ef7c5c78153acdce8c8714e5918b1018c710b Well, we could always compare default and value in slice parameters, but I really don't see the benefit of doing that extra work. Best regards, Jernej > > Acked-by: Paul Kocialkowski > > Cheers, > > Paul > > > Signed-off-by: Jernej Skrabec > > --- > > > > drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 8 ++-- > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index > > bd848146eada..4a0e69855c7f 100644 > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > @@ -364,12 +364,8 @@ static void cedrus_set_params(struct cedrus_ctx *ctx, > > > > // picture parameters > > reg = 0; > > > > - /* > > -* FIXME: the kernel headers are allowing the default value to > > -* be passed, but the libva doesn't give us that. > > -*/ > > - reg |= (slice->num_ref_idx_l0_active_minus1 & 0x1f) << 10; > > - reg |= (slice->num_ref_idx_l1_active_minus1 & 0x1f) << 5; > > + reg |= (pps->num_ref_idx_l0_default_active_minus1 & 0x1f) << 10; > > + reg |= (pps->num_ref_idx_l1_default_active_minus1 & 0x1f) << 5; > > > > reg |= (pps->weighted_bipred_idc & 0x3) << 2; > > if (pps->flags & V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE) > > > > reg |= VE_H264_PPS_ENTROPY_CODING_MODE;
Re: [PATCH v2 0/3] media: cedrus: improvements
Dne četrtek, 03. oktober 2019 ob 00:23:07 CEST je Paul Kocialkowski napisal(a): > Hi, > > On Wed 02 Oct 19, 21:35, Jernej Skrabec wrote: > > This is continuation of https://lkml.org/lkml/2019/5/30/1459 with several > > patches removed (2 merged, others needs redesign) and one added. > > Thanks for the continued effort on this, these fixes are greatly appreciated > (and more generally, all the work you are putting into cedrus)! > > Although I've been out of the loop on cedrus, it is very nice to see > development happening. Keep up the good work! Thanks! Those fixes are just cleaned up version of patches I'm using in LibreELEC for some time now. I hate maintaining out-of-tree patches over a long period, so pushing them upstream is beneficial for all :) I'll send more improvements once your HEVC patches are merged. Best regards, Jernej > > Cheers, > > Paul > > > Patch 1 fixes h264 playback issue which happens in rare cases. > > > > Patch 2 sets PPS default reference index count in register from PPS > > control. Currently it was set to values from slice control. > > > > Patch 3 replaces direct accesses to capture queue from m2m contex with > > helpers which was designed exactly for that. It's also safer since > > helpers do some checks. > > > > Best regards, > > Jernej > > > > Jernej Skrabec (3): > > media: cedrus: Fix decoding for some H264 videos > > media: cedrus: Fix H264 default reference index count > > media: cedrus: Use helpers to access capture queue > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 8 +++- > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 46 ++- > > .../staging/media/sunxi/cedrus/cedrus_regs.h | 3 ++ > > 3 files changed, 44 insertions(+), 13 deletions(-)
Re: [PATCH v5 11/15] ASoC: sun4i-i2s: Add support for H6 I2S
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:50 CEST je codekip...@gmail.com
napisal(a):
> From: Jernej Skrabec
>
> H6 I2S is very similar to that in H3, except it supports up to 16
> channels.
>
> Signed-off-by: Jernej Skrabec
Your Signed-off-by is missing here and on all other patches made originally by
me.
Best regards,
Jernej
> ---
> sound/soc/sunxi/sun4i-i2s.c | 148
> 1 file changed, 148 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 6de3cb41aaf6..a8d98696fe7c 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -121,6 +121,21 @@
> #define SUN8I_I2S_RX_CHAN_SEL_REG0x54
> #define SUN8I_I2S_RX_CHAN_MAP_REG0x58
>
> +/* Defines required for sun50i-h6 support */
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASKGENMASK(21, 20)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16)
> +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan) ((chan - 1) << 16)
> +#define SUN50I_H6_I2S_TX_CHAN_EN_MASKGENMASK(15, 0)
> +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1))
> +
> +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44
> +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48
> +
> +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG0x64
> +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68
> +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C
> +
> struct sun4i_i2s;
>
> /**
> @@ -440,6 +455,25 @@ static void sun8i_i2s_set_rxchanoffset(const struct
> sun4i_i2s *i2s) SUN8I_I2S_TX_CHAN_OFFSET(i2s->offset));
> }
>
> +static void sun50i_h6_i2s_set_txchanoffset(const struct sun4i_i2s *i2s, int
> output) +{
> + if (output >= 0 && output < 4) {
> + regmap_update_bits(i2s->regmap,
> +SUN8I_I2S_TX_CHAN_SEL_REG +
(output * 4),
> +
SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK,
> +
SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(i2s->offset));
> + }
> +
> +}
> +
> +static void sun50i_h6_i2s_set_rxchanoffset(const struct sun4i_i2s *i2s)
> +{
> + regmap_update_bits(i2s->regmap,
> +SUN50I_H6_I2S_RX_CHAN_SEL_REG,
> +SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK,
> +SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(i2s-
>offset));
> +}
> +
> static void sun8i_i2s_set_txchanen(const struct sun4i_i2s *i2s, int output,
> int channel)
> {
> @@ -459,6 +493,26 @@ static void sun8i_i2s_set_rxchanen(const struct
> sun4i_i2s *i2s, int channel) SUN8I_I2S_TX_CHAN_EN(channel));
> }
>
> +
> +static void sun50i_h6_i2s_set_txchanen(const struct sun4i_i2s *i2s, int
> output, +int channel)
> +{
> + if (output >= 0 && output < 4) {
> + regmap_update_bits(i2s->regmap,
> +SUN8I_I2S_TX_CHAN_SEL_REG +
(output * 4),
> +SUN50I_H6_I2S_TX_CHAN_EN_MASK,
> +
SUN50I_H6_I2S_TX_CHAN_EN(channel));
> + }
> +}
> +
> +static void sun50i_h6_i2s_set_rxchanen(const struct sun4i_i2s *i2s, int
> channel) +{
> + regmap_update_bits(i2s->regmap,
> +SUN50I_H6_I2S_RX_CHAN_SEL_REG,
> +SUN50I_H6_I2S_TX_CHAN_EN_MASK,
> +SUN50I_H6_I2S_TX_CHAN_EN(channel));
> +}
> +
> static void sun4i_i2s_set_txchansel(const struct sun4i_i2s *i2s, int
> output, int channel)
> {
> @@ -495,6 +549,25 @@ static void sun8i_i2s_set_rxchansel(const struct
> sun4i_i2s *i2s, int channel) SUN8I_I2S_TX_CHAN_SEL(channel));
> }
>
> +static void sun50i_h6_i2s_set_txchansel(const struct sun4i_i2s *i2s, int
> output, +int channel)
> +{
> + if (output >= 0 && output < 4) {
> + regmap_update_bits(i2s->regmap,
> +SUN8I_I2S_TX_CHAN_SEL_REG +
(output * 4),
> +SUN50I_H6_I2S_TX_CHAN_SEL_MASK,
> +
SUN50I_H6_I2S_TX_CHAN_SEL(channel));
> + }
> +}
> +
> +static void sun50i_h6_i2s_set_rxchansel(const struct sun4i_i2s *i2s, int
> channel) +{
> + regmap_update_bits(i2s->regmap,
> +SUN50I_H6_I2S_RX_CHAN_SEL_REG,
> +SUN50I_H6_I2S_TX_CHAN_SEL_MASK,
> +SUN50I_H6_I2S_TX_CHAN_SEL(channel));
> +}
> +
> static void sun4i_i2s_set_txchanmap(const struct sun4i_i2s *i2s, int
> output, int channel)
> {
> @@ -520,6 +593,20 @@ static void sun8i_i2s_set_rxchanmap(const struct
> sun4i_i2s *i2s, int channel) regmap_write(i2s->regmap,
> SUN8I_I2S_RX_CHAN_MAP_REG, channel);
> }
>
> +static void sun50i_h6_i2s_set_txchanmap(const struct sun4i_i2s *i2s, int
> output, +int channel)
> +{
> + if (output >= 0 && output < 4) {
> +
Re: [linux-sunxi] [PATCH v5 12/15] ASoC: sun4i-i2s: Add multi-lane functionality
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:51 CEST je codekip...@gmail.com
napisal(a):
> From: Marcus Cooper
>
> The i2s block supports multi-lane i2s output however this functionality
> is only possible in earlier SoCs where the pins are exposed and for
> the i2s block used for HDMI audio on the later SoCs.
>
> To enable this functionality, an optional property has been added to
> the bindings.
>
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/sun4i-i2s.c | 28 +---
> 1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index a8d98696fe7c..a020c3b372a8 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -23,7 +23,7 @@
>
> #define SUN4I_I2S_CTRL_REG 0x00
> #define SUN4I_I2S_CTRL_SDO_EN_MASK GENMASK(11, 8)
> -#define SUN4I_I2S_CTRL_SDO_EN(sdo) BIT(8 +
(sdo))
> +#define SUN4I_I2S_CTRL_SDO_EN(lines) (((1 << lines) - 1)
<< 8)
> #define SUN4I_I2S_CTRL_MODE_MASK BIT(5)
> #define SUN4I_I2S_CTRL_MODE_SLAVE(1 << 5)
> #define SUN4I_I2S_CTRL_MODE_MASTER (0 << 5)
> @@ -614,6 +614,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream, struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
> int sr, wss, channels;
> u32 width;
> + int lines;
>
> channels = params_channels(params);
> if (channels != 2) {
> @@ -622,6 +623,13 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream, return -EINVAL;
> }
>
> + lines = (channels + 1) / 2;
> +
> + /* Enable the required output lines */
> + regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG,
> +SUN4I_I2S_CTRL_SDO_EN_MASK,
> +SUN4I_I2S_CTRL_SDO_EN(lines));
As Maxime said before, this doesn't work for TDM. Maybe we can skip this for
now, until we agree on method how to describe channel allocation?
> +
> if (i2s->variant->has_chcfg) {
> regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
>
SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK,
> @@ -1389,9 +1397,10 @@ static int sun4i_i2s_init_regmap_fields(struct device
> *dev, static int sun4i_i2s_probe(struct platform_device *pdev)
> {
> struct sun4i_i2s *i2s;
> + struct snd_soc_dai_driver *soc_dai;
> struct resource *res;
> void __iomem *regs;
> - int irq, ret;
> + int irq, ret, val;
>
> i2s = devm_kzalloc(>dev, sizeof(*i2s), GFP_KERNEL);
> if (!i2s)
> @@ -1456,6 +1465,19 @@ static int sun4i_i2s_probe(struct platform_device
> *pdev) i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
> i2s->capture_dma_data.maxburst = 8;
>
> + soc_dai = devm_kmemdup(>dev, _i2s_dai,
> +sizeof(*soc_dai), GFP_KERNEL);
> + if (!soc_dai) {
> + ret = -ENOMEM;
> + goto err_pm_disable;
> + }
> +
> + if (!of_property_read_u32(pdev->dev.of_node,
> + "allwinner,playback-channels",
)) {
> + if (val >= 2 && val <= 8)
> + soc_dai->playback.channels_max = val;
> + }
> +
Rather than inventing new DT properties, I would rather have multiple
snd_soc_dai_driver structures, depending on capabilities of that particular
I2S block. That way we avoid some boilerplate code as can be seen here and
it's IMO more transparent.
In this case, I would make another snd_soc_dai_driver struct for H3, which has
channel_max property set to 8 and from patch 14, additional supported formats.
Best regards,
Jernej
> pm_runtime_enable(>dev);
> if (!pm_runtime_enabled(>dev)) {
> ret = sun4i_i2s_runtime_resume(>dev);
> @@ -1465,7 +1487,7 @@ static int sun4i_i2s_probe(struct platform_device
> *pdev)
>
> ret = devm_snd_soc_register_component(>dev,
>
_i2s_component,
> - _i2s_dai,
1);
> + soc_dai, 1);
> if (ret) {
> dev_err(>dev, "Could not register DAI\n");
> goto err_suspend;
Re: [linux-sunxi] [PATCH v5 14/15] ASoc: sun4i-i2s: Add 20, 24 and 32 bit support
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:53 CEST je codekip...@gmail.com
napisal(a):
> From: Marcus Cooper
>
> Extend the functionality of the driver to include support of 20 and
> 24 bits per sample for the earlier SoCs.
>
> Newer SoCs can also handle 32bit samples.
>
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/sun4i-i2s.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index a71969167053..d3c8789f70bb 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -690,6 +690,11 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream, case 16:
> width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> break;
> + case 20:
> + case 24:
> + case 32:
params_physical_width() returns 32 also for 20 and 24-bit formats, so drop 20
and 24.
Best regards,
Jernej
> + width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + break;
> default:
> dev_err(dai->dev, "Unsupported physical sample width:
%d\n",
> params_physical_width(params));
> @@ -1015,6 +1020,13 @@ static int sun4i_i2s_dai_probe(struct snd_soc_dai
> *dai) return 0;
> }
>
> +#define SUN4I_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | \
> + SNDRV_PCM_FMTBIT_S20_LE | \
> + SNDRV_PCM_FMTBIT_S24_LE)
> +
> +#define SUN8I_FORMATS(SUN4I_FORMATS | \
> + SNDRV_PCM_FMTBIT_S32_LE)
> +
> static struct snd_soc_dai_driver sun4i_i2s_dai = {
> .probe = sun4i_i2s_dai_probe,
> .capture = {
> @@ -1022,14 +1034,14 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
> .channels_min = 2,
> .channels_max = 2,
> .rates = SNDRV_PCM_RATE_8000_192000,
> - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> + .formats = SUN4I_FORMATS,
> },
> .playback = {
> .stream_name = "Playback",
> .channels_min = 2,
> .channels_max = 2,
> .rates = SNDRV_PCM_RATE_8000_192000,
> - .formats = SNDRV_PCM_FMTBIT_S16_LE,
> + .formats = SUN4I_FORMATS,
> },
> .ops = _i2s_dai_ops,
> .symmetric_rates = 1,
> @@ -1505,6 +1517,11 @@ static int sun4i_i2s_probe(struct platform_device
> *pdev) goto err_pm_disable;
> }
>
> + if (i2s->variant->has_fmt_set_lrck_period) {
> + soc_dai->playback.formats = SUN8I_FORMATS;
> + soc_dai->capture.formats = SUN8I_FORMATS;
> + }
> +
> if (!of_property_read_u32(pdev->dev.of_node,
> "allwinner,playback-channels",
)) {
> if (val >= 2 && val <= 8)
Re: [linux-sunxi] [PATCH v5 15/15] ASoC: sun4i-i2s: Adjust regmap settings
Hi!
Dne sreda, 14. avgust 2019 ob 08:08:54 CEST je codekip...@gmail.com
napisal(a):
> From: Marcus Cooper
>
> Bypass the regmap cache when flushing the i2s FIFOs and modify the tables
> to reflect this.
>
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/sun4i-i2s.c | 31 ++-
> 1 file changed, 10 insertions(+), 21 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index d3c8789f70bb..ecfc1ed79379 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -876,9 +876,11 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai,
> unsigned int fmt) static void sun4i_i2s_start_capture(struct sun4i_i2s
> *i2s)
> {
> /* Flush RX FIFO */
> + regcache_cache_bypass(i2s->regmap, true);
> regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> SUN4I_I2S_FIFO_CTRL_FLUSH_RX,
> SUN4I_I2S_FIFO_CTRL_FLUSH_RX);
> + regcache_cache_bypass(i2s->regmap, false);
Did you try with regmap_write_bits() instead? This function will
unconditionally write bits so it's nicer solution, because you don't have to
use regcache_cache_bypass().
>
> /* Clear RX counter */
> regmap_write(i2s->regmap, SUN4I_I2S_RX_CNT_REG, 0);
> @@ -897,9 +899,11 @@ static void sun4i_i2s_start_capture(struct sun4i_i2s
> *i2s) static void sun4i_i2s_start_playback(struct sun4i_i2s *i2s)
> {
> /* Flush TX FIFO */
> + regcache_cache_bypass(i2s->regmap, true);
> regmap_update_bits(i2s->regmap, SUN4I_I2S_FIFO_CTRL_REG,
> SUN4I_I2S_FIFO_CTRL_FLUSH_TX,
> SUN4I_I2S_FIFO_CTRL_FLUSH_TX);
> + regcache_cache_bypass(i2s->regmap, false);
Ditto.
>
> /* Clear TX counter */
> regmap_write(i2s->regmap, SUN4I_I2S_TX_CNT_REG, 0);
> @@ -1053,13 +1057,7 @@ static const struct snd_soc_component_driver
> sun4i_i2s_component = {
>
> static bool sun4i_i2s_rd_reg(struct device *dev, unsigned int reg)
> {
> - switch (reg) {
> - case SUN4I_I2S_FIFO_TX_REG:
> - return false;
> -
> - default:
> - return true;
> - }
> + return true;
Why did you change this? Manual mentions that SUN4I_I2S_FIFO_TX_REG is write-
only register. Even if it can be read, then it's better to remove whole
function, which will automatically mean that all registers can be read.
> }
>
> static bool sun4i_i2s_wr_reg(struct device *dev, unsigned int reg)
> @@ -1078,6 +1076,8 @@ static bool sun4i_i2s_volatile_reg(struct device *dev,
> unsigned int reg) {
> switch (reg) {
> case SUN4I_I2S_FIFO_RX_REG:
> + case SUN4I_I2S_FIFO_TX_REG:
> + case SUN4I_I2S_FIFO_STA_REG:
> case SUN4I_I2S_INT_STA_REG:
> case SUN4I_I2S_RX_CNT_REG:
> case SUN4I_I2S_TX_CNT_REG:
SUN4I_I2S_FIFO_CTRL_REG should be put here, because it has two bits which
returns to 0 immediately after they are set to 1.
Best regards,
Jernej
> @@ -1088,23 +1088,12 @@ static bool sun4i_i2s_volatile_reg(struct device
> *dev, unsigned int reg) }
> }
>
> -static bool sun8i_i2s_rd_reg(struct device *dev, unsigned int reg)
> -{
> - switch (reg) {
> - case SUN8I_I2S_FIFO_TX_REG:
> - return false;
> -
> - default:
> - return true;
> - }
> -}
> -
> static bool sun8i_i2s_volatile_reg(struct device *dev, unsigned int reg)
> {
> if (reg == SUN8I_I2S_INT_STA_REG)
> return true;
> if (reg == SUN8I_I2S_FIFO_TX_REG)
> - return false;
> + return true;
>
> return sun4i_i2s_volatile_reg(dev, reg);
> }
> @@ -1175,7 +1164,7 @@ static const struct regmap_config
> sun8i_i2s_regmap_config = { .reg_defaults = sun8i_i2s_reg_defaults,
> .num_reg_defaults = ARRAY_SIZE(sun8i_i2s_reg_defaults),
> .writeable_reg = sun4i_i2s_wr_reg,
> - .readable_reg = sun8i_i2s_rd_reg,
> + .readable_reg = sun4i_i2s_rd_reg,
> .volatile_reg = sun8i_i2s_volatile_reg,
> };
>
> @@ -1188,7 +1177,7 @@ static const struct regmap_config
> sun50i_i2s_regmap_config = { .reg_defaults= sun50i_i2s_reg_defaults,
> .num_reg_defaults = ARRAY_SIZE(sun50i_i2s_reg_defaults),
> .writeable_reg = sun4i_i2s_wr_reg,
> - .readable_reg = sun8i_i2s_rd_reg,
> + .readable_reg = sun4i_i2s_rd_reg,
> .volatile_reg = sun8i_i2s_volatile_reg,
> };
Re: [linux-sunxi] Re: [PATCH v5 15/15] ASoC: sun4i-i2s: Adjust regmap settings
Dne sreda, 14. avgust 2019 ob 09:20:07 CEST je Maxime Ripard napisal(a): > On Wed, Aug 14, 2019 at 08:08:54AM +0200, codekip...@gmail.com wrote: > > From: Marcus Cooper > > > > Bypass the regmap cache when flushing the i2s FIFOs and modify the tables > > to reflect this. > > > > Signed-off-by: Marcus Cooper > > This patch looks like it's fixing something while the commit log > doesn't mention what is being fixed. Main issue addressed here is that SUN4I_I2S_FIFO_CTRL_REG has two self-clear registers (SUN4I_I2S_FIFO_CTRL_FLUSH_RX and SUN4I_I2S_FIFO_CTRL_FLUSH_TX) and thus it should be marked as volatile. Best regards, Jernej > > Having some context here would be great. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Re: [PATCH v2 2/3] media: cedrus: Fix H264 default reference index count
Dne četrtek, 03. oktober 2019 ob 22:28:46 CEST je Paul Kocialkowski napisal(a): > Hi, > > On Thu 03 Oct 19, 07:16, Jernej Škrabec wrote: > > Dne četrtek, 03. oktober 2019 ob 00:06:50 CEST je Paul Kocialkowski > > > > napisal(a): > > > Hi, > > > > > > On Wed 02 Oct 19, 21:35, Jernej Skrabec wrote: > > > > Reference index count in VE_H264_PPS should come from PPS control. > > > > However, this is not really important, because reference index count > > > > is > > > > in our case always overridden by that from slice header. > > > > > > Thanks for the fixup! > > > > > > Our libva userspace and v4l2-request testing tool currently don't > > > provide > > > this, but I have a pending merge request adding it for the hantro so > > > it's > > > good to go. > > > > Actually, I think this is just cosmetic and it would work even if it would > > be always 0. We always override this number in SHS2 register with > > VE_H264_SHS2_NUM_REF_IDX_ACTIVE_OVRD flag and recently there was a patch > > merged to clarify that value in slice parameters should be the one that's > > set on default value if override flag is not set in bitstream: > > https://git.linuxtv.org/media_tree.git/commit/? > > id=187ef7c5c78153acdce8c8714e5918b1018c710b > > > > Well, we could always compare default and value in slice parameters, but I > > really don't see the benefit of doing that extra work. > > Thanks for the detailed explanation! So I just realized that for HEVC, I > didn't even include the default value in PPS and only went for the > per-slice value. The HEVC hardware block apparently only needs the fields > once at slice level, and by looking at the spec, only one of the two set of > fields will be used. > > So perhaps we could do the same for H.264 and only have the set of fields > once in the slice params, so that both codecs are consistent. Userspace can > just check the flag to know whether it should put the PPS default or > slice-specific value in the slice-specific control. > > What do you think? I think that there would be less confusion if only value in slice params would exists. But since Philipp rather made clarification in documentation, maybe he sees benefit having both values? Best regards, Jernej > > Cheers, > > Paul > > > Best regards, > > Jernej > > > > > Acked-by: Paul Kocialkowski > > > > > > Cheers, > > > > > > Paul > > > > > > > Signed-off-by: Jernej Skrabec > > > > --- > > > > > > > > drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 8 ++-- > > > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > > > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index > > > > bd848146eada..4a0e69855c7f 100644 > > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > > > @@ -364,12 +364,8 @@ static void cedrus_set_params(struct cedrus_ctx > > > > *ctx, > > > > > > > > // picture parameters > > > > reg = 0; > > > > > > > > - /* > > > > -* FIXME: the kernel headers are allowing the default value to > > > > -* be passed, but the libva doesn't give us that. > > > > -*/ > > > > - reg |= (slice->num_ref_idx_l0_active_minus1 & 0x1f) << 10; > > > > - reg |= (slice->num_ref_idx_l1_active_minus1 & 0x1f) << 5; > > > > + reg |= (pps->num_ref_idx_l0_default_active_minus1 & 0x1f) << 10; > > > > + reg |= (pps->num_ref_idx_l1_default_active_minus1 & 0x1f) << 5; > > > > > > > > reg |= (pps->weighted_bipred_idc & 0x3) << 2; > > > > if (pps->flags & V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE) > > > > > > > > reg |= VE_H264_PPS_ENTROPY_CODING_MODE;
Re: [PATCH v2 2/3] media: cedrus: Fix H264 default reference index count
Dne četrtek, 03. oktober 2019 ob 22:58:57 CEST je Paul Kocialkowski napisal(a): > Hi, > > On Thu 03 Oct 19, 22:44, Jernej Škrabec wrote: > > Dne četrtek, 03. oktober 2019 ob 22:28:46 CEST je Paul Kocialkowski > > > > napisal(a): > > > Hi, > > > > > > On Thu 03 Oct 19, 07:16, Jernej Škrabec wrote: > > > > Dne četrtek, 03. oktober 2019 ob 00:06:50 CEST je Paul Kocialkowski > > > > > > > > napisal(a): > > > > > Hi, > > > > > > > > > > On Wed 02 Oct 19, 21:35, Jernej Skrabec wrote: > > > > > > Reference index count in VE_H264_PPS should come from PPS control. > > > > > > However, this is not really important, because reference index > > > > > > count > > > > > > is > > > > > > in our case always overridden by that from slice header. > > > > > > > > > > Thanks for the fixup! > > > > > > > > > > Our libva userspace and v4l2-request testing tool currently don't > > > > > provide > > > > > this, but I have a pending merge request adding it for the hantro so > > > > > it's > > > > > good to go. > > > > > > > > Actually, I think this is just cosmetic and it would work even if it > > > > would > > > > be always 0. We always override this number in SHS2 register with > > > > VE_H264_SHS2_NUM_REF_IDX_ACTIVE_OVRD flag and recently there was a > > > > patch > > > > merged to clarify that value in slice parameters should be the one > > > > that's > > > > set on default value if override flag is not set in bitstream: > > > > https://git.linuxtv.org/media_tree.git/commit/? > > > > id=187ef7c5c78153acdce8c8714e5918b1018c710b > > > > > > > > Well, we could always compare default and value in slice parameters, > > > > but I > > > > really don't see the benefit of doing that extra work. > > > > > > Thanks for the detailed explanation! So I just realized that for HEVC, I > > > didn't even include the default value in PPS and only went for the > > > per-slice value. The HEVC hardware block apparently only needs the > > > fields > > > once at slice level, and by looking at the spec, only one of the two set > > > of > > > fields will be used. > > > > > > So perhaps we could do the same for H.264 and only have the set of > > > fields > > > once in the slice params, so that both codecs are consistent. Userspace > > > can > > > just check the flag to know whether it should put the PPS default or > > > slice-specific value in the slice-specific control. > > > > > > What do you think? > > > > I think that there would be less confusion if only value in slice params > > would exists. But since Philipp rather made clarification in > > documentation, maybe he sees benefit having both values? > > Actually I just caught up with the discussion from thread: > media: uapi: h264: Add num_ref_idx_active_override_flag > > which explains that we need to pass the default fields for hardware that > parses the slice header itself and we need the non-default fields and flag > for other cases. > > To cover the case of hardware that does slice header parsing, I guess it > would also work to use the slice-specific values in place of the pps > default values in the hardware register for that. But it feels quite > confusing and a lot less straightforward than having all the fields and the > override flag exposed. I wasn't aware of that patch and related discussion. Ok, so it make sense to have both values. However, does it make sense to use default values in Cedrus? > > So I think I should fix HEVC support accordingly, just in case the same > situation arises for HEVC. Seems reasonable. Does that mean there will be another revision of HEVC patches? If so, I think slice_segment_addr should also be included in slice params, so multi-slice frames can be supported at later time. Best regards, Jernej > > Cheers, > > Paul > > > Best regards, > > Jernej > > > > > Cheers, > > > > > > Paul > > > > > > > Best regards, > > > > Jernej > > > > > > > > > Acked-by: Paul Kocialkowski > > > > > > > > > > Cheers, > > > > > > > > > > Paul > > > > > > > > > > > Signed-off-by: Jernej Skra
Re: [linux-sunxi] Re: [PATCH 4/6] pwm: sun4i: Add support for H6 PWM
Dne ponedeljek, 12. avgust 2019 ob 12:47:00 CEST je Uwe Kleine-König napisal(a): > Hello Maxime, > > the idea of my mail was to summarize quickly the discussion for the dt > people to give their judgement to stop us circling in a discussion about > the always same points. > > I suggest we stop the discussion here now and wait for a reply from them > instead. Shouldn't we just go with compromise solution you suggested and Maxime accepted? I would like to send new version in time for 5.4. Best regards, Jernej > > Best regards > Uwe
Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe napisal(a):
> This patch adds the evaluation variant of the model A of the PineH64.
> The model A has the same size of the pine64 and has a PCIE slot.
>
> The only devicetree difference with current pineH64, is the PHY
> regulator.
I have Model A board which also needs ddc-en-gpios property for HDMI connector
in order for HDMI to work correctly. Otherwise it will just use 1024x768
resolution. Can you confirm that?
Best regards,
Jernej
>
> Signed-off-by: Corentin Labbe
> ---
> arch/arm64/boot/dts/allwinner/Makefile| 1 +
> .../sun50i-h6-pine-h64-modelA-eval.dts| 26 +++
> 2 files changed, 27 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile index f6db0611cb85..9a02166cbf72
> 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> diff --git
> a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts new file
> mode 100644
> index ..d8ff02747efe
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2019 Corentin Labbe
> + */
> +
> +#include "sun50i-h6-pine-h64.dts"
> +
> +/ {
> + model = "Pine H64 model A evaluation board";
> + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> +
> + reg_gmac_3v3: gmac-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-gmac-3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + startup-delay-us = <10>;
> + gpio = < 2 16 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> +};
> +
> + {
> + phy-supply = <_gmac_3v3>;
> +};
Re: [PATCH 0/7] media: cedrus: Improvements/cleanup
Dne ponedeljek, 12. avgust 2019 ob 14:12:21 CEST je Hans Verkuil napisal(a): > On 5/30/19 11:15 PM, Jernej Skrabec wrote: > > Here is first batch of random Cedrus improvements/cleanups. Only patch 2 > > has a change which raises a question about H264 controls. > > > > Changes were tested on H3 SoC using modified ffmpeg and Kodi. > > > > Please take a look. > > This has been sitting in patchwork for quite some time. I've updated the > status of the various patches and most needed extra work. > > It seems that patches 4/7 and 5/7 are OK. Maxime, can you please confirm > that these two are still valid? They apply cleanly on the latest master > at least, but since they are a bit old I prefer to have confirmation that > it's OK to merge them. I'm not sure about patch 4, IIRC Boris Brezillon also wants to improve that area in separate series, but patch 5 should be safe to merge. Anyway, I didn't post new version because I'm waiting on close-to-be-merged H264 and HEVC patch series to be actually merged. Best regards, Jernej > > Regards, > > Hans > > > Best regards, > > Jernej > > > > Jernej Skrabec (7): > > media: cedrus: Disable engine after each slice decoding > > media: cedrus: Fix H264 default reference index count > > media: cedrus: Fix decoding for some H264 videos > > media: cedrus: Remove dst_bufs from context > > media: cedrus: Don't set chroma size for scale & rotation > > media: cedrus: Add infra for extra buffers connected to capture > > > > buffers > > > > media: cedrus: Improve H264 memory efficiency > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 12 +- > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 115 -- > > .../staging/media/sunxi/cedrus/cedrus_hw.c| 4 +- > > .../staging/media/sunxi/cedrus/cedrus_video.c | 25 ++-- > > 4 files changed, 68 insertions(+), 88 deletions(-)
Re: [PATCH v2 3/6] media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers
Dne petek, 04. oktober 2019 ob 11:21:12 CEST je Hans Verkuil napisal(a):
> On 9/29/19 10:00 PM, Jernej Skrabec wrote:
> > These helpers are used by stateless codecs when they support multiple
> > slices per frame and hold capture buffer flag is set. It's expected that
> > all such codecs will use this code.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/media/v4l2-core/v4l2-mem2mem.c | 35 ++
> > include/media/v4l2-mem2mem.h | 4 +++
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
> > b/drivers/media/v4l2-core/v4l2-mem2mem.c index 19937dd3c6f6..2677a07e4c9b
> > 100644
> > --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> > +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> > @@ -1154,6 +1154,41 @@ int v4l2_m2m_ioctl_try_decoder_cmd(struct file
> > *file, void *fh,>
> > }
> > EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_try_decoder_cmd);
> >
> > +int v4l2_m2m_ioctl_stateless_try_decoder_cmd(struct file *file, void *fh,
> > +struct
v4l2_decoder_cmd *dc)
> > +{
> > + if (dc->cmd != V4L2_DEC_CMD_FLUSH)
> > + return -EINVAL;
> > +
> > + dc->flags = 0;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_stateless_try_decoder_cmd);
> > +
> > +int v4l2_m2m_ioctl_stateless_decoder_cmd(struct file *file, void *priv,
> > +struct
v4l2_decoder_cmd *dc)
> > +{
> > + struct v4l2_fh *fh = file->private_data;
> > + struct vb2_v4l2_buffer *out_vb, *cap_vb;
> > + int ret;
> > +
> > + ret = v4l2_m2m_ioctl_stateless_try_decoder_cmd(file, priv, dc);
> > + if (ret < 0)
> > + return ret;
> > +
> > + out_vb = v4l2_m2m_last_src_buf(fh->m2m_ctx);
> > + cap_vb = v4l2_m2m_last_dst_buf(fh->m2m_ctx);
>
> I think this should be v4l2_m2m_next_dst_buf. If multiple capture buffers
> were queued up, then it can only be the first capture buffer that can be
> 'HELD'.
I'm pretty sure v4l2_m2m_last_dst_buf() is correct. We want to affect last job
in the queue, all jobs before are already properly handled by comparing
timestamps.
>
> This might solve the race condition you saw with ffmpeg.
This actually doesn't change anything. ffmpeg currently queues only one job and
then waits until it's executed. In this case it actually doesn't matter if
"last" or "next" variant is used.
Best regards,
Jernej
>
> Regards,
>
> Hans
>
> > +
> > + if (out_vb)
> > + out_vb->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
> > + else if (cap_vb && cap_vb->is_held)
> > + v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_stateless_decoder_cmd);
> > +
> >
> > /*
> >
> > * v4l2_file_operations helpers. It is assumed here same lock is used
> > * for the output and the capture buffer queue.
> >
> > diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
> > index c9fa96c8eed1..8ae2f56c7fa3 100644
> > --- a/include/media/v4l2-mem2mem.h
> > +++ b/include/media/v4l2-mem2mem.h
> > @@ -714,6 +714,10 @@ int v4l2_m2m_ioctl_try_encoder_cmd(struct file *file,
> > void *fh,>
> >struct v4l2_encoder_cmd *ec);
> >
> > int v4l2_m2m_ioctl_try_decoder_cmd(struct file *file, void *fh,
> >
> >struct v4l2_decoder_cmd *dc);
> >
> > +int v4l2_m2m_ioctl_stateless_try_decoder_cmd(struct file *file, void *fh,
> > +struct
v4l2_decoder_cmd *dc);
> > +int v4l2_m2m_ioctl_stateless_decoder_cmd(struct file *file, void *priv,
> > +struct
v4l2_decoder_cmd *dc);
> >
> > int v4l2_m2m_fop_mmap(struct file *file, struct vm_area_struct *vma);
> > __poll_t v4l2_m2m_fop_poll(struct file *file, poll_table *wait);
Re: [PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames
Dne ponedeljek, 07. oktober 2019 ob 12:44:24 CEST je Hans Verkuil napisal(a):
> Hi Jernej,
>
> On 9/29/19 10:00 PM, Jernej Skrabec wrote:
> > This series adds support for decoding multi-slice H264 frames along with
> > support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF.
> >
> > Code was tested by modified ffmpeg, which can be found here:
> > https://github.com/jernejsk/FFmpeg, branch mainline-test
> > It has to be configured with at least following options:
> > --enable-v4l2-request --enable-libudev --enable-libdrm
> >
> > Samples used for testing:
> > http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4
> > http://jernej.libreelec.tv/videos/h264/h264.mp4
> >
> > Command line used for testing:
> > ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt
> > bgra -f fbdev /dev/fb0
> >
> > Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm
> > not sure how. ffmpeg follows exactly which slice is last in frame
> > and sets hold flag accordingly. Improper usage of hold flag would
> > corrupt ffmpeg assumptions and it would probably crash. Any ideas
> > how to test this are welcome!
> >
> > Thanks to Jonas for adjusting ffmpeg.
> >
> > Please let me know what you think.
> >
> > Best regards,
> > Jernej
> >
> > Changes from v1:
> > - added Rb tags
> > - updated V4L2_DEC_CMD_FLUSH documentation
> > - updated first slice detection in Cedrus
> > - hold capture buffer flag is set according to source format
> > - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers
> >
> > Hans Verkuil (2):
> > vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
> > videodev2.h: add V4L2_DEC_CMD_FLUSH
> >
> > Jernej Skrabec (4):
> > media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers
> > media: cedrus: Detect first slice of a frame
> > media: cedrus: h264: Support multiple slices per frame
> > media: cedrus: Add support for holding capture buffer
> >
> > Documentation/media/uapi/v4l/buffer.rst | 13 ++
> > .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++-
> > .../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++
> > .../media/videodev2.h.rst.exceptions | 1 +
> > .../media/common/videobuf2/videobuf2-v4l2.c | 8 +++-
> > drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > .../staging/media/sunxi/cedrus/cedrus_dec.c | 11 +
> > .../staging/media/sunxi/cedrus/cedrus_h264.c | 11 -
> > .../staging/media/sunxi/cedrus/cedrus_hw.c| 8 ++--
> > .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++
> > include/media/v4l2-mem2mem.h | 46 +++
> > include/media/videobuf2-core.h| 3 ++
> > include/media/videobuf2-v4l2.h| 5 ++
> > include/uapi/linux/videodev2.h| 14 --
> > 15 files changed, 175 insertions(+), 11 deletions(-)
>
> I didn't want to make a v3 of this series, instead I hacked this patch that
> will hopefully do all the locking right.
>
> Basically I moved all the 'held' related code into v4l2-mem2mem under
> job_spinlock. This simplifies the driver code as well.
>
> But this is a hack that sits on top of this series. If your ffmpeg tests are
> now successful, then I'll turn this into a proper series with correct
> documentation (a lot of the comments are now wrong with this patch, so just
> ignore that).
Thanks for looking into this! With small fix mentioned below, it works! Note
that both scenarios I tested (flushing during decoding and flushing after
decoding is finished) are focused on capture queue. In order to trigger output
queue flush, ffmpeg would need to queue multiple jobs and call flush before
they
are all processed. This is not something I can do at this time. Maybe Jonas
can help with modifying ffmpeg appropriately. However, code for case seems
correct to me.
>
> Regards,
>
> Hans
>
> diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
> b/drivers/media/v4l2-core/v4l2-mem2mem.c index 2677a07e4c9b..f81a8f2465ab
> 100644
> --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> @@ -412,25 +412,24 @@ static void v4l2_m2m_cancel_job(struct v4l2_m2m_ctx
> *m2m_ctx) }
> }
>
> -void v4l2_m2m_job_finish(struct v4l2_m2m_dev *m2m_dev,
> - struct v4l2_m2m_ctx *m2m_ctx)
> +static bool _v4l2_m2m_job_finish(struct v4l2_m2m_dev *m2m_dev,
> + struct v4l2_m2m_ctx *m2m_ctx)
> {
> - unsigned long flags;
> -
> - spin_lock_irqsave(_dev->job_spinlock, flags);
> if (!m2m_dev->curr_ctx || m2m_dev->curr_ctx != m2m_ctx) {
> - spin_unlock_irqrestore(_dev->job_spinlock, flags);
> dprintk("Called by an instance not currently
running\n");
> - return;
> + return false;
> }
>
> list_del(_dev->curr_ctx->queue);
> m2m_dev->curr_ctx->job_flags &= ~(TRANS_QUEUED | TRANS_RUNNING);
Re: [PATCH v8 0/3] HEVC/H.265 stateless support for V4L2 and Cedrus
Dne petek, 27. september 2019 ob 16:34:08 CEST je Paul Kocialkowski napisal(a): > HEVC/H.265 stateless support for V4L2 and Cedrus > > This is early support for HEVC/H.265 stateless decoding in V4L2, > including both definitions and driver support for the Cedrus VPU > driver, which concerns Allwinner devices. > > A specific pixel format is introduced for the HEVC slice format and > controls are provided to pass the bitstream metadata to the decoder. > Some bitstream extensions are intentionally not supported at this point. > > Since this is the first proposal for stateless HEVC/H.265 support in > V4L2, reviews and comments about the controls definitions are > particularly welcome. > > On the Cedrus side, the H.265 implementation covers frame pictures > with both uni-directional and bi-direction prediction modes (P/B > slices). Field pictures (interleaved), scaling lists and 10-bit output > are not supported at this point. Whole series is: Reviewed-by: Jernej Skrabec Hopefully this can be merged soon. Best regards, Jernej > > Changes since v7: > * Rebased on latest media tree; > * Fixed holes in structures for cacheline alignment; > * Added decode mode and start code controls > (only per-slice and no start code is supported at this point). > > Changes since v6: > * Rebased on latest media tree from Hans; > * Reordered some fields to avoid holes and multi-padding; > * Updated the documentation. > > Changes since v5: > * Rebased atop latest next media tree; > * Moved to flags instead of u8 fields; > * Added padding to ensure 64-bit alignment > (tested with GDB on 32 and 64-bit architectures); > * Reworked cedrus H.265 driver support a bit for flags; > * Split off codec-specific control validation and init; > * Added HEVC controls fields cleanup at std_validate to allow reliable > control comparison with memcmp; > * Fixed various misc reported mistakes. > > Changes since v4: > * Rebased atop latest H.254 series. > > Changes since v3: > * Updated commit messages; > * Updated CID base to avoid conflicts; > * Used cpu_to_le32 for packed le32 data; > * Fixed misc minor issues in the drive code; > * Made it clear in the docs that the API will evolve; > * Made the pixfmt private and split commits about it. > > Changes since v2: > * Moved headers to non-public API; > * Added H265 capability for A64 and H5; > * Moved docs to ext-ctrls-codec.rst; > * Mentionned sections of the spec in the docs; > * Added padding to control structures for 32-bit alignment; > * Made write function use void/size in bytes; > * Reduced the number of arguments to helpers when possible; > * Removed PHYS_OFFSET since we already set PFN_OFFSET; > * Added comments where suggested; > * Moved to timestamp for references instead of index; > * Fixed some style issues reported by checkpatch. > > Changes since v1: > * Added a H.265 capability to whitelist relevant platforms; > * Switched over to tags instead of buffer indices in the DPB > * Declared variable in their reduced scope as suggested; > * Added the H.265/HEVC spec to the biblio; > * Used in-doc references to the spec and the required APIs; > * Removed debugging leftovers. > > Cheers! > > Paul Kocialkowski (3): > media: v4l: Add definitions for HEVC stateless decoding > media: pixfmt: Document the HEVC slice pixel format > media: cedrus: Add HEVC/H.265 decoding support > > Documentation/media/uapi/v4l/biblio.rst | 9 + > .../media/uapi/v4l/ext-ctrls-codec.rst| 553 +++- > .../media/uapi/v4l/pixfmt-compressed.rst | 23 + > .../media/uapi/v4l/vidioc-queryctrl.rst | 18 + > .../media/videodev2.h.rst.exceptions | 3 + > drivers/media/v4l2-core/v4l2-ctrls.c | 108 ++- > drivers/media/v4l2-core/v4l2-ioctl.c | 1 + > drivers/staging/media/sunxi/cedrus/Makefile | 2 +- > drivers/staging/media/sunxi/cedrus/cedrus.c | 52 +- > drivers/staging/media/sunxi/cedrus/cedrus.h | 18 + > .../staging/media/sunxi/cedrus/cedrus_dec.c | 9 + > .../staging/media/sunxi/cedrus/cedrus_h265.c | 616 ++ > .../staging/media/sunxi/cedrus/cedrus_hw.c| 4 + > .../staging/media/sunxi/cedrus/cedrus_regs.h | 271 > .../staging/media/sunxi/cedrus/cedrus_video.c | 10 + > include/media/hevc-ctrls.h| 212 ++ > include/media/v4l2-ctrls.h| 7 + > 17 files changed, 1907 insertions(+), 9 deletions(-) > create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h265.c > create mode 100644 include/media/hevc-ctrls.h
Re: [PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames
Dne sreda, 09. oktober 2019 ob 12:18:45 CEST je Hans Verkuil napisal(a): > On 10/7/19 9:01 PM, Jernej Škrabec wrote: > > Dne ponedeljek, 07. oktober 2019 ob 12:44:24 CEST je Hans Verkuil napisal(a): > >> Hi Jernej, > >> > >> On 9/29/19 10:00 PM, Jernej Skrabec wrote: > >>> This series adds support for decoding multi-slice H264 frames along with > >>> support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF. > >>> > >>> Code was tested by modified ffmpeg, which can be found here: > >>> https://github.com/jernejsk/FFmpeg, branch mainline-test > >>> It has to be configured with at least following options: > >>> --enable-v4l2-request --enable-libudev --enable-libdrm > >>> > >>> Samples used for testing: > >>> http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4 > >>> http://jernej.libreelec.tv/videos/h264/h264.mp4 > >>> > >>> Command line used for testing: > >>> ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt > >>> bgra -f fbdev /dev/fb0 > >>> > >>> Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm > >>> not sure how. ffmpeg follows exactly which slice is last in frame > >>> and sets hold flag accordingly. Improper usage of hold flag would > >>> corrupt ffmpeg assumptions and it would probably crash. Any ideas > >>> how to test this are welcome! > >>> > >>> Thanks to Jonas for adjusting ffmpeg. > >>> > >>> Please let me know what you think. > >>> > >>> Best regards, > >>> Jernej > >>> > >>> Changes from v1: > >>> - added Rb tags > >>> - updated V4L2_DEC_CMD_FLUSH documentation > >>> - updated first slice detection in Cedrus > >>> - hold capture buffer flag is set according to source format > >>> - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers > >>> > >>> Hans Verkuil (2): > >>> vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF > >>> videodev2.h: add V4L2_DEC_CMD_FLUSH > >>> > >>> Jernej Skrabec (4): > >>> media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers > >>> media: cedrus: Detect first slice of a frame > >>> media: cedrus: h264: Support multiple slices per frame > >>> media: cedrus: Add support for holding capture buffer > >>> > >>> Documentation/media/uapi/v4l/buffer.rst | 13 ++ > >>> .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++- > >>> .../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++ > >>> .../media/videodev2.h.rst.exceptions | 1 + > >>> .../media/common/videobuf2/videobuf2-v4l2.c | 8 +++- > >>> drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++ > >>> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > >>> .../staging/media/sunxi/cedrus/cedrus_dec.c | 11 + > >>> .../staging/media/sunxi/cedrus/cedrus_h264.c | 11 - > >>> .../staging/media/sunxi/cedrus/cedrus_hw.c| 8 ++-- > >>> .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++ > >>> include/media/v4l2-mem2mem.h | 46 +++ > >>> include/media/videobuf2-core.h| 3 ++ > >>> include/media/videobuf2-v4l2.h| 5 ++ > >>> include/uapi/linux/videodev2.h| 14 -- > >>> 15 files changed, 175 insertions(+), 11 deletions(-) > >> > >> I didn't want to make a v3 of this series, instead I hacked this patch > >> that > >> will hopefully do all the locking right. > >> > >> Basically I moved all the 'held' related code into v4l2-mem2mem under > >> job_spinlock. This simplifies the driver code as well. > >> > >> But this is a hack that sits on top of this series. If your ffmpeg tests > >> are now successful, then I'll turn this into a proper series with > >> correct documentation (a lot of the comments are now wrong with this > >> patch, so just ignore that). > > > > Thanks for looking into this! With small fix mentioned below, it works! > > Note that both scenarios I tested (flushing during decoding and flushing > > after decoding is finished) are focused on capture queue. In order to > > trigger output queue flush, ffmpeg would need to queue multiple jobs and > > call flush before they are al
Re: [PATCH v3 5/6] media: sun4i: Add H3 deinterlace driver
Dne četrtek, 17. oktober 2019 ob 09:51:28 CEST je Hans Verkuil napisal(a): > On 10/16/19 9:28 PM, Jernej Skrabec wrote: > > Allwinner H3 SoC contains deinterlace unit, which has several modes of > > operation - bypass, weave, bob and mixed (advanced) mode. I don't know > > how mixed mode works, but according to Allwinner it gives best results, > > so they use it exclusively. Currently this mode is also hardcoded here. > > > > For each interleaved frame queued, this driver produces 2 deinterlaced > > frames. Deinterlaced frames are based on 2 consequtive output buffers, > > except for the first 2, where same output buffer is given to peripheral > > as current and previous. > > > > There is no documentation for this core, so register layout and fixed > > values were taken from BSP driver. > > > > I'm not sure if maximum size of the image unit is capable to process is > > governed by size of "flag" buffers, frequency or it really is some HW > > limitation. Currently driver can process full HD image in ~15ms (7.5ms > > for each capture buffer), which allows to process 1920x1080@60i video > > smoothly in real time. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > MAINTAINERS |7 + > > drivers/media/platform/sunxi/Kconfig |1 + > > drivers/media/platform/sunxi/Makefile |1 + > > drivers/media/platform/sunxi/sun8i-di/Kconfig | 11 + > > .../media/platform/sunxi/sun8i-di/Makefile|2 + > > .../media/platform/sunxi/sun8i-di/sun8i-di.c | 1020 + > > .../media/platform/sunxi/sun8i-di/sun8i-di.h | 237 > > 7 files changed, 1279 insertions(+) > > create mode 100644 drivers/media/platform/sunxi/sun8i-di/Kconfig > > create mode 100644 drivers/media/platform/sunxi/sun8i-di/Makefile > > create mode 100644 drivers/media/platform/sunxi/sun8i-di/sun8i-di.c > > create mode 100644 drivers/media/platform/sunxi/sun8i-di/sun8i-di.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index c7b48525822a..c375455125fb 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4646,6 +4646,13 @@ M: "Maciej W. Rozycki" > > > > S: Maintained > > F: drivers/net/fddi/defxx.* > > > > +DEINTERLACE DRIVERS FOR ALLWINNER H3 > > +M: Jernej Skrabec > > +L: linux-me...@vger.kernel.org > > +T: git git://linuxtv.org/media_tree.git > > +S: Maintained > > +F: drivers/media/platform/sunxi/sun8i-di/ > > + > > > > DELL SMBIOS DRIVER > > M: Pali Rohár > > M: Mario Limonciello > > > > diff --git a/drivers/media/platform/sunxi/Kconfig > > b/drivers/media/platform/sunxi/Kconfig index 71808e93ac2e..d7a5621bf327 > > 100644 > > --- a/drivers/media/platform/sunxi/Kconfig > > +++ b/drivers/media/platform/sunxi/Kconfig > > @@ -1,2 +1,3 @@ > > > > source "drivers/media/platform/sunxi/sun4i-csi/Kconfig" > > source "drivers/media/platform/sunxi/sun6i-csi/Kconfig" > > > > +source "drivers/media/platform/sunxi/sun8i-di/Kconfig" > > This is a m2m driver, so this belongs in drivers/media/platform/Kconfig in > the Memory-to-memory section. > > > diff --git a/drivers/media/platform/sunxi/Makefile > > b/drivers/media/platform/sunxi/Makefile index a05127529006..3878cb4efdc2 > > 100644 > > --- a/drivers/media/platform/sunxi/Makefile > > +++ b/drivers/media/platform/sunxi/Makefile > > @@ -1,2 +1,3 @@ > > > > obj-y += sun4i-csi/ > > obj-y += sun6i-csi/ > > > > +obj-y += sun8i-di/ > > diff --git a/drivers/media/platform/sunxi/sun8i-di/Kconfig > > b/drivers/media/platform/sunxi/sun8i-di/Kconfig new file mode 100644 > > index ..dbd77a61e3b3 > > --- /dev/null > > +++ b/drivers/media/platform/sunxi/sun8i-di/Kconfig > > @@ -0,0 +1,11 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +config VIDEO_SUN8I_DEINTERLACE > > + tristate "Allwinner Deinterlace driver" > > + depends on VIDEO_DEV && VIDEO_V4L2 > > + depends on HAS_DMA > > + depends on OF > > + depends on PM > > + select VIDEOBUF2_DMA_CONTIG > > + select V4L2_MEM2MEM_DEV > > + help > > + Support for the Allwinner Deinterlace unit found on some SoCs. > > Shouldn't this depend on ARCH_SUNXI || COMPILE_TEST? > And also on COMMON_CLK? Yes to both. Also I don't see a reason why it would depend on HAS_DMA, so I will remove that. Best regards, Jernej > > Regards, > > Hans
Re: [PATCH v3 5/6] media: sun4i: Add H3 deinterlace driver
Dne četrtek, 17. oktober 2019 ob 11:28:00 CEST je Maxime Ripard napisal(a):
> Hi,
>
> I have a small comment that can definitely be addressed in a subsequent
> patch
> On Wed, Oct 16, 2019 at 09:28:06PM +0200, Jernej Skrabec wrote:
> > + dev->bus_clk = devm_clk_get(dev->dev, "bus");
> > + if (IS_ERR(dev->bus_clk)) {
> > + dev_err(dev->dev, "Failed to get bus clock\n");
> > +
> > + return PTR_ERR(dev->bus_clk);
> > + }
> > +
> > + dev->mod_clk = devm_clk_get(dev->dev, "mod");
> > + if (IS_ERR(dev->mod_clk)) {
> > + dev_err(dev->dev, "Failed to get mod clock\n");
> > +
> > + return PTR_ERR(dev->mod_clk);
> > + }
> > +
> > + dev->ram_clk = devm_clk_get(dev->dev, "ram");
> > + if (IS_ERR(dev->ram_clk)) {
> > + dev_err(dev->dev, "Failed to get ram clock\n");
> > +
> > + return PTR_ERR(dev->ram_clk);
> > + }
> > +
> > + dev->rstc = devm_reset_control_get(dev->dev, NULL);
> > + if (IS_ERR(dev->rstc)) {
> > + dev_err(dev->dev, "Failed to get reset control\n");
> > +
> > + return PTR_ERR(dev->rstc);
> > + }
> > +
> > + clk_set_rate_exclusive(dev->mod_clk, 3);
>
> clk_set_rate_exclusive puts a pretty big constraint on the clock tree,
> and we shouldn't really enforce it if the device is unused.
That is true in general, but as I said before, that is not really an issue for
H3. Deinterlace clock default parent is peripheral clock, which is fixed to 600
MHz and doesn't change.
>
> I guess we should move it to the runtime_pm resume hook (with the
> put_exclusive call in suspend).
Ok, I'll move it in case that this deinterlace core is used on other SoCs with
non-fixed parent clock.
>
> Otherwise, that patch is
> Acked-by: Maxime Ripard
Thanks!
Best regards,
Jernej
Re: [linux-sunxi] Re: Audio sound card name [was [PATCH 4/7] arm64: dts: allwinner: a64: Add HDMI audio]
Dne sreda, 29. april 2020 ob 12:43:06 CEST je Robin Murphy napisal(a):
> On 2020-04-29 9:17 am, Maxime Ripard wrote:
> > On Wed, Apr 29, 2020 at 02:24:00PM +0800, Chen-Yu Tsai wrote:
> >> On Wed, Apr 29, 2020 at 1:11 AM Robin Murphy
wrote:
> >>> On 2020-04-28 5:49 pm, Clément Péron wrote:
> Hi Mark, Rob,
>
> On Tue, 28 Apr 2020 at 18:04, Maxime Ripard wrote:
> > On Tue, Apr 28, 2020 at 10:54:00AM +0200, Clément Péron wrote:
> >> Hi Maxime,
> >>
> >> On Tue, 28 Apr 2020 at 10:00, Maxime Ripard
wrote:
> >>> On Sun, Apr 26, 2020 at 02:04:39PM +0200, Clément Péron wrote:
> From: Marcus Cooper
>
> Add a simple-soundcard to link audio between HDMI and I2S.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Marcus Cooper
> Signed-off-by: Clément Péron
> ---
>
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21
> +++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> e56e1e3d4b73..08ab6b5e72a5 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -102,6 +102,25 @@
>
> status = "disabled";
>
> };
>
> + hdmi_sound: hdmi-sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "allwinner,hdmi";
> >>>
> >>> I'm not sure what the usual card name should be like though. I would
> >>> assume that this should be something specific enough so that you're
> >>> able to differentiate between boards / SoC so that the userspace
> >>> can choose a different configuration based on it?
> >>
> >> I really don't know what we should use here,
> >> I just have a look at other SoC:
> >> rk3328: "HDMI"
> >> rk3399: "hdmi-sound"
> >> r8a774c0-cat874: "CAT874 HDMI sound"
> >>
> >> But maybe it's time to introduce proper name:
> >> What about :
> >> pat
> >> sun50i-h6-hdmi
> >
> > It's pretty much what we've been using for the other sound cards we
> > have, so it makes sense to me.
>
> I have a question regarding the simple-audio-card,name.
> In this patch, I would like to introduce a simple-audio-card for the
> Allwinner A64 HDMI.
>
> What should be the preferred name for this sound card?
> "sun50i-a64-hdmi" ? "allwinner, sun50i-a64-hdmi" ?
> >>>
> >>> I can at least speak for RK3328, and the reasoning there was that as the
> >>> user looking at what `aplay -l` says, I don't give a hoot about what the
> >>> SoC may be called, I see two cards and I want to know, with the least
> >>> amount of uncertainty, which one will make the sound come out of the
> >>> port that's labelled "HDMI" on the box ;)
> >>
> >> I agree. The user really doesn't care what SoC the system uses. The only
> >> real requirement is to be able to tell which output the card is related
> >> to, i.e. is it onboard or an external DAC, is it analog or HDMI, etc..
> >
> > Yeah, but it's exactly the point.
> >
> > If we also end up with "HDMI" as our card name, then the userspace has no
> > way to tell anymore if it's running from an rk3328 or an allwinner SoC,
> > or something else entirely. And therefore it cannot really configure
> > anything to work out of the box anymore.
>
> OK, you're a userspace audio application - enlighten me as to what exact
> chip you're running on here, and why you need to know:
>
> card 0: HDMI [HDA ATI HDMI]
>
> or how about here?
>
> card 0: Intel [HDA Intel]
>
>
> Furthermore, your argument works both ways - if the equivalent (or in
> common cases like DesignWare IP blocks, exact same) thing across 3
> different SoCs has 3 different names, then it's that much harder for
> userspace that wants to present a consistent behaviour. I don't know
> exactly why LibreELEC have downstream patches that standardise all the
> Rockchip ones to "HDMI", but I can't help noting that they do.
>
> With simple-audio-card we're talking about trivial interfaces that often
> don't expose any controls at all, so there's unlikely to be much
> 'configuration' for userspace to do beyond choosing which card to output to.
This combination (DesignWare HDMI controller + I2S) is same as on Rockchip.
Only difference is slightly different version of HDMI controller and different
I2S core. Not sure what kind of configuration do you have in mind, but all
these controllers support 2-8 channels, different sample sizes, even
passthrough mode can be set (but it's not implemented yet). I would say that
this audio output supports
Re: [PATCH v2 1/3] media: cedrus: Fix decoding for some H264 videos
Hi!
Sorry for late reponse, technical issues...
Dne sreda, 02. oktober 2019 ob 23:54:47 CEST je Paul Kocialkowski napisal(a):
> Hi,
>
> On Wed 02 Oct 19, 21:35, Jernej Skrabec wrote:
> > It seems that for some H264 videos at least one bitstream parsing
> > trigger must be called in order to be decoded correctly. There is no
> > explanation why this helps, but it was observed that two sample videos
> > with this fix are now decoded correctly and there is no regression with
> > others.
>
> I understand there might be some magic going on under the hood here, but I
> would be interested in trying to understand what's really going on.
Me too.
>
> For instance, comparing register dumps of the whole H264 block before/after
> calling the hardware parser could help, and comparing that to using the
> previous code (without hardware parsing).
Please understand that I was working on this on and off for almost half a year
and checked many times all register values. At one point I tried libvdpau-
sunxi which has no problem with sample video. Still, all relevant register
values were the same. In a desperate attempt, I tried with HW header parsing
which magically solved the issue. After that, I reused values provided in
controls and then finally I made minimal solution as suggested in this patch.
>
> I could try and have a look if you have an available sample for testing the
> erroneous case!
Of course: http://jernej.libreelec.tv/videos/h264/test.mkv
>
> Another minor thing: do you have some idea of whether the udelay call adds
> significant delay in the process?
I didn't notice any issue with it. Do you have any better idea? I just didn't
want to make empty loop and udelay is the shortest delay that is provided by
the kernel API.
Best regards,
Jernej
>
> Cheers and thanks for the patch!
>
> Paul
>
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > .../staging/media/sunxi/cedrus/cedrus_h264.c | 30 +--
> > .../staging/media/sunxi/cedrus/cedrus_regs.h | 3 ++
> > 2 files changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > d6a782703c9b..bd848146eada 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > @@ -6,6 +6,7 @@
> >
> > * Copyright (c) 2018 Bootlin
> > */
> >
> > +#include
> >
> > #include
> >
> > #include
> >
> > @@ -289,6 +290,28 @@ static void cedrus_write_pred_weight_table(struct
> > cedrus_ctx *ctx,>
> > }
> >
> > }
> >
> > +/*
> > + * It turns out that using VE_H264_VLD_OFFSET to skip bits is not
> > reliable. In + * rare cases frame is not decoded correctly. However,
> > setting offset to 0 and + * skipping appropriate amount of bits with
> > flush bits trigger always works. + */
> > +static void cedrus_skip_bits(struct cedrus_dev *dev, int num)
> > +{
> > + int count = 0;
> > +
> > + while (count < num) {
> > + int tmp = min(num - count, 32);
> >
> > +
> > + cedrus_write(dev, VE_H264_TRIGGER_TYPE,
> > +VE_H264_TRIGGER_TYPE_FLUSH_BITS |
> > +VE_H264_TRIGGER_TYPE_N_BITS(tmp));
> > + while (cedrus_read(dev, VE_H264_STATUS) &
VE_H264_STATUS_VLD_BUSY)
> > + udelay(1);
> > +
> > + count += tmp;
> > + }
> > +}
> > +
> >
> > static void cedrus_set_params(struct cedrus_ctx *ctx,
> >
> > struct cedrus_run *run)
> >
> > {
> >
> > @@ -299,12 +322,11 @@ static void cedrus_set_params(struct cedrus_ctx
> > *ctx,
> >
> > struct vb2_buffer *src_buf = >src->vb2_buf;
> > struct cedrus_dev *dev = ctx->dev;
> > dma_addr_t src_buf_addr;
> >
> > - u32 offset = slice->header_bit_size;
> > - u32 len = (slice->size * 8) - offset;
> > + u32 len = slice->size * 8;
> >
> > u32 reg;
> >
> > cedrus_write(dev, VE_H264_VLD_LEN, len);
> >
> > - cedrus_write(dev, VE_H264_VLD_OFFSET, offset);
> > + cedrus_write(dev, VE_H264_VLD_OFFSET, 0);
> >
> > src_buf_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
> > cedrus_write(dev, VE_H264_VLD_END,
> >
> > @@ -323,6 +345,8 @@ static void cedrus_set_params(struct cedrus_ctx *ctx,
> >
> > cedrus_write(dev, VE_H264_TRIGGER_TYPE,
> >
> > VE_H264_TRIGGER_TYPE_INIT_SWDEC);
> >
> > + cedrus_skip_bits(dev, slice->header_bit_size);
> > +
> >
> > if (((pps->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) &&
> >
> > (slice->slice_type == V4L2_H264_SLICE_TYPE_P ||
> >
> > slice->slice_type == V4L2_H264_SLICE_TYPE_SP)) ||
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h index
> > 3329f9aaf975..b52926a54025 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h
> > +++
Re: [PATCH 7/8] media: cedrus: Add support for holding capture buffer
Dne četrtek, 29. avgust 2019 ob 13:23:29 CEST je Hans Verkuil napisal(a):
> On 8/22/19 9:44 PM, Jernej Skrabec wrote:
> > When frame contains multiple slices and driver works in slice mode, it's
> > more efficient to hold capture buffer in queue until all slices of a
> > same frame are decoded.
> >
> > Add support for that to Cedrus driver by exposing and implementing
> > V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +
> > drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 8 +---
> > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 1 +
> > 3 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > d7b54accfe83..68462b99750e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > +
> > + if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
> > + run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > + }
> > + run.dst->is_held = run.src->flags &
V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
> > +
> >
> > run.first_slice =
> >
> > run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
> >
> > @@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
> >
> > run.mpeg2.quantization = cedrus_find_control_data(ctx,
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
> >
> > + run.dst->is_held = false;
> >
> > break;
> >
> > case V4L2_PIX_FMT_H264_SLICE:
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c index
> > a942cd9bed57..99fedec80224 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > @@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
> >
> > src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> >
> > - dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > if (!src_buf || !dst_buf) {
> >
> > v4l2_err(>v4l2_dev,
> >
> > @@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > state = VB2_BUF_STATE_DONE;
> >
> > v4l2_m2m_buf_done(src_buf, state);
> >
> > - v4l2_m2m_buf_done(dst_buf, state);
> > -
> > + if (!dst_buf->is_held) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(dst_buf, state);
> > + }
> >
> > v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
> >
> > return IRQ_HANDLED;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c index
> > 3efd247b..5153b2bba21e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -515,6 +515,7 @@ int cedrus_queue_init(void *priv, struct vb2_queue
> > *src_vq,>
> > src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> > src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
> > src_vq->drv_priv = ctx;
> >
> > + src_vq->subsystem_flags =
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
>
> This isn't quite right: this flag should only be set for formats that
> support slicing. So cedrus_s_fmt_vid_out() should set this for H264, but
> clear it for MPEG2.
>
> Looking at the cedrus code it seems that it does not set an initial default
> output format after opening the video device. This seems wrong to me. If it
> did set a default output format, then src_vq->subsystem_flags should set
> this flag corresponding to the default output format.
Ok, I'll base v2 series on your "cedrus: v4l2-compliance fixes", because it has
some useful changes for this case.
Best regards,
Jernej
>
> > src_vq->buf_struct_size = sizeof(struct cedrus_buffer);
> > src_vq->min_buffers_needed = 1;
> > src_vq->ops = _qops;
>
> Regards,
>
> Hans
Re: [PATCH v2] media: cedrus: Add support for VP8 decoding
Hi Ezequiel!
Dne sobota, 25. julij 2020 ob 15:08:37 CEST je Ezequiel Garcia napisal(a):
> Hi Jernej,
>
> As you know, I'm not familiar with this hardware,
> but I've tried to take a detailed look anyway.
>
Thanks, any review is welcome.
> The driver looks mostly good to me, I just have
> some minor comments.
>
> More importantly, seems the current uAPI
> control is supporting this platform nicely,
> which gives us some confidence to mark it
> as stable.
Yes, it looks pretty good in that regard.
>
> Comments below.
>
> On Wed, 22 Jul 2020 at 17:35, Jernej Skrabec
wrote:
> > VP8 in Cedrus shares same engine as H264.
> >
> > Note that it seems necessary to call bitstream parsing functions,
> > to parse frame header, otherwise decoded image is garbage. This is
> > contrary to what is driver supposed to do. However, values are not
> > really used, so this might be acceptable. It's possible that bitstream
> > parsing functions set some internal VPU state, which is later necessary
> > for proper decoding. Biggest suspect is "VP8 probs update" trigger.
>
> I suggest that you also put this explanation here, as a comment
> in the cedrus_vp8.c
Ok.
>
> > Signed-off-by: Jernej Skrabec
> > ---
> > Changes in v2:
> > - rebased on top of current linux-media master branch
> >
> > drivers/staging/media/sunxi/cedrus/Makefile | 3 +-
> > drivers/staging/media/sunxi/cedrus/cedrus.c | 8 +
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 15 +
> > .../staging/media/sunxi/cedrus/cedrus_dec.c | 5 +
> > .../staging/media/sunxi/cedrus/cedrus_hw.c| 1 +
> > .../staging/media/sunxi/cedrus/cedrus_regs.h | 80 ++
> > .../staging/media/sunxi/cedrus/cedrus_video.c | 9 +
> > .../staging/media/sunxi/cedrus/cedrus_vp8.c | 699 ++
> > 8 files changed, 819 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_vp8.c
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/Makefile
> > b/drivers/staging/media/sunxi/cedrus/Makefile index
> > 1bce49d3e7e2..a647b3690bf8 100644
> > --- a/drivers/staging/media/sunxi/cedrus/Makefile
> > +++ b/drivers/staging/media/sunxi/cedrus/Makefile
> > @@ -2,4 +2,5 @@
> >
> > obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
> >
> > sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o \
> >
> > -cedrus_mpeg2.o cedrus_h264.o cedrus_h265.o
> > +cedrus_mpeg2.o cedrus_h264.o cedrus_h265.o \
> > +cedrus_vp8.o
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus.c index
> > bc27f9430eeb..b2f5f03ad4a3 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > @@ -135,6 +135,13 @@ static const struct cedrus_control cedrus_controls[]
> > = {>
> > .codec = CEDRUS_CODEC_H265,
> > .required = false,
> >
> > },
> >
> > + {
> > + .cfg = {
> > + .id =
> > V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER, + },
> > + .codec = CEDRUS_CODEC_VP8,
> > + .required = true,
> > + },
> >
> > };
> >
> > #define CEDRUS_CONTROLS_COUNT ARRAY_SIZE(cedrus_controls)
> >
> > @@ -381,6 +388,7 @@ static int cedrus_probe(struct platform_device *pdev)
> >
> > dev->dec_ops[CEDRUS_CODEC_MPEG2] = _dec_ops_mpeg2;
> > dev->dec_ops[CEDRUS_CODEC_H264] = _dec_ops_h264;
> > dev->dec_ops[CEDRUS_CODEC_H265] = _dec_ops_h265;
> >
> > + dev->dec_ops[CEDRUS_CODEC_VP8] = _dec_ops_vp8;
> >
> > mutex_init(>dev_mutex);
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 9676ab8a..9f4605afa0f4 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -35,6 +35,7 @@ enum cedrus_codec {
> >
> > CEDRUS_CODEC_MPEG2,
> > CEDRUS_CODEC_H264,
> > CEDRUS_CODEC_H265,
> >
> > + CEDRUS_CODEC_VP8,
> >
> > CEDRUS_CODEC_LAST,
> >
> > };
> >
> > @@ -75,6 +76,10 @@ struct cedrus_h265_run {
> >
> > const struct v4l2_ctrl_hevc_slice_params*slice_params;
> >
> > };
> >
> > +struct cedrus_vp8_run {
> > + const struct v4l2_ctrl_vp8_frame_header *slice_params;
>
> I don't think VP8 has any concept of slice, as H264 does.
> I think it's misleading to call this parameter as slice_params.
>
frame_info perhaps? Or frame_params?
> > +};
> > +
> >
> > struct cedrus_run {
> >
> > struct vb2_v4l2_buffer *src;
> > struct vb2_v4l2_buffer *dst;
> >
> > @@ -83,6 +88,7 @@ struct cedrus_run {
> >
> > struct cedrus_h264_run h264;
> > struct cedrus_mpeg2_run mpeg2;
> > struct cedrus_h265_run h265;
> >
> > +
Re: [PATCH 03/10] media: uapi: h264: Split prediction weight parameters
Hi!
Dne sreda, 15. julij 2020 ob 22:22:26 CEST je Ezequiel Garcia napisal(a):
> The prediction weight parameters are only required under
> certain conditions, which depend on slice header parameters.
>
> The slice header syntax specifies that the prediction
> weight table is present if:
>
> ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \
> (weighted_bipred_idc == 1 && slice_type == B))
>
> Given its size, it makes sense to move this table to its control,
> so applications can avoid passing it if the slice doesn't specify it.
>
> Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes.
> With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight
> is 772 bytes.
>
> Signed-off-by: Ezequiel Garcia
> ---
> .../userspace-api/media/v4l/ext-ctrls-codec.rst| 14 +-
> drivers/media/v4l2-core/v4l2-ctrls.c | 6 ++
> drivers/staging/media/sunxi/cedrus/cedrus.h| 1 +
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c| 2 ++
> drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++
> include/media/h264-ctrls.h | 5 +++--
> 6 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index
> 16bfc98ab2f6..d1695ae96700 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -1879,18 +1879,22 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> - 0x0008
>-
>
> -``Prediction Weight Table``
> -
> -The bitstream parameters are defined according to :ref:`h264`,
> +``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHT (struct)``
> +Prediction weight table defined according to :ref:`h264`,
> section 7.4.3.2 "Prediction Weight Table Semantics". For further
> documentation, refer to the above specification, unless there is
> an explicit comment stating otherwise.
>
> -.. c:type:: v4l2_h264_pred_weight_table
> +.. note::
> +
> + This compound control is not yet part of the public kernel API and
> + it is expected to change.
> +
> +.. c:type:: v4l2_ctrl_h264_pred_weight
>
> .. cssclass:: longtable
>
> -.. flat-table:: struct v4l2_h264_pred_weight_table
> +.. flat-table:: struct v4l2_ctrl_h264_pred_weight
>
> :header-rows: 0
> :stub-columns: 0
> :widths: 1 1 2
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c index 3f3fbcd60cc6..3a8a23e34c70
> 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1412,6 +1412,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type, case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS:
> *type = V4L2_CTRL_TYPE_H264_DECODE_PARAMS;
> break;
> + case V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHT:
> + *type = V4L2_CTRL_TYPE_H264_PRED_WEIGHT;
> + break;
> case V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER:
> *type = V4L2_CTRL_TYPE_VP8_FRAME_HEADER;
> break;
> @@ -2553,6 +2556,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl, case V4L2_CTRL_TYPE_H264_DECODE_PARAMS:
> elem_size = sizeof(struct
v4l2_ctrl_h264_decode_params);
> break;
> + case V4L2_CTRL_TYPE_H264_PRED_WEIGHT:
> + elem_size = sizeof(struct v4l2_ctrl_h264_pred_weight);
> + break;
> case V4L2_CTRL_TYPE_VP8_FRAME_HEADER:
> elem_size = sizeof(struct v4l2_ctrl_vp8_frame_header);
> break;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> 9676ab8a..80a0ecffa384 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -62,6 +62,7 @@ struct cedrus_h264_run {
> const struct v4l2_ctrl_h264_scaling_matrix
*scaling_matrix;
> const struct v4l2_ctrl_h264_slice_params*slice_params;
> const struct v4l2_ctrl_h264_sps *sps;
> + const struct v4l2_ctrl_h264_pred_weight
*pred_weight;
> };
>
> struct cedrus_mpeg2_run {
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> 58c48e4fdfe9..047f773f64f9 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -57,6 +57,8 @@ void cedrus_device_run(void *priv)
> V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS);
> run.h264.sps = cedrus_find_control_data(ctx,
> V4L2_CID_MPEG_VIDEO_H264_SPS);
> + run.h264.pred_weight = cedrus_find_control_data(ctx,
> + V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHT);
> break;
>
>
Re: [PATCH 06/10] media: uapi: h264: Cleanup DPB entry interface
Hi! Dne sreda, 15. julij 2020 ob 22:22:29 CEST je Ezequiel Garcia napisal(a): > As discussed recently, the current interface for the > Decoded Picture Buffer is not enough to properly > support field coding. > > This commit introduces enough semantics to support > frame and field coding, and to signal how DPB entries > are "used for reference". > > Signed-off-by: Ezequiel Garcia > --- > .../media/v4l/ext-ctrls-codec.rst | 46 --- > drivers/media/v4l2-core/v4l2-h264.c | 4 +- > drivers/staging/media/rkvdec/rkvdec-h264.c| 8 ++-- > include/media/h264-ctrls.h| 8 +++- > 4 files changed, 42 insertions(+), 24 deletions(-) > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > dd8e5a2e8986..46d4c8c6ad47 100644 > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > @@ -2058,10 +2058,35 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - > * - __s32 >- ``bottom_field_order_cnt`` >- > +* - enum :c:type:`v4l2_h264_dpb_reference` > + - ``reference`` > + - Specifies how the DPB entry is referenced. > * - __u32 >- ``flags`` >- See :ref:`DPB Entry Flags ` > > +.. c:type:: v4l2_h264_dpb_reference > + > +.. cssclass:: longtable > + > +.. flat-table:: > +:header-rows: 0 > +:stub-columns: 0 > +:widths: 1 1 2 > + > +* - ``V4L2_H264_DPB_TOP_REF`` > + - 0x1 > + - The top field in field pair is used for > +short-term reference. > +* - ``V4L2_H264_DPB_BOTTOM_REF`` > + - 0x2 > + - The bottom field in field pair is used for > +short-term reference. > +* - ``V4L2_H264_DPB_FRAME_REF`` > + - 0x3 > + - The frame (or the top/bottom fields, if it's a field pair) > +is used for short-term reference. > + > .. _h264_dpb_flags: > > ``DPB Entries Flags`` > @@ -2075,29 +2100,16 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - > > * - ``V4L2_H264_DPB_ENTRY_FLAG_VALID`` >- 0x0001 > - - The DPB entry is valid and should be considered > + - The DPB entry is valid (non-empty) and should be considered. > * - ``V4L2_H264_DPB_ENTRY_FLAG_ACTIVE`` I'm still not sure that we actually need both flags. Technically, if entry is not used for reference then doesn't need to be present. Am I missing something? Best regards, Jernej >- 0x0002 > - - The DPB entry is currently being used as a reference frame > + - The DPB entry is used for reference. > * - ``V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM`` >- 0x0004 > - - The DPB entry is a long term reference frame > + - The DPB entry is used for long-term reference. > * - ``V4L2_H264_DPB_ENTRY_FLAG_FIELD`` >- 0x0008 > - - The DPB entry is a field reference, which means only one of the > field -will be used when decoding the new frame/field. When not set > the DPB -entry is a frame reference (both fields will be used). > Note that this -flag does not say anything about the number of > fields contained in the -reference frame, it just describes the one > used to decode the new -field/frame > -* - ``V4L2_H264_DPB_ENTRY_FLAG_BOTTOM_FIELD`` > - - 0x0010 > - - The DPB entry is a bottom field reference (only the bottom field of > the -reference frame is needed to decode the new frame/field). Only > valid if -V4L2_H264_DPB_ENTRY_FLAG_FIELD is set. When > -V4L2_H264_DPB_ENTRY_FLAG_FIELD is set but > -V4L2_H264_DPB_ENTRY_FLAG_BOTTOM_FIELD is not, that means the > -DPB entry is a top field reference > + - The DPB entry is a single field or a complementary field pair. > > ``V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE (enum)`` > Specifies the decoding mode to use. Currently exposes slice-based and > diff --git a/drivers/media/v4l2-core/v4l2-h264.c > b/drivers/media/v4l2-core/v4l2-h264.c index edf6225f0522..306a51683606 > 100644 > --- a/drivers/media/v4l2-core/v4l2-h264.c > +++ b/drivers/media/v4l2-core/v4l2-h264.c > @@ -66,10 +66,10 @@ v4l2_h264_init_reflist_builder(struct > v4l2_h264_reflist_builder *b, else > b->refs[i].frame_num = dpb[i].frame_num; > > - if (!(dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_FIELD)) > + if (dpb[i].reference & V4L2_H264_DPB_FRAME_REF) > pic_order_count = min(dpb[i].top_field_order_cnt, > dpb[i].bottom_field_order_cnt); > - else if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_BOTTOM_FIELD) > + else if (dpb[i].reference & V4L2_H264_DPB_BOTTOM_REF) > pic_order_count = dpb[i].bottom_field_order_cnt; > else > pic_order_count =
Re: [PATCH v5 2/4] media: pixfmt: Add HEVC slice pixel format
Hi!
Dne petek, 24. maj 2019 ob 11:36:33 CEST je Paul Kocialkowski napisal(a):
> Introduce the V4L2_PIX_FMT_HEVC_SLICE pixel format, which currently
> describes an output buffer with enough appended slice data for
> producing one decoded frame with a stateless video decoder.
>
> This will need to be reworked (along with the controls and the core) to
> allow passing slice data individually, as it is the natural decoding
> unit in HEVC.
>
> We also need to figure out the description of the possible source data:
> * Compressed slice data only, with slice controls attached;
> * Slice data in Annex-B format (with raw slice header), without slice
> controls attached;
> * Slice data in Annex-B format (with raw slice header), with slice
> controls attached.
>
> Signed-off-by: Paul Kocialkowski
> ---
> include/media/hevc-ctrls.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
> index 9ea013c88afc..2de83d9f6d47 100644
> --- a/include/media/hevc-ctrls.h
> +++ b/include/media/hevc-ctrls.h
> @@ -11,6 +11,9 @@
> #ifndef _HEVC_CTRLS_H_
> #define _HEVC_CTRLS_H_
>
> +/* The pixel format isn't stable at the moment and will likely be renamed.
> */ +#define V4L2_PIX_FMT_HEVC_SLICE v4l2_fourcc('S', '2', '6', '5') /* HEVC
You should add include to cover v4l2_fourcc() macro.
Best regards,
Jernej
> parsed slices */ +
> #define V4L2_CID_MPEG_VIDEO_HEVC_SPS (V4L2_CID_MPEG_BASE +
1008)
> #define V4L2_CID_MPEG_VIDEO_HEVC_PPS (V4L2_CID_MPEG_BASE +
1009)
> #define V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS(V4L2_CID_MPEG_BASE +
1010)
Re: [PATCH] MAINTAINERS: Update Maintainers and Reviewers of DRM Bridge Drivers
Dne ponedeljek, 24. junij 2019 ob 11:08:51 CEST je Neil Armstrong napisal(a): > Add myself as co-maintainer of DRM Bridge Drivers then add Jonas Karlman > and Jernej Škrabec as Reviewers of DRM Bridge Drivers. > > Cc: Laurent Pinchart > Cc: Jonas Karlman > Cc: Andrzej Hajda > Cc: Jernej Škrabec > Cc: Daniel Vetter > Signed-off-by: Neil Armstrong Reviewed-by: Jernej Skrabec Thanks! Best regards, Jernej > --- > MAINTAINERS | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2abf6d28db64..dd8dacc61e79 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5253,7 +5253,10 @@ T: git git://anongit.freedesktop.org/drm/drm- misc > > DRM DRIVERS FOR BRIDGE CHIPS > M: Andrzej Hajda > +M: Neil Armstrong > R: Laurent Pinchart > +R: Jonas Karlman > +R: Jernej Skrabec > S: Maintained > T: git git://anongit.freedesktop.org/drm/drm-misc > F: drivers/gpu/drm/bridge/
Re: [PATCH 6/7] media: cedrus: Add infra for extra buffers connected to capture buffers
Dne sreda, 05. junij 2019 ob 23:10:17 CEST je Paul Kocialkowski napisal(a):
> Hi,
>
> Le lundi 03 juin 2019 à 17:48 +0200, Jernej Škrabec a écrit :
> > Dne ponedeljek, 03. junij 2019 ob 14:18:59 CEST je Maxime Ripard
napisal(a):
> > > Hi,
> > >
> > > On Thu, May 30, 2019 at 11:15:15PM +0200, Jernej Skrabec wrote:
> > > > H264 and HEVC engines need additional buffers for each capture buffer.
> > > > H264 engine has this currently solved by allocating fixed size pool,
> > > > which is not ideal. Most of the time pool size is much bigger than it
> > > > needs to be.
> > > >
> > > > Ideally, extra buffer should be allocated at buffer initialization,
> > > > but
> > > > that's not efficient. It's size in H264 depends on flags set in SPS,
> > > > but
> > > > that information is not available in buffer init callback.
> > > >
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > >
> > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 4
> > > > .../staging/media/sunxi/cedrus/cedrus_video.c | 19
> > > > +++
> > > > 2 files changed, 23 insertions(+)
> > > >
> > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > > > d8e6777e5e27..16c1bdfd243a 100644
> > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > > @@ -81,6 +81,10 @@ struct cedrus_run {
> > > >
> > > > struct cedrus_buffer {
> > > >
> > > > struct v4l2_m2m_buffer m2m_buf;
> > > >
> > > > + void*extra_buf;
> > > > + dma_addr_t extra_buf_dma;
> > > > + ssize_t extra_buf_size;
> > > > +
> > > >
> > > > union {
> > > >
> > > > struct {
> > > >
> > > > unsigned intposition;
> > > >
> > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c index
> > > > 681dfe3367a6..d756e0e69634 100644
> > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > @@ -411,6 +411,24 @@ static void cedrus_queue_cleanup(struct vb2_queue
> > > > *vq, u32 state)>
> > > >
> > > > }
> > > >
> > > > }
> > > >
> > > > +static void cedrus_buf_cleanup(struct vb2_buffer *vb)
> > > > +{
> > > > + struct vb2_queue *vq = vb->vb2_queue;
> > > > +
> > > > + if (!V4L2_TYPE_IS_OUTPUT(vq->type)) {
> > > > + struct cedrus_ctx *ctx = vb2_get_drv_priv(vq);
> > > > + struct cedrus_buffer *cedrus_buf;
> > > > +
> > > > + cedrus_buf = vb2_to_cedrus_buffer(vq->bufs[vb->index]);
> > > > +
> > > > + if (cedrus_buf->extra_buf_size)
> > > > + dma_free_coherent(ctx->dev->dev,
> > > > + cedrus_buf-
> > >
> > > extra_buf_size,
> > >
> > > > + cedrus_buf-
> > >
> > > extra_buf,
> > >
> > > > + cedrus_buf-
> > >
> > > extra_buf_dma);
> > >
> > > > + }
> > > > +}
> > > > +
> > >
> > > I'm really not a fan of allocating something somewhere, and freeing it
> > > somewhere else. Making sure you don't leak something is hard enough to
> > > not have some non-trivial allocation scheme.
> >
> > Ok, what about introducing two new optional methods in engine callbacks,
> > buffer_init and buffer_destroy, which would be called from
> > cedrus_buf_init() and cedrus_buf_cleanup(), respectively. That way all
> > (de)allocation logic stays within the same engine.
>
> I'm thinking that we should have v4l2-framework-level per-codec helpers
> to provide ops for these kinds of things, since they tend be quite
> common across decoders.
Isn't .buf_init and .buf_cleanup callbacks provided by struct vb2_ops meant
for exactly that?
Related, but different topic. I managed to fix 10-bit HEVC support on H6, but
when working in 8-bit mode, capture buffers have to be big enough to hold
normal NV12 decoded image plus extra buffer for 2 bits of each pixel. VPU
accepts only offset from destination buffer for this extra buffer instead of
full
address. How we will handle that? Override sizeimage when allocating? But
there we don't have information if it's 10-bit video or not. As you can see,
I'm not a fan of overallocating.
I suspect we will have even bigger issues when decoding 10-bit HEVC video in
P010 format, which is the only 10-bit YUV format useable by DRM driver (not
implemented yet). From what I know till now, VPU needs aforementioned 8-bit+2-
bit buffers (for decoding) and another one in which it rearranges samples in
P010 format. But that has to be confirmed first.
Best regards,
Jernej
Re: [PATCH 2/7] media: cedrus: Fix H264 default reference index count
Dne ponedeljek, 03. junij 2019 ob 13:46:20 CEST je Maxime Ripard napisal(a): > On Thu, May 30, 2019 at 11:15:11PM +0200, Jernej Skrabec wrote: > > Reference index count in VE_H264_PPS reg should come from PPS control. > > However, this is not really important because reference index count is > > in our case always overridden by that from slice header. > > > > Cc: nico...@ndufresne.ca > > Cc: boris.brezil...@collabora.com > > Cc: jo...@kwiboo.se > > > > Signed-off-by: Jernej Skrabec > > Acked-by: Maxime Ripard > > > --- > > We have to decide if we drop pps->num_ref_idx_l0_default_active_minus1 > > and pps->num_ref_idx_l1_default_active_minus1 fields or add > > num_ref_idx_l0_active_override_flag and > > num_ref_idx_l0_active_override_flag > > to slice control. Actually only one flag is in bitstream valid for both l0 and l1 ref list. > > > > Current control doesn't have those two flags, so in Cedrus override flag > > is > > always set and we rely on userspace to set > > slice->num_ref_idx_l0_active_minus1 and > > slice->num_ref_idx_l1_active_minus1 to correct values. This means that > > values stored in PPS are not needed and always ignored by VPU. > > > > If I understand correctly, algorithm is very simple: > > > > ref_count = PPS->ref_count > > if (override_flag) > > > > ref_count = slice->ref_count > > > > It seems that VAAPI provides only final value. In my opinion we should do > > the same - get rid of PPS default ref index count fields. > > The rationale was to be as conservative as possible and just expose > everything that is in the bitstream in those controls to accomodate > for as many weird hardware as possible. Ok, so then we should add that override flag, which would align with h264 specs and you can still do same trick in VAAPI library which it's currently used in Cedrus driver - always set override flag and fill out only slice reflist count. At the end it shouldn't matter for proper decoding in any driver. Best regards, Jernej
Re: [PATCH 3/7] media: cedrus: Fix decoding for some H264 videos
Dne ponedeljek, 03. junij 2019 ob 13:55:36 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, May 30, 2019 at 11:15:12PM +0200, Jernej Skrabec wrote:
> > It seems that for some H264 videos at least one bitstream parsing
> > trigger must be called in order to be decoded correctly. There is no
> > explanation why this helps, but it was observed that two sample videos
> > with this fix are now decoded correctly and there is no regression with
> > others.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> > I have two samples which are fixed by this:
> > http://jernej.libreelec.tv/videos/h264/test.mkv
> > http://jernej.libreelec.tv/videos/h264/Dredd%20%E2%80%93%20DTS%20Sound%20C
> > heck%20DTS-HD%20MA%207.1.m2ts
> >
> > Although second one also needs support for multi-slice frames, which is
> > not yet implemented here.>
> > .../staging/media/sunxi/cedrus/cedrus_h264.c | 22 ---
> > 1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > cc8d17f211a1..d0ee3f90ff46 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > @@ -6,6 +6,7 @@
> >
> > * Copyright (c) 2018 Bootlin
> > */
> >
> > +#include
> >
> > #include
> >
> > #include
> >
> > @@ -289,6 +290,20 @@ static void cedrus_write_pred_weight_table(struct
> > cedrus_ctx *ctx,>
> > }
> >
> > }
>
> We should have a comment here explaining why that is needed
ok.
>
> > +static void cedrus_skip_bits(struct cedrus_dev *dev, int num)
> > +{
> > + for (; num > 32; num -= 32) {
> > + cedrus_write(dev, VE_H264_TRIGGER_TYPE, 0x3 | (32 <<
8));
>
> Using defines here would be great
Yes, sorry about that.
>
> > + while (cedrus_read(dev, VE_H264_STATUS) & (1 << 8))
> > + udelay(1);
> > + }
>
> A new line here would be great
>
> > + if (num > 0) {
> > + cedrus_write(dev, VE_H264_TRIGGER_TYPE, 0x3 | (num <<
8));
> > + while (cedrus_read(dev, VE_H264_STATUS) & (1 << 8))
> > + udelay(1);
> > + }
>
> Can't we make that a bit simpler by not duplicating the loop?
>
> Something like:
>
> int current = 0;
>
> while (current < num) {
> int tmp = min(num - current, 32);
>
> cedrus_write(dev, VE_H264_TRIGGER_TYPE, 0x3 | (current << 8))
> while (...)
>...
>
> current += tmp;
> }
Yes, that looks better, I'll change it in next version.
Best regards,
Jernej
Re: [PATCH 6/7] media: cedrus: Add infra for extra buffers connected to capture buffers
Dne ponedeljek, 03. junij 2019 ob 14:18:59 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, May 30, 2019 at 11:15:15PM +0200, Jernej Skrabec wrote:
> > H264 and HEVC engines need additional buffers for each capture buffer.
> > H264 engine has this currently solved by allocating fixed size pool,
> > which is not ideal. Most of the time pool size is much bigger than it
> > needs to be.
> >
> > Ideally, extra buffer should be allocated at buffer initialization, but
> > that's not efficient. It's size in H264 depends on flags set in SPS, but
> > that information is not available in buffer init callback.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 4
> > .../staging/media/sunxi/cedrus/cedrus_video.c | 19 +++
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > d8e6777e5e27..16c1bdfd243a 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -81,6 +81,10 @@ struct cedrus_run {
> >
> > struct cedrus_buffer {
> >
> > struct v4l2_m2m_buffer m2m_buf;
> >
> > + void*extra_buf;
> > + dma_addr_t extra_buf_dma;
> > + ssize_t extra_buf_size;
> > +
> >
> > union {
> >
> > struct {
> >
> > unsigned intposition;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c index
> > 681dfe3367a6..d756e0e69634 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -411,6 +411,24 @@ static void cedrus_queue_cleanup(struct vb2_queue
> > *vq, u32 state)>
> > }
> >
> > }
> >
> > +static void cedrus_buf_cleanup(struct vb2_buffer *vb)
> > +{
> > + struct vb2_queue *vq = vb->vb2_queue;
> > +
> > + if (!V4L2_TYPE_IS_OUTPUT(vq->type)) {
> > + struct cedrus_ctx *ctx = vb2_get_drv_priv(vq);
> > + struct cedrus_buffer *cedrus_buf;
> > +
> > + cedrus_buf = vb2_to_cedrus_buffer(vq->bufs[vb->index]);
> > +
> > + if (cedrus_buf->extra_buf_size)
> > + dma_free_coherent(ctx->dev->dev,
> > + cedrus_buf-
>extra_buf_size,
> > + cedrus_buf-
>extra_buf,
> > + cedrus_buf-
>extra_buf_dma);
> > + }
> > +}
> > +
>
> I'm really not a fan of allocating something somewhere, and freeing it
> somewhere else. Making sure you don't leak something is hard enough to
> not have some non-trivial allocation scheme.
Ok, what about introducing two new optional methods in engine callbacks,
buffer_init and buffer_destroy, which would be called from cedrus_buf_init()
and
cedrus_buf_cleanup(), respectively. That way all (de)allocation logic stays
within the same engine.
Best regards,
Jernej
Re: [PATCH 7/7] media: cedrus: Improve H264 memory efficiency
Dne ponedeljek, 03. junij 2019 ob 14:23:28 CEST je Maxime Ripard napisal(a):
> On Thu, May 30, 2019 at 11:15:16PM +0200, Jernej Skrabec wrote:
> > H264 decoder driver preallocated pretty big worst case mv col buffer
> > pool. It turns out that pool is most of the time much bigger than it
> > needs to be.
> >
> > Solution implemented here is to allocate memory only if capture buffer
> > is actually used and only as much as it is really necessary.
> >
> > This is also preparation for 4K video decoding support, which will be
> > implemented later.
>
> What is it doing exactly to prepare for 4k?
Well, with that change 4K videos can be actually watched with 256 MiB CMA
pool, but I can drop this statement in next version.
I concentrated on 256 MiB CMA pool, because it's maximum memory size supported
by older VPU versions, but I think they don't support 4K decoding. I don't
have them, so I can't test that hypothesis.
>
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 4 -
> > .../staging/media/sunxi/cedrus/cedrus_h264.c | 81 +++
> > 2 files changed, 28 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 16c1bdfd243a..fcbbbef65494 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -106,10 +106,6 @@ struct cedrus_ctx {
> >
> > union {
> >
> > struct {
> >
> > - void*mv_col_buf;
> > - dma_addr_t mv_col_buf_dma;
> > - ssize_t mv_col_buf_field_size;
> > - ssize_t mv_col_buf_size;
> >
> > void*pic_info_buf;
> > dma_addr_t pic_info_buf_dma;
> > void*neighbor_info_buf;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > b2290f98d81a..758fd0049e8f 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > @@ -54,17 +54,14 @@ static void cedrus_h264_write_sram(struct cedrus_dev
> > *dev,>
> > cedrus_write(dev, VE_AVC_SRAM_PORT_DATA, *buffer++);
> >
> > }
> >
> > -static dma_addr_t cedrus_h264_mv_col_buf_addr(struct cedrus_ctx *ctx,
> > - unsigned int
position,
> > +static dma_addr_t cedrus_h264_mv_col_buf_addr(struct cedrus_buffer *buf,
> >
> > unsigned int
field)
> >
> > {
> >
> > - dma_addr_t addr = ctx->codec.h264.mv_col_buf_dma;
> > -
> > - /* Adjust for the position */
> > - addr += position * ctx->codec.h264.mv_col_buf_field_size * 2;
> > + dma_addr_t addr = buf->extra_buf_dma;
> >
> > /* Adjust for the field */
> >
> > - addr += field * ctx->codec.h264.mv_col_buf_field_size;
> > + if (field)
> > + addr += buf->extra_buf_size / 2;
> >
> > return addr;
> >
> > }
> >
> > @@ -76,7 +73,6 @@ static void cedrus_fill_ref_pic(struct cedrus_ctx *ctx,
> >
> > struct cedrus_h264_sram_ref_pic
*pic)
> >
> > {
> >
> > struct vb2_buffer *vbuf = >m2m_buf.vb.vb2_buf;
> >
> > - unsigned int position = buf->codec.h264.position;
> >
> > pic->top_field_order_cnt = cpu_to_le32(top_field_order_cnt);
> > pic->bottom_field_order_cnt = cpu_to_le32(bottom_field_order_cnt);
> >
> > @@ -84,10 +80,8 @@ static void cedrus_fill_ref_pic(struct cedrus_ctx *ctx,
> >
> > pic->luma_ptr = cpu_to_le32(cedrus_buf_addr(vbuf, >dst_fmt,
0));
> > pic->chroma_ptr = cpu_to_le32(cedrus_buf_addr(vbuf, >dst_fmt,
1));
> >
> > - pic->mv_col_top_ptr =
> > - cpu_to_le32(cedrus_h264_mv_col_buf_addr(ctx, position,
0));
> > - pic->mv_col_bot_ptr =
> > - cpu_to_le32(cedrus_h264_mv_col_buf_addr(ctx, position,
1));
> > + pic->mv_col_top_ptr = cpu_to_le32(cedrus_h264_mv_col_buf_addr(buf,
0));
> > + pic->mv_col_bot_ptr = cpu_to_le32(cedrus_h264_mv_col_buf_addr(buf,
1));
> >
> > }
> >
> > static void cedrus_write_frame_list(struct cedrus_ctx *ctx,
> >
> > @@ -142,6 +136,28 @@ static void cedrus_write_frame_list(struct cedrus_ctx
> > *ctx,>
> > output_buf = vb2_to_cedrus_buffer(>dst->vb2_buf);
> > output_buf->codec.h264.position = position;
> >
> > + if (!output_buf->extra_buf_size) {
> > + const struct v4l2_ctrl_h264_sps *sps = run->h264.sps;
> > + unsigned int field_size;
> > +
> > + field_size = DIV_ROUND_UP(ctx->src_fmt.width, 16) *
> > + DIV_ROUND_UP(ctx->src_fmt.height, 16) * 16;
> > + if (!(sps->flags &
V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE))
> > + field_size = field_size * 2;
> > + if (!(sps->flags &
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: sun50i-h6-r: Fix incorrect W1 clock gate register
Dne torek, 04. junij 2019 ob 17:00:54 CEST je megous via linux-sunxi napisal(a): > From: Ondrej Jirman > > The current code defines W1 clock gate to be at 0x1cc, overlaying it > with the IR gate. > > Clock gate for r-apb1-w1 is at 0x1ec. This fixes issues with IR receiver > causing interrupt floods on H6 (because interrupt flags can't be cleared, > due to IR module's bus being disabled). > > Signed-off-by: Ondrej Jirman You should add Fixes tag and CC stable with this. Best regards, Jernej
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: sun50i-h6-r: Fix incorrect W1 clock gate register
Hi! Dne torek, 04. junij 2019 ob 17:31:20 CEST je 'Ondřej Jirman' via linux-sunxi napisal(a): > Hi Jernej, > > On Tue, Jun 04, 2019 at 05:03:55PM +0200, Jernej Škrabec wrote: > > Dne torek, 04. junij 2019 ob 17:00:54 CEST je megous via linux-sunxi > > > > napisal(a): > > > From: Ondrej Jirman > > > > > > The current code defines W1 clock gate to be at 0x1cc, overlaying it > > > with the IR gate. > > > > > > Clock gate for r-apb1-w1 is at 0x1ec. This fixes issues with IR receiver > > > causing interrupt floods on H6 (because interrupt flags can't be > > > cleared, > > > due to IR module's bus being disabled). > > > > > > Signed-off-by: Ondrej Jirman > > > > You should add Fixes tag and CC stable with this. > > Not necessary, since H6 IR is not yet supported on mainline. Well, CCing stable is probably really not necessary, but you are fixing bug in existing driver (clk), fixes tag still apply. Best regards, Jernej > > regards, > o. > > > Best regards, > > Jernej > > > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 1/2] regulator: axp20x: fix DCDCA and DCDCD for AXP806
Dne sobota, 06. julij 2019 ob 13:21:44 CEST je Mark Brown napisal(a): > On Sat, Jul 06, 2019 at 12:05:44PM +0200, Jernej Skrabec wrote: > > Refactoring of the driver introduced few bugs in AXP806's DCDCA and > > DCDCD regulator definitions. > > This is not a great changelog - what are the bugs and how does > this patch fix them? In case of DCDCA, number of steps for second range should be 20 (0x14), but it was set to 14. So I guess patch author missed "0x". Currently, math doesn't work, because sum of both number of steps plus 2 must be equal to number of voltages macro. Same error is present in AXP803 DCDC6 regulator. In case of DCDCD, array of ranges (axp806_dcdcd_ranges) contains two ranges, which use same start and end macros. By checking datasheet or just checking macros at the top of the source file, it's obvious that "1" is missing in second range macro names (1600 instead of 600). And I think I found another bug, AXP803_DCDC5_NUM_VOLTAGES should be 69 and not 68. However, this bug was present before refactoring, refactoring just carried it over. Best regards, Jernej
Re: [PATCH v4 0/6] media: Introduce Allwinner H3 deinterlace driver
Dne ponedeljek, 21. oktober 2019 ob 13:16:24 CEST je Hans Verkuil napisal(a): > Hi Jernej, > > I found something odd in the compliance output: > > On 10/17/19 8:37 PM, Jernej Skrabec wrote: > > Starting with H3, Allwinner began to include standalone deinterlace > > core in multimedia oriented SoCs. This patch series introduces support > > for it. Note that new SoCs, like H6, have radically different (updated) > > deinterlace core, which will need a new driver. > > > > v4l2-compliance report: > > v4l2-compliance SHA: dece02f862f38d8f866230ca9f1015cb93ddfac4, 32 bits > > > > Compliance test for sun8i-di device /dev/video0: > > > > Driver Info: > > Driver name : sun8i-di > > Card type: sun8i-di > > Bus info : platform:sun8i-di > > Driver version : 5.3.0 > > Capabilities : 0x84208000 > > > > Video Memory-to-Memory > > Streaming > > Extended Pix Format > > Device Capabilities > > > > Device Caps : 0x04208000 > > > > Video Memory-to-Memory > > Streaming > > Extended Pix Format > > > > Required ioctls: > > test VIDIOC_QUERYCAP: OK > > > > Allow for multiple opens: > > test second /dev/video0 open: OK > > test VIDIOC_QUERYCAP: OK > > test VIDIOC_G/S_PRIORITY: OK > > test for unlimited opens: OK > > > > Debug ioctls: > > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > > test VIDIOC_LOG_STATUS: OK (Not Supported) > > > > Input ioctls: > > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > > test VIDIOC_ENUMAUDIO: OK (Not Supported) > > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) > > test VIDIOC_G/S_AUDIO: OK (Not Supported) > > Inputs: 0 Audio Inputs: 0 Tuners: 0 > > > > Output ioctls: > > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > > > Input/Output configuration ioctls: > > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > > test VIDIOC_G/S_EDID: OK (Not Supported) > > > > Control ioctls: > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) > > test VIDIOC_QUERYCTRL: OK (Not Supported) > > test VIDIOC_G/S_CTRL: OK (Not Supported) > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > > Standard Controls: 0 Private Controls: 0 > > > > Format ioctls: > > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > > test VIDIOC_G/S_PARM: OK (Not Supported) > > test VIDIOC_G_FBUF: OK (Not Supported) > > test VIDIOC_G_FMT: OK > > test VIDIOC_TRY_FMT: OK > > test VIDIOC_S_FMT: OK > > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > > test Cropping: OK (Not Supported) > > test Composing: OK (Not Supported) > > test Scaling: OK > > This claims that the driver supports scaling, but I don't think that is > right. HW does indeed support scaling so there is no bug. I tested that and result looks fine. Best regards, Jernej > > More likely the deinterlacing part is what confuses the compliance test. > > Can you look in v4l2-test-formats.cpp, function testBasicScaling() where it > sets node->can_scale to true? And see if this is due to a driver bug, or due > to a bug in the test? > > Regards, > > Hans > > > Codec ioctls: > > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > > > Buffer ioctls: > > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > > test VIDIOC_EXPBUF: OK > > test Requests: OK (Not Supported) > > > > Total for sun8i-di device /dev/video0: 44, Succeeded: 44, Failed: 0, > > Warnings: 0 > > > > Please take a look. > > > > Best regards, > > Jernej > > > > Changes from v3: > > - added Maxime's a-b tag > > - moved and fixed Kconfig entry > > - put clk_set_rate_exclusive() and it's counterpart in PM callbacks > > > > Changes from v2: > > - added acked-by and review-by tags > > - fixed schema path in H3 deinterlace binding > > - moved busy check after format args check > > > > Changes from v1: > > - updated Maxime's
Re: [PATCH v4 5/6] media: sun4i: Add H3 deinterlace driver
Dne ponedeljek, 21. oktober 2019 ob 13:13:20 CEST je Hans Verkuil napisal(a): > On 10/17/19 8:37 PM, Jernej Skrabec wrote: > > Allwinner H3 SoC contains deinterlace unit, which has several modes of > > operation - bypass, weave, bob and mixed (advanced) mode. I don't know > > how mixed mode works, but according to Allwinner it gives best results, > > so they use it exclusively. Currently this mode is also hardcoded here. > > > > For each interleaved frame queued, this driver produces 2 deinterlaced > > frames. Deinterlaced frames are based on 2 consequtive output buffers, > > except for the first 2, where same output buffer is given to peripheral > > as current and previous. > > > > There is no documentation for this core, so register layout and fixed > > values were taken from BSP driver. > > > > I'm not sure if maximum size of the image unit is capable to process is > > governed by size of "flag" buffers, frequency or it really is some HW > > limitation. Currently driver can process full HD image in ~15ms (7.5ms > > for each capture buffer), which allows to process 1920x1080@60i video > > smoothly in real time. > > > > Acked-by: Maxime Ripard > > Signed-off-by: Jernej Skrabec > > --- > > > > MAINTAINERS |7 + > > drivers/media/platform/Kconfig| 12 + > > drivers/media/platform/sunxi/Makefile |1 + > > .../media/platform/sunxi/sun8i-di/Makefile|2 + > > .../media/platform/sunxi/sun8i-di/sun8i-di.c | 1028 + > > .../media/platform/sunxi/sun8i-di/sun8i-di.h | 237 > > 6 files changed, 1287 insertions(+) > > create mode 100644 drivers/media/platform/sunxi/sun8i-di/Makefile > > create mode 100644 drivers/media/platform/sunxi/sun8i-di/sun8i-di.c > > create mode 100644 drivers/media/platform/sunxi/sun8i-di/sun8i-di.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index c7b48525822a..c375455125fb 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4646,6 +4646,13 @@ M: "Maciej W. Rozycki" > > > > S: Maintained > > F: drivers/net/fddi/defxx.* > > > > +DEINTERLACE DRIVERS FOR ALLWINNER H3 > > +M: Jernej Skrabec > > +L: linux-me...@vger.kernel.org > > +T: git git://linuxtv.org/media_tree.git > > +S: Maintained > > +F: drivers/media/platform/sunxi/sun8i-di/ > > This is missing the bindings file added in the previous patch. Well, I listed Maxime and Chen-Yu as binding maintainers in patch 4, so that's why I didn't include it here. If you think I should be maintainer of that binding too, I can change that. I took sun6i-csi as example where binding maintainers are Maxime and Chen-Yu and driver maintainer is Yong Deng. Best regards, Jernej > > Regards, > > Hans > > > + > > > > DELL SMBIOS DRIVER > > M: Pali Rohár > > M: Mario Limonciello
Re: [PATCH 3/6] pwm: sun4i: Add a quirk for bus clock
Dne sobota, 27. julij 2019 ob 12:46:28 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Fri, Jul 26, 2019 at 08:40:42PM +0200, Jernej Skrabec wrote:
> > H6 PWM core needs bus clock to be enabled in order to work.
> >
> > Add a quirk for it.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/pwm/pwm-sun4i.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > index 1b7be8fbde86..7d3ac3f2dc3f 100644
> > --- a/drivers/pwm/pwm-sun4i.c
> > +++ b/drivers/pwm/pwm-sun4i.c
> > @@ -72,6 +72,7 @@ static const u32 prescaler_table[] = {
> >
> > };
> >
> > struct sun4i_pwm_data {
> >
> > + bool has_bus_clock;
> >
> > bool has_prescaler_bypass;
> > bool has_reset;
> > unsigned int npwm;
> >
> > @@ -79,6 +80,7 @@ struct sun4i_pwm_data {
> >
> > struct sun4i_pwm_chip {
> >
> > struct pwm_chip chip;
> >
> > + struct clk *bus_clk;
> >
> > struct clk *clk;
> > struct reset_control *rst;
> > void __iomem *base;
> >
> > @@ -382,6 +384,16 @@ static int sun4i_pwm_probe(struct platform_device
> > *pdev)>
> > reset_control_deassert(pwm->rst);
> >
> > }
> >
> > + if (pwm->data->has_bus_clock) {
> > + pwm->bus_clk = devm_clk_get(>dev, "bus");
> > + if (IS_ERR(pwm->bus_clk)) {
> > + ret = PTR_ERR(pwm->bus_clk);
> > + goto err_bus;
> > + }
> > +
> > + clk_prepare_enable(pwm->bus_clk);
> > + }
> > +
>
> The patch itself looks fine, but you should clarify which clock is
> being used by the old driver.
>
> My guess is that the "new" clock is actually the mod one, while the
> old one was both the clock of the register interface (bus) and the
> clock of the PWM generation logic (mod).
Well, I checked few datasheets and nowhere is explicitly stated what is the
bus clock, but I would make same guess as you.
Anyway, since you requested that order of the clocks has to be changed, I have
to separately obtain clocks if there is bus clock present too or not. If it
is, both clocks have to be obtained by name, and if not, old code without name
can be used.
Best regards,
Jernej
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Re: [PATCH 5/6] pwm: sun4i: Add support to output source clock directly
Dne sobota, 27. julij 2019 ob 12:50:08 CEST je Maxime Ripard napisal(a): > On Fri, Jul 26, 2019 at 08:40:44PM +0200, Jernej Skrabec wrote: > > PWM core has an option to bypass whole logic and output unchanged source > > clock as PWM output. This is achieved by enabling bypass bit. > > > > Note that when bypass is enabled, no other setting has any meaning, not > > even enable bit. > > > > This mode of operation is needed to achieve high enough frequency to > > serve as clock source for AC200 chip, which is integrated into same > > package as H6 SoC. > > > > Signed-off-by: Jernej Skrabec > > It doesn't seem to be available on the A10 (at least) though. The A13 > seem to have it, so you should probably check that, and make that > conditional to the compatible if not available on all of them. Ok, can you suggest the name for the quirk? "has_bypass" is suspiciously similar to "has_prescaler_bypass". Also, how to name these sun4i_pwm_data structures? Now that there are (will be) three new quirks, name of the structure would be just too long, like "sun50i_pwm_dual_prescaler_bypass_clk_rst_bypass". Best regards, Jernej > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Re: [PATCH 3/6] pwm: sun4i: Add a quirk for bus clock
Hi Uwe,
Dne ponedeljek, 29. julij 2019 ob 08:38:25 CEST je Uwe Kleine-König
napisal(a):
> Hello,
>
> On Fri, Jul 26, 2019 at 08:40:42PM +0200, Jernej Skrabec wrote:
> > H6 PWM core needs bus clock to be enabled in order to work.
> >
> > Add a quirk for it.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/pwm/pwm-sun4i.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > index 1b7be8fbde86..7d3ac3f2dc3f 100644
> > --- a/drivers/pwm/pwm-sun4i.c
> > +++ b/drivers/pwm/pwm-sun4i.c
> > @@ -72,6 +72,7 @@ static const u32 prescaler_table[] = {
> >
> > };
> >
> > struct sun4i_pwm_data {
> >
> > + bool has_bus_clock;
> >
> > bool has_prescaler_bypass;
> > bool has_reset;
> > unsigned int npwm;
> >
> > @@ -79,6 +80,7 @@ struct sun4i_pwm_data {
> >
> > struct sun4i_pwm_chip {
> >
> > struct pwm_chip chip;
> >
> > + struct clk *bus_clk;
> >
> > struct clk *clk;
> > struct reset_control *rst;
> > void __iomem *base;
> >
> > @@ -382,6 +384,16 @@ static int sun4i_pwm_probe(struct platform_device
> > *pdev)>
> > reset_control_deassert(pwm->rst);
> >
> > }
> >
> > + if (pwm->data->has_bus_clock) {
> > + pwm->bus_clk = devm_clk_get(>dev, "bus");
>
> Similar to my suggestion in patch 2: I'd use devm_clk_get_optional() and
> drop struct sun4i_pwm_data::has_bus_clock.
This one is not so simple. This patch has incorrect logic. Correct logic would
be to use "devm_clk_get(>dev, NULL)" for variants without bus clock as
it is done already and "devm_clk_get(>dev, "bus")" and
"devm_clk_get(>dev, "mod")" for variants with bus clock.
You see, DT nodes for other variants don't have clock-names property at all.
If it would be specified, it would be "mod". So, DT nodes for other variants
have "mod" clock specified on first place (the only one), while H6 DT node will
have "mod" clock specified on second place (see one of e-mails from Maxime), so
"NULL" can't be used instead of "mod" in both cases.
So I would say quirk is beneficial to know if you have to look up clocks by
name or you just take first clock specified.
Best regards,
Jernej
>
> Best regards
> Uwe
Re: [PATCH 4/6] pwm: sun4i: Add support for H6 PWM
Hi Uwe,
Dne ponedeljek, 29. julij 2019 ob 08:40:30 CEST je Uwe Kleine-König
napisal(a):
> On Fri, Jul 26, 2019 at 08:40:43PM +0200, Jernej Skrabec wrote:
> > Now that sun4i PWM driver supports deasserting reset line and enabling
> > bus clock, support for H6 PWM can be added.
> >
> > Note that while H6 PWM has two channels, only first one is wired to
> > output pin. Second channel is used as a clock source to companion AC200
> > chip which is bundled into same package.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/pwm/pwm-sun4i.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > index 7d3ac3f2dc3f..9e0eca79ff88 100644
> > --- a/drivers/pwm/pwm-sun4i.c
> > +++ b/drivers/pwm/pwm-sun4i.c
> > @@ -331,6 +331,13 @@ static const struct sun4i_pwm_data
> > sun4i_pwm_single_bypass = {>
> > .npwm = 1,
> >
> > };
> >
> > +static const struct sun4i_pwm_data sun50i_pwm_dual_bypass_clk_rst = {
> > + .has_bus_clock = true,
> > + .has_prescaler_bypass = true,
> > + .has_reset = true,
> > + .npwm = 2,
> > +};
> > +
> >
> > static const struct of_device_id sun4i_pwm_dt_ids[] = {
> >
> > {
> >
> > .compatible = "allwinner,sun4i-a10-pwm",
> >
> > @@ -347,6 +354,9 @@ static const struct of_device_id sun4i_pwm_dt_ids[] =
> > {
> >
> > }, {
> >
> > .compatible = "allwinner,sun8i-h3-pwm",
> > .data = _pwm_single_bypass,
> >
> > + }, {
> > + .compatible = "allwinner,sun50i-h6-pwm",
> > + .data = _pwm_dual_bypass_clk_rst,
>
> If you follow my suggestion for the two previous patches, you can just
> use:
>
> compatible = "allwinner,sun50i-h6-pwm", "allwinner,sun5i-a10s-pwm";
>
> and drop this patch.
Maxime found out that it's not compatible with A10s due to difference in bypass
bit, but yes, I know what you mean.
Since H6 requires reset line and bus clock to be specified, it's not compatible
from DT binding side. New yaml based binding must somehow know that in order
to be able to validate DT node, so it needs standalone compatible. However,
depending on conclusions of other discussions, this new compatible can be
associated with already available quirks structure or have it's own.
Best regards,
Jernej
>
> Best regards
> Uwe
>
> > }, {
> >
> > /* sentinel */
> >
> > },
Re: [PATCH 5/6] pwm: sun4i: Add support to output source clock directly
Hi Uwe,
Dne ponedeljek, 29. julij 2019 ob 09:06:05 CEST je Uwe Kleine-König
napisal(a):
> On Fri, Jul 26, 2019 at 08:40:44PM +0200, Jernej Skrabec wrote:
> > PWM core has an option to bypass whole logic and output unchanged source
> > clock as PWM output. This is achieved by enabling bypass bit.
> >
> > Note that when bypass is enabled, no other setting has any meaning, not
> > even enable bit.
> >
> > This mode of operation is needed to achieve high enough frequency to
> > serve as clock source for AC200 chip, which is integrated into same
> > package as H6 SoC.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/pwm/pwm-sun4i.c | 31 ++-
> > 1 file changed, 30 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > index 9e0eca79ff88..848cff26f385 100644
> > --- a/drivers/pwm/pwm-sun4i.c
> > +++ b/drivers/pwm/pwm-sun4i.c
> > @@ -120,6 +120,19 @@ static void sun4i_pwm_get_state(struct pwm_chip
> > *chip,
> >
> > val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> >
> > + /*
> > +* PWM chapter in H6 manual has a diagram which explains that if
bypass
> > +* bit is set, no other setting has any meaning. Even more,
experiment
> > +* proved that also enable bit is ignored in this case.
> > +*/
> > + if (val & BIT_CH(PWM_BYPASS, pwm->hwpwm)) {
> > + state->period = DIV_ROUND_CLOSEST_ULL(NSEC_PER_SEC,
clk_rate);
> > + state->duty_cycle = state->period / 2;
> > + state->polarity = PWM_POLARITY_NORMAL;
> > + state->enabled = true;
> > + return;
> > + }
> > +
> >
> > if ((PWM_REG_PRESCAL(val, pwm->hwpwm) == PWM_PRESCAL_MASK) &&
> >
> > sun4i_pwm->data->has_prescaler_bypass)
> >
> > prescaler = 1;
> >
> > @@ -211,7 +224,8 @@ static int sun4i_pwm_apply(struct pwm_chip *chip,
> > struct pwm_device *pwm,>
> > {
> >
> > struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
> > struct pwm_state cstate;
> >
> > - u32 ctrl;
> > + u32 ctrl, clk_rate;
> > + bool bypass;
> >
> > int ret;
> > unsigned int delay_us;
> > unsigned long now;
> >
> > @@ -226,6 +240,16 @@ static int sun4i_pwm_apply(struct pwm_chip *chip,
> > struct pwm_device *pwm,>
> > }
> >
> > }
> >
> > + /*
> > +* Although it would make much more sense to check for bypass in
> > +* sun4i_pwm_calculate(), value of bypass bit also depends on
"enabled".
> > +* Period is allowed to be rounded up or down.
> > +*/
>
> Every driver seems to implement rounding the way its driver considers it
> sensible. @Thierry: This is another patch where it would be good to have
> a global directive about how rounding is supposed to work to provide the
> users an reliable and uniform way to work with PWMs.
>
> > + clk_rate = clk_get_rate(sun4i_pwm->clk);
> > + bypass = (state->period == NSEC_PER_SEC / clk_rate ||
> > +state->period == DIV_ROUND_UP(NSEC_PER_SEC, clk_rate))
&&
> > +state->enabled;
>
> Not sure if the compiler is clever enough to notice the obvious
> optimisation with this code construct, but you can write this test in a
> more clever way which has zero instead of up to two divisions. Something
> like:
>
> bypass = ((state->period * clk_rate >= NSEC_PER_SEC &&
> state->period * clk_rate < NSEC_PER_SEC + clk_rate) &&
> state->enabled);
>
> In the commit log you write the motivation for using bypass is that it
> allows to implement higher frequency then with the "normal" operation.
> As you don't skip calculating the normal parameters requesting such a
> high-frequency setting either errors out or doesn't catch the impossible
> request. In both cases there is something to fix.
It's the latter, otherwise it wouldn't work for my case. I'll fix the check and
skip additional logic.
>
> > +
> >
> > spin_lock(_pwm->ctrl_lock);
> > ctrl = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> >
> > @@ -273,6 +297,11 @@ static int sun4i_pwm_apply(struct pwm_chip *chip,
> > struct pwm_device *pwm,>
> > ctrl &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> >
> > }
> >
> > + if (bypass)
> > + ctrl |= BIT_CH(PWM_BYPASS, pwm->hwpwm);
> > + else
> > + ctrl &= ~BIT_CH(PWM_BYPASS, pwm->hwpwm);
> > +
>
> Does switching on (or off) the bypass bit complete the currently running
> period?
I don't really know. If I understand correctly, it just bypasses PWM logic
completely, so I would say it doesn't complete the currently running period.
Take a look at chapter 3.9.2 http://linux-sunxi.org/
File:Allwinner_H6_V200_User_Manual_V1.1.pdf
Best regards,
Jernej
>
> > sun4i_pwm_writel(sun4i_pwm, ctrl, PWM_CTRL_REG);
> >
> > spin_unlock(_pwm->ctrl_lock);
>
> Best regards
> Uwe
Re: [linux-sunxi] Re: [PATCH 4/6] pwm: sun4i: Add support for H6 PWM
Dne ponedeljek, 29. julij 2019 ob 18:24:28 CEST je Uwe Kleine-König
napisal(a):
> Hello,
>
> On Tue, Jul 30, 2019 at 12:09:40AM +0800, Chen-Yu Tsai wrote:
> > On Tue, Jul 30, 2019 at 12:07 AM Uwe Kleine-König
> >
> > wrote:
> > > On Mon, Jul 29, 2019 at 05:55:52PM +0200, Jernej Škrabec wrote:
> > > > Dne ponedeljek, 29. julij 2019 ob 08:40:30 CEST je Uwe Kleine-König
> > > >
> > > > napisal(a):
> > > > > On Fri, Jul 26, 2019 at 08:40:43PM +0200, Jernej Skrabec wrote:
> > > > > > --- a/drivers/pwm/pwm-sun4i.c
> > > > > > +++ b/drivers/pwm/pwm-sun4i.c
> > > > > > @@ -331,6 +331,13 @@ static const struct sun4i_pwm_data
> > > > > > sun4i_pwm_single_bypass = {>
> > > > > >
> > > > > > .npwm = 1,
> > > > > >
> > > > > > };
> > > > > >
> > > > > > +static const struct sun4i_pwm_data sun50i_pwm_dual_bypass_clk_rst
> > > > > > = {
> > > > > > + .has_bus_clock = true,
> > > > > > + .has_prescaler_bypass = true,
> > > > > > + .has_reset = true,
> > > > > > + .npwm = 2,
> > > > > > +};
> > > > > > +
> > > > > >
> > > > > > static const struct of_device_id sun4i_pwm_dt_ids[] = {
> > > > > >
> > > > > > {
> > > > > >
> > > > > > .compatible = "allwinner,sun4i-a10-pwm",
> > > > > >
> > > > > > @@ -347,6 +354,9 @@ static const struct of_device_id
> > > > > > sun4i_pwm_dt_ids[] =
> > > > > > {
> > > > > >
> > > > > > }, {
> > > > > >
> > > > > > .compatible = "allwinner,sun8i-h3-pwm",
> > > > > > .data = _pwm_single_bypass,
> > > > > >
> > > > > > + }, {
> > > > > > + .compatible = "allwinner,sun50i-h6-pwm",
> > > > > > + .data = _pwm_dual_bypass_clk_rst,
> > > > >
> > > > > If you follow my suggestion for the two previous patches, you can
> > > > > just
> > > > >
> > > > > use:
> > > > > compatible = "allwinner,sun50i-h6-pwm",
> > > > > "allwinner,sun5i-a10s-pwm";
> > > > >
> > > > > and drop this patch.
> > > >
> > > > Maxime found out that it's not compatible with A10s due to difference
> > > > in bypass bit, but yes, I know what you mean.
> > > >
> > > > Since H6 requires reset line and bus clock to be specified, it's not
> > > > compatible from DT binding side. New yaml based binding must somehow
> > > > know that in order to be able to validate DT node, so it needs
> > > > standalone compatible. However, depending on conclusions of other
> > > > discussions, this new compatible can be associated with already
> > > > available quirks structure or have it's own.> >
> > > I cannot follow. You should be able to specify in the binding that the
> > > reset line and bus clock is optional. Then allwinner,sun50i-h6-pwm
> > > without a reset line and bus clock also verifies, but this doesn't
> > > really hurt (and who knows, maybe the next allwinner chip needs exactly
> > > this).
> >
> > It is not optional. It will not work if either the clocks or reset
> > controls
> > are missing. How would these be optional anyway? Either it's connected and
> > thus required, or it's not and therefore should be omitted from the
> > description.
>
> [Just arguing about the clock here, the argumentation is analogous for
> the reset control.]
>
> From the driver's perspective it's optional: There are devices with and
> without a bus clock. This doesn't mean that you can just ignore this
> clock if it's specified. It's optional in the sense "If dt doesn't
> specify it, then assume this is a device that doesn't have it and so you
> don't need to handle it." but not in the sense "it doesn't matter if
> you handle it or not.".
>
> Other than that I'm on your side. So for example I think it's not
> optimal that gpiod_get_optional returns NULL if GPIOLIB=n or that
> devm_reset_control_get_optional returns NULL if RESET_CONTROLLER=n
> because this hides exactly the kind of problem you point out here.
>
I think there's misunderstanding. I only argued that we can't use
compatible = "allwinner,sun50i-h6-pwm",
"allwinner,sun5i-a10s-pwm";
as you suggested and only
compatible = "allwinner,sun50i-h6-pwm";
will work. Not because of driver itself (it can still use _optional()
variants), but because of DT binding, which should be able to validate H6 PWM
node - reset and bus clock references are required in this case.
Best regards,
Jernej
> Best regards
> Uwe
Re: [linux-sunxi] Re: [PATCH 4/6] pwm: sun4i: Add support for H6 PWM
Dne ponedeljek, 29. julij 2019 ob 20:40:41 CEST je Uwe Kleine-König
napisal(a):
> On Mon, Jul 29, 2019 at 06:40:15PM +0200, Jernej Škrabec wrote:
> > Dne ponedeljek, 29. julij 2019 ob 18:24:28 CEST je Uwe Kleine-König
> >
> > napisal(a):
> > > Hello,
> > >
> > > On Tue, Jul 30, 2019 at 12:09:40AM +0800, Chen-Yu Tsai wrote:
> > > > On Tue, Jul 30, 2019 at 12:07 AM Uwe Kleine-König
> > > >
> > > > wrote:
> > > > > On Mon, Jul 29, 2019 at 05:55:52PM +0200, Jernej Škrabec wrote:
> > > > > > Dne ponedeljek, 29. julij 2019 ob 08:40:30 CEST je Uwe
> > > > > > Kleine-König
> > > > > >
> > > > > > napisal(a):
> > > > > > > On Fri, Jul 26, 2019 at 08:40:43PM +0200, Jernej Skrabec wrote:
> > > > > > > > --- a/drivers/pwm/pwm-sun4i.c
> > > > > > > > +++ b/drivers/pwm/pwm-sun4i.c
> > > > > > > > @@ -331,6 +331,13 @@ static const struct sun4i_pwm_data
> > > > > > > > sun4i_pwm_single_bypass = {>
> > > > > > > >
> > > > > > > > .npwm = 1,
> > > > > > > >
> > > > > > > > };
> > > > > > > >
> > > > > > > > +static const struct sun4i_pwm_data
> > > > > > > > sun50i_pwm_dual_bypass_clk_rst
> > > > > > > > = {
> > > > > > > > + .has_bus_clock = true,
> > > > > > > > + .has_prescaler_bypass = true,
> > > > > > > > + .has_reset = true,
> > > > > > > > + .npwm = 2,
> > > > > > > > +};
> > > > > > > > +
> > > > > > > >
> > > > > > > > static const struct of_device_id sun4i_pwm_dt_ids[] = {
> > > > > > > >
> > > > > > > > {
> > > > > > > >
> > > > > > > > .compatible = "allwinner,sun4i-a10-pwm",
> > > > > > > >
> > > > > > > > @@ -347,6 +354,9 @@ static const struct of_device_id
> > > > > > > > sun4i_pwm_dt_ids[] =
> > > > > > > > {
> > > > > > > >
> > > > > > > > }, {
> > > > > > > >
> > > > > > > > .compatible = "allwinner,sun8i-h3-pwm",
> > > > > > > > .data = _pwm_single_bypass,
> > > > > > > >
> > > > > > > > + }, {
> > > > > > > > + .compatible = "allwinner,sun50i-h6-pwm",
> > > > > > > > + .data = _pwm_dual_bypass_clk_rst,
> > > > > > >
> > > > > > > If you follow my suggestion for the two previous patches, you
> > > > > > > can
> > > > > > > just
> > > > > > >
> > > > > > > use:
> > > > > > > compatible = "allwinner,sun50i-h6-pwm",
> > > > > > > "allwinner,sun5i-a10s-pwm";
> > > > > > >
> > > > > > > and drop this patch.
> > > > > >
> > > > > > Maxime found out that it's not compatible with A10s due to
> > > > > > difference
> > > > > > in bypass bit, but yes, I know what you mean.
> > > > > >
> > > > > > Since H6 requires reset line and bus clock to be specified, it's
> > > > > > not
> > > > > > compatible from DT binding side. New yaml based binding must
> > > > > > somehow
> > > > > > know that in order to be able to validate DT node, so it needs
> > > > > > standalone compatible. However, depending on conclusions of other
> > > > > > discussions, this new compatible can be associated with already
> > > > > > available quirks structure or have it's own.> >
> > > > >
> > > > > I cannot follow. You should be able to specify in the binding that
> > > > > the
> > > > > reset line and bus clock is optional. Then allwinner,sun50i-h6-pwm
> > > > > without a reset line and bus clock also verifies, but this doesn't
> > > > > really hurt (and who knows, maybe the next allwinner chip needs
> >
Re: [PATCH 1/3] media: uapi: h264: update reference lists
Hi!
Dne sreda, 08. julij 2020 ob 15:28:52 CEST je Ezequiel Garcia napisal(a):
> Hello Jernej,
>
> I'd like to post a new H264 uAPI cleanup series soon,
> would you mind resending this, or otherwise do you
> mind if I include this patch in the series?
I don't mind at all. Currently my focus was elsewhere...
>
> See below for a tiny comment.
>
> On Thu, 4 Jun 2020 at 15:55, Jernej Skrabec wrote:
> > When dealing with with interlaced frames, reference lists must tell if
> > each particular reference is meant for top or bottom field. This info
> > is currently not provided at all in the H264 related controls.
> >
> > Make reference lists hold a structure which will also hold flags along
> > index into DPB array. Flags will tell if reference is meant for top or
> > bottom field.
> >
> > Currently the only user of these lists is Cedrus which is just compile
> > fixed here. Actual usage of newly introduced flags will come in
> > following commit.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > .../media/v4l/ext-ctrls-codec.rst | 40 ++-
> > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +--
> > include/media/h264-ctrls.h| 12 +-
> > 3 files changed, 51 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index
> > d0d506a444b1..6c36d298db20 100644
> > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > @@ -1843,10 +1843,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type
> > ->
> > * - __u32
> >
> >- ``slice_group_change_cycle``
> >-
> >
> > -* - __u8
> > +* - struct :c:type:`v4l2_h264_reference`
> >
> >- ``ref_pic_list0[32]``
> >- Reference picture list after applying the per-slice modifications
> >
> > -* - __u8
> > +* - struct :c:type:`v4l2_h264_reference`
> >
> >- ``ref_pic_list1[32]``
> >- Reference picture list after applying the per-slice modifications
> >
> > * - __u32
> >
> > @@ -1926,6 +1926,42 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type
> > -
> >
> >- ``chroma_offset[32][2]``
> >-
> >
> > +``Picture Reference``
> > +
> > +.. c:type:: v4l2_h264_reference
> > +
> > +.. cssclass:: longtable
> > +
> > +.. flat-table:: struct v4l2_h264_reference
> > +:header-rows: 0
> > +:stub-columns: 0
> > +:widths: 1 1 2
> > +
> > +* - __u16
> > + - ``flags``
> > + - See :ref:`Picture Reference Flags `
> > +* - __u8
> > + - ``index``
> > + -
> > +
> > +.. _h264_reference_flags:
> > +
> > +``Picture Reference Flags``
> > +
> > +.. cssclass:: longtable
> > +
> > +.. flat-table::
> > +:header-rows: 0
> > +:stub-columns: 0
> > +:widths: 1 1 2
> > +
> > +* - ``V4L2_H264_REFERENCE_FLAG_TOP_FIELD``
> > + - 0x0001
> > + -
> > +* - ``V4L2_H264_REFERENCE_FLAG_BOTTOM_FIELD``
> > + - 0x0002
> > + -
> > +
> >
> > ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
> >
> > Specifies the decode parameters (as extracted from the bitstream)
> > for the associated H264 slice data. This includes the necessary
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index
> > 54ee2aa423e2..cce527bbdf86 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> > @@ -166,8 +166,8 @@ static void cedrus_write_frame_list(struct cedrus_ctx
> > *ctx,>
> > static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> >
> >struct cedrus_run *run,
> >
> > - const u8 *ref_list, u8 num_ref,
> > - enum cedrus_h264_sram_off sram)
> > + const struct v4l2_h264_reference
> > *ref_list, + u8 num_ref, enum
> > cedrus_h264_sram_off sram)>
> > {
> >
> > const struct v4l2_ctrl_h264_decode_params *decode =
> > run->h264.decode_params; struct vb2_queue *cap_q;
> >
> > @@ -188,7 +188,7 @@ static void _cedrus_write_ref_list(struct cedrus_ctx
> > *ctx,>
> > int buf_idx;
> > u8 dpb_idx;
> >
> > - dpb_idx = ref_list[i];
> > + dpb_idx = ref_list[i].index;
> >
> > dpb = >dpb[dpb_idx];
> >
> > if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
> >
> > diff --git a/include/media/h264-ctrls.h b/include/media/h264-ctrls.h
> > index 080fd1293c42..9b1cbc9bc38e 100644
> > --- a/include/media/h264-ctrls.h
> > +++ b/include/media/h264-ctrls.h
> > @@ -140,6 +140,14 @@ struct v4l2_h264_pred_weight_table {
> >
> > #define
Re: [PATCH 13/16] arm64: dts: allwinner: a64: Add HDMI audio
Hi!
Dne ponedeljek, 06. julij 2020 ob 07:31:23 CEST je Maxime Ripard napisal(a):
> On Sat, Jul 04, 2020 at 01:38:59PM +0200, Clément Péron wrote:
> > From: Marcus Cooper
> >
> > Add a simple-soundcard to link audio between HDMI and I2S.
> >
> > Signed-off-by: Jernej Skrabec
> > Signed-off-by: Marcus Cooper
> > Signed-off-by: Clément Péron
> > ---
> >
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +++
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> > c662f6a170ce..6a321fdc8e90 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -102,6 +102,25 @@ de: display-engine {
> >
> > status = "disabled";
> >
> > };
> >
> > + hdmi_sound: hdmi-sound {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,name = "sun50i-a64-hdmi";
> > + simple-audio-card,mclk-fs = <128>;
> > + simple-audio-card,frame-inversion;
> > + status = "disabled";
> > +
> > + simple-audio-card,codec {
> > + sound-dai = <>;
> > + };
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <>;
> > + dai-tdm-slot-num = <2>;
> > + dai-tdm-slot-width = <32>;
> > + };
> > + };
> > +
> >
> > osc24M: osc24M_clk {
> >
> > #clock-cells = <0>;
> > compatible = "fixed-clock";
> >
> > @@ -856,6 +875,7 @@ i2s2: i2s@1c22800 {
> >
> > resets = < RST_BUS_I2S2>;
> > dma-names = "tx";
> > dmas = < 27>;
> >
> > + allwinner,playback-channels = <8>;
>
> This isn't documented anywhere
This can be safely dropped. It is just leftover from multi-channel (>2) work,
which will have to be redesigned anyway.
Best regards,
Jernej
Re: [PATCH 08/16] arm64: dts: allwinner: h6: Add HDMI audio node
Hi!
Dne ponedeljek, 06. julij 2020 ob 07:29:37 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Sat, Jul 04, 2020 at 01:38:54PM +0200, Clément Péron wrote:
> > From: Jernej Skrabec
> >
> > Add a simple-soundcard to link audio between HDMI and I2S.
> >
> > Signed-off-by: Jernej Skrabec
> > Signed-off-by: Marcus Cooper
> > Signed-off-by: Clément Péron
> > ---
> >
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index
> > 78b1361dfbb9..ae169d07b939 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -67,6 +67,25 @@ de: display-engine {
> >
> > status = "disabled";
> >
> > };
> >
> > + hdmi_sound: hdmi-sound {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,name = "sun50i-h6-hdmi";
> > + simple-audio-card,mclk-fs = <128>;
> > + simple-audio-card,frame-inversion;
>
> Have you figured that one out?
>
> > + status = "disabled";
> > +
> > + simple-audio-card,codec {
> > + sound-dai = <>;
> > + };
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <>;
> > + dai-tdm-slot-num = <2>;
> > + dai-tdm-slot-width = <32>;
>
> I'm not sure why you need to use the TDM stuff here. IIRC the HDMI
> controller can output on up to 6 channels, so how would that work out?
dai-tdm-slot-width is needed to override automatic slot width selection. It
should always be 32 for HDMI, no matter what is actual physical sample width.
In this case this property is abused to set width also for I2S mode of
operation. IMO there is no sense to duplicate code because I2S variant would
work exactly the same, except name would be different.
I'm not sure about dai-tdm-slot-num. Marcus, can you explain the need for this
property?
Would it be better to implement separate link driver instead of using simple-
card to hide all this properties into the code?
Best regards,
Jernej
Re: [linux-sunxi] [PATCH 01/16] ASoC: sun4i-i2s: Add support for H6 I2S
Hi Samuel!
Dne petek, 10. julij 2020 ob 07:44:33 CEST je Samuel Holland napisal(a):
> On 7/4/20 6:38 AM, Clément Péron wrote:
> > From: Jernej Skrabec
> >
> > H6 I2S is very similar to that in H3, except it supports up to 16
> > channels.
> >
> > Signed-off-by: Jernej Skrabec
> > Signed-off-by: Marcus Cooper
> > Signed-off-by: Clément Péron
> > ---
> >
> > sound/soc/sunxi/sun4i-i2s.c | 227
> > 1 file changed, 227 insertions(+)
> >
> > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> > index d0a8d5810c0a..9690389cb68e 100644
> > --- a/sound/soc/sunxi/sun4i-i2s.c
> > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > @@ -124,6 +124,21 @@
> >
> > #define SUN8I_I2S_RX_CHAN_SEL_REG 0x54
> > #define SUN8I_I2S_RX_CHAN_MAP_REG 0x58
> >
> > +/* Defines required for sun50i-h6 support */
> > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET_MASK GENMASK(21, 20)
> > +#define SUN50I_H6_I2S_TX_CHAN_SEL_OFFSET(offset) ((offset) << 20)
> > +#define SUN50I_H6_I2S_TX_CHAN_SEL_MASK GENMASK(19, 16)
> > +#define SUN50I_H6_I2S_TX_CHAN_SEL(chan)((chan - 1) << 16)
> > +#define SUN50I_H6_I2S_TX_CHAN_EN_MASK GENMASK(15, 0)
> > +#define SUN50I_H6_I2S_TX_CHAN_EN(num_chan) (((1 << num_chan) - 1))
> > +
> > +#define SUN50I_H6_I2S_TX_CHAN_MAP0_REG 0x44
> > +#define SUN50I_H6_I2S_TX_CHAN_MAP1_REG 0x48
> > +
> > +#define SUN50I_H6_I2S_RX_CHAN_SEL_REG 0x64
> > +#define SUN50I_H6_I2S_RX_CHAN_MAP0_REG 0x68
> > +#define SUN50I_H6_I2S_RX_CHAN_MAP1_REG 0x6C
> > +
> >
> > struct sun4i_i2s;
> >
> > /**
> >
> > @@ -466,6 +481,65 @@ static int sun8i_i2s_set_chan_cfg(const struct
> > sun4i_i2s *i2s,>
> > return 0;
> >
> > }
> >
> > +static int sun50i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
> > + const struct snd_pcm_hw_params
*params)
> > +{
> > + unsigned int channels = params_channels(params);
> > + unsigned int slots = channels;
> > + unsigned int lrck_period;
> > +
> > + if (i2s->slots)
> > + slots = i2s->slots;
> > +
> > + /* Map the channels for playback and capture */
> > + regmap_write(i2s->regmap, SUN50I_H6_I2S_TX_CHAN_MAP1_REG,
0x76543210);
> > + regmap_write(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_MAP1_REG,
0x76543210);
> > +
> > + /* Configure the channels */
> > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
> > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK,
> > + SUN50I_H6_I2S_TX_CHAN_SEL(channels));
> > + regmap_update_bits(i2s->regmap, SUN50I_H6_I2S_RX_CHAN_SEL_REG,
> > + SUN50I_H6_I2S_TX_CHAN_SEL_MASK,
> > + SUN50I_H6_I2S_TX_CHAN_SEL(channels));
> > +
> > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
> > + SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK,
> > +
SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM(channels));
> > + regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
> > + SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK,
> > +
SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(channels));
> > +
> > + switch (i2s->format & SND_SOC_DAIFMT_FORMAT_MASK) {
> > + case SND_SOC_DAIFMT_DSP_A:
> > + case SND_SOC_DAIFMT_DSP_B:
> > + case SND_SOC_DAIFMT_LEFT_J:
>
> > + case SND_SOC_DAIFMT_RIGHT_J:
> According to the manual, LEFT_J and RIGHT_J should use the same calculation
> as I2S, not the one for PCM/DSP.
>
> > + lrck_period = params_physical_width(params) * slots;
> > + break;
> > +
> > + case SND_SOC_DAIFMT_I2S:
> > + lrck_period = params_physical_width(params);
> > + break;
> > +
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + if (i2s->slot_width)
> > + lrck_period = i2s->slot_width;
> > +
> > + regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
> > + SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
> > + SUN8I_I2S_FMT0_LRCK_PERIOD(lrck_period));
>
> From the description in the manual, this looks off by one. The number of
> BCLKs per LRCK is LRCK_PERIOD + 1.
Are you sure? Macro SUN8I_I2S_FMT0_LRCK_PERIOD() is defined as follows:
#define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)
which already lowers value by 1.
Best regards,
Jernej
>
> > +
> > + regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
> > + SUN50I_H6_I2S_TX_CHAN_EN_MASK,
> > + SUN50I_H6_I2S_TX_CHAN_EN(channels));
> > +
> > + return 0;
> > +}
> > +
> >
> > static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
> >
> >struct snd_pcm_hw_params *params,
> >struct snd_soc_dai *dai)
> >
> > @@ -691,6 +765,108 @@ static int sun8i_i2s_set_soc_fmt(const struct
> > sun4i_i2s *i2s,>
> > return 0;
> >
> > }
> >
> > +static int sun50i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
> >
Re: [PATCH] media: cedrus: Add support for VP8 decoding
Dne sreda, 20. maj 2020 ob 23:43:40 CEST je Nicolas Dufresne napisal(a): > Le mercredi 20 mai 2020 à 23:01 +0200, Jernej Skrabec a écrit : > > VP8 in Cedrus shares same engine as H264. > > > > Note that it seems necessary to call bitstream parsing functions, > > to parse frame header, otherwise decoded image is garbage. This is > > contrary to what is driver supposed to do. However, values are not > > really used, so this might be acceptable. It's possible that bitstream > > Have you verified that all values passed through controls are not used > ? To remain a stateless driver, there is no requirement for parsed data > to be used, the only requirement is that the reference are used. > Otherwise doing parallel decoding of two stream of different stream > would be broken. Have you verified that parallel decoding is working as > expected ? I'm not sure if you understand what I meant. Although userspace app parses frame header and fills all data in VP8 control, driver parses frame header again, using HW bitstream parsing functionality in cedrus_read_header(). Without that second header parsing in HW, decoded image is garbage. Note that cedrus_read_header() discards all parsed values and relies on those provided in controls. This parsing doesn't cause any problems with parallel decoding or anything. It's done during frame decoding job, so it doesn't affect any state. It's just that we shouldn't need to parse header in driver because all data is already provided in controls. It seems that Cedrus core was never tested without that HW frame header parsing. I found out that HEVC and H264 frames can sometimes also be wrongly decoded if no bitstream parsing function is triggered in HW before final decoding. I spend a lot of time trying to avoid that header parsing, but I couldn't find any way around it. In another words, Cedrus VPU provides two functionalities - HW bitstream parsing (to speed up header parsing) and video decoding. One would thought that video decoding can be used independently, if all data from header is already known, but it can't be. Best regards, Jernej > > > parsing functions set some internal VPU state, which is later necessary > > for proper decoding. Biggest suspect is "VP8 probs update" trigger. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > drivers/staging/media/sunxi/cedrus/Makefile | 3 +- > > drivers/staging/media/sunxi/cedrus/cedrus.c | 8 + > > drivers/staging/media/sunxi/cedrus/cedrus.h | 15 + > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 5 + > > .../staging/media/sunxi/cedrus/cedrus_hw.c| 1 + > > .../staging/media/sunxi/cedrus/cedrus_regs.h | 80 ++ > > .../staging/media/sunxi/cedrus/cedrus_video.c | 9 + > > .../staging/media/sunxi/cedrus/cedrus_vp8.c | 699 ++ > > 8 files changed, 819 insertions(+), 1 deletion(-) > > create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_vp8.c
Re: [linux-sunxi] Re: [PATCH 12/15] drm/sun4i: Add support for second clock parent to DW HDMI PHY clk driver
Hi, Dne ponedeljek, 21. maj 2018 ob 10:12:53 CEST je Maxime Ripard napisal(a): > On Sat, May 19, 2018 at 08:31:24PM +0200, Jernej Skrabec wrote: > > Expand HDMI PHY clock driver to support second clock parent. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 6 +- > > drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 29 ++- > > drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 -- > > 3 files changed, 98 insertions(+), 27 deletions(-) > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h > > b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 801a17222762..aadbe0a10b0c > > 100644 > > --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h > > +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h > > @@ -98,7 +98,8 @@ > > > > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_ENBIT(29) > > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_ENBIT(28) > > #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27) > > > > -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26) > > +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26) > > +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26 > > > > #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25) > > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x)((x) << 22) > > #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20) > > > > @@ -190,6 +191,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi > > *hdmi); > > > > void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy); > > const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void); > > > > -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev); > > +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev, > > +bool second_parent); > > > > #endif /* _SUN8I_DW_HDMI_H_ */ > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > > b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index deba47ed69d8..7a911f0a3ae3 > > 100644 > > --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > > +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > > @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi > > *hdmi,> > > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG, > > > >SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0); > > > > - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init); > > + /* > > +* NOTE: We have to be careful not to overwrite PHY parent > > +* clock selection bit and clock divider. > > +*/ > > + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, > > + ~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK, > > + pll_cfg1_init); > > It feels like it belongs in a separate patch. Why? clk_set_rate() on HDMI PHY clock is called before this function, so SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL bit is already set to correct value. Original code doesn't take this into account and sets it to 0 here in all cases, which obviously is not right. If you insist on splitting this in new patch, it has to be applied before clock changes. It would also need to include "reset PLL clock configuration" chunk (next change in this patch), otherwise other SoCs with only one parent could get 1 there, which is obviously wrong. Note that I didn't really tested if default value of this bit is 0 or 1, but I wouldn't really like to depend on default values. > > > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, > > > >(u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK, > >pll_cfg2_init); > > > > @@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct > > sun8i_hdmi_phy *phy)> > >SUN8I_HDMI_PHY_ANA_CFG3_SCLEN | > >SUN8I_HDMI_PHY_ANA_CFG3_SDAEN); > > > > + /* reset PLL clock configuration */ > > + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0); > > + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0); > > + > > Ditto, > > > + > > + /* > > +* Even though HDMI PHY clock doesn't have enable/disable > > +* handlers, we have to enable it. Otherwise it could happen > > +* that parent PLL is not enabled by clock framework in a > > +* highly unlikely event when parent PLL is used solely for > > +* HDMI PHY clock. > > +*/ > > + clk_prepare_enable(phy->clk_phy); > > The implementation of the clock doesn't really matter in our API > usage. If we're using a clock, we have to call > clk_prepare_enable. That's documented everywhere, and mentionning how > the clock is implemented is an abstraction leakage and it's > irrelevant. I'd simply remove the comment here. > > And it should be in a separate patch as well. OK. Should I add Fixes tag, since current code obviously is not by the specs? It could still get in 4.17... Best regards, Jernej
Re: [PATCH 04/15] dt-bindings: display: sunxi-drm: Add TCON TOP description
Hi, Dne ponedeljek, 21. maj 2018 ob 10:01:47 CEST je Maxime Ripard napisal(a): > Hi, > > On Sat, May 19, 2018 at 08:31:16PM +0200, Jernej Skrabec wrote: > > TCON TOP main purpose is to configure whole display pipeline. It > > determines relationships between mixers and TCONs, selects source TCON > > for HDMI, muxes LCD and TV encoder GPIO output, > > I'm not sure you mean GPIO here, but rather pin? Right, I'll fix that. > > > selects TV encoder clock source and contains additional TV TCON and > > DSI gates. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > .../bindings/display/sunxi/sun4i-drm.txt | 20 +++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > > 3346c1e2a7a0..a099957ab62a 100644 > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > @@ -187,6 +187,26 @@ And on the A23, A31, A31s and A33, you need one more clock line: > > - 'lvds-alt': An alternative clock source, separate from the TCON > > channel 0 > > > > clock, that can be used to drive the LVDS clock > > > > +TCON TOP > > + > > + > > +TCON TOPs main purpose is to configure whole display pipeline. It > > determines +relationships between mixers and TCONs, selects source TCON > > for HDMI, muxes +LCD and TV encoder GPIO output, selects TV encoder clock > > source and contains +additional TV TCON and DSI gates. > > + > > +Required properties: > > + - compatible: value must be one of: > > +* allwinner,sun8i-r40-tcon-top > > + - reg: base address and size of the memory-mapped region. > > + - clocks: phandle to the clocks feeding the TCON TOP > > +* bus: TCON TOP interface clock > > + - clock-names: clock name mentioned above > > + - resets: phandle to the reset line driving the DRC > > +* rst: TCON TOP reset line > > + - reset-names: reset name mentioned above > > + - #clock-cells : must contain 1 > > + > > I guess you should better describe the OF-graph endpoints, and the > clocks output. Just using the binding additions here doesn't allow to > get a clear idea of how the DT should look like. With my idea of implementation, OF graph is the same as before, so I didn't mention anything about it. My idea of dependencies (you should view it in fixed width font): TCON-TOP ^ | mixer <-> TCON <-> HDMI I'll explain my design decision as response to other mail. Best regards, Jernej
Re: [PATCH 05/15] drm/sun4i: Add TCON TOP driver
Hi,
Dne ponedeljek, 21. maj 2018 ob 10:05:17 CEST je Maxime Ripard napisal(a):
> On Sat, May 19, 2018 at 08:31:17PM +0200, Jernej Skrabec wrote:
> > As already described in DT binding, TCON TOP is responsible for
> > configuring display pipeline. In this initial driver focus is on HDMI
> > pipeline, so TVE and LCD configuration is not implemented.
> >
> > Implemented features:
> > - HDMI source selection
> > - clock driver (TCON and DSI gating)
> > - connecting mixers and TCONS
> >
> > Something similar also existed in previous SoCs, except that it was part
> > of first TCON.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/sun4i/Makefile | 3 +-
> > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 256 +
> > drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 20 ++
> > include/dt-bindings/clock/sun8i-tcon-top.h | 11 +
> > 4 files changed, 289 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
> > create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
> >
> > diff --git a/drivers/gpu/drm/sun4i/Makefile
> > b/drivers/gpu/drm/sun4i/Makefile index 2589f4acd5ae..09fbfd6304ba 100644
> > --- a/drivers/gpu/drm/sun4i/Makefile
> > +++ b/drivers/gpu/drm/sun4i/Makefile
> > @@ -16,7 +16,8 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
> >
> > sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
> >
> >sun8i_vi_layer.o sun8i_ui_scaler.o \
> >
> > - sun8i_vi_scaler.o sun8i_csc.o
> > + sun8i_vi_scaler.o sun8i_csc.o \
> > + sun8i_tcon_top.o
> >
> > sun4i-tcon-y += sun4i_crtc.o
> > sun4i-tcon-y += sun4i_dotclock.o
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c new file mode 100644
> > index ..075a356a6dfa
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > @@ -0,0 +1,256 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/* Copyright (c) 2018 Jernej Skrabec */
> > +
> > +#include
> > +
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "sun8i_tcon_top.h"
> > +
> > +#define TCON_TOP_PORT_SEL_REG 0x1C
> > +#define TCON_TOP_PORT_DE0_MSK GENMASK(1, 0)
> > +#define TCON_TOP_PORT_DE1_MSK GENMASK(5, 4)
> > +#define TCON_TOP_PORT_TCON_LCD00
> > +#define TCON_TOP_PORT_TCON_LCD11
> > +#define TCON_TOP_PORT_TCON_TV0 2
> > +#define TCON_TOP_PORT_TCON_TV1 3
> > +
> > +#define TCON_TOP_GATE_SRC_REG 0x20
> > +#define TCON_TOP_HDMI_SRC_MSK GENMASK(29, 28)
> > +#define TCON_TOP_HDMI_SRC_NONE 0
> > +#define TCON_TOP_HDMI_SRC_TCON_TV0 1
> > +#define TCON_TOP_HDMI_SRC_TCON_TV1 2
> > +#define TCON_TOP_TCON_TV1_GATE 24
> > +#define TCON_TOP_TCON_TV0_GATE 20
> > +#define TCON_TOP_TCON_DSI_GATE 16
> > +
> > +#define CLK_NUM3
> > +
> > +struct sun8i_tcon_top {
> > + struct clk *bus;
> > + void __iomem*regs;
> > + struct reset_control*rst;
> > +
> > + /*
> > +* spinlock is used for locking access to registers from different
> > +* places - tcon driver and clk subsystem.
> > +*/
> > + spinlock_t reg_lock;
> > +};
> > +
> > +struct sun8i_tcon_top_gate {
> > + const char *name;
> > + u8 bit;
> > + int index;
> > +};
> > +
> > +static const struct sun8i_tcon_top_gate gates[] = {
> > + {"bus-tcon-top-dsi", TCON_TOP_TCON_DSI_GATE, CLK_BUS_TCON_TOP_DSI},
> > + {"bus-tcon-top-tv0", TCON_TOP_TCON_TV0_GATE, CLK_BUS_TCON_TOP_TV0},
> > + {"bus-tcon-top-tv1", TCON_TOP_TCON_TV1_GATE, CLK_BUS_TCON_TOP_TV1},
> > +};
> > +
> > +void sun8i_tcon_top_set_hdmi_src(struct sun8i_tcon_top *tcon_top, int
> > tcon) +{
> > + unsigned long flags;
> > + u32 val;
> > +
> > + if (tcon > 1) {
> > + DRM_ERROR("TCON index is too high!\n");
> > + return;
> > + }
> > +
> > + spin_lock_irqsave(_top->reg_lock, flags);
> > +
> > + val = readl(tcon_top->regs + TCON_TOP_GATE_SRC_REG);
> > + val &= ~TCON_TOP_HDMI_SRC_MSK;
> > + val |= FIELD_PREP(TCON_TOP_HDMI_SRC_MSK,
> > + TCON_TOP_HDMI_SRC_TCON_TV0 + tcon);
> > + writel(val, tcon_top->regs + TCON_TOP_GATE_SRC_REG);
> > +
> > + spin_unlock_irqrestore(_top->reg_lock, flags);
> > +}
> > +
> > +void sun8i_tcon_top_de_config(struct sun8i_tcon_top *tcon_top,
> > + int mixer, enum tcon_type tcon_type, int tcon)
> > +{
> > +
Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
Hi,
Dne ponedeljek, 21. maj 2018 ob 10:07:59 CEST je Maxime Ripard napisal(a):
> On Sat, May 19, 2018 at 08:31:18PM +0200, Jernej Skrabec wrote:
> > If SoC has TCON TOP unit, it has to be configured from TCON, since it
> > has all information needed. Additionally, if it is TCON TV, it must also
> > enable bus gate inside TCON TOP unit.
>
> Why?
I'll explain my design decision below.
>
> > Add support for such TCONs.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 28
> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 8
> > 2 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..e0c562ce1c22
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> >
> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > return PTR_ERR(tcon->clk);
> >
> > }
> >
> > +
> > + if (tcon->quirks->needs_tcon_top && tcon->quirks->has_channel_1) {
> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > + if (IS_ERR(tcon->top_clk)) {
> > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> > + return PTR_ERR(tcon->top_clk);
> > + }
> > + clk_prepare_enable(tcon->top_clk);
> > + }
> > +
> >
> > clk_prepare_enable(tcon->clk);
> >
> > if (tcon->quirks->has_channel_0) {
> >
> > @@ -712,6 +722,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> >
> > static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
> > {
> >
> > clk_disable_unprepare(tcon->clk);
> >
> > + clk_disable_unprepare(tcon->top_clk);
> >
> > }
> >
> > static int sun4i_tcon_init_irq(struct device *dev,
> >
> > @@ -980,6 +991,23 @@ static int sun4i_tcon_bind(struct device *dev, struct
> > device *master,>
> > tcon->id = engine->id;
> > tcon->quirks = of_device_get_match_data(dev);
> >
> > + if (tcon->quirks->needs_tcon_top) {
> > + struct device_node *np;
> > +
> > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top", 0);
> > + if (np) {
> > + struct platform_device *pdev;
> > +
> > + pdev = of_find_device_by_node(np);
> > + if (pdev)
> > + tcon->tcon_top = platform_get_drvdata(pdev);
> > + of_node_put(np);
> > +
> > + if (!tcon->tcon_top)
> > + return -EPROBE_DEFER;
> > + }
> > + }
> > +
>
> I might have missed it, but I've not seen the bindings additions for
> that property. This shouldn't really be done that way anyway, instead
> of using a direct phandle, you should be using the of-graph, with the
> TCON-top sitting where it belongs in the flow of data.
Just to answer to the first question, it did describe it in "[PATCH 07/15] dt-
bindings: display: sun4i-drm: Add R40 HDMI pipeline".
As why I designed it that way - HW representation could be described that way
(ASCII art makes sense when fixed width font is used to view it):
/ LCD0/LVDS0
/ TCON-LCD0
| \ MIPI DSI
mixer0 |
\/ TCON-LCD1 - LCD1/LVDS1
TCON-TOP
/\ TCON-TV0 - TVE0/RGB
mixer1 | \
| TCON-TOP - HDMI
| /
\ TCON-TV1 - TVE1/RGB
This is a bit simplified, since there is also TVE-TOP, which is responsible
for sharing 4 DACs between both TVE encoders. You can have two TV outs (PAL/
NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even seems that you
can arbitrarly choose which DAC is responsible for which signal, so there is a
ton of possible end combinations, but I'm not 100% sure.
Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
suggest more possibilities, although some of them seem wrong, like RGB feeding
from LCD TCON. That is confirmed to be wrong when checking BSP code.
Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and LCD1 for
pin muxing, although I'm not sure why is that needed at all, since according
to R40 datasheet, TVE0 and TVE1 pins are dedicated and not on PORT D and PORT
H, respectively, as TCON-TOP documentation suggest. However, HSYNC and PSYNC
lines might be shared between TVE (when it works in RGB mode) and LCD. But
that is just my guess since I'm not really familiar with RGB and LCD
interfaces.
I'm really not sure what would be the best representation in OF-graph. Can you
suggest one?
On the other hand, mux callback in TCON driver has all available informations
at hand. It knows mixer ID, TCON ID and most importantly, encoder type. Based
on all that informations,
Re: [PATCH v3 2/2] media: cedrus: Add H264 decoding support
Dne ponedeljek, 11. februar 2019 ob 15:39:03 CET je Maxime Ripard napisal(a):
> Introduce some basic H264 decoding support in cedrus. So far, only the
> baseline profile videos have been tested, and some more advanced features
> used in higher profiles are not even implemented.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/staging/media/sunxi/cedrus/Makefile | 3 +-
> drivers/staging/media/sunxi/cedrus/cedrus.c | 31 +-
> drivers/staging/media/sunxi/cedrus/cedrus.h | 38 +-
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 15 +-
> drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 589 +++-
> drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 4 +-
> drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 91 ++-
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 9 +-
> 8 files changed, 778 insertions(+), 2 deletions(-)
> create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h264.c
>
> diff --git a/drivers/staging/media/sunxi/cedrus/Makefile
> b/drivers/staging/media/sunxi/cedrus/Makefile index
> e9dc68b7bcb6..aaf141fc58b6 100644
> --- a/drivers/staging/media/sunxi/cedrus/Makefile
> +++ b/drivers/staging/media/sunxi/cedrus/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
>
> -sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o
> cedrus_mpeg2.o +sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o
> cedrus_dec.o \ + cedrus_mpeg2.o cedrus_h264.o
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c index
> ff11cbeba205..b275607b8111 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -40,6 +40,36 @@ static const struct cedrus_control cedrus_controls[] = {
> .codec = CEDRUS_CODEC_MPEG2,
> .required = false,
> },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS,
> + .elem_size = sizeof(struct
v4l2_ctrl_h264_decode_param),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_slice_param),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_SPS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_sps),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_PPS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_pps),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX,
> + .elem_size = sizeof(struct
v4l2_ctrl_h264_scaling_matrix),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> };
>
> #define CEDRUS_CONTROLS_COUNTARRAY_SIZE(cedrus_controls)
> @@ -278,6 +308,7 @@ static int cedrus_probe(struct platform_device *pdev)
> }
>
> dev->dec_ops[CEDRUS_CODEC_MPEG2] = _dec_ops_mpeg2;
> + dev->dec_ops[CEDRUS_CODEC_H264] = _dec_ops_h264;
>
> mutex_init(>dev_mutex);
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> 4aedd24a9848..8c64f9a27e9d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -30,7 +30,7 @@
>
> enum cedrus_codec {
> CEDRUS_CODEC_MPEG2,
> -
> + CEDRUS_CODEC_H264,
> CEDRUS_CODEC_LAST,
> };
>
> @@ -40,6 +40,12 @@ enum cedrus_irq_status {
> CEDRUS_IRQ_OK,
> };
>
> +enum cedrus_h264_pic_type {
> + CEDRUS_H264_PIC_TYPE_FRAME = 0,
> + CEDRUS_H264_PIC_TYPE_FIELD,
> + CEDRUS_H264_PIC_TYPE_MBAFF,
> +};
> +
> struct cedrus_control {
> u32 id;
> u32 elem_size;
> @@ -47,6 +53,14 @@ struct cedrus_control {
> unsigned char required:1;
> };
>
> +struct cedrus_h264_run {
> + const struct v4l2_ctrl_h264_decode_param*decode_param;
> + const struct v4l2_ctrl_h264_pps *pps;
> + const struct v4l2_ctrl_h264_scaling_matrix *scaling_matrix;
> + const struct v4l2_ctrl_h264_slice_param *slice_param;
> + const struct v4l2_ctrl_h264_sps *sps;
> +};
> +
> struct cedrus_mpeg2_run {
> const struct v4l2_ctrl_mpeg2_slice_params *slice_params;
> const struct v4l2_ctrl_mpeg2_quantization *quantization;
> @@ -57,12 +71,20 @@ struct cedrus_run {
> struct vb2_v4l2_buffer
Re: [PATCH v3 2/2] media: cedrus: Add H264 decoding support
Dne ponedeljek, 11. februar 2019 ob 15:39:03 CET je Maxime Ripard napisal(a):
> Introduce some basic H264 decoding support in cedrus. So far, only the
> baseline profile videos have been tested, and some more advanced features
> used in higher profiles are not even implemented.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/staging/media/sunxi/cedrus/Makefile | 3 +-
> drivers/staging/media/sunxi/cedrus/cedrus.c | 31 +-
> drivers/staging/media/sunxi/cedrus/cedrus.h | 38 +-
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 15 +-
> drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 589 +++-
> drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 4 +-
> drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 91 ++-
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 9 +-
> 8 files changed, 778 insertions(+), 2 deletions(-)
> create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h264.c
>
> diff --git a/drivers/staging/media/sunxi/cedrus/Makefile
> b/drivers/staging/media/sunxi/cedrus/Makefile index
> e9dc68b7bcb6..aaf141fc58b6 100644
> --- a/drivers/staging/media/sunxi/cedrus/Makefile
> +++ b/drivers/staging/media/sunxi/cedrus/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
>
> -sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o
> cedrus_mpeg2.o +sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o
> cedrus_dec.o \ + cedrus_mpeg2.o cedrus_h264.o
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c index
> ff11cbeba205..b275607b8111 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -40,6 +40,36 @@ static const struct cedrus_control cedrus_controls[] = {
> .codec = CEDRUS_CODEC_MPEG2,
> .required = false,
> },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS,
> + .elem_size = sizeof(struct
v4l2_ctrl_h264_decode_param),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_slice_param),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_SPS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_sps),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_PPS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_pps),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX,
> + .elem_size = sizeof(struct
v4l2_ctrl_h264_scaling_matrix),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> };
>
> #define CEDRUS_CONTROLS_COUNTARRAY_SIZE(cedrus_controls)
> @@ -278,6 +308,7 @@ static int cedrus_probe(struct platform_device *pdev)
> }
>
> dev->dec_ops[CEDRUS_CODEC_MPEG2] = _dec_ops_mpeg2;
> + dev->dec_ops[CEDRUS_CODEC_H264] = _dec_ops_h264;
>
> mutex_init(>dev_mutex);
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> 4aedd24a9848..8c64f9a27e9d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -30,7 +30,7 @@
>
> enum cedrus_codec {
> CEDRUS_CODEC_MPEG2,
> -
> + CEDRUS_CODEC_H264,
> CEDRUS_CODEC_LAST,
> };
>
> @@ -40,6 +40,12 @@ enum cedrus_irq_status {
> CEDRUS_IRQ_OK,
> };
>
> +enum cedrus_h264_pic_type {
> + CEDRUS_H264_PIC_TYPE_FRAME = 0,
> + CEDRUS_H264_PIC_TYPE_FIELD,
> + CEDRUS_H264_PIC_TYPE_MBAFF,
> +};
> +
> struct cedrus_control {
> u32 id;
> u32 elem_size;
> @@ -47,6 +53,14 @@ struct cedrus_control {
> unsigned char required:1;
> };
>
> +struct cedrus_h264_run {
> + const struct v4l2_ctrl_h264_decode_param*decode_param;
> + const struct v4l2_ctrl_h264_pps *pps;
> + const struct v4l2_ctrl_h264_scaling_matrix *scaling_matrix;
> + const struct v4l2_ctrl_h264_slice_param *slice_param;
> + const struct v4l2_ctrl_h264_sps *sps;
> +};
> +
> struct cedrus_mpeg2_run {
> const struct v4l2_ctrl_mpeg2_slice_params *slice_params;
> const struct v4l2_ctrl_mpeg2_quantization *quantization;
> @@ -57,12 +71,20 @@ struct cedrus_run {
> struct vb2_v4l2_buffer
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a): > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > Currently MP clocks don't consider adjusting parent rate even if they > > > > are allowed to do so. Such behaviour considerably lowers amount of > > > > possible rates, which is very inconvenient when such clock is used for > > > > pixel clock, for example. > > > > > > > > In order to improve the situation, adjusting parent rate is considered > > > > when allowed. > > > > > > > > This code is inspired by clk_divider_bestdiv() function, which does > > > > basically the same thing for different clock type. > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC > > > boards: > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > I'm not familiar with A20. What is interesting is that emmc clocks don't > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any difference. > > > > Can you post content of clk_summary with and without this patch? > > In both cases I booted from FEL with rootfs on sdcard and tried to mount > partition from eMMC to /mnt. With your patch, last step it fails. > > pre-patch working: > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is off?) > > post-patch not working: > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > Also, attached the logs. Thanks. Just one more request. Can you enable debug messages in mmc driver? I'm interested in output of this line: dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", clock, rate); Just wondering what it should be. Best regards, Jernej > > > Best regards, > > Jernej > > > > > $ git bisect log > > > git bisect start > > > # good: [3df407b2a5346db1c48809706ece7a8616c79e0b] mmc: > > > dw_mmc-bluefield: > > > simplify the probe() function git bisect good > > > 3df407b2a5346db1c48809706ece7a8616c79e0b > > > # bad: [00d59fde8532b2d42e80909d2e58678755e04da9] Merge tag 'mmc-v4.21' > > > of > > > git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc git bisect bad > > > 00d59fde8532b2d42e80909d2e58678755e04da9 > > > # good: [01e421feec0817bb3141eaae4c517410d193d440] Merge branch 'fixes' > > > into next git bisect good 01e421feec0817bb3141eaae4c517410d193d440 > > > # bad: [1eefdec18eded41833401cfd64749643ff72e7da] Merge branch > > > 'locking-core-for-linus' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad > > > 1eefdec18eded41833401cfd64749643ff72e7da > > > # good: [eaa76499711535fd64d747cc4ef0d78ab0fd41c6] Merge tag > > > 'mtd/for-4.21' > > > of git://git.infradead.org/linux-mtd git bisect good > > > eaa76499711535fd64d747cc4ef0d78ab0fd41c6 > > > # good: [4e4390ad067a61ce4e7607bd0df31f19a4caa36a] Merge tag > > > 'leds-for-4.21-rc1' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds > > > git > > > bisect good 4e4390ad067a61ce4e7607bd0df31f19a4caa36a > > > # bad: [c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698] Merge > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next git > > > bisect > > > bad c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698 > > > # bad: [e4b99d415c3908581d4703203e1e805f043a3e71] Merge branch > > > 'irq-core-for-linus' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad > > > e4b99d415c3908581d4703203e1e805f043a3e71 > > > # bad: [ffe05540d18013db62c43627836a3638e9a2c7aa] Merge branches > > > 'clk-renesas', 'clk-allwinner', 'clk-tegra', 'clk-meson' and > > > 'clk-rockchip' > > > into clk-next git bisect bad ffe05540d18013db62c43627836a3638e9a2c7aa > > > # good: [1a501c8defe950571316d5ddd917bf44f5ed7bd4] Merge branches > > > 'clk-managed-registration', 'clk-spdx', 'clk-remove-basic' and > > > 'clk-ops-const' into clk-next git bisect good > > > 1a501c8defe950571316d5ddd917bf44f5ed7bd4 > > > # good: [e74581b79ddd9b49b8c61e2791fc4dffc0245afb] Merge tag > > > 'meson-clk-4.21-2'
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a): > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote: > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a): > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > > > Currently MP clocks don't consider adjusting parent rate even if > > > > > > they > > > > > > are allowed to do so. Such behaviour considerably lowers amount of > > > > > > possible rates, which is very inconvenient when such clock is used > > > > > > for > > > > > > pixel clock, for example. > > > > > > > > > > > > In order to improve the situation, adjusting parent rate is > > > > > > considered > > > > > > when allowed. > > > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, which > > > > > > does > > > > > > basically the same thing for different clock type. > > > > > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC > > > > > boards: > > > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > > > I'm not familiar with A20. What is interesting is that emmc clocks > > > > don't > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any > > > > difference. > > > > > > > > Can you post content of clk_summary with and without this patch? > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to mount > > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > > > pre-patch working: > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is > > > off?) > > > > > > post-patch not working: > > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > > > Also, attached the logs. > > > > Thanks. Just one more request. Can you enable debug messages in mmc > > driver? > > I'm interested in output of this line: > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > > > > clock, rate); > > 1c11000 is eMMC: > [snip] > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to 5200, > rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to > 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc: setting > clk to 5200, rounded 5200 [8.755345] sunxi-mmc 1c11000.mmc: > setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc > 1c11000.mmc: setting clk to 5200, rounded 5200 > > Here I tried to mount partition from eMMC... > > [ 72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > 5200 [ 72.269629] sunxi-mmc 1c11000.mmc: data error, sending stop > command [ 73.268999] sunxi-mmc 1c11000.mmc: send stop command failed > [/snip] > > And clock tree: > [snip] > pll-periph-base330 12 0 > 0 5 pll-periph 660 6 >0 0 5 mmc2 3305000 > 0 0 5 mmc2_sample 110 > 5000
Re: [PATCH 1/3] media: dt: bindings: sunxi-ir: Add A64 compatible
Dne ponedeljek, 21. januar 2019 ob 10:57:57 CET je Chen-Yu Tsai napisal(a): > On Mon, Jan 21, 2019 at 5:50 PM Maxime Ripard wrote: > > Hi, > > > > I'm a bit late to the party, sorry for that. > > > > On Sat, Jan 12, 2019 at 09:56:11AM +0800, Chen-Yu Tsai wrote: > > > On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec wrote: > > > > A64 IR is compatible with A13, so add A64 compatible with A13 as a > > > > fallback. > > > > > > We ask people to add the SoC-specific compatible as a contigency, > > > in case things turn out to be not so "compatible". > > > > > > To be consistent with all the other SoCs and other peripherals, > > > unless you already spotted a "compatible" difference in the > > > hardware, i.e. the hardware isn't completely the same, this > > > patch isn't needed. On the other hand, if you did, please mention > > > the differences in the commit log. > > > > Even if we don't spot things, since we have the stable DT now, if we > > ever had that compatible in the DT from day 1, it's much easier to > > deal with. > > > > I'd really like to have that pattern for all the IPs even if we didn't > > spot any issue, since we can't really say that the datasheet are > > complete, and one can always make a mistake and overlook something. > > > > I'm fine with this version, and can apply it as is if we all agree. > > I'm OK with having the fallback compatible. I'm just pointing out > that there are and will be a whole bunch of them, and we don't need > to document all of them unless we are actually doing something to > support them. > > On the other hand, the compatible string situation for IR needs a > bit of cleaning up at the moment. Right now we have sun4i-a10 and > sun5i-a13. As Jernej pointed out, the A13's register definition is > different from A64 (or any other SoCs later than sun6i). So we need > someone with an A10s/A13 device that has IR to test it and see if > the driver or the manual is wrong, and we'd likely add a compatible > for the A20. > > Also, the earlier SoCs (A10/sun5i/A20) have IR TX capability. This > was lost in A31, and also all of sun8i / sun50i. So we're going to > need to add an A31 compatible that all later platforms would need > to switch to. Actually, A13 also doesn't have IR TX capability. So I still think it's best having A13 compatible as a fallback and not A31. Unless A31 was released before A13? Best regards, Jernej
