Re: [PATCH 1/4] dt-bindings: iio: light: stk33xx: add regulator for vdd supply
Dne nedelja, 14. april 2024 ob 19:57:13 GMT +2 je Aren Moynihan napisal(a): > Signed-off-by: Aren Moynihan Commit message cannot be empty. Best regards, Jernej > --- > Documentation/devicetree/bindings/iio/light/stk33xx.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > index f6e22dc9814a..db35e239d4a8 100644 > --- a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > +++ b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > @@ -29,6 +29,7 @@ properties: >interrupts: > maxItems: 1 > > + vdd-supply: true >proximity-near-level: true > > required: >
Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver
CC Hans Verkuil Dne petek, 16. april 2021 ob 13:38:59 CEST je Neil Armstrong napisal(a): > On 16/04/2021 11:58, Laurent Pinchart wrote: > > Hi Neil, > > > > On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: > >> This adds DW-HDMI driver a glue option to disable loading of the CEC > >> sub-driver. > >> > >> On some SoCs, the CEC functionality is enabled in the IP config bits, but > >> the CEC bus is non-functional like on Amlogic SoCs, where the CEC config > >> bit is set but the DW-HDMI CEC signal is not connected to a physical > >> pin, leading to some confusion when the DW-HDMI CEC controller can't > >> communicate on the bus.> > > If we can't trust the CEC config bit, would it be better to not use it > > at all, and instead let each platform glue logic tell whether to enable > > CEC or not ? > > Actually, the CEC config bit is right, the HW exists and should be > functional, but this bit doesn't tell if the CEC signal is connected to > something. I'm in favour of Neil's solution. Currently we have only one exception. > > This lies in the IP integration, like other bits under the > "amlogic,meson-*-dw-hdmi" umbrella. > > The first attempt was by Hans using DT, but adding a property in DT for a > vendor specific compatible doesn't make sense. Another idea would be to > describe the CEC signal endpoint like we do for video signal, but I think > this is out of scope and this solution is much simpler and straightforward, > and it's more an exception than a general use case to solve. Note that we still need DT property for disabling CEC. I have one Allwinner H3 board where board designer decided to use GPIO CEC implementation instead of DW HDMI one (vendor Linux doesn't implement DW HDMI CEC driver). Other H3 boards happily use DW HDMI CEC. Best regards, Jernej > > Neil > > >> Jernej Skrabec (1): > >> drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC > >> > >> driver > >> > >> Neil Armstrong (1): > >> drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver > >> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > >> drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + > >> include/drm/bridge/dw_hdmi.h | 2 ++ > >> 3 files changed, 4 insertions(+), 1 deletion(-)
Re: [PATCH 4/8] iommu/sun50i: Fix spelling mistake "consits" -> "consists"
Hi! Dne petek, 26. marec 2021 ob 07:24:08 CEST je Zhen Lei napisal(a): > There is a spelling mistake in a comment, fix it. > > Signed-off-by: Zhen Lei > --- > drivers/iommu/sun50i-iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH -next] media: sun8i: Fix PM reference leak in deinterlace_start_streaming()
Dne četrtek, 08. april 2021 ob 15:36:30 CEST je Lu Jialin napisal(a): > > pm_runtime_get_sync will increment pm usage counter even it failed. > Forgetting to putting operation will result in reference leak here. > Fix it by replacing it with pm_runtime_resume_and_get to keep usage > counter balanced. > > Reported-by: Hulk Robot > Signed-off-by: Lu Jialin Acked-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH -next] media: sunxi: sun8i-rotate: fix PM reference leak in rotate_start_streaming()
Dne petek, 09. april 2021 ob 08:46:58 CEST je Xiang Yang napisal(a): > pm_runtime_get_sync will increment pm usage counter even it failed. > Forgetting to putting operation will result in reference leak here. > Fix it by replacing it with pm_runtime_resume_and_get to keep usage > counter balanced. > > Reported-by: Hulk Robot > Signed-off-by: Xiang Yang Acked-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 4/5] arm64: dts: allwinner: Add sun4i MMIO timer nodes
Hi!
Dne ponedeljek, 15. marec 2021 ob 05:32:49 CET je Samuel Holland napisal(a):
> For a CPU to enter an idle state, there must be some timer which can
> trigger an IRQ to wake it back up. The local ARM architectural timer is
> not sufficient, because that timer stops when the CPU is powered down.
> Some other CPU's ARM architectural timer can be used, but this prevents
> that other CPU from entering an idle state. So to allow all CPUs to
> enter an idle state at the same time, some MMIO timer must be available
> that is not tied to any CPU.
>
> The basic "sun4i" timer seems most appropriate for this purpose due to
> its moderate rate, balancing precision and power consumption.
>
> Signed-off-by: Samuel Holland
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +
> 3 files changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> 33df866f6ea9..64e8b4a372cc 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -905,6 +905,15 @@ uart4_rts_cts_pins: uart4-rts-cts-pins {
> };
> };
>
> + timer@1c20c00 {
> + compatible = "allwinner,sun50i-a64-timer",
> + "allwinner,sun8i-a23-timer";
> + reg = <0x01c20c00 0xa0>;
> + interrupts = ,
> + ;
> + clocks = <&osc24M>;
> + };
> +
> wdt0: watchdog@1c20ca0 {
> compatible = "allwinner,sun50i-a64-wdt",
>"allwinner,sun6i-a31-wdt";
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index
> 62334054c710..9ba3b30e11fa 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -332,6 +332,15 @@ cpu_speed_grade: cpu-speed-grade@1c {
> };
> };
>
> + timer@3009000 {
> + compatible = "allwinner,sun50i-h6-timer",
> + "allwinner,sun8i-a23-timer";
> + reg = <0x03009000 0xa0>;
> + interrupts = ,
> + ;
> + clocks = <&osc24M>;
> + };
> +
> watchdog: watchdog@30090a0 {
> compatible = "allwinner,sun50i-h6-wdt",
>"allwinner,sun6i-a31-wdt";
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi index
> c277b53f94ea..ff55712ce96e 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
This file does not exist yet upstream.
Best regards,
Jernej
> @@ -128,6 +128,15 @@ ccu: clock@3001000 {
> #reset-cells = <1>;
> };
>
> + timer@3009000 {
> + compatible = "allwinner,sun50i-h616-timer",
> + "allwinner,sun8i-a23-timer";
> + reg = <0x03009000 0xa0>;
> + interrupts = ,
> + ;
> + clocks = <&osc24M>;
> + };
> +
> watchdog: watchdog@30090a0 {
> compatible = "allwinner,sun50i-h616-wdt",
>"allwinner,sun6i-a31-wdt";
Re: Re: [PATCH] ARM: dts: sun8i: h3: beelink-x2: Add power button
Hi!
Dne ponedeljek, 08. marec 2021 ob 14:05:06 CET je Maxime Ripard napisal(a):
> Hi
>
> On Sat, Mar 06, 2021 at 09:36:11PM +0100, Jernej Skrabec wrote:
> > Beelink X2 has power button. Add node for it.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> > arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/
sun8i-h3-beelink-x2.dts
> > index 62b5280ec093..4a2cb072ecf6 100644
> > --- a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> > +++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> > @@ -111,6 +111,17 @@ spdif_out: spdif-out {
> > #sound-dai-cells = <0>;
> > compatible = "linux,spdif-dit";
> > };
> > +
> > + r_gpio_keys {
>
> Underscores are not valid for node names (and will trigger a dtc warning
> when running with W=1).
Unless I'm doing something wrong, I didn't get any warning with "make dtbs
W=1". In fact many H3 boards have a node with this name and not a single
warning is produced with this command for underscores (there are other
warnings though).
Actually, several H3 DT files have nodes like "sound_spdif" or "wifi_pwrseq".
It
seems like warnings are triggered only for children of soc node.
>
> > + compatible = "gpio-keys";
> > +
> > + power {
> > + label = "power";
>
> IIRC the node name is used as a fallback when the label isn't there?
Binding doesn't say anything about what happens if label is missing. Driver
sets generic description "gpio_keys" in such case, which is not something that
we want.
Best regards,
Jernej
>
> Maxime
>
Re: [PATCH] arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices
Hi Chen-Yu,
Dne ponedeljek, 01. marec 2021 ob 17:23:09 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The macros for the clock and reset indices for the RSB hardware block
> were replaced with raw numbers when the RSB controller node was added.
> This was done to avoid cross-tree dependencies.
>
> Now that both the clk and DT changes have been merged, we can switch
> back to using the macros.
>
> Fixes: aaad900757a6 ("arm64: dts: allwinner: h6: Add RSB controller node")
> Signed-off-by: Chen-Yu Tsai
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
Re: Re: Re: [PATCH v3 1/9] media: hevc: Modify structures to follow H265 ITU spec
Dne četrtek, 25. februar 2021 ob 18:34:48 CET je Ezequiel Garcia napisal(a): > Hey Jernej, > > On Thu, 2021-02-25 at 18:01 +0100, Jernej Škrabec wrote: > > Hi Ezequiel, > > > > Dne četrtek, 25. februar 2021 ob 14:09:52 CET je Ezequiel Garcia napisal(a): > > > Hi Benjamin, > > > > > > Thanks for the good work. > > > > > > On Mon, 2021-02-22 at 13:23 +0100, Benjamin Gaignard wrote: > > > > The H.265 ITU specification (section 7.4) define the general > > > > slice segment header semantics. > > > > Modified/added fields are: > > > > - video_parameter_set_id: (7.4.3.1) identifies the VPS for > > > > reference by other syntax elements. > > > > - seq_parameter_set_id: (7.4.3.2.1) specifies the value of > > > > the vps_video_parameter_set_id of the active VPS. > > > > - chroma_format_idc: (7.4.3.2.1) specifies the chroma sampling > > > > relative to the luma sampling > > > > - pic_parameter_set_id: (7.4.3.3.1) identifies the PPS for > > > > reference by other syntax elements > > > > - num_ref_idx_l0_default_active_minus1: (7.4.3.3.1) specifies > > > > the inferred value of num_ref_idx_l0_active_minus1 > > > > - num_ref_idx_l1_default_active_minus1: (7.4.3.3.1) specifies > > > > the inferred value of num_ref_idx_l1_active_minus1 > > > > - slice_segment_addr: (7.4.7.1) specifies the address of > > > > the first coding tree block in the slice segment > > > > - num_entry_point_offsets: (7.4.7.1) specifies the number of > > > > entry_point_offset_minus1[ i ] syntax elements in the slice header > > > > > > > > Add HEVC decode params contains the information used in section > > > > "8.3 Slice decoding process" of the specification to let the hardware > > > > perform decoding of a slices. > > > > > > > > Adapt Cedrus driver according to these changes. > > > > > > > > Signed-off-by: Benjamin Gaignard > > > > --- > > > > version 3: > > > > - Add documentation about the new structuers and fields. > > > > > > > > version 2: > > > > - remove all change related to scaling > > > > - squash commits to a coherent split > > > > - be more verbose about the added fields > > > > > > > > .../media/v4l/ext-ctrls-codec.rst | 126 ++ +--- > > > > .../media/v4l/vidioc-queryctrl.rst| 6 + > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 26 +++- > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 6 + > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 + > > > > .../staging/media/sunxi/cedrus/cedrus_h265.c | 6 +- > > > > include/media/hevc-ctrls.h| 45 +-- > > > > 8 files changed, 186 insertions(+), 32 deletions(-) > > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/ > > Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > index 00944e97d638..5e6d77e858c0 100644 > > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > @@ -3109,6 +3109,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > > > :stub-columns: 0 > > > > :widths: 1 1 2 > > > > > > > > +* - __u8 > > > > + - ``video_parameter_set_id`` > > > > + - Identifies the VPS for reference by other syntax elements > > > > +* - __u8 > > > > + - ``seq_parameter_set_id̀`` > > > > + - Specifies the value of the vps_video_parameter_set_id of the > > active VPS > > > > +* - __u8 > > > > + - ``chroma_format_idc`` > > > > + - Specifies the chroma sampling relative to the luma sampling > > > > > > None of these fields seem needed for the Hantro G2 driver, > > > so I suggest you drop them for now. > > > > > > > * - __u16 > > > >- ``pic_width_in_luma_samples`` > > > >- > > > > @@ -3172,6 +3181,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > > > * - __u8 > > > >- ``chroma_format_idc`` > > > >- > > > &g
Re: Re: [PATCH v3 1/9] media: hevc: Modify structures to follow H265 ITU spec
Hi Ezequiel, Dne četrtek, 25. februar 2021 ob 14:09:52 CET je Ezequiel Garcia napisal(a): > Hi Benjamin, > > Thanks for the good work. > > On Mon, 2021-02-22 at 13:23 +0100, Benjamin Gaignard wrote: > > The H.265 ITU specification (section 7.4) define the general > > slice segment header semantics. > > Modified/added fields are: > > - video_parameter_set_id: (7.4.3.1) identifies the VPS for > > reference by other syntax elements. > > - seq_parameter_set_id: (7.4.3.2.1) specifies the value of > > the vps_video_parameter_set_id of the active VPS. > > - chroma_format_idc: (7.4.3.2.1) specifies the chroma sampling > > relative to the luma sampling > > - pic_parameter_set_id: (7.4.3.3.1) identifies the PPS for > > reference by other syntax elements > > - num_ref_idx_l0_default_active_minus1: (7.4.3.3.1) specifies > > the inferred value of num_ref_idx_l0_active_minus1 > > - num_ref_idx_l1_default_active_minus1: (7.4.3.3.1) specifies > > the inferred value of num_ref_idx_l1_active_minus1 > > - slice_segment_addr: (7.4.7.1) specifies the address of > > the first coding tree block in the slice segment > > - num_entry_point_offsets: (7.4.7.1) specifies the number of > > entry_point_offset_minus1[ i ] syntax elements in the slice header > > > > Add HEVC decode params contains the information used in section > > "8.3 Slice decoding process" of the specification to let the hardware > > perform decoding of a slices. > > > > Adapt Cedrus driver according to these changes. > > > > Signed-off-by: Benjamin Gaignard > > --- > > version 3: > > - Add documentation about the new structuers and fields. > > > > version 2: > > - remove all change related to scaling > > - squash commits to a coherent split > > - be more verbose about the added fields > > > > .../media/v4l/ext-ctrls-codec.rst | 126 +++--- > > .../media/v4l/vidioc-queryctrl.rst| 6 + > > drivers/media/v4l2-core/v4l2-ctrls.c | 26 +++- > > drivers/staging/media/sunxi/cedrus/cedrus.c | 6 + > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 + > > .../staging/media/sunxi/cedrus/cedrus_h265.c | 6 +- > > include/media/hevc-ctrls.h| 45 +-- > > 8 files changed, 186 insertions(+), 32 deletions(-) > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/ Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > index 00944e97d638..5e6d77e858c0 100644 > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > @@ -3109,6 +3109,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > :stub-columns: 0 > > :widths: 1 1 2 > > > > +* - __u8 > > + - ``video_parameter_set_id`` > > + - Identifies the VPS for reference by other syntax elements > > +* - __u8 > > + - ``seq_parameter_set_id̀`` > > + - Specifies the value of the vps_video_parameter_set_id of the active VPS > > +* - __u8 > > + - ``chroma_format_idc`` > > + - Specifies the chroma sampling relative to the luma sampling > > None of these fields seem needed for the Hantro G2 driver, > so I suggest you drop them for now. > > > * - __u16 > >- ``pic_width_in_luma_samples`` > >- > > @@ -3172,6 +3181,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > * - __u8 > >- ``chroma_format_idc`` > >- > > +* - __u8 > > + - ``num_slices`` > > + > > Not used, but also doesn't seem part of the SPS syntax. If we have to > pass the number of slices, we'll need another mechanism. > > > - > > * - __u64 > >- ``flags`` > >- See :ref:`Sequence Parameter Set Flags ` > > @@ -3231,9 +3243,18 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > :stub-columns: 0 > > :widths: 1 1 2 > > > > +* - __u8 > > + - ``pic_parameter_set_id`` > > + - Identifies the PPS for reference by other syntax elements > > Not used. > > > * - __u8 > >- ``num_extra_slice_header_bits`` > >- > > +* - __u8 > > + - ``num_ref_idx_l0_default_active_minus1`` > > + - Specifies the inferred value of num_ref_idx_l0_active_minus1 > > +* - __u8 > > + - ``num_ref_idx_l1_default_active_minus1`` > > + - Specifies the inferred value of num_ref_idx_l1_active_minus1 > > * - __s8 > >- ``init_qp_minus26`` > >- > > @@ -3342,6 +3363,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT`` > >- 0x0004 > >- > > +* - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT`` > > + - 0x0008 > > + - > > +* - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING`` > > + - 0x0010 > > + - > > > > I suggest to do all the PPS control changes in a separate patch, > feels easier to review
Re: [PATCH v2 1/9] media: hevc: Modify structures to follow H265 ITU spec
Hi!
Dne četrtek, 18. februar 2021 ob 20:18:36 CET je Benjamin Gaignard napisal(a):
> The H.265 ITU specification (section 7.4) define the general
> slice segment header semantics.
> Modified/added fields are:
> - video_parameter_set_id: (7.4.3.1) identifies the VPS for
> reference by other syntax elements.
> - seq_parameter_set_id: (7.4.3.2.1) specifies the value of
> the vps_video_parameter_set_id of the active VPS.
> - chroma_format_idc: (7.4.3.2.1) specifies the chroma sampling
> relative to the luma sampling
> - pic_parameter_set_id: (7.4.3.3.1) identifies the PPS for
> reference by other syntax elements
> - num_ref_idx_l0_default_active_minus1: (7.4.3.3.1) specifies
> the inferred value of num_ref_idx_l0_active_minus1
> - num_ref_idx_l1_default_active_minus1: (7.4.3.3.1) specifies
> the inferred value of num_ref_idx_l1_active_minus1
> - slice_segment_addr: (7.4.7.1) specifies the address of
> the first coding tree block in the slice segment
> - num_entry_point_offsets: (7.4.7.1) specifies the number of
> entry_point_offset_minus1[ i ] syntax elements in the slice header
>
> Add HEVC decode params contains the information used in section
> "8.3 Slice decoding process" of the specification to let the hardware
> perform decoding of a slices.
>
> Adapt Cedrus driver according to these changes.
>
> Signed-off-by: Benjamin Gaignard
> ---
> version 2:
> - remove all change related to scaling
> - squash commits to a coherent split
> - be more verbose about the added fields
>
> drivers/media/v4l2-core/v4l2-ctrls.c | 26 ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 6 +++
> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 +
> .../staging/media/sunxi/cedrus/cedrus_h265.c | 6 ++-
> include/media/hevc-ctrls.h| 45 +++
> 6 files changed, 69 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/
v4l2-ctrls.c
> index 016cf6204cbb..4060b5bcc3c0 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1028,6 +1028,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_HEVC_SPS:
return "HEVC Sequence Parameter Set";
> case V4L2_CID_MPEG_VIDEO_HEVC_PPS:
return "HEVC Picture Parameter Set";
> case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS: return
"HEVC Slice Parameters";
> + case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
return "HEVC Decode Parameters";
> case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE: return "HEVC
Decode Mode";
> case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE: return
"HEVC Start Code";
>
> @@ -1482,6 +1483,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
> case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
> *type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
> break;
> + case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
> + *type = V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS;
> + break;
> case V4L2_CID_UNIT_CELL_SIZE:
> *type = V4L2_CTRL_TYPE_AREA;
> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> @@ -1833,6 +1837,7 @@ static int std_validate_compound(const struct
v4l2_ctrl *ctrl, u32 idx,
> struct v4l2_ctrl_hevc_sps *p_hevc_sps;
> struct v4l2_ctrl_hevc_pps *p_hevc_pps;
> struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
> + struct v4l2_ctrl_hevc_decode_params *p_hevc_decode_params;
> struct v4l2_area *area;
> void *p = ptr.p + idx * ctrl->elem_size;
> unsigned int i;
> @@ -2108,23 +2113,27 @@ static int std_validate_compound(const struct
v4l2_ctrl *ctrl, u32 idx,
> zero_padding(*p_hevc_pps);
> break;
>
> - case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
> - p_hevc_slice_params = p;
> + case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
> + p_hevc_decode_params = p;
>
> - if (p_hevc_slice_params->num_active_dpb_entries >
> + if (p_hevc_decode_params->num_active_dpb_entries >
> V4L2_HEVC_DPB_ENTRIES_NUM_MAX)
> return -EINVAL;
>
> - zero_padding(p_hevc_slice_params->pred_weight_table);
> -
> - for (i = 0; i < p_hevc_slice_params-
>num_active_dpb_entries;
> + for (i = 0; i < p_hevc_decode_params-
>num_active_dpb_entries;
>i++) {
> struct v4l2_hevc_dpb_entry *dpb_entry =
> - &p_hevc_slice_params->dpb[i];
> + &p_hevc_decode_params->dpb[i];
>
> zero_padding(*dpb_entry);
> }
>
> + break;
> +
> + case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
> + p_hevc_slice_params = p;
> +
> + zero_padding(p_hevc_slice_pa
Re: [PATCH v2 4/9] media: uapi: Add a control for HANTRO driver
Hi!
Dne četrtek, 18. februar 2021 ob 20:18:39 CET je Benjamin Gaignard napisal(a):
> The HEVC HANTRO driver needs to know the number of bits to skip at
> the beginning of the slice header.
> That is a hardware specific requirement so create a dedicated control
> that this purpose.
>
> Signed-off-by: Benjamin Gaignard
> ---
> include/uapi/linux/hantro-v4l2-controls.h | 20
> include/uapi/linux/v4l2-controls.h| 5 +
> 2 files changed, 25 insertions(+)
> create mode 100644 include/uapi/linux/hantro-v4l2-controls.h
>
> diff --git a/include/uapi/linux/hantro-v4l2-controls.h b/include/uapi/linux/
hantro-v4l2-controls.h
> new file mode 100644
> index ..30b1999b7af3
> --- /dev/null
> +++ b/include/uapi/linux/hantro-v4l2-controls.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +
> +#ifndef __UAPI_HANTRO_V4L2_CONYTROLS_H__
> +#define __UAPI_HANTRO_V4L2_CONYTROLS_H__
> +
> +#include
> +#include
> +
> +#define V4L2_CID_HANTRO_HEVC_EXTRA_DECODE_PARAMS
(V4L2_CID_USER_HANTRO_BASE + 0)
> +
> +/**
> + * struct hantro_hevc_extra_decode_params - extra decode parameters for
hantro driver
> + * @hevc_hdr_skip_lenght:header first bits offset
> + */
> +struct hantro_hevc_extra_decode_params {
> + __u32 hevc_hdr_skip_lenght;
typo: lenght -> length
Same mistake in description above.
Best regards,
Jernej
> + __u8padding[4];
> +};
> +
> +#endif
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-
controls.h
> index 039c0d7add1b..ced7486c7f46 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -209,6 +209,11 @@ enum v4l2_colorfx {
> * We reserve 128 controls for this driver.
> */
> #define V4L2_CID_USER_CCS_BASE (V4L2_CID_USER_BASE +
0x10f0)
> +/*
> + * The base for HANTRO driver controls.
> + * We reserve 32 controls for this driver.
> + */
> +#define V4L2_CID_USER_HANTRO_BASE(V4L2_CID_USER_BASE +
0x1170)
>
> /* MPEG-class control IDs */
> /* The MPEG controls are applicable to all codec controls
> --
> 2.25.1
>
>
Re: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix Ethernet PHY mode
Hi! Let me first explain that it was oversight on my side not noticing initials in your SoB tag. But since the issue was raised by Maxime, I didn't follow up. Dne sobota, 13. februar 2021 ob 07:51:32 CET je B.R. Oake napisal(a): > On Wed Feb 10 at 16:01:18 CET 2021, Maxime Ripard wrote: > > Unfortunately we can't take this patch as is, this needs to be your real > > name, see: > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#de > > veloper-s-certificate-of-origin-1-1 > Dear Maxime, > > Thank you very much for considering my contribution and for all your > work on supporting sunxi-based hardware; I appreciate it. > > Thank you for referring me to the Developer's Certificate of Origin, but > I had already read it before submitting (I had to do so in order to know > what I was saying by "Signed-off-by:") and I do certify what it says. > > Looking through recent entries in the commit log of the mainline kernel, > I see several patches from authors such as: > > H.J. Lu > B K Karthik > JC Kuo > EJ Hsu > LH Lin > KP Singh > Karthik B S > Shreyas NC > Vandana BN > > so I believe names of this form are in fact acceptable, even if the > style might seem a little old-fashioned to some. Speaking generally, not only for this case, prior art arguments rarely hold, because: - it might be oversight, - it might be a bad practice, which should not be followed in new contributions, - different maintainers have different point of view on same thing, - maintainer wants to adapt new practice or steer subsystem in new direction > > I would like to add that I have met many people with names such as C.J., > A A, TC, MG, etc. That is what everybody calls them and it would be > natural for them to sign themselves that way. Some of them might want to > contribute to Linux some day, and I think it would be a great shame and > a loss to all of us if they were discouraged from doing so by reading > our conversation in the archives and concluding that any contribution > from them, however small, would be summarily refused simply because of > their name. Please could you ensure that does not happen? The link you posted says following: "using your real name (sorry, no pseudonyms or anonymous contributions.)" I believe that real name means no initials, no matter what people are accustomed to. From my point of view, CJ is pseudonym derived from real name. This is not the first time that fix of SoB tag was requested, you can find such requests in ML archives. Best regards, Jernej > > Thank you again for your consideration. > > Yours sincerely, > B.R. Oake.
Re: [PATCH v3 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
Dne četrtek, 11. februar 2021 ob 03:28:00 CET je Stephen Boyd napisal(a):
> Quoting Maxime Ripard (2021-02-10 02:29:04)
>
> > Hi Mike, Stephen,
> >
> > On Tue, Feb 09, 2021 at 06:58:56PM +0100, Jernej Skrabec wrote:
> > > CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> > > one. Fix that.
> > >
> > > Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> > > allowed") Reviewed-by: Chen-Yu Tsai
> > > Tested-by: Andre Heider
> > > Signed-off-by: Jernej Skrabec
> >
> > This is a last minute fix for us, can you merge it into clk-fixes
> > directly?
> >
> > Acked-by: Maxime Ripard
>
> It's also fixing a problem that's been around since v5.0. Is something
> broken that needs fixing this late? The motivation could be added to the
> commit text because right now it looks like a typo fix spotted visually.
Yes, it's needed. Without this patch, 4k@60 doesn't work and probably some
other resolutions too. That's why it's send with other display related fixes.
This is part of solution for longstanding display issues.
Best regards,
Jernej
Re: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix Ethernet PHY mode
Dne ponedeljek, 08. februar 2021 ob 12:24:57 CET je B.R. Oake napisal(a):
> Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
> delay config"), Ethernet no longer works on the Orange Pi Plus,
> because that commit sets the RX/TX delay according to the phy-mode
> property in the device tree, which is "rgmii", the wrong setting
> for this board.
>
> Following the example of others who fixed the same problem for
> many other boards, this patch changes the phy-mode to "rgmii-id"
> which gets Ethernet working again on this board.
>
> Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
> Fixes: 1dcd0095019a ("ARM: sun8i: orangepi-plus: Enable dwmac-sun8i")
> Signed-off-by: B.R. Oake
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Jernej Skrabec
Thanks!
Best regards,
Jernej
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/
dts/sun8i-h3-orangepi-plus.dts
> index 97f497854e..d05fa679dc 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> @@ -85,7 +85,7 @@
> pinctrl-0 = <&emac_rgmii_pins>;
> phy-supply = <®_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
>
> status = "okay";
> };
> --
> 2.20.1
>
>
Re: Re: [linux-sunxi] [PATCH 4/5] drm/sun4i: Fix H6 HDMI PHY configuration
Dne petek, 05. februar 2021 ob 04:22:56 CET je Chen-Yu Tsai napisal(a):
> On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
wrote:
> >
> > cpce value for 594 MHz is set differently in BSP driver. Fix that.
> >
> > Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
> > Tested-by: Andre Heider
> > Signed-off-by: Jernej Skrabec
>
> Reviewed-by: Chen-Yu Tsai
Thanks, but I figured that this change is not the proper one. It still gives me
issues with my TV. Proper change is to fix current and voltage settings below.
I'll replace this patch in v2.
Best regards,
Jernej
>
> --
> 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/
CAGb2v64BpizczmSJdompGosFwWWayNscWvW-7oARLgwNNo%3DteQ%40mail.gmail.com.
>
Re: Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
wrote:
> > >
> > > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > > sets them. It turns out that with pre-HDMI2 controllers seemingly there
> > > is no issue if polarity is not set. However, with HDMI2 controllers
> > > (H6) there often comes to de-synchronization due to phase shift. This
> > > causes flickering screen. It's safe to assume that similar issues might
> > > happen also with pre-HDMI2 controllers.
> > >
> > > Solve issue with setting vsync and hsync polarity. Note that display
> > > stacks with tcon top have polarity bits actually in tcon0 polarity
> > > register.
> > >
> > > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> > > Tested-by: Andre Heider
> > > Signed-off-by: Jernej Skrabec
> > > ---
> > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > > 2 files changed, 29 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/
sun4i_tcon.c
> > > index 6b9af4c08cd6..0d132dae58c0 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon
*tcon,
> > > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> > >
> > > + /* Setup the polarity of sync signals */
> > > + if (tcon->quirks->polarity_in_ch0) {
> > > + val = 0;
> > > +
> > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > > +
> > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > > +
> > > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> > > + } else {
> > > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
> >
> > I think a comment for the origin of this is warranted.
>
> If it's anything like TCON0, it's the pixel clock polarity
Hard to say, DW HDMI controller has "data enable" polarity along hsync and
vsync. It could be either or none of those.
What should I write in comment? BSP drivers and documentation use only generic
names like io2_inv.
Best regards,
Jernej
Re: Re: Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
Dne petek, 05. februar 2021 ob 17:28:23 CET je Chen-Yu Tsai napisal(a):
> On Sat, Feb 6, 2021 at 12:21 AM Jernej Škrabec
wrote:
> >
> > Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> > > On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
> > wrote:
> > > > >
> > > > > Channel 1 has polarity bits for vsync and hsync signals but driver
never
> > > > > sets them. It turns out that with pre-HDMI2 controllers seemingly
there
> > > > > is no issue if polarity is not set. However, with HDMI2 controllers
> > > > > (H6) there often comes to de-synchronization due to phase shift.
This
> > > > > causes flickering screen. It's safe to assume that similar issues
might
> > > > > happen also with pre-HDMI2 controllers.
> > > > >
> > > > > Solve issue with setting vsync and hsync polarity. Note that display
> > > > > stacks with tcon top have polarity bits actually in tcon0 polarity
> > > > > register.
> > > > >
> > > > > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine
support")
> > > > > Tested-by: Andre Heider
> > > > > Signed-off-by: Jernej Skrabec
> > > > > ---
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > > > > 2 files changed, 29 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/
sun4i/
> > sun4i_tcon.c
> > > > > index 6b9af4c08cd6..0d132dae58c0 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct
sun4i_tcon
> > *tcon,
> > > > > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > > > > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> > > > >
> > > > > + /* Setup the polarity of sync signals */
> > > > > + if (tcon->quirks->polarity_in_ch0) {
> > > > > + val = 0;
> > > > > +
> > > > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > > > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > > > > +
> > > > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > > > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > > > > +
> > > > > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG,
val);
> > > > > + } else {
> > > > > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
> > > >
> > > > I think a comment for the origin of this is warranted.
> > >
> > > If it's anything like TCON0, it's the pixel clock polarity
> >
> > Hard to say, DW HDMI controller has "data enable" polarity along hsync and
> > vsync. It could be either or none of those.
> >
> > What should I write in comment? BSP drivers and documentation use only
generic
> > names like io2_inv.
>
> Just say that we don't know exactly what it is, but it is required for
things
> to work properly? Would be interesting to know what happens if you don't set
> this bit, but do set VSYNC/HSYNC polarity properly.
Nothing seems to happen - tested on H3 with HDMI (4k@30) and CVBS. At least I
didn't notice anything.
Best regards,
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: [PATCH v2] ARM: dts: sun7i: a20: bananapro: Fix ethernet node
Dne četrtek, 21. januar 2021 ob 18:08:36 CET je Hermann Lauer napisal(a): > BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high > packet loss rates. The realtek phy driver overrides the settings of the > pull ups for the delays, so fix this for Banana Pro. > > Signed-off-by: Hermann Lauer Much better. Now the only thing missing is "Fixes" tag, which references commit which introduced the issue. Probably this will be the commit which added ethernet node. This tag is important for deciding which commits should be backported to stable releases. Take a look in v1 for M2U fixes tag. Btw, each version should have changelog under "---" line, so maintainers and reviewers know what changed. Best regards, Jernej
Re: [PATCH 1/2] drm/sun4i: tcon: fix inverted DCLK polarity
Dne sreda, 06. januar 2021 ob 20:27:59 CET je Giulio Benetti napisal(a): > During commit "88bc4178568b8e0331143cc0616640ab72f0cba1" DRM_BUS_FLAG_* Please use same commit referencing approach as for "Fixes" tag. > macros have been changed to avoid ambiguity but just because of this > ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning > _SAMPLE_ not _DRIVE_. This lead to DLCK inversion, so let's swap DCLK > phase to fix it. > Add Fixes tag here. Best regards, Jernej > Signed-off-by: Giulio Benetti > --- > drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/ sun4i_tcon.c > index eaaf5d70e352..52598bb0fb0b 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > @@ -585,10 +585,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, >* and DOTCLOCK drivers. >*/ > if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE) > - clk_set_phase(tcon->dclk, 240); > + clk_set_phase(tcon->dclk, 0); > > if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) > - clk_set_phase(tcon->dclk, 0); > + clk_set_phase(tcon->dclk, 240); > > regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG, > SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | > -- > 2.25.1 > >
Re: [PATCH v3] drm/sun4i: de2: Reimplement plane z position setting logic
Dne sreda, 06. januar 2021 ob 21:46:30 CET je Jernej Skrabec napisal(a):
> From: Roman Stratiienko
>
> To set blending channel order register software needs to know state and
> position of each channel, which impossible at plane commit stage.
>
> Move this procedure to atomic_flush stage, where all necessary information
> is available.
>
> Fixes: f88c5ee77496 ("drm/sun4i: Implement zpos for DE2")
> Fixes: d8b3f454dab4 ("drm/sun4i: sun8i: Avoid clearing blending order at
each atomic commit")
> Signed-off-by: Roman Stratiienko
> [rebased, addressed comments]
> Signed-off-by: Jernej Skrabec
> ---
Forgot to include changelog:
This is update of:
https://patchwork.kernel.org/project/dri-devel/patch/20191229162828.3326-1-roman.stratiie...@globallogic.com/
with addressed comments.
Changes from v2:
- renamed SUN8I_MIXER_MAX_LAYERS to SUN8I_MIXER_MAX_CHANNELS
- removed unused variable in sun8i_vi_layer_enable()
- renamed and reordered variables in sun8i_mixer_commit()
- removed route allocation for disabled channels
- write SUN8I_MIXER_BLEND_PIPE_CTL reg only in commit hook
- added fixed tags
Best regards,
Jernej
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 57 +-
> drivers/gpu/drm/sun4i/sun8i_mixer.h| 5 +++
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 42 +++
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 42 +++
> 4 files changed, 64 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/
sun8i_mixer.c
> index 5b42cf25cc86..d2153b10b08d 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -250,6 +250,50 @@ int sun8i_mixer_drm_format_to_hw(u32 format, u32
*hw_format)
>
> static void sun8i_mixer_commit(struct sunxi_engine *engine)
> {
> + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> + int channel_by_zpos[SUN8I_MIXER_MAX_CHANNELS];
> + u32 base = sun8i_blender_base(mixer);
> + u32 route = 0, pipe_ctl = 0;
> + unsigned int channel_count;
> + int i, j;
> +
> + channel_count = mixer->cfg->vi_num + mixer->cfg->ui_num;
> +
> + DRM_DEBUG_DRIVER("Update blender routing\n");
> +
> + for (i = 0; i < SUN8I_MIXER_MAX_CHANNELS; i++)
> + channel_by_zpos[i] = -1;
> +
> + for (i = 0; i < channel_count; i++) {
> + int zpos = mixer->channel_zpos[i];
> +
> + if (zpos >= 0 && zpos < channel_count)
> + channel_by_zpos[zpos] = i;
> + }
> +
> + j = 0;
> + for (i = 0; i < channel_count; i++) {
> + int ch = channel_by_zpos[i];
> +
> + if (ch >= 0) {
> + pipe_ctl |= SUN8I_MIXER_BLEND_PIPE_CTL_EN(j);
> + route |= ch <<
SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(j);
> + j++;
> + }
> + }
> +
> + /*
> + * Set fill color of bottom plane to black. Generally not needed
> + * except when VI plane is at bottom (zpos = 0) and enabled.
> + */
> + pipe_ctl |= SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(0);
> +
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_BLEND_PIPE_CTL(base), pipe_ctl);
> +
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_BLEND_ROUTE(base), route);
> +
> DRM_DEBUG_DRIVER("Committing changes\n");
>
> regmap_write(engine->regs, SUN8I_MIXER_GLOBAL_DBUFF,
> @@ -479,23 +523,16 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
> regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR(base),
>SUN8I_MIXER_BLEND_COLOR_BLACK);
>
> - /*
> - * Set fill color of bottom plane to black. Generally not needed
> - * except when VI plane is at bottom (zpos = 0) and enabled.
> - */
> - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL(base),
> - SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(0));
> regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_FCOLOR(base, 0),
>SUN8I_MIXER_BLEND_COLOR_BLACK);
>
> plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
> - for (i = 0; i < plane_cnt; i++)
> + for (i = 0; i < plane_cnt; i++) {
> + mixer->channel_zpos[i] = -1;
> regmap_write(mixer->engine.regs,
>SUN8I_MIXER_BLEND_MODE(base, i),
>SUN8I_MIXER_BLEND_MODE_DEF);
> -
> - regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL(base),
> -SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 0);
> + }
>
> return 0;
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/
sun8i_mixer.h
> index 7576b523fdbb..7b378d6e4dd9 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -12,6 +12,8 @@
>
> #include "sunxi_engine.h"
>
> +#define SUN8I_MIXER_MAX_CHANNELS 5
> +
> #defi
Re: [PATCH RESEND] ARM: configs: sunxi: enable brcm wireless
Hi! Dne nedelja, 27. december 2020 ob 21:00:00 CET je Corentin Labbe napisal(a): > Lot of sunxi boards have BRCM wireless device, so let's enable necessary > options for it in our defconfig. Idea is good but modules (=m) instead of build in (=y) would be better. As you said, not all boards have such wifi and there is no need to make kernel binary bigger. Best regards, Jernej > > Signed-off-by: Corentin Labbe > --- > arch/arm/configs/sunxi_defconfig | 23 ++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/sunxi_defconfig > b/arch/arm/configs/sunxi_defconfig index a60c134c5e04..4891aefdef7d 100644 > --- a/arch/arm/configs/sunxi_defconfig > +++ b/arch/arm/configs/sunxi_defconfig > @@ -52,7 +52,28 @@ CONFIG_STMMAC_ETH=y > # CONFIG_NET_VENDOR_WIZNET is not set > CONFIG_MICREL_PHY=y > CONFIG_REALTEK_PHY=y > -# CONFIG_WLAN is not set > +CONFIG_WLAN=y > +# CONFIG_WLAN_VENDOR_ADMTEK is not set > +# CONFIG_WLAN_VENDOR_ATH is not set > +# CONFIG_WLAN_VENDOR_ATMEL is not set > +CONFIG_WLAN_VENDOR_BROADCOM=y > +# CONFIG_WLAN_VENDOR_CISCO is not set > +# CONFIG_WLAN_VENDOR_INTEL is not set > +# CONFIG_WLAN_VENDOR_INTERSIL is not set > +# CONFIG_WLAN_VENDOR_MARVELL is not set > +# CONFIG_WLAN_VENDOR_MEDIATEK is not set > +# CONFIG_WLAN_VENDOR_MICROCHIP is not set > +# CONFIG_WLAN_VENDOR_RALINK is not set > +# CONFIG_WLAN_VENDOR_REALTEK is not set > +# CONFIG_WLAN_VENDOR_RSI is not set > +# CONFIG_WLAN_VENDOR_ST is not set > +# CONFIG_WLAN_VENDOR_TI is not set > +# CONFIG_WLAN_VENDOR_ZYDAS is not set > +# CONFIG_WLAN_VENDOR_QUANTENNA is not set > +CONFIG_CFG80211=y > +CONFIG_CFG80211_WEXT=y > +CONFIG_MAC80211=y > +CONFIG_BRCMFMAC=y > CONFIG_INPUT_EVDEV=y > CONFIG_KEYBOARD_SUN4I_LRADC=y > # CONFIG_INPUT_MOUSE is not set
Re: [PATCH v2 1/2] dt-bindings: pwm: allwinner: Add V3s compatible description
Hi! Dne petek, 18. december 2020 ob 21:54:35 CET je Paul Kocialkowski napisal(a): > Introduce bindings description for the V3s PWM, which is > register-compatible with the A20 PWM. > > Signed-off-by: Paul Kocialkowski This is meant to be used together with V3s PWM patch you recently send? Can you please resend them together, with fixed compatible in DT node? Currently it's not clear why this patch is needed and PWM patch will need fix anyway. Best regards, Jernej > --- > .../devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml > b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index > 7dcab2bf8128..04ff708fdc86 100644 > --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml > +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml > @@ -24,6 +24,9 @@ properties: >- items: >- const: allwinner,sun8i-a83t-pwm >- const: allwinner,sun8i-h3-pwm > + - items: > + - const: allwinner,sun8i-v3s-pwm > + - const: allwinner,sun7i-a20-pwm >- items: >- const: allwinner,sun50i-a64-pwm >- const: allwinner,sun5i-a13-pwm
Re: [PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition
Hi!
Dne petek, 18. december 2020 ob 20:50:33 CET je Paul Kocialkowski napisal(a):
> This adds a device-tree definition for the CSI0 MCLK pin,
> which can be used for feeding MIPI CSI-2 sensors.
>
> Signed-off-by: Paul Kocialkowski
Is this used anywhere? Current policy is to add pin definitions only if any
user exists.
Best regards,
Jernej
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> b/arch/arm/boot/dts/sun8i-v3s.dtsi index a9f5795d4e57..bff822b9fa01 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -337,6 +337,12 @@ pio: pinctrl@1c20800 {
> interrupt-controller;
> #interrupt-cells = <3>;
>
> + /omit-if-no-ref/
> + csi0_mclk_pin: csi0-mclk-pin {
> + pins = "PE20";
> + function = "csi_mipi";
> + };
> +
> /omit-if-no-ref/
> csi1_8bit_pins: csi1-8bit-pins {
> pins = "PE0", "PE2", "PE3",
"PE8", "PE9",
Re: [linux-sunxi] [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
Dne sreda, 09. december 2020 ob 22:35:51 CET je André Przywara napisal(a):
> On 09/12/2020 14:33, Clément Péron wrote:
>
> Hi,
>
> > I try to review this, and compare against the vendor Kernel>
> >
> > On Wed, 2 Dec 2020 at 14:54, Andre Przywara
wrote:
> >> While the clocks are fairly similar to the H6, many differ in tiny
> >> details, so a separate clock driver seems indicated.
> >>
> >> Derived from the H6 clock driver, and adjusted according to the manual.
> >>
> >> Signed-off-by: Andre Przywara
> >> ---
> >>
> >> drivers/clk/sunxi-ng/Kconfig|7 +-
> >> drivers/clk/sunxi-ng/Makefile |1 +
> >> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 1134 +++
> >> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 58 +
> >> include/dt-bindings/clock/sun50i-h616-ccu.h | 110 ++
> >> include/dt-bindings/reset/sun50i-h616-ccu.h | 67 ++
> >> 6 files changed, 1376 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> >> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> >> create mode 100644 include/dt-bindings/clock/sun50i-h616-ccu.h
> >> create mode 100644 include/dt-bindings/reset/sun50i-h616-ccu.h
> >>
> >> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> >> index ce5f5847d5d3..cd46d8853876 100644
> >> --- a/drivers/clk/sunxi-ng/Kconfig
> >> +++ b/drivers/clk/sunxi-ng/Kconfig
> >> @@ -32,8 +32,13 @@ config SUN50I_H6_CCU
> >>
> >> default ARM64 && ARCH_SUNXI
> >> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> >>
> >> +config SUN50I_H616_CCU
> >> + bool "Support for the Allwinner H616 CCU"
> >> + default ARM64 && ARCH_SUNXI
> >> + depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> >> +
> >>
> >> config SUN50I_H6_R_CCU
> >>
> >> - bool "Support for the Allwinner H6 PRCM CCU"
> >> + bool "Support for the Allwinner H6 and H616 PRCM CCU"
> >>
> >> default ARM64 && ARCH_SUNXI
> >> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> >>
> >> diff --git a/drivers/clk/sunxi-ng/Makefile
> >> b/drivers/clk/sunxi-ng/Makefile
> >> index 3eb5cff40eac..96c324306d97 100644
> >> --- a/drivers/clk/sunxi-ng/Makefile
> >> +++ b/drivers/clk/sunxi-ng/Makefile
> >> @@ -26,6 +26,7 @@ obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
> >>
> >> obj-$(CONFIG_SUN50I_A100_CCU) += ccu-sun50i-a100.o
> >> obj-$(CONFIG_SUN50I_A100_R_CCU)+= ccu-sun50i-a100-r.o
> >> obj-$(CONFIG_SUN50I_H6_CCU)+= ccu-sun50i-h6.o
> >>
> >> +obj-$(CONFIG_SUN50I_H616_CCU) += ccu-sun50i-h616.o
> >>
> >> obj-$(CONFIG_SUN50I_H6_R_CCU) += ccu-sun50i-h6-r.o
> >> obj-$(CONFIG_SUN4I_A10_CCU)+= ccu-sun4i-a10.o
> >> obj-$(CONFIG_SUN5I_CCU)+= ccu-sun5i.o
> >>
> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> >> b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c new file mode 100644
> >> index ..3fbb258f0354
> >> --- /dev/null
> >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> >> @@ -0,0 +1,1134 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (c) 2020 Arm Ltd.
> >> + * Based on the H6 CCU driver, which is:
> >> + * Copyright (c) 2017 Icenowy Zheng
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "ccu_common.h"
> >> +#include "ccu_reset.h"
> >> +
> >> +#include "ccu_div.h"
> >> +#include "ccu_gate.h"
> >> +#include "ccu_mp.h"
> >> +#include "ccu_mult.h"
> >> +#include "ccu_nk.h"
> >> +#include "ccu_nkm.h"
> >> +#include "ccu_nkmp.h"
> >> +#include "ccu_nm.h"
> >> +
> >> +#include "ccu-sun50i-h616.h"
> >> +
> >> +/*
> >> + * The CPU PLL is actually NP clock, with P being /1, /2 or /4. However
> >> + * P should only be used for output frequencies lower than 288 MHz.
> >> + *
> >> + * For now we can just model it as a multiplier clock, and force P to
> >> /1.
> >> + *
> >> + * The M factor is present in the register's description, but not in the
> >> + * frequency formula, and it's documented as "M is only used for
> >> backdoor
> >> + * testing", so it's not modelled and then force to 0.
> >> + */
> >> +#define SUN50I_H616_PLL_CPUX_REG 0x000
> >> +static struct ccu_mult pll_cpux_clk = {
> >> + .enable = BIT(31),
> >> + .lock = BIT(28),
> >> + .mult = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> >> + .common = {
> >> + .reg= 0x000,
> >> + .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
> >> + &ccu_mult_ops,
> >> + CLK_SET_RATE_UNGATE),
> >> + },
> >> +};
> >> +
> >> +/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */
> >> +#define SUN50I_H616_PLL_DDR0_REG 0x010
> >> +static struct ccu_nkmp pll_ddr0_clk = {
> >> + .enable = BIT(31),
> >> + .lock = BIT(28),
> >> + .n = _SUNXI
Re: [linux-sunxi] [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
Dne nedelja, 06. december 2020 ob 13:32:49 CET je Clément Péron napisal(a):
> Hi Andre,
>
> On Wed, 2 Dec 2020 at 14:54, Andre Przywara wrote:
> > Port A is used for an internal connection to some analogue circuitry
> > which looks like an AC200 IP (as in the H6), though this is not
> > mentioned in the manual.
> >
> > Signed-off-by: Andre Przywara
> > ---
> >
> > drivers/pinctrl/sunxi/Kconfig | 5 +
> > drivers/pinctrl/sunxi/Makefile | 1 +
> > drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
> > 3 files changed, 555 insertions(+)
> > create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> >
> > diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> > index 593293584ecc..73e88ce71a48 100644
> > --- a/drivers/pinctrl/sunxi/Kconfig
> > +++ b/drivers/pinctrl/sunxi/Kconfig
> > @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
> >
> > default ARM64 && ARCH_SUNXI
> > select PINCTRL_SUNXI
> >
> > +config PINCTRL_SUN50I_H616
> > + bool "Support for the Allwinner H616 PIO"
> > + default ARM64 && ARCH_SUNXI
> > + select PINCTRL_SUNXI
> > +
> >
> > endif
> >
> > diff --git a/drivers/pinctrl/sunxi/Makefile
> > b/drivers/pinctrl/sunxi/Makefile index 8b7ff0dc3bdf..5359327a3c8f 100644
> > --- a/drivers/pinctrl/sunxi/Makefile
> > +++ b/drivers/pinctrl/sunxi/Makefile
> > @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
> > pinctrl-sun8i-v3s.o>
> > obj-$(CONFIG_PINCTRL_SUN50I_H5)+= pinctrl-sun50i-h5.o
> > obj-$(CONFIG_PINCTRL_SUN50I_H6)+= pinctrl-sun50i-h6.o
> > obj-$(CONFIG_PINCTRL_SUN50I_H6_R) += pinctrl-sun50i-h6-r.o
> >
> > +obj-$(CONFIG_PINCTRL_SUN50I_H616) += pinctrl-sun50i-h616.o
> >
> > obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
> > obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
> >
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> > b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c new file mode 100644
> > index ..734f63eb08dd
> > --- /dev/null
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> > @@ -0,0 +1,549 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Allwinner H616 SoC pinctrl driver.
> > + *
> > + * Copyright (C) 2020 Arm Ltd.
> > + * based on the H6 pinctrl driver
> > + * Copyright (C) 2017 Icenowy Zheng
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "pinctrl-sunxi.h"
> > +
> > +static const struct sunxi_desc_pin h616_pins[] = {
> > + /* Internal connection to the AC200 part */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXEN */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* EMDC */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* EMDIO */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> > + SUNXI_FUNCTION(0x2, "i2c3")), /* SCK */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> > + SUNXI_FUNCTION(0x2, "i2c3")), /* SDA */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> > + SUNXI_FUNCTION(0x2, "pwm5")),
> > + /* Hole */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> > + SUNXI_FUNCTION(0x0, "gpio_in"),
> > + SUNXI_FUNCTION(0x1, "gpio_out"),
> > + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> > + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> > + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PC_EINT0 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> > + SUNXI_FUNCTION(0x0, "gpio_in"),
> > + SUNXI_FUNCTION(0x1, "gpio_out"),
> > + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> > + SUNXI_FUNCTION(0x3, "mmc2"), /* RST */
> > + SUNXI_FUNCTION_IRQ_B
Re: [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
Dne sreda, 02. december 2020 ob 14:54:06 CET je Andre Przywara napisal(a):
> While the clocks are fairly similar to the H6, many differ in tiny
> details, so a separate clock driver seems indicated.
>
> Derived from the H6 clock driver, and adjusted according to the manual.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/clk/sunxi-ng/Kconfig|7 +-
> drivers/clk/sunxi-ng/Makefile |1 +
> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 1134 +++
> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 58 +
> include/dt-bindings/clock/sun50i-h616-ccu.h | 110 ++
> include/dt-bindings/reset/sun50i-h616-ccu.h | 67 ++
> 6 files changed, 1376 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> create mode 100644 include/dt-bindings/clock/sun50i-h616-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-h616-ccu.h
>
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> index ce5f5847d5d3..cd46d8853876 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -32,8 +32,13 @@ config SUN50I_H6_CCU
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> +config SUN50I_H616_CCU
> + bool "Support for the Allwinner H616 CCU"
> + default ARM64 && ARCH_SUNXI
> + depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> +
> config SUN50I_H6_R_CCU
> - bool "Support for the Allwinner H6 PRCM CCU"
> + bool "Support for the Allwinner H6 and H616 PRCM CCU"
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 3eb5cff40eac..96c324306d97 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_SUN50I_A64_CCU)+= ccu-sun50i-a64.o
> obj-$(CONFIG_SUN50I_A100_CCU)+= ccu-sun50i-a100.o
> obj-$(CONFIG_SUN50I_A100_R_CCU) += ccu-sun50i-a100-r.o
> obj-$(CONFIG_SUN50I_H6_CCU) += ccu-sun50i-h6.o
> +obj-$(CONFIG_SUN50I_H616_CCU)+= ccu-sun50i-h616.o
> obj-$(CONFIG_SUN50I_H6_R_CCU)+= ccu-sun50i-h6-r.o
> obj-$(CONFIG_SUN4I_A10_CCU) += ccu-sun4i-a10.o
> obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h616.c
> new file mode 100644
> index ..3fbb258f0354
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> @@ -0,0 +1,1134 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Arm Ltd.
> + * Based on the H6 CCU driver, which is:
> + * Copyright (c) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ccu_common.h"
> +#include "ccu_reset.h"
> +
> +#include "ccu_div.h"
> +#include "ccu_gate.h"
> +#include "ccu_mp.h"
> +#include "ccu_mult.h"
> +#include "ccu_nk.h"
> +#include "ccu_nkm.h"
> +#include "ccu_nkmp.h"
> +#include "ccu_nm.h"
> +
> +#include "ccu-sun50i-h616.h"
> +
> +/*
> + * The CPU PLL is actually NP clock, with P being /1, /2 or /4. However
> + * P should only be used for output frequencies lower than 288 MHz.
> + *
> + * For now we can just model it as a multiplier clock, and force P to /1.
> + *
> + * The M factor is present in the register's description, but not in the
> + * frequency formula, and it's documented as "M is only used for backdoor
> + * testing", so it's not modelled and then force to 0.
> + */
> +#define SUN50I_H616_PLL_CPUX_REG 0x000
> +static struct ccu_mult pll_cpux_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .mult = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> + .common = {
> + .reg= 0x000,
> + .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
> + &ccu_mult_ops,
> +
CLK_SET_RATE_UNGATE),
> + },
> +};
> +
> +/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */
> +#define SUN50I_H616_PLL_DDR0_REG 0x010
> +static struct ccu_nkmp pll_ddr0_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> + .m = _SUNXI_CCU_DIV(1, 1), /* input divider */
> + .p = _SUNXI_CCU_DIV(0, 1), /* output divider */
> + .common = {
> + .reg= 0x010,
> + .hw.init= CLK_HW_INIT("pll-ddr0", "osc24M",
> + &ccu_nkmp_ops,
> +
CLK_SET_RATE_UNGATE),
> + },
> +};
> +
> +#define SUN50I_H616_PLL_DDR1_REG 0x018
> +static struct ccu_nkmp pll_ddr1_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
>
Re: [PATCH 4/8] clk: sunxi-ng: Add support for the Allwinner H616 R-CCU
Dne sreda, 02. december 2020 ob 14:54:05 CET je Andre Przywara napisal(a):
> The clocks itself are identical to the H6 R-CCU, it's just that the H616
> has not all of them implemented (or connected).
>
> Signed-off-by: Andre Przywara
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 47 +-
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 3 +-
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.c
> index 50f8d1bc7046..119d1797f501 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> @@ -136,6 +136,15 @@ static struct ccu_common *sun50i_h6_r_ccu_clks[] = {
> &w1_clk.common,
> };
>
> +static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
> + &r_apb1_clk.common,
> + &r_apb2_clk.common,
> + &r_apb1_twd_clk.common,
> + &r_apb2_i2c_clk.common,
> + &r_apb1_ir_clk.common,
> + &ir_clk.common,
> +};
> +
> static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
> .hws= {
> [CLK_AR100] = &ar100_clk.common.hw,
> @@ -152,7 +161,20 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks =
{
> [CLK_IR]= &ir_clk.common.hw,
> [CLK_W1]= &w1_clk.common.hw,
> },
> - .num= CLK_NUMBER,
> + .num= CLK_NUMBER_H616,
Above macro should be CLK_NUMBER_H6.
> +};
> +
> +static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
> + .hws= {
> + [CLK_R_AHB] = &r_ahb_clk.hw,
> + [CLK_R_APB1]=
&r_apb1_clk.common.hw,
> + [CLK_R_APB2]=
&r_apb2_clk.common.hw,
> + [CLK_R_APB1_TWD]= &r_apb1_twd_clk.common.hw,
Do we know if TWD exists? I tested I2C and IR. What is your source for these
clocks?
Best regards,
Jernej
> + [CLK_R_APB2_I2C]= &r_apb2_i2c_clk.common.hw,
> + [CLK_R_APB1_IR] =
&r_apb1_ir_clk.common.hw,
> + [CLK_IR]= &ir_clk.common.hw,
> + },
> + .num= CLK_NUMBER_H616,
> };
>
> static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
> @@ -165,6 +187,12 @@ static struct ccu_reset_map sun50i_h6_r_ccu_resets[] =
{
> [RST_R_APB1_W1] = { 0x1ec, BIT(16) },
> };
>
> +static struct ccu_reset_map sun50i_h616_r_ccu_resets[] = {
> + [RST_R_APB1_TWD]= { 0x12c, BIT(16) },
> + [RST_R_APB2_I2C]= { 0x19c, BIT(16) },
> + [RST_R_APB1_IR] = { 0x1cc, BIT(16) },
> +};
> +
> static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
> .ccu_clks = sun50i_h6_r_ccu_clks,
> .num_ccu_clks = ARRAY_SIZE(sun50i_h6_r_ccu_clks),
> @@ -175,6 +203,16 @@ static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc
= {
> .num_resets = ARRAY_SIZE(sun50i_h6_r_ccu_resets),
> };
>
> +static const struct sunxi_ccu_desc sun50i_h616_r_ccu_desc = {
> + .ccu_clks = sun50i_h616_r_ccu_clks,
> + .num_ccu_clks = ARRAY_SIZE(sun50i_h616_r_ccu_clks),
> +
> + .hw_clks= &sun50i_h616_r_hw_clks,
> +
> + .resets = sun50i_h616_r_ccu_resets,
> + .num_resets = ARRAY_SIZE(sun50i_h616_r_ccu_resets),
> +};
> +
> static void __init sunxi_r_ccu_init(struct device_node *node,
> const struct sunxi_ccu_desc
*desc)
> {
> @@ -195,3 +233,10 @@ static void __init sun50i_h6_r_ccu_setup(struct
device_node *node)
> }
> CLK_OF_DECLARE(sun50i_h6_r_ccu, "allwinner,sun50i-h6-r-ccu",
> sun50i_h6_r_ccu_setup);
> +
> +static void __init sun50i_h616_r_ccu_setup(struct device_node *node)
> +{
> + sunxi_r_ccu_init(node, &sun50i_h616_r_ccu_desc);
> +}
> +CLK_OF_DECLARE(sun50i_h616_r_ccu, "allwinner,sun50i-h616-r-ccu",
> +sun50i_h616_r_ccu_setup);
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.h
> index 782117dc0b28..128302696ca1 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> @@ -14,6 +14,7 @@
>
> #define CLK_R_APB2 3
>
> -#define CLK_NUMBER (CLK_W1 + 1)
> +#define CLK_NUMBER_H6(CLK_W1 + 1)
> +#define CLK_NUMBER_H616 (CLK_IR + 1)
>
> #endif /* _CCU_SUN50I_H6_R_H */
> --
> 2.17.5
>
>
Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
Dne sreda, 02. december 2020 ob 14:54:03 CET je Andre Przywara napisal(a):
> Port A is used for an internal connection to some analogue circuitry
> which looks like an AC200 IP (as in the H6), though this is not
> mentioned in the manual.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/pinctrl/sunxi/Kconfig | 5 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
> 3 files changed, 555 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index 593293584ecc..73e88ce71a48 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H616
> + bool "Support for the Allwinner H616 PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 8b7ff0dc3bdf..5359327a3c8f 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
pinctrl-sun8i-v3s.o
> obj-$(CONFIG_PINCTRL_SUN50I_H5) += pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6) += pinctrl-sun50i-h6.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6_R)+= pinctrl-sun50i-h6-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H616)+= pinctrl-sun50i-h616.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c b/drivers/pinctrl/
sunxi/pinctrl-sun50i-h616.c
> new file mode 100644
> index ..734f63eb08dd
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> @@ -0,0 +1,549 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Allwinner H616 SoC pinctrl driver.
> + *
> + * Copyright (C) 2020 Arm Ltd.
> + * based on the H6 pinctrl driver
> + * Copyright (C) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin h616_pins[] = {
> + /* Internal connection to the AC200 part */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXEN
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDIO
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SDA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> + SUNXI_FUNCTION(0x2, "pwm5")),
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /*
PC_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* RST */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /*
PC_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CLE */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MOSI
*/
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /*
PC_EINT2 */
> + SUNXI_PIN(SUNXI_
Re: [PATCH 3/8] pinctrl: sunxi: Add support for the Allwinner H616-R pin controller
Dne sreda, 02. december 2020 ob 14:54:04 CET je Andre Przywara napisal(a):
> There are only two pins left now, used to connect to the PMIC via I2C.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/pinctrl/sunxi/Kconfig | 5 ++
> drivers/pinctrl/sunxi/Makefile| 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c | 58 +++
> 3 files changed, 64 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index 73e88ce71a48..33751a6a0757 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -124,4 +124,9 @@ config PINCTRL_SUN50I_H616
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H616_R
> + bool "Support for the Allwinner H616 R-PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 5359327a3c8f..d3440c42b9d6 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -24,5 +24,6 @@ obj-$(CONFIG_PINCTRL_SUN50I_H5) +=
pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6) += pinctrl-sun50i-h6.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6_R)+= pinctrl-sun50i-h6-r.o
> obj-$(CONFIG_PINCTRL_SUN50I_H616)+= pinctrl-sun50i-h616.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H616_R) += pinctrl-sun50i-h616-r.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c b/drivers/pinctrl/
sunxi/pinctrl-sun50i-h616-r.c
> new file mode 100644
> index ..eb76c009bf24
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Allwinner H616 R_PIO pin controller driver
> + *
> + * Copyright (C) 2020 Arm Ltd.
> + * Based on former work, which is:
> + * Copyright (C) 2017 Icenowy Zheng
> + * Copyright (C) 2014 Boris Brezillon
> + * Boris Brezillon
> + * Copyright (C) 2014 Maxime Ripard
> + * Maxime Ripard
> + */
I'm not sure if it makes sense to reference so many previous work for so
simple driver...
Anyway:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun50i_h616_r_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "s_i2c")),/* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "s_i2c")),/* SDA */
> +};
> +
> +static const struct sunxi_pinctrl_desc sun50i_h616_r_pinctrl_data = {
> + .pins = sun50i_h616_r_pins,
> + .npins = ARRAY_SIZE(sun50i_h616_r_pins),
> + .pin_base = PL_BASE,
> +};
> +
> +static int sun50i_h616_r_pinctrl_probe(struct platform_device *pdev)
> +{
> + return sunxi_pinctrl_init(pdev,
> + &sun50i_h616_r_pinctrl_data);
> +}
> +
> +static const struct of_device_id sun50i_h616_r_pinctrl_match[] = {
> + { .compatible = "allwinner,sun50i-h616-r-pinctrl", },
> + {}
> +};
> +
> +static struct platform_driver sun50i_h616_r_pinctrl_driver = {
> + .probe = sun50i_h616_r_pinctrl_probe,
> + .driver = {
> + .name = "sun50i-h616-r-pinctrl",
> + .of_match_table = sun50i_h616_r_pinctrl_match,
> + },
> +};
> +builtin_platform_driver(sun50i_h616_r_pinctrl_driver);
> --
> 2.17.5
>
>
Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
Dne sreda, 02. december 2020 ob 14:54:08 CET je Andre Przywara napisal(a):
> This (relatively) new SoC is similar to the H6, but drops the (broken)
> PCIe support and the USB 3.0 controller. It also gets the management
> controller removed, which in turn removes *some*, but not all of the
> devices formerly dedicated to the ARISC (CPUS).
> There does not seem to be an external interrupt controller anymore, so
> no external interrupts through an NMI pin. The AXP driver needs to learn
> living with that.
>
> Signed-off-by: Andre Przywara
> ---
> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 704 ++
> 1 file changed, 704 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
boot/dts/allwinner/sun50i-h616.dtsi
> new file mode 100644
> index ..dcffbfdcd26b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,704 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2020 Arm Ltd.
> +// based on the H6 dtsi, which is:
> +// Copyright (C) 2017 Icenowy Zheng
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> + secmon_reserved: secmon@4000 {
> + reg = <0x0 0x4000 0x0 0x8>;
> + no-map;
> + };
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2400>;
> + clock-output-names = "osc24M";
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = ,
> + ,
> + ,
> + ;
> + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x4000>;
> +
> + syscon: syscon@300 {
> + compatible = "allwinner,sun50i-h616-system-
control",
> + "allwinner,sun50i-a64-system-
control";
Those H616 is not compatible to A64 one because it has second emac control
register at offset 0x34, which no other supported SoC has.
> + reg = <0x0300 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram_c: sram@28000 {
> + compatible = "mmio-sram";
> + reg = <0x00028000 0x3>;
> + #address-cells = <1>;
> +
Re: Re: [PATCH 8/8] arm64: dts: allwinner: Add OrangePi Zero 2 .dts
Dne sreda, 02. december 2020 ob 17:07:02 CET je Maxime Ripard napisal(a):
> On Wed, Dec 02, 2020 at 01:54:09PM +, Andre Przywara wrote:
> > The OrangePi Zero 2 is a development board with the new H616 SoC.
> >
> > It features the usual connectors used on those small boards, and comes
> > with the AXP305, which seems to be compatible with the AXP805.
> >
> > For more details see: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero2
> >
> > Signed-off-by: Andre Przywara
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile| 1 +
> > .../allwinner/sun50i-h616-orangepi-zero2.dts | 228 ++
> > 2 files changed, 229 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
zero2.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
allwinner/Makefile
> > index 211d1e9d4701..0cf8299b1ce7 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -35,3 +35,4 @@ 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-model-b.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > new file mode 100644
> > index ..814f5b4fec7c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > @@ -0,0 +1,228 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2020 Arm Ltd.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616.dtsi"
> > +
> > +#include
> > +#include
> > +
> > +/ {
> > + model = "OrangePi Zero2";
> > + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
>
> This needs to be documented too
>
> > + aliases {
> > + ethernet0 = &emac0;
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + power {
> > + label = "orangepi:red:power";
> > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
PC13 */
> > + default-state = "on";
> > + };
> > +
> > + status {
> > + label = "orangepi:green:status";
> > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
PC12 */
> > + };
>
> Those node names don't follow the led binding convention
>
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the USB-C socket
*/
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_usb1_vbus: usb1-vbus {
> > + compatible = "regulator-fixed";
> > + regulator-name = "usb1-vbus";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + enable-active-high;
> > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> > + status = "okay";
> > + };
> > +};
> > +
> > +&ehci0 {
> > + status = "okay";
> > +};
> > +
> > +&ehci1 {
> > + status = "okay";
> > +};
> > +
> > +/* USB 2 & 3 are on headers only. */
> > +
> > +&emac0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ext_rgmii_pins>;
> > + phy-mode = "rgmii";
> > + phy-handle = <&ext_rgmii_phy>;
> > + phy-supply = <®_dcdce>;
> > + allwinner,rx-delay-ps = <3100>;
> > + allwinner,tx-delay-ps = <700>;
> > + status = "okay";
> > +};
> > +
> > +&mdio {
> > + ext_rgmii_phy: ethernet-phy@1 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <1>;
> > + };
> > +};
> > +
> > +&mmc0 {
> > + vmmc-supply = <®_dcdce>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&ohci0 {
> > + status = "okay";
> > +};
> > +
> > +&ohci1 {
> > + status = "okay";
> > +};
> > +
> > +&r_i2c {
> > + status = "okay";
> > +
> > + axp305: pmic@36 {
> > + compatible = "x-powers,axp305", "x-powers,axp805",
> > +"x-powers,axp806";
> > + reg = <0x36>;
> > +
> > + /* dummy interrupt to appease the driver for now */
> > + interrupts = ;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > +
> > + x-powers,self-working-mode;
> > + vina-supply = <®_vcc5v>;
> > + vinb-supply = <®_vcc5v>;
> > + vinc-supply = <®_vcc5v>;
> > + vind-supply = <®_vcc5v>;
> > + vine-s
Re: [PATCH 1/8] clk: sunxi-ng: h6: Fix clock divider range on some clocks
Dne sreda, 02. december 2020 ob 14:54:02 CET je Andre Przywara napisal(a):
> While comparing clocks between the H6 and H616, some of the M factor
> ranges were found to be wrong: the manual says they are only covering
> two bits [1:0], but our code had "5" in the number-of-bits field.
>
> By writing 0xff into that register in U-Boot and via FEL, it could be
> confirmed that bits [4:2] are indeed masked off, so the manual is right.
>
> Change to number of bits in the affected clock's description.
>
> Fixes: 524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU")
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
Re: Re: [PATCH v3] media: cedrus: Add support for VP8 decoding
Hi! Dne petek, 27. november 2020 ob 00:21:11 CET je Ezequiel Garcia napisal(a): > Hi Jernej, Emmanuel, > > Thanks for the patch. > > On Tue, 2020-11-10 at 23:35 +0100, 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. > > > > Signed-off-by: Jernej Skrabec > > [addressed issues from reviewer] > > Signed-off-by: Emmanuel Gil Peyrot > > --- > > Changes in v3: > > - addressed comments from Ezequiel Garcia - new comments, > > using new macros from VP8 UAPI, new function for waiting > > on bit to be set > > Changes in v2: > > - rebased on top of current linux-media master branch > > > > NOTE: This now depends on following patch: > > https://patchwork.linuxtv.org/project/linux-media/patch/ 20201108202021.4187-1-linkma...@linkmauve.fr/ > > > > The patch looks fairly good, so let's wait and see > what Hans, Paul and Maxime think about it. > > FWIW, my humble Reviewed-by: Ezequiel Garcia Thanks! > > It would be good to make sure this doesn't regress > v4l2-compliance, or cause some regression in decoding. I didn't include v4l2-compliance here, but it was in previous revisions. This revision has just cosmetics. Not sure how it could cause any regression since it's pretty standalone. > > Not really a blocker to merge this, but I'm thinking > that now that we have Fluster for conformance testing, > we could add the VP8 vectors and use them against > Cedrus and Hantro: > > https://chromium.googlesource.com/webm/vp8-test-vectors/+/refs/heads/master I tested VP8 test vectors with initial version of this decoder by hand and all videos were properly decoded as far as I can tell. But automated testing is always welcome. Best regards, Jernej > > Thanks, > Ezequiel > > > drivers/staging/media/sunxi/cedrus/Makefile | 3 +- > > drivers/staging/media/sunxi/cedrus/cedrus.c | 8 + > > drivers/staging/media/sunxi/cedrus/cedrus.h | 24 + > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 5 + > > .../staging/media/sunxi/cedrus/cedrus_hw.c| 2 + > > .../staging/media/sunxi/cedrus/cedrus_regs.h | 80 ++ > > .../staging/media/sunxi/cedrus/cedrus_video.c | 9 + > > .../staging/media/sunxi/cedrus/cedrus_vp8.c | 907 ++ > > 8 files changed, 1037 insertions(+), 1 deletion(-) > > create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_vp8.c > > > >
Re: [PATCH v4 03/13] media: cedrus: h264: Support profile controls
Hi! Dne ponedeljek, 23. november 2020 ob 15:39:50 CET je Ezequiel Garcia napisal(a): > Cedrus supports H.264 profiles from Baseline to High, > except for the Extended profile > > Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE so that > userspace can query the driver for the supported > profiles and levels. > > Signed-off-by: Ezequiel Garcia Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v4 00/13] Stateless H.264 de-staging
Hi! Dne ponedeljek, 23. november 2020 ob 15:39:47 CET je Ezequiel Garcia napisal(a): > Seems we are converging, as this iteration is really small. > > Just like v3, this iteration (plus a patch for VP8 VP8_FRAME_HEADER initialization, > which I'll send shortly) passes v4l2-compliance with no failures. > > As an additional test, Fluendo's JVT-AVC_V1 conformance test [1] passes with > score 72/135, for the Hantro driver on i.MX8MQ (Hantro G1 VPU). > Considering the Hantro driver only supports 4:2:0 and 4:0:0, this score > looks quite good. > > [1] https://github.com/fluendo/fluster/ Tested with ffmpeg/kodi stack on Allwinner R40 with different samples which use different H264 features and works without any problem. You can add Tested-by: Jernej Skrabec for whole series. Best regards, Jernej > > Thanks, > Ezequiel > > v4: > * Minor documentation fixes. > * Remove media/h264-ctrls.h, which was missing before. > * Thanks to feedback from Jernej, std_validation_compound > is now more complete, initializing non-present syntax elements. > v3: > * Dropped level control from Cedrus, as agreed. > * Add support for H264 stateless controls in std_log and std_validate_compound. > * Added a ctrl debug error message, to help debug validation issues. > * Style minor fixes as requested by Hans. > v2: > * Split destage changes in several patches so it's easier to review. > * Added missing changes to drivers/media/v4l2-core/v4l2-ctrls.c. > * Renamed V4L2_CID_CODEC_CX2341X_ and V4L2_CID_MPEG_MFC51_ > * Moved the compatibility macros for MPEG to the end of the header. > > Ezequiel Garcia (12): > media: ctrls: Add validate failure debug message > media: cedrus: h264: Support profile controls > media: Rename stateful codec control macros > media: Clean stateless control includes > media: uapi: h264: Add profile_idc macros > media: controls: Validate H264 stateless controls > media: controls: Add the stateless codec control class > media: uapi: Move parsed H264 pixel format out of staging > media: uapi: Move the H264 stateless control types out of staging > media: controls: Log H264 stateless controls in .std_log > media: uapi: move H264 stateless controls out of staging > media: docs: Move the H264 stateless codec uAPI > > Jonas Karlman (1): > media: rkvdec: h264: Support profile and level controls > > .../userspace-api/media/v4l/common.rst| 1 + > .../userspace-api/media/v4l/dev-mem2mem.rst | 2 +- > .../media/v4l/ext-ctrls-codec-stateless.rst | 674 +++ > .../media/v4l/ext-ctrls-codec.rst | 696 +-- > .../media/v4l/extended-controls.rst | 9 +- > .../media/v4l/pixfmt-compressed.rst | 21 +- > .../media/v4l/vidioc-g-ext-ctrls.rst | 6 +- > drivers/media/common/cx2341x.c| 4 +- > drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +- > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 2 +- > drivers/media/v4l2-core/v4l2-ctrls.c | 198 - > drivers/staging/media/hantro/hantro_drv.c | 26 +- > drivers/staging/media/hantro/hantro_h264.c| 8 +- > drivers/staging/media/hantro/hantro_hw.h | 4 +- > drivers/staging/media/rkvdec/rkvdec-h264.c| 8 +- > drivers/staging/media/rkvdec/rkvdec.c | 39 +- > drivers/staging/media/sunxi/cedrus/cedrus.c | 43 +- > .../staging/media/sunxi/cedrus/cedrus_dec.c | 12 +- > include/media/fwht-ctrls.h| 2 +- > include/media/h264-ctrls.h| 406 - > include/media/hevc-ctrls.h| 10 +- > include/media/mpeg2-ctrls.h | 4 +- > include/media/v4l2-ctrls.h| 1 - > include/media/v4l2-h264.h | 2 +- > include/media/vp8-ctrls.h | 2 +- > include/uapi/linux/v4l2-controls.h| 804 +- > include/uapi/linux/videodev2.h| 8 + > 27 files changed, 1582 insertions(+), 1412 deletions(-) > create mode 100644 Documentation/userspace-api/media/v4l/ext-ctrls-codec- stateless.rst > delete mode 100644 include/media/h264-ctrls.h > > -- > 2.27.0 > >
Re: Re: [PATCH v2 2/9] media: cedrus: h264: Support profile and level controls
Dne torek, 17. november 2020 ob 20:40:09 CET je Ezequiel Garcia napisal(a):
> On Tue, 2020-11-17 at 20:24 +0100, Jernej Škrabec wrote:
> > Hi Ezequiel,
> >
> > sorry for late review.
> >
> > First of all, this patch doesn't break anything. However, see comment
below.
> >
> > Dne petek, 13. november 2020 ob 22:51:14 CET je Ezequiel Garcia
napisal(a):
> > > Cedrus supports H.264 profiles from Baseline to High,
> > > up to Level 5.1, except for the Extended profile
> > >
> > > Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE and
> > > V4L2_CID_MPEG_VIDEO_H264_LEVEL so that userspace can
> > > query the driver for the supported profiles and levels.
> > >
> > > Signed-off-by: Ezequiel Garcia
> > > ---
> > > drivers/staging/media/sunxi/cedrus/cedrus.c | 21 +
> > > 1 file changed, 21 insertions(+)
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/
staging/
> > media/sunxi/cedrus/cedrus.c
> > > index 9a102b7c1bb9..8b0e97752d27 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > > @@ -103,6 +103,27 @@ static const struct cedrus_control
cedrus_controls[] =
> > {
> > > .codec = CEDRUS_CODEC_H264,
> > > .required = false,
> > > },
> > > + {
> > > + .cfg = {
> > > + .id =
> > V4L2_CID_MPEG_VIDEO_H264_PROFILE,
> > > + .min=
> > V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE,
> > > + .def=
> > V4L2_MPEG_VIDEO_H264_PROFILE_MAIN,
> > > + .max=
> > V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
> > > + .menu_skip_mask =
> > > +
> > BIT(V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED),
> > > + },
> > > + .codec = CEDRUS_CODEC_H264,
> > > + .required = false,
> > > + },
> > > + {
> > > + .cfg = {
> > > + .id = V4L2_CID_MPEG_VIDEO_H264_LEVEL,
> > > + .min = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> > > + .max = V4L2_MPEG_VIDEO_H264_LEVEL_5_1,
> >
> > I went through several datasheets and only newer ones (H6, H616) state
max.
> > supported level, which is 4.2. Please change it in next revision.
> >
> > After that, you can add
> > Reviewed-by: Jernej Skrabec
> >
>
> Note that I used level 5.1 based on a commit from you:
> """
> media: cedrus: h264: Fix 4K decoding on H6
>
> Due to unknown reason, H6 needs larger intraprediction buffer for 4K
> videos than other SoCs. This was discovered by playing 4096x2304 video,
> which is maximum what H6 VPU is supposed to support.
> """
>
> I guessed this meant it supported level 5 or higher.
> (Now that I think about it, I meant at least H6, does).
>
> According to https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels,
> level 4.2 is up to 2,048×1,080@60.0.
Strange, then I guess datasheet is wrong (wouldn't be first time).
Unfortunatelly there is no documentation for Cedrus capabilities, so
everything is either educated guess or tested on HW. Documentation for older
than H6 SoCs always mention only 1080p @ 60fps limit, even though several of
them are capable of decoding 4K H264 videos (I'm not sure about max. fps
though).
>
> Frankly, I'm open to put whatever value makes you happy.
To be honest, I'm not sure what is correct value here. It may depend on Cedrus
core variant.
Best regards,
Jernej
>
> Thanks,
> Ezequiel
>
> > Best regards,
> > Jernej
> >
> > > + },
> > > + .codec = CEDRUS_CODEC_H264,
> > > + .required = false,
> > > + },
> > > {
> > > .cfg = {
> > > .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
> > > --
> > > 2.27.0
> > >
> > >
> >
> >
>
>
>
Re: [PATCH v2 2/9] media: cedrus: h264: Support profile and level controls
Hi Ezequiel,
sorry for late review.
First of all, this patch doesn't break anything. However, see comment below.
Dne petek, 13. november 2020 ob 22:51:14 CET je Ezequiel Garcia napisal(a):
> Cedrus supports H.264 profiles from Baseline to High,
> up to Level 5.1, except for the Extended profile
>
> Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE and
> V4L2_CID_MPEG_VIDEO_H264_LEVEL so that userspace can
> query the driver for the supported profiles and levels.
>
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/
media/sunxi/cedrus/cedrus.c
> index 9a102b7c1bb9..8b0e97752d27 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -103,6 +103,27 @@ static const struct cedrus_control cedrus_controls[] =
{
> .codec = CEDRUS_CODEC_H264,
> .required = false,
> },
> + {
> + .cfg = {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_PROFILE,
> + .min=
V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE,
> + .def=
V4L2_MPEG_VIDEO_H264_PROFILE_MAIN,
> + .max=
V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
> + .menu_skip_mask =
> +
BIT(V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED),
> + },
> + .codec = CEDRUS_CODEC_H264,
> + .required = false,
> + },
> + {
> + .cfg = {
> + .id = V4L2_CID_MPEG_VIDEO_H264_LEVEL,
> + .min = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .max = V4L2_MPEG_VIDEO_H264_LEVEL_5_1,
I went through several datasheets and only newer ones (H6, H616) state max.
supported level, which is 4.2. Please change it in next revision.
After that, you can add
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> + },
> + .codec = CEDRUS_CODEC_H264,
> + .required = false,
> + },
> {
> .cfg = {
> .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
> --
> 2.27.0
>
>
Re: [PATCH v2] drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
Dne ponedeljek, 16. november 2020 ob 02:09:29 CET je Xiongfeng Wang
napisal(a):
> Fix to return a negative error code from the error handling case instead
> of 0 in function sun8i_dw_hdmi_bind().
>
> Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
> Reported-by: Hulk Robot
> Signed-off-by: Xiongfeng Wang
> Reviewed-by: Jernej Skrabec
Applied to drm-misc-fixes, thanks!
In future, please CC all people given by get_maintainer.pl script. In this
case you missed Maxime Ripard and Chen-Yu Tsai.
Best regards,
Jernej
Re: [PATCH] ARM: configs: sunxi: enable Realtek PHY
Dne četrtek, 12. november 2020 ob 21:26:52 CET je Corentin Labbe napisal(a): > Lot of sunxi boards has a Realtek PHY, so let's enable it. > > Signed-off-by: Corentin Labbe > --- > arch/arm/configs/sunxi_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/sunxi_defconfig > b/arch/arm/configs/sunxi_defconfig index 244126172fd6..05f7f4ed8ded 100644 > --- a/arch/arm/configs/sunxi_defconfig > +++ b/arch/arm/configs/sunxi_defconfig > @@ -51,6 +51,7 @@ CONFIG_STMMAC_ETH=y > # CONFIG_NET_VENDOR_VIA is not set > # CONFIG_NET_VENDOR_WIZNET is not set > CONFIG_MICREL_PHY=y > +CONFIG_REALTEK_PHY=y > # CONFIG_WLAN is not set > CONFIG_INPUT_EVDEV=y > CONFIG_KEYBOARD_SUN4I_LRADC=y Acked-by: Jernej Skrabec Thanks! Best regards, Jernej
Re: [PATCH] drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
Hi!
Thanks for the patch.
Dne četrtek, 12. november 2020 ob 14:14:51 CET je Xiongfeng Wang napisal(a):
> Fix to return a negative error code from the error handling case instead
> of 0 in function sun8i_dw_hdmi_bind().
>
> Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
> Reported-by: Hulk Robot
> Signed-off-by: Xiongfeng Wang
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index d4c0804..f010fe8 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -208,6 +208,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
> device *master, phy_node = of_parse_phandle(dev->of_node, "phys", 0);
> if (!phy_node) {
> dev_err(dev, "Can't found PHY phandle\n");
> + ret = -ENODEV;
That should be EINVAL because DT node doesn't have mandatory property.
With that fixed, you can add:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> goto err_disable_clk_tmds;
> }
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] 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: 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: [linux-sunxi] Re: [PATCH v10 00/15] Add Allwinner H3/H5/H6/A64 HDMI audio
Dne petek, 30. oktober 2020 ob 21:50:43 CET je Stefan Monnier napisal(a): > >> This series add H6 I2S support and the I2S node missing to support > >> HDMI audio in different Allwinner SoC. > > > > Applied to > > > >https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git > >for-next > > Yay! Note that this doesn't bring HDMI audio card just yet. Another driver will be needed for that. > > Now, I wonder: will that make it easier to add support for HDMI-Audio for > the A10/A20? No, A10/A20 HDMI audio uses completely different interface. > > (there was a patch for that submitted earlier this year by Stefan > Mavrodiev , but it seems there hasn't been any > progress on it since then (I think the last message on it concluded that > it should be rewritten to use ALSA instead of ASoC)). IIUC original author left Olimex, so work stalled. Best regards, Jernej > > [ To clarify, don't know what's the difference between ALSA and ASoC; > I'm only interested here as an owner of an A20 box on which I'd > love to be able to use the HDMI-Audio. ] > > > -- Stefan
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: [PATCH 09/10] arm64: dts: allwinner: h5: libretech-all-h5-cc: Enable RGMII RX/TX delay on PHY
Dne sobota, 24. oktober 2020 ob 18:25:14 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the Libre Computer ALL-H5-CC 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: 60d0426d7603 ("arm64: dts: allwinner: h5: Add Libre Computer ALL-H5-
CC H5 board")
> Signed-off-by: Chen-Yu Tsai
Was this board ever in production? I can't find anything relevant about it on
the internet.
Anyway:
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 02/10] ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY
Dne sobota, 24. oktober 2020 ob 18:25:07 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the A31 Hummingbird 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: c220aec2bb79 ("ARM: dts: sun6i: Add Merrii A31 Hummingbird support")
> Signed-off-by: Chen-Yu Tsai
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 04/10] ARM: dts: sun7i: bananapi-m1-plus: Enable RGMII RX/TX delay on Ethernet PHY
Dne sobota, 24. oktober 2020 ob 18:25:09 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> 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: 04c85ecad32a ("ARM: dts: sun7i: Add dts file for Bananapi M1 Plus
board")
> Signed-off-by: Chen-Yu Tsai
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 06/10] ARM: dts: sun8i: a83t: Enable both RGMII RX/TX delay on Ethernet PHY
Dne sobota, 24. oktober 2020 ob 18:25:11 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the Bananapi M3 and Cubietruck Plus have 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: 039359948a4b ("ARM: dts: sun8i: a83t: Enable Ethernet on two boards")
> Signed-off-by: Chen-Yu Tsai
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 07/10] ARM: dts: sun9i: Enable both RGMII RX/TX delay on Ethernet PHY
Dne sobota, 24. oktober 2020 ob 18:25:12 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the Cubieboard 4 and A80 Optimus have 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: 98048143b7f8 ("ARM: dts: sun9i: cubieboard4: Enable GMAC")
> Fixes: bc9bd03a44f9 ("ARM: dts: sun9i: a80-optimus: Enable GMAC")
> Signed-off-by: Chen-Yu Tsai
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: Re: [linux-sunxi] [PATCH 10/10] arm64: dts: allwinner: a64: bananapi-m64: Enable RGMII RX/TX delay on PHY
Dne sobota, 24. oktober 2020 ob 21:58:03 CET je Corentin Labbe napisal(a):
> On Sun, Oct 25, 2020 at 12:25:15AM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > The Ethernet PHY on the Bananapi M64 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: e7295499903d ("arm64: allwinner: bananapi-m64: Enable dwmac-sun8i")
> > Fixes: 94f442886711 ("arm64: dts: allwinner: A64: Restore EMAC changes")
> > Signed-off-by: Chen-Yu Tsai
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> > index 3ea5182ca489..e5e840b9fbb4 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> > @@ -105,7 +105,7 @@ &ehci1 {
> > &emac {
> > pinctrl-names = "default";
> > pinctrl-0 = <&rgmii_pins>;
> > - phy-mode = "rgmii";
> > + phy-mode = "rgmii-id";
> > phy-handle = <&ext_rgmii_phy>;
> > phy-supply = <®_dc1sw>;
> > status = "okay";
> > --
> > 2.28.0
>
> Tested-by: Corentin Labbe
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 08/10] ARM: dts: sunxi: bananapi-m2-plus: Enable RGMII RX/TX delay on Ethernet PHY
Dne sobota, 24. oktober 2020 ob 18:25:13 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the Bananapi M2+ 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: 8c7ba536e709 ("ARM: sun8i: bananapi-m2-plus: Enable dwmac-sun8i")
> Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
> Fixes: aa8fee415f46 ("ARM: dts: sun8i: h3: Split out non-SoC-specific parts
of Bananapi M2 Plus")
> Signed-off-by: Chen-Yu Tsai
Tested-by: Jernej Skrabec
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 05/10] ARM: dts: sun8i: h3: orangepi-plus2e: Enable RGMII RX/TX delay on Ethernet PHY
Dne sobota, 24. oktober 2020 ob 18:25:10 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the Orange Pi Plus 2E 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: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
> Fixes: 7a78ef92cdc5 ("ARM: sun8i: h3: Enable EMAC with external PHY on
Orange Pi Plus 2E")
> Signed-off-by: Chen-Yu Tsai
Tested-by: Jernej Skrabec
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH 01/10] Revert "arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high"
Dne sobota, 24. oktober 2020 ob 18:25:06 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> This reverts commit 75ee680cbd2e4d0156b94f9fec50076361ab12f2.
>
> Turns out the activity and link LEDs on the RJ45 port are active low,
> just like on the Orange Pi PC.
>
> Revert the commit that says otherwise.
>
> Fixes: 75ee680cbd2e ("arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs
to active high")
> Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
> Signed-off-by: Chen-Yu Tsai
> ---
> If you have this board, please help test it.
>
> For me, the correct lighting of the LEDs is both LEDs should be lit
> when connected at 100 Mbps.
Tested-by: Jernej Skrabec
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [linux-sunxi] [PATCH 02/10] ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY
Dne sobota, 24. oktober 2020 ob 19:51:06 CEST je Icenowy Zheng napisal(a):
> 在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：
>
> > From: Chen-Yu Tsai
> >
> > The Ethernet PHY on the A31 Hummingbird 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").
>
> Personally I think they should revert this commit, and consider other
> solution.
>
> This commit breaks everything.
>
Previously broken driver allowed inproper DT to work, so you have to fix
everything eventually.
Plus side, there is no need to have hack for Pine64 Plus ethernet anymore.
Best regards,
Jernej
> (Although the patch on individual DT patches are technically correct)
>
> > Fixes: c220aec2bb79 ("ARM: dts: sun6i: Add Merrii A31 Hummingbird
> > support")
> > Signed-off-by: Chen-Yu Tsai
> > ---
> >
> > arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> > b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> > index 049e6ab3cf56..73de34ae37fd 100644
> > --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> > +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> > @@ -154,7 +154,7 @@ &gmac {
> >
> > pinctrl-names = "default";
> > pinctrl-0 = <&gmac_rgmii_pins>;
> > phy-handle = <&phy1>;
> >
> > - phy-mode = "rgmii";
> > + phy-mode = "rgmii-id";
> >
> > status = "okay";
> >
> > };
Re: [linux-sunxi] [PATCH 01/14] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes
Hi!
Dne petek, 23. oktober 2020 ob 19:45:33 CEST je Paul Kocialkowski napisal(a):
> As some D-PHY controllers support both Rx and Tx mode, we need a way for
> users to explicitly request one or the other. For instance, Rx mode can
> be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.
>
> Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
> The default (zero value) is kept to Tx so only the rkisp1 driver, which
> uses D-PHY in Rx mode, needs to be adapted.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/staging/media/rkisp1/rkisp1-isp.c | 3 ++-
> include/linux/phy/phy-mipi-dphy.h | 13 +
I think some changes are missing in this patch. For example,
phy_set_mode_ext() must be modified to take another argument, otherwise change
of rkisp1-isp driver doesn't make much sense.
Best regards,
Jernej
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/rkisp1/rkisp1-isp.c b/drivers/staging/
media/rkisp1/rkisp1-isp.c
> index 6ec1e9816e9f..0afbce00121e 100644
> --- a/drivers/staging/media/rkisp1/rkisp1-isp.c
> +++ b/drivers/staging/media/rkisp1/rkisp1-isp.c
> @@ -902,7 +902,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp
*isp,
>
> phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt-
>bus_width,
>sensor->lanes, cfg);
> - phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
> + phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
> + PHY_MIPI_DPHY_SUBMODE_RX);
> phy_configure(sensor->dphy, &opts);
> phy_power_on(sensor->dphy);
>
> diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-
dphy.h
> index a877ffee845d..0f57ef46a8b5 100644
> --- a/include/linux/phy/phy-mipi-dphy.h
> +++ b/include/linux/phy/phy-mipi-dphy.h
> @@ -6,6 +6,19 @@
> #ifndef __PHY_MIPI_DPHY_H_
> #define __PHY_MIPI_DPHY_H_
>
> +/**
> + * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
> + *
> + * A MIPI D-PHY can be used to transmit or receive data.
> + * Since some controllers can support both, the direction to enable is
specified
> + * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
> + */
> +
> +enum phy_mipi_dphy_submode {
> + PHY_MIPI_DPHY_SUBMODE_TX = 0,
> + PHY_MIPI_DPHY_SUBMODE_RX,
> +};
> +
> /**
> * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> *
> --
> 2.28.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/20201023174546.504028-2-paul.kocialkowski%40bootlin.com.
>
Re: Re: [PATCH v2] arm64: dts: allwinner: h6: add eMMC voltage property for Beelink GS1
Dne četrtek, 15. oktober 2020 ob 11:35:44 CEST je Maxime Ripard napisal(a):
> On Tue, Oct 13, 2020 at 11:27:33PM +0200, Jernej Škrabec wrote:
> > 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 @@ &mmc2 {
> > > > > > > > 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
> > > > >
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 @@ &mmc2 {
> > > > > > 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: Re: [PATCH v4 09/22] arm64: dts: allwinner: h6: Add HDMI audio node
Dne ponedeljek, 21. september 2020 ob 19:23:49 CEST je Clément Péron
napisal(a):
> Hi Maxime,
>
> On Mon, 21 Sep 2020 at 15:59, Maxime Ripard wrote:
> >
> > On Mon, Sep 21, 2020 at 12:27:18PM +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 28c77d6872f6..a8853ee7885a 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;
> > > + status = "disabled";
> > > +
> > > + simple-audio-card,codec {
> > > + sound-dai = <&hdmi>;
> > > + };
> > > +
> > > + simple-audio-card,cpu {
> > > + sound-dai = <&i2s1>;
> > > + dai-tdm-slot-num = <2>;
> > > + dai-tdm-slot-width = <32>;
> >
> > It looks weird to have both some TDM setup here, and yet the format in
> > i2s?
>
> Yes, I agree I will check if it's really needed.
I think this was explained before. Anyway, this is needed to force width to
32, no matter actual sample width. That's a requirement of HDMI codec. I
believe Marcus Cooper have another codec which also needs fixed width.
There is no similar property for I2S, so TDM one is used here.
Best regards,
Jernej
>
> Clement
>
> >
> > Maxime
>
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 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: [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 = &sun4i_i2s_dai_ops,
> > .symmetric_rates = 1,
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: [PATCH v2 00/14] Clean H264 stateless uAPI
Hi! Dne četrtek, 06. avgust 2020 ob 17:12:56 CEST je Ezequiel Garcia napisal(a): > Here's a new round for the H.264 uAPI cleanup, which as discussed > aims at being stabilized and promoted as a first-class public uAPI soon. > > It should be noted that there is already GStreamer native > support for this interface, which will be part of 1.18, > once it's released. > > I have pushed a branch porting GStreamer to > support these interface changes: > > https://gitlab.freedesktop.org/ezequielgarcia/gst-plugins-bad/-/commits/for_ > h264_uapi_v3 > > As was discussed the SLICE_PARAMS control is now clarified > to work for one-slice-per-request operation, using CAPTURE > buffer holding features. This is how Cedrus driver is implemented. > > The other drivers currently supported Hantro and Rockchip VDEC, > as well as the MTK stateless decoder posted by Alex Courbot > operate in frame-based mode. > > These "frame-based" devices parse the slice headers in hardware, > and therefore shall not support SLICE_PARAMS. To that extent, > the redundant bitstream fields are now part of the DECODE_PARAMS > control. > > Hopefully now the specification documentation is clear enough. > GStreamer, Chromium and FFmpeg (which I'm sure will be implemented > as soon as we stabilize the API) should serve as reference examples > on how the API is consumed. > I tested this series using https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3.1 on Cedrus (Allwinner H6) using additional patch contained in discussion around patch 3 and I couldn't find any issue. You can add to whole series: Tested-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH] RFC: sun4i/drm: Swap back U and V channels for DRM_FORMAT_YVU4xx
Dne torek, 01. september 2020 ob 23:29:29 CEST je Ondřej Jirman napisal(a):
> On Tue, Sep 01, 2020 at 11:30:47PM +0300, Roman Stratiienko wrote:
> > Fixes: e1ef9006663b ("drm/sun4i: Wire in DE2 YUV support")
> > Signed-off-by: Roman Stratiienko
> >
> > ---
> > CC: meg...@megous.com
> > CC: jernej.skra...@gmail.com
> > CC: linux-su...@googlegroups.com
> > CC: dri-de...@lists.freedesktop.org
> > CC: linux-arm-ker...@lists.infradead.org
> > CC: linux-kernel@vger.kernel.org
> >
> > Hi, this patch fixes wrong colors during video playback for me.
> > Implemented ugly for now, please review/suggest how to improve.
>
> Why do you think the issue is at DRM level? Have you tried displaying a known
> color image via a vi layer, and was it wrong?
>
> I used DRM with YUV data in the past, and didn't notice any weird colors,
> so I'm a bit skeptical.
There is a bug, I just tested it, but solution is much more simpler:
--- 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;
I made a mistake when I was reworking (simplifying) format handling. I'll send
a fix soon.
Thanks for report!
Best regards,
Jernej
>
> regards,
> o.
>
> > ---
> > drivers/gpu/drm/sun4i/sun8i_mixer.c| 8 +++-
> > drivers/gpu/drm/sun4i/sun8i_mixer.h| 2 +-
> > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
> > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 28 +++---
> > 4 files changed, 30 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > index dce40c430100..bbbeef44899a 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -31,6 +31,7 @@
> > struct de2_fmt_info {
> > u32 drm_fmt;
> > u32 de2_fmt;
> > + boolswap_uv;
> > };
> >
> > static bool hw_preconfigured;
> > @@ -219,14 +220,17 @@ static const struct de2_fmt_info de2_formats[] = {
> > {
> > .drm_fmt = DRM_FORMAT_YVU422,
> > .de2_fmt = SUN8I_MIXER_FBFMT_YUV422,
> > + .swap_uv = true,
> > },
> > {
> > .drm_fmt = DRM_FORMAT_YVU420,
> > .de2_fmt = SUN8I_MIXER_FBFMT_YUV420,
> > + .swap_uv = true,
> > },
> > {
> > .drm_fmt = DRM_FORMAT_YVU411,
> > .de2_fmt = SUN8I_MIXER_FBFMT_YUV411,
> > + .swap_uv = true,
> > },
> > {
> > .drm_fmt = DRM_FORMAT_P010,
> > @@ -238,13 +242,15 @@ static const struct de2_fmt_info de2_formats[] = {
> > },
> > };
> >
> > -int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format)
> > +int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format, bool *swap_uv)
> > {
> > unsigned int i;
> >
> > for (i = 0; i < ARRAY_SIZE(de2_formats); ++i)
> > if (de2_formats[i].drm_fmt == format) {
> > *hw_format = de2_formats[i].de2_fmt;
> > + if (swap_uv)
> > + *swap_uv = de2_formats[i].swap_uv;
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > index 79a74bca1ea3..6358ffd251f9 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > @@ -207,5 +207,5 @@ sun8i_channel_base(struct sun8i_mixer *mixer, int
> > channel)
> > return DE2_CH_BASE + channel * DE2_CH_SIZE;
> > }
> >
> > -int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format);
> > +int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format, bool
> > *swap_uv);
> > #endif /* _SUN8I_MIXER_H_ */
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > index a7f21f08ec89..57bbd9f1071c 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > @@ -215,7 +215,7 @@ static int sun8i_ui_layer_update_formats(struct
> > sun8i_mixer *mixer, int channel,
> > ch_base = sun8i_channel_base(mixer, channel);
> >
> > fmt = state->fb->format;
> > - ret = sun8i_mixer_drm_format_to_hw(fmt->format, &hw_fmt);
> > + ret = sun8i_mixer_drm_format_to_hw(fmt->format, &hw_fmt, NULL);
> > if (ret || fmt->is_yuv) {
> > DRM_DEBUG_DRIVER("Invalid format\n");
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > index 3553e38ec642..4da51155c4d5 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> > @@ -313,7
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 t
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, &crc, 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] [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: [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: [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters
Dne ponedeljek, 10. avgust 2020 ob 21:30:59 CEST je Ezequiel Garcia napisal(a): > On Mon, 2020-08-10 at 19:05 +0200, Jernej Škrabec wrote: > > Dne ponedeljek, 10. avgust 2020 ob 14:57:17 CEST je Ezequiel Garcia > > > > napisal(a): > > > On Sun, 2020-08-09 at 23:11 +0200, Jernej Škrabec wrote: > > > > Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia > > > > napisal(a): > > > > > On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote: > > > > > > On 2020-08-06 17:12, Ezequiel Garcia wrote: > > > > > > > The prediction weight parameters are only required under > > > > > > > certain conditions, which depend on slice header parameters. > > > > > > > > > > > > > > As specified in section 7.3.3 Slice header syntax, the > > > > > > > prediction > > > > > > > weight table is present if: > > > > > > > > > > > > > > ((weighted_pred_flag && (slice_type == P || slice_type == SP)) > > > > > > > || \ > > > > > > > (weighted_bipred_idc == 1 && slice_type == B)) > > > > > > > > > > > > Maybe a macro can be added to help check this contition? > > > > > > > > > > > > Something like this maybe: > > > > > > > > > > > > #define V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED(pps, slice) \ > > > > > > > > > > > > pps)->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) && \ > > > > > > > > > > > > ((slice)->slice_type == V4L2_H264_SLICE_TYPE_P || \ > > > > > > > > > > > >(slice)->slice_type == V4L2_H264_SLICE_TYPE_SP)) || \ > > > > > > > > > > > > ((pps)->weighted_bipred_idc == 1 && \ > > > > > > > > > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_B)) > > > > > > > > > > Yeah, that could make sense. > > > > > > > > > > Note that the biggest value in having the prediction weight table > > > > > separated is to allow applications to skip setting this largish > > > > > control, > > > > > reducing the amount of data that needs to be passed from userspace > > > > > -- especially when not needed :-) > > > > > > > > > > > > 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 > > > > > > > --- > > > > > > > v2: Fix missing Cedrus changes and mssing control declaration, > > > > > > > > > > > > > > as noted by Hans and Jernej. > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > .../media/v4l/ext-ctrls-codec.rst | 19 > > > > > > > --- > > > > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 8 > > > > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++ > > > > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > > > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ > > > > > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++ > > > > > > > include/media/h264-ctrls.h| 5 +++-- > > > > > > > include/media/v4l2-ctrls.h| 2 ++ > > > > > > > 8 files changed, 37 insertions(+), 13 deletions(-) > > > > > > > > > > > > > > diff --git > > > > > > > a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > >
Re: [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters
Dne ponedeljek, 10. avgust 2020 ob 14:57:17 CEST je Ezequiel Garcia napisal(a): > On Sun, 2020-08-09 at 23:11 +0200, Jernej Škrabec wrote: > > Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia napisal(a): > > > On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote: > > > > On 2020-08-06 17:12, Ezequiel Garcia wrote: > > > > > The prediction weight parameters are only required under > > > > > certain conditions, which depend on slice header parameters. > > > > > > > > > > As specified in section 7.3.3 Slice header syntax, the prediction > > > > > weight table is present if: > > > > > > > > > > ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ > > > > > (weighted_bipred_idc == 1 && slice_type == B)) > > > > > > > > Maybe a macro can be added to help check this contition? > > > > > > > > Something like this maybe: > > > > > > > > #define V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED(pps, slice) \ > > > > > > > > pps)->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) && \ > > > > > > > > ((slice)->slice_type == V4L2_H264_SLICE_TYPE_P || \ > > > > > > > >(slice)->slice_type == V4L2_H264_SLICE_TYPE_SP)) || \ > > > > > > > > ((pps)->weighted_bipred_idc == 1 && \ > > > > > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_B)) > > > > > > Yeah, that could make sense. > > > > > > Note that the biggest value in having the prediction weight table > > > separated is to allow applications to skip setting this largish > > > control, > > > reducing the amount of data that needs to be passed from userspace > > > -- especially when not needed :-) > > > > > > > > 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 > > > > > --- > > > > > v2: Fix missing Cedrus changes and mssing control declaration, > > > > > > > > > > as noted by Hans and Jernej. > > > > > > > > > > --- > > > > > > > > > > .../media/v4l/ext-ctrls-codec.rst | 19 > > > > > --- > > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 8 > > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++ > > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ > > > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++ > > > > > include/media/h264-ctrls.h| 5 +++-- > > > > > include/media/v4l2-ctrls.h| 2 ++ > > > > > 8 files changed, 37 insertions(+), 13 deletions(-) > > > > > > > > > > diff --git > > > > > a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > > > > > d1438b1e259f..c36ce5a95fc5 100644 > > > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > @@ -1879,18 +1879,23 @@ enum > > > > > v4l2_mpeg_video_h264_hierarchical_coding_type -> > > > > > > > > > > >- 0x0008 > > > > >- > > > > > > > > > > -``Prediction Weight Table`` > > > > > +``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS (struct)`` > > > > > +Prediction weight table defined according to :ref:`h264`, > > > > > +section 7.4.3.2 "Prediction Weight Table Semantics". > > > > > +The prediction weight table must be passed by applications > > > > > +under the conditions explaine
Re: [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters
Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia napisal(a): > On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote: > > On 2020-08-06 17:12, Ezequiel Garcia wrote: > > > The prediction weight parameters are only required under > > > certain conditions, which depend on slice header parameters. > > > > > > As specified in section 7.3.3 Slice header syntax, the prediction > > > weight table is present if: > > > > > > ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ > > > (weighted_bipred_idc == 1 && slice_type == B)) > > > > Maybe a macro can be added to help check this contition? > > > > Something like this maybe: > > > > #define V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED(pps, slice) \ > > > > pps)->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) && \ > > > > ((slice)->slice_type == V4L2_H264_SLICE_TYPE_P || \ > > > >(slice)->slice_type == V4L2_H264_SLICE_TYPE_SP)) || \ > > > > ((pps)->weighted_bipred_idc == 1 && \ > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_B)) > > Yeah, that could make sense. > > Note that the biggest value in having the prediction weight table > separated is to allow applications to skip setting this largish control, > reducing the amount of data that needs to be passed from userspace > -- especially when not needed :-) > > > > 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 > > > --- > > > v2: Fix missing Cedrus changes and mssing control declaration, > > > > > > as noted by Hans and Jernej. > > > > > > --- > > > > > > .../media/v4l/ext-ctrls-codec.rst | 19 --- > > > drivers/media/v4l2-core/v4l2-ctrls.c | 8 > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++ > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++ > > > include/media/h264-ctrls.h| 5 +++-- > > > include/media/v4l2-ctrls.h| 2 ++ > > > 8 files changed, 37 insertions(+), 13 deletions(-) > > > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > > > d1438b1e259f..c36ce5a95fc5 100644 > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > @@ -1879,18 +1879,23 @@ enum > > > v4l2_mpeg_video_h264_hierarchical_coding_type -> > > > >- 0x0008 > > >- > > > > > > -``Prediction Weight Table`` > > > +``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS (struct)`` > > > +Prediction weight table defined according to :ref:`h264`, > > > +section 7.4.3.2 "Prediction Weight Table Semantics". > > > +The prediction weight table must be passed by applications > > > +under the conditions explained in section 7.3.3 "Slice header > > > +syntax". > > > > > > -The bitstream parameters are 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. > > > +.. note:: > > > + > > > + This compound control is not yet part of the public kernel API > > > and > > > + it is expected to change. > > > > > > -.. c:type:: v4l2_h264_pred_weight_table > > > +.. c:type:: v4l2_ctrl_h264_pred_weights > > > > > > .. cssclass:: longtable > > > > > > -.. flat-table:: struct v4l2_h264_pred_weight_table > > > +.. flat-table:: struct v4l2_ctrl_h264_pred_weights > > > > > > :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..76c8dc8fb31c > > > 100644 > > > --- a/drivers/media/v4l2-core/v4l2-ctrls.c > > > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c > > > @@ -897,6 +897,7 @@ const char *v4l2_ctrl_get_name(u32 id) > > > > > > case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS:return > > > "H264 Decode Parameters"; case > > > V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE: return "H264 > > > Decode Mode"; case V4L2_CID_MPEG_VIDEO_H264_START_CODE: > > > return "H264 Start Code";> > > > > + case V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS: return > > > "H264 Prediction Weight Table";> > > > > case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL: return > > >
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 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] = &cedrus_dec_ops_mpeg2;
> > dev->dec_ops[CEDRUS_CODEC_H264] = &cedrus_dec_ops_h264;
> > dev->dec_ops[CEDRUS_CODEC_H265] = &cedrus_dec_ops_h265;
> >
> > + dev->dec_ops[CEDRUS_CODEC_VP8] = &cedrus_dec_ops_vp8;
> >
> > mutex_init(&dev->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 cedru
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 = dpb[i
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: [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 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 = <&hdmi>;
> > + };
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <&i2s1>;
> > + 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: [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 = <&hdmi>;
> > + };
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <&i2s2>;
> > + 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 = <&ccu RST_BUS_I2S2>;
> > dma-names = "tx";
> > dmas = <&dma 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 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 = &decode->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 V
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 = &decode->dpb[dpb_idx];
> > >
> > > if (!(dpb->flags & V4L2_H264_DPB
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] 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: 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 quiet
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 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 e-m
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: [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 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 = &run->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
> > +++ b/drivers/staging/media/sunxi/ce
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 flu
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 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(&m2m_dev->job_spinlock, flags);
> if (!m2m_dev->curr_ctx || m2m_dev->curr_ctx != m2m_ctx) {
> - spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
> dprintk("Called by an instance not currently
running\n");
> - return;
> + return false;
> }
>
> list_del(&m2m_dev->curr_ctx->queue);
> m2m_dev->curr_ctx->job_flags &= ~(TRANS_QUEUED | TRAN
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 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 > > > > > > > > > > &
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 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 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/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(-)
