mbox series

[v3,0/6] Enable decoder for mt8183

Message ID 20230620000349.2122191-1-nfraprado@collabora.com
Headers show
Series Enable decoder for mt8183 | expand

Message

Nícolas F. R. A. Prado June 20, 2023, 12:03 a.m. UTC
This series enables the hardware decoder present on mt8183. At first
glance, the only missing piece is the devicetree node for it, however,
simply adding it as is would cause an address collision between the
first register iospace and the clock-controller node, so a rework of the
dt-binding and driver, as well as addition of a new syscon phandle
property, were needed first.

Tested that H264 decoding works with the hardware decoder on
mt8183-kukui-jacuzzi-juniper-sku16, giving a fluster score of 98/135 on
the JVT-AVC_V1 test suite. And ensured other SoCs (MT8192 and MT8195)
still work as usual.

Changes in v3:
- Switched the handling of the VDEC_HW_ACTIVE bit to use a syscon
  instead of the 'active' clock

Changes in v2:
- Merged commit 1 (media: dt-bindings: mediatek,vcodec: Allow single
  clock for mt8183) into commit 3 (media: dt-bindings: mediatek,vcodec:
  Remove VDEC_SYS for mt8183)
- Further constrained properties in dt-binding
- Added CLK_IGNORE_UNUSED flag to active clock
- Reformatted reg-names in DT node

Nícolas F. R. A. Prado (5):
  media: dt-bindings: mediatek,vcodec: Allow single clock for mt8183
  media: dt-bindings: mediatek,vcodec: Don't require assigned-clocks
  media: dt-bindings: mediatek,vcodec: Remove VDEC_SYS for mt8183
  media: mediatek: vcodec: Define address for VDEC_HW_ACTIVE
  media: mediatek: vcodec: Read HW active status from syscon on MT8183

Yunfei Dong (1):
  arm64: dts: mediatek: mt8183: Add decoder

 .../media/mediatek,vcodec-decoder.yaml        | 69 +++++++++++++++---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 30 ++++++++
 .../mediatek/vcodec/mtk_vcodec_dec_drv.c      | 71 ++++++++++++++++---
 .../mediatek/vcodec/mtk_vcodec_dec_hw.c       |  4 +-
 .../mediatek/vcodec/mtk_vcodec_dec_hw.h       |  3 +-
 .../platform/mediatek/vcodec/mtk_vcodec_drv.h |  1 +
 6 files changed, 153 insertions(+), 25 deletions(-)

Comments

Krzysztof Kozlowski June 23, 2023, 4:21 p.m. UTC | #1
On 21/06/2023 20:00, Nícolas F. R. A. Prado wrote:
>>
>> But anyway this variant comes with some set of regs and reg-names. Other
>> variant comes with different set. In all cases they should be defined,
>> even by "defined" means not allowed.
> 
> I'm not sure what you mean. Are you suggesting to disable reg-names on mt8173?

That's one of the options if for some reason you don't want to define them.

> 
>>
>>>
>>> But in a separate series we could drop vdecsys from mt8173's reg as well,
>>> passing it as a syscon instead, which would solve the warning on that platform,
>>> though some more driver changes would be needed to be able to handle it for that
>>> SoC. The newer SoCs like mt8192, mt8195, etc, should also get vdecsys dropped
>>> from their regs to have a correct memory description.
>>>
>>
>> Sure, but I don't understand how does it affect defining and making
>> specific regs/reg-names or keeping them loose.
> 
> We need some way to tell in the driver whether the first reg is VDEC_SYS or not.
> Since so far reg-names have not been used for the vcodec, the simplest, and
> cleanest, way to do it, is to add reg-names when VDEC_SYS is not present. When
> the other SoCs are updated to no longer have the first reg as VDEC_SYS, they
> would also have reg-names added to their binding, to clearly indicate that.

Don't use reg-names for that. The order of entries is anyway strict.

> 
> For example, for mt8173 we currently have
> 
> 		vcodec_dec: vcodec@16000000 {
> 			compatible = "mediatek,mt8173-vcodec-dec";
> 			reg = <0 0x16000000 0 0x100>,	/* VDEC_SYS */
> 			      <0 0x16020000 0 0x1000>,	/* VDEC_MISC */
> 			      <0 0x16021000 0 0x800>,	/* VDEC_LD */
> 			      <0 0x16021800 0 0x800>,	/* VDEC_TOP */
> 			      <0 0x16022000 0 0x1000>,	/* VDEC_CM */
> 			      <0 0x16023000 0 0x1000>,	/* VDEC_AD */
> 			      <0 0x16024000 0 0x1000>,	/* VDEC_AV */
> 			      <0 0x16025000 0 0x1000>,	/* VDEC_PP */
> 			      <0 0x16026800 0 0x800>,	/* VDEC_HWD */
> 			      <0 0x16027000 0 0x800>,	/* VDEC_HWQ */
> 			      <0 0x16027800 0 0x800>,	/* VDEC_HWB */
> 			      <0 0x16028400 0 0x400>;	/* VDEC_HWG */
> 
> In a future series, when removing VDEC_SYS from it, it would become
> 
> 		vcodec_dec: vcodec@16020000 {
> 			compatible = "mediatek,mt8173-vcodec-dec";
> 			reg = <0 0x16020000 0 0x1000>,	/* VDEC_MISC */
> 			      <0 0x16021000 0 0x800>,	/* VDEC_LD */
> 			      <0 0x16021800 0 0x800>,	/* VDEC_TOP */
> 			      <0 0x16022000 0 0x1000>,	/* VDEC_CM */
> 			      <0 0x16023000 0 0x1000>,	/* VDEC_AD */
> 			      <0 0x16024000 0 0x1000>,	/* VDEC_AV */
> 			      <0 0x16025000 0 0x1000>,	/* VDEC_PP */
> 			      <0 0x16026800 0 0x800>,	/* VDEC_HWD */
> 			      <0 0x16027000 0 0x800>,	/* VDEC_HWQ */
> 			      <0 0x16027800 0 0x800>,	/* VDEC_HWB */
> 			      <0 0x16028400 0 0x400>;	/* VDEC_HWG */
> 			reg-names = "misc", "ld", "top", "cm", "ad", "av", "pp",
>                                     "hwd", "hwq", "hwb", "hwg";

So you want to use reg-names to avoid ABI break. This is not the reason
not to define reg-names for other case.



Best regards,
Krzysztof
Krzysztof Kozlowski June 26, 2023, 3:30 p.m. UTC | #2
On 26/06/2023 15:54, Nícolas F. R. A. Prado wrote:
> On Fri, Jun 23, 2023 at 06:21:31PM +0200, Krzysztof Kozlowski wrote:
>> On 21/06/2023 20:00, Nícolas F. R. A. Prado wrote:
>>>>
>>>> But anyway this variant comes with some set of regs and reg-names. Other
>>>> variant comes with different set. In all cases they should be defined,
>>>> even by "defined" means not allowed.
>>>
>>> I'm not sure what you mean. Are you suggesting to disable reg-names on mt8173?
>>
>> That's one of the options if for some reason you don't want to define them.
>>
>>>
>>>>
>>>>>
>>>>> But in a separate series we could drop vdecsys from mt8173's reg as well,
>>>>> passing it as a syscon instead, which would solve the warning on that platform,
>>>>> though some more driver changes would be needed to be able to handle it for that
>>>>> SoC. The newer SoCs like mt8192, mt8195, etc, should also get vdecsys dropped
>>>>> from their regs to have a correct memory description.
>>>>>
>>>>
>>>> Sure, but I don't understand how does it affect defining and making
>>>> specific regs/reg-names or keeping them loose.
>>>
>>> We need some way to tell in the driver whether the first reg is VDEC_SYS or not.
>>> Since so far reg-names have not been used for the vcodec, the simplest, and
>>> cleanest, way to do it, is to add reg-names when VDEC_SYS is not present. When
>>> the other SoCs are updated to no longer have the first reg as VDEC_SYS, they
>>> would also have reg-names added to their binding, to clearly indicate that.
>>
>> Don't use reg-names for that. The order of entries is anyway strict.
> 
> Since the order of entries is strict, if I remove VDEC_SYS from mt8183, I also
> need to remove it from mt8173, is that what you mean?

It's different compatible, so it can have different entries.


> I would still check for
> the presence of reg-names in the driver to differentiate whether the old or new
> binding is used, you just don't want different reg-names between compatibles in
> the binding?

I wrote already what I want:

  In all cases they should be defined, even by "defined" means not allowed.

Now of course the best would be if the reg-names are always the same, at
least in respect of order of items. This is what we try to do for all
devices.

> 
>>
>>>
>>> For example, for mt8173 we currently have
>>>
>>> 		vcodec_dec: vcodec@16000000 {
>>> 			compatible = "mediatek,mt8173-vcodec-dec";
>>> 			reg = <0 0x16000000 0 0x100>,	/* VDEC_SYS */
>>> 			      <0 0x16020000 0 0x1000>,	/* VDEC_MISC */
>>> 			      <0 0x16021000 0 0x800>,	/* VDEC_LD */
>>> 			      <0 0x16021800 0 0x800>,	/* VDEC_TOP */
>>> 			      <0 0x16022000 0 0x1000>,	/* VDEC_CM */
>>> 			      <0 0x16023000 0 0x1000>,	/* VDEC_AD */
>>> 			      <0 0x16024000 0 0x1000>,	/* VDEC_AV */
>>> 			      <0 0x16025000 0 0x1000>,	/* VDEC_PP */
>>> 			      <0 0x16026800 0 0x800>,	/* VDEC_HWD */
>>> 			      <0 0x16027000 0 0x800>,	/* VDEC_HWQ */
>>> 			      <0 0x16027800 0 0x800>,	/* VDEC_HWB */
>>> 			      <0 0x16028400 0 0x400>;	/* VDEC_HWG */
>>>
>>> In a future series, when removing VDEC_SYS from it, it would become
>>>
>>> 		vcodec_dec: vcodec@16020000 {
>>> 			compatible = "mediatek,mt8173-vcodec-dec";
>>> 			reg = <0 0x16020000 0 0x1000>,	/* VDEC_MISC */
>>> 			      <0 0x16021000 0 0x800>,	/* VDEC_LD */
>>> 			      <0 0x16021800 0 0x800>,	/* VDEC_TOP */
>>> 			      <0 0x16022000 0 0x1000>,	/* VDEC_CM */
>>> 			      <0 0x16023000 0 0x1000>,	/* VDEC_AD */
>>> 			      <0 0x16024000 0 0x1000>,	/* VDEC_AV */
>>> 			      <0 0x16025000 0 0x1000>,	/* VDEC_PP */
>>> 			      <0 0x16026800 0 0x800>,	/* VDEC_HWD */
>>> 			      <0 0x16027000 0 0x800>,	/* VDEC_HWQ */
>>> 			      <0 0x16027800 0 0x800>,	/* VDEC_HWB */
>>> 			      <0 0x16028400 0 0x400>;	/* VDEC_HWG */
>>> 			reg-names = "misc", "ld", "top", "cm", "ad", "av", "pp",
>>>                                     "hwd", "hwq", "hwb", "hwg";
>>
>> So you want to use reg-names to avoid ABI break. This is not the reason
>> not to define reg-names for other case.
> 
> There will be an ABI break anyway when the first reg is removed (as shown
> above), I'm just trying to avoid churn: adding a reg-name that will be removed
> later.

So remove the reg-name now and there will be no "later"?

Best regards,
Krzysztof