* [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: linux-kernel, linux-arm-kernel, mjourdan, Martin Blumenstingl This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas IP is used by the video decoder hardware as well as the VPU (video output) hardware. Neither the VPU nor the video decoder driver support the 32-bit SoCs yet. However, we can still add the canvas module to have it available once these drivers gain support for the older SoCs. I have tested this on my Meson8m2 board by hacking the VPU driver to not re-initialize the VPU (and to use the configuration set by u-boot). With that hack I could get some image out of the CVBS connector. No changes to the canvas driver were required. Due to lack of hardware I could not test Meson8, but I'm following (as always) what the Amlogic 3.10 vendor kernel uses. Meson8b is also not tested because u-boot of my EC-100 doesn't have video output enabled (so I couldn't use the same hack I used on my Meson8m2 board). This series meant to be applied on top of "Meson8b: add support for the RTC on EC-100 and Odroid-C1" from [0] [0] https://patchwork.kernel.org/cover/10899509/ Martin Blumenstingl (3): ARM: dts: meson8: add the canvas module ARM: dts: meson8m2: update the offset of the canvas module ARM: dts: meson8b: add the canvas module arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ 3 files changed, 52 insertions(+) -- 2.21.0 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas IP is used by the video decoder hardware as well as the VPU (video output) hardware. Neither the VPU nor the video decoder driver support the 32-bit SoCs yet. However, we can still add the canvas module to have it available once these drivers gain support for the older SoCs. I have tested this on my Meson8m2 board by hacking the VPU driver to not re-initialize the VPU (and to use the configuration set by u-boot). With that hack I could get some image out of the CVBS connector. No changes to the canvas driver were required. Due to lack of hardware I could not test Meson8, but I'm following (as always) what the Amlogic 3.10 vendor kernel uses. Meson8b is also not tested because u-boot of my EC-100 doesn't have video output enabled (so I couldn't use the same hack I used on my Meson8m2 board). This series meant to be applied on top of "Meson8b: add support for the RTC on EC-100 and Odroid-C1" from [0] [0] https://patchwork.kernel.org/cover/10899509/ Martin Blumenstingl (3): ARM: dts: meson8: add the canvas module ARM: dts: meson8m2: update the offset of the canvas module ARM: dts: meson8b: add the canvas module arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ 3 files changed, 52 insertions(+) -- 2.21.0 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas IP is used by the video decoder hardware as well as the VPU (video output) hardware. Neither the VPU nor the video decoder driver support the 32-bit SoCs yet. However, we can still add the canvas module to have it available once these drivers gain support for the older SoCs. I have tested this on my Meson8m2 board by hacking the VPU driver to not re-initialize the VPU (and to use the configuration set by u-boot). With that hack I could get some image out of the CVBS connector. No changes to the canvas driver were required. Due to lack of hardware I could not test Meson8, but I'm following (as always) what the Amlogic 3.10 vendor kernel uses. Meson8b is also not tested because u-boot of my EC-100 doesn't have video output enabled (so I couldn't use the same hack I used on my Meson8m2 board). This series meant to be applied on top of "Meson8b: add support for the RTC on EC-100 and Odroid-C1" from [0] [0] https://patchwork.kernel.org/cover/10899509/ Martin Blumenstingl (3): ARM: dts: meson8: add the canvas module ARM: dts: meson8m2: update the offset of the canvas module ARM: dts: meson8b: add the canvas module arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ 3 files changed, 52 insertions(+) -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 1/3] ARM: dts: meson8: add the canvas module 2019-04-13 17:15 ` Martin Blumenstingl (?) @ 2019-04-13 17:15 ` Martin Blumenstingl -1 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: linux-kernel, linux-arm-kernel, mjourdan, Martin Blumenstingl Add the canvas module to Meson8 because it's required for the VPU (video output) and video decoders. The canvas module is located inside thie "DMC bus" (where also some of the memory controller registers are located). The "DMC bus" itself is part of the so-called "MMC bus". Amlogic's vendor kernel has an explicit #define for the "DMC" register range on Meson8m2 while there's no such #define for Meson8. However, the canvas and memory controller registers on Meson8 are all expressed as "0x6000 + actual offset", while Meson8m2 uses "DMC + actual offset". Thus it's safe to assume that the DMC bus exists on both SoCs even though the registers inside are slightly different. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi index 7ef442462ea4..6b5c90bb960b 100644 --- a/arch/arm/boot/dts/meson8.dtsi +++ b/arch/arm/boot/dts/meson8.dtsi @@ -228,6 +228,27 @@ }; }; + mmcbus: bus@c8000000 { + compatible = "simple-bus"; + reg = <0xc8000000 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc8000000 0x8000>; + + dmcbus: bus@6000 { + compatible = "simple-bus"; + reg = <0x6000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x6000 0x400>; + + canvas: video-lut@20 { + compatible = "amlogic,canvas"; + reg = <0x20 0x14>; + }; + }; + }; + apb: bus@d0000000 { compatible = "simple-bus"; reg = <0xd0000000 0x200000>; -- 2.21.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 1/3] ARM: dts: meson8: add the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel Add the canvas module to Meson8 because it's required for the VPU (video output) and video decoders. The canvas module is located inside thie "DMC bus" (where also some of the memory controller registers are located). The "DMC bus" itself is part of the so-called "MMC bus". Amlogic's vendor kernel has an explicit #define for the "DMC" register range on Meson8m2 while there's no such #define for Meson8. However, the canvas and memory controller registers on Meson8 are all expressed as "0x6000 + actual offset", while Meson8m2 uses "DMC + actual offset". Thus it's safe to assume that the DMC bus exists on both SoCs even though the registers inside are slightly different. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi index 7ef442462ea4..6b5c90bb960b 100644 --- a/arch/arm/boot/dts/meson8.dtsi +++ b/arch/arm/boot/dts/meson8.dtsi @@ -228,6 +228,27 @@ }; }; + mmcbus: bus@c8000000 { + compatible = "simple-bus"; + reg = <0xc8000000 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc8000000 0x8000>; + + dmcbus: bus@6000 { + compatible = "simple-bus"; + reg = <0x6000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x6000 0x400>; + + canvas: video-lut@20 { + compatible = "amlogic,canvas"; + reg = <0x20 0x14>; + }; + }; + }; + apb: bus@d0000000 { compatible = "simple-bus"; reg = <0xd0000000 0x200000>; -- 2.21.0 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 1/3] ARM: dts: meson8: add the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel Add the canvas module to Meson8 because it's required for the VPU (video output) and video decoders. The canvas module is located inside thie "DMC bus" (where also some of the memory controller registers are located). The "DMC bus" itself is part of the so-called "MMC bus". Amlogic's vendor kernel has an explicit #define for the "DMC" register range on Meson8m2 while there's no such #define for Meson8. However, the canvas and memory controller registers on Meson8 are all expressed as "0x6000 + actual offset", while Meson8m2 uses "DMC + actual offset". Thus it's safe to assume that the DMC bus exists on both SoCs even though the registers inside are slightly different. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi index 7ef442462ea4..6b5c90bb960b 100644 --- a/arch/arm/boot/dts/meson8.dtsi +++ b/arch/arm/boot/dts/meson8.dtsi @@ -228,6 +228,27 @@ }; }; + mmcbus: bus@c8000000 { + compatible = "simple-bus"; + reg = <0xc8000000 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc8000000 0x8000>; + + dmcbus: bus@6000 { + compatible = "simple-bus"; + reg = <0x6000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x6000 0x400>; + + canvas: video-lut@20 { + compatible = "amlogic,canvas"; + reg = <0x20 0x14>; + }; + }; + }; + apb: bus@d0000000 { compatible = "simple-bus"; reg = <0xd0000000 0x200000>; -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 2/3] ARM: dts: meson8m2: update the offset of the canvas module 2019-04-13 17:15 ` Martin Blumenstingl (?) @ 2019-04-13 17:15 ` Martin Blumenstingl -1 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: linux-kernel, linux-arm-kernel, mjourdan, Martin Blumenstingl With the Meson8m2 SoC the canvas module was moved from offset 0x20 (Meson8) to offset 0x48 (same as on Meson8b). The offsets inside the canvas module are identical. Correct the offset so the driver uses the correct registers. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/meson8m2.dtsi b/arch/arm/boot/dts/meson8m2.dtsi index bb87b251e16d..e88c36d47e5c 100644 --- a/arch/arm/boot/dts/meson8m2.dtsi +++ b/arch/arm/boot/dts/meson8m2.dtsi @@ -14,6 +14,16 @@ compatible = "amlogic,meson8m2-clkc", "amlogic,meson8-clkc"; }; +&dmcbus { + /* the offset of the canvas registers has changed compared to Meson8 */ + /delete-node/ video-lut@20; + + canvas: video-lut@48 { + compatible = "amlogic,canvas"; + reg = <0x48 0x14>; + }; +}; + ðmac { compatible = "amlogic,meson8m2-dwmac", "snps,dwmac"; reg = <0xc9410000 0x10000 -- 2.21.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 2/3] ARM: dts: meson8m2: update the offset of the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel With the Meson8m2 SoC the canvas module was moved from offset 0x20 (Meson8) to offset 0x48 (same as on Meson8b). The offsets inside the canvas module are identical. Correct the offset so the driver uses the correct registers. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/meson8m2.dtsi b/arch/arm/boot/dts/meson8m2.dtsi index bb87b251e16d..e88c36d47e5c 100644 --- a/arch/arm/boot/dts/meson8m2.dtsi +++ b/arch/arm/boot/dts/meson8m2.dtsi @@ -14,6 +14,16 @@ compatible = "amlogic,meson8m2-clkc", "amlogic,meson8-clkc"; }; +&dmcbus { + /* the offset of the canvas registers has changed compared to Meson8 */ + /delete-node/ video-lut@20; + + canvas: video-lut@48 { + compatible = "amlogic,canvas"; + reg = <0x48 0x14>; + }; +}; + ðmac { compatible = "amlogic,meson8m2-dwmac", "snps,dwmac"; reg = <0xc9410000 0x10000 -- 2.21.0 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 2/3] ARM: dts: meson8m2: update the offset of the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel With the Meson8m2 SoC the canvas module was moved from offset 0x20 (Meson8) to offset 0x48 (same as on Meson8b). The offsets inside the canvas module are identical. Correct the offset so the driver uses the correct registers. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/meson8m2.dtsi b/arch/arm/boot/dts/meson8m2.dtsi index bb87b251e16d..e88c36d47e5c 100644 --- a/arch/arm/boot/dts/meson8m2.dtsi +++ b/arch/arm/boot/dts/meson8m2.dtsi @@ -14,6 +14,16 @@ compatible = "amlogic,meson8m2-clkc", "amlogic,meson8-clkc"; }; +&dmcbus { + /* the offset of the canvas registers has changed compared to Meson8 */ + /delete-node/ video-lut@20; + + canvas: video-lut@48 { + compatible = "amlogic,canvas"; + reg = <0x48 0x14>; + }; +}; + ðmac { compatible = "amlogic,meson8m2-dwmac", "snps,dwmac"; reg = <0xc9410000 0x10000 -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 3/3] ARM: dts: meson8b: add the canvas module 2019-04-13 17:15 ` Martin Blumenstingl (?) @ 2019-04-13 17:15 ` Martin Blumenstingl -1 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: linux-kernel, linux-arm-kernel, mjourdan, Martin Blumenstingl Add the canvas module to Meson8b because it's required for the VPU (video output) and video decoders. The canvas module is located inside the "DMC bus" (where also some of the memory controller registers are located). The "DMC bus" itself is part of the so-called "MMC bus". Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi index 800cd65fc50a..f4e832638e9c 100644 --- a/arch/arm/boot/dts/meson8b.dtsi +++ b/arch/arm/boot/dts/meson8b.dtsi @@ -205,6 +205,27 @@ }; }; + mmcbus: bus@c8000000 { + compatible = "simple-bus"; + reg = <0xc8000000 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc8000000 0x8000>; + + dmcbus: bus@6000 { + compatible = "simple-bus"; + reg = <0x6000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x6000 0x400>; + + canvas: video-lut@48 { + compatible = "amlogic,canvas"; + reg = <0x48 0x14>; + }; + }; + }; + apb: bus@d0000000 { compatible = "simple-bus"; reg = <0xd0000000 0x200000>; -- 2.21.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 3/3] ARM: dts: meson8b: add the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel Add the canvas module to Meson8b because it's required for the VPU (video output) and video decoders. The canvas module is located inside the "DMC bus" (where also some of the memory controller registers are located). The "DMC bus" itself is part of the so-called "MMC bus". Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi index 800cd65fc50a..f4e832638e9c 100644 --- a/arch/arm/boot/dts/meson8b.dtsi +++ b/arch/arm/boot/dts/meson8b.dtsi @@ -205,6 +205,27 @@ }; }; + mmcbus: bus@c8000000 { + compatible = "simple-bus"; + reg = <0xc8000000 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc8000000 0x8000>; + + dmcbus: bus@6000 { + compatible = "simple-bus"; + reg = <0x6000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x6000 0x400>; + + canvas: video-lut@48 { + compatible = "amlogic,canvas"; + reg = <0x48 0x14>; + }; + }; + }; + apb: bus@d0000000 { compatible = "simple-bus"; reg = <0xd0000000 0x200000>; -- 2.21.0 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 3/3] ARM: dts: meson8b: add the canvas module @ 2019-04-13 17:15 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-13 17:15 UTC (permalink / raw) To: linux-amlogic, khilman Cc: mjourdan, Martin Blumenstingl, linux-kernel, linux-arm-kernel Add the canvas module to Meson8b because it's required for the VPU (video output) and video decoders. The canvas module is located inside the "DMC bus" (where also some of the memory controller registers are located). The "DMC bus" itself is part of the so-called "MMC bus". Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> --- arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi index 800cd65fc50a..f4e832638e9c 100644 --- a/arch/arm/boot/dts/meson8b.dtsi +++ b/arch/arm/boot/dts/meson8b.dtsi @@ -205,6 +205,27 @@ }; }; + mmcbus: bus@c8000000 { + compatible = "simple-bus"; + reg = <0xc8000000 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xc8000000 0x8000>; + + dmcbus: bus@6000 { + compatible = "simple-bus"; + reg = <0x6000 0x400>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x6000 0x400>; + + canvas: video-lut@48 { + compatible = "amlogic,canvas"; + reg = <0x48 0x14>; + }; + }; + }; + apb: bus@d0000000 { compatible = "simple-bus"; reg = <0xd0000000 0x200000>; -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module 2019-04-13 17:15 ` Martin Blumenstingl (?) @ 2019-04-13 18:54 ` Maxime Jourdan -1 siblings, 0 replies; 24+ messages in thread From: Maxime Jourdan @ 2019-04-13 18:54 UTC (permalink / raw) To: Martin Blumenstingl Cc: linux-amlogic, Kevin Hilman, mjourdan, Linux Kernel Mailing List, linux-arm-kernel Hi Martin, On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > IP is used by the video decoder hardware as well as the VPU (video > output) hardware. > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > yet. However, we can still add the canvas module to have it available > once these drivers gain support for the older SoCs. > > I have tested this on my Meson8m2 board by hacking the VPU driver to > not re-initialize the VPU (and to use the configuration set by u-boot). > With that hack I could get some image out of the CVBS connector. No > changes to the canvas driver were required. > > Due to lack of hardware I could not test Meson8, but I'm following (as > always) what the Amlogic 3.10 vendor kernel uses. > Meson8b is also not tested because u-boot of my EC-100 doesn't have > video output enabled (so I couldn't use the same hack I used on my > Meson8m2 board). > > This series meant to be applied on top of "Meson8b: add support for the > RTC on EC-100 and Odroid-C1" from [0] > > The series looks good to me, however I wonder if we should maybe add a new compatible ? The canvas IP before the GX* generation does not handle what Amlogic calls "endianness", the field that allows doing some byte-switching to get proper NV12/NV21. So the following defines are unusable: #define MESON_CANVAS_ENDIAN_SWAP16 0x1 #define MESON_CANVAS_ENDIAN_SWAP32 0x3 #define MESON_CANVAS_ENDIAN_SWAP64 0x7 #define MESON_CANVAS_ENDIAN_SWAP128 0xf It wouldn't change much functionally, but we could have e.g a warning if a m8 canvas user tries to set endianness even though it does nothing. Maxime > [0] https://patchwork.kernel.org/cover/10899509/ > > > Martin Blumenstingl (3): > ARM: dts: meson8: add the canvas module > ARM: dts: meson8m2: update the offset of the canvas module > ARM: dts: meson8b: add the canvas module > > arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ > arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ > arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ > 3 files changed, 52 insertions(+) > > -- > 2.21.0 > > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-04-13 18:54 ` Maxime Jourdan 0 siblings, 0 replies; 24+ messages in thread From: Maxime Jourdan @ 2019-04-13 18:54 UTC (permalink / raw) To: Martin Blumenstingl Cc: mjourdan, linux-amlogic, Linux Kernel Mailing List, linux-arm-kernel, Kevin Hilman Hi Martin, On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > IP is used by the video decoder hardware as well as the VPU (video > output) hardware. > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > yet. However, we can still add the canvas module to have it available > once these drivers gain support for the older SoCs. > > I have tested this on my Meson8m2 board by hacking the VPU driver to > not re-initialize the VPU (and to use the configuration set by u-boot). > With that hack I could get some image out of the CVBS connector. No > changes to the canvas driver were required. > > Due to lack of hardware I could not test Meson8, but I'm following (as > always) what the Amlogic 3.10 vendor kernel uses. > Meson8b is also not tested because u-boot of my EC-100 doesn't have > video output enabled (so I couldn't use the same hack I used on my > Meson8m2 board). > > This series meant to be applied on top of "Meson8b: add support for the > RTC on EC-100 and Odroid-C1" from [0] > > The series looks good to me, however I wonder if we should maybe add a new compatible ? The canvas IP before the GX* generation does not handle what Amlogic calls "endianness", the field that allows doing some byte-switching to get proper NV12/NV21. So the following defines are unusable: #define MESON_CANVAS_ENDIAN_SWAP16 0x1 #define MESON_CANVAS_ENDIAN_SWAP32 0x3 #define MESON_CANVAS_ENDIAN_SWAP64 0x7 #define MESON_CANVAS_ENDIAN_SWAP128 0xf It wouldn't change much functionally, but we could have e.g a warning if a m8 canvas user tries to set endianness even though it does nothing. Maxime > [0] https://patchwork.kernel.org/cover/10899509/ > > > Martin Blumenstingl (3): > ARM: dts: meson8: add the canvas module > ARM: dts: meson8m2: update the offset of the canvas module > ARM: dts: meson8b: add the canvas module > > arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ > arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ > arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ > 3 files changed, 52 insertions(+) > > -- > 2.21.0 > > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-04-13 18:54 ` Maxime Jourdan 0 siblings, 0 replies; 24+ messages in thread From: Maxime Jourdan @ 2019-04-13 18:54 UTC (permalink / raw) To: Martin Blumenstingl Cc: mjourdan, linux-amlogic, Linux Kernel Mailing List, linux-arm-kernel, Kevin Hilman Hi Martin, On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > IP is used by the video decoder hardware as well as the VPU (video > output) hardware. > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > yet. However, we can still add the canvas module to have it available > once these drivers gain support for the older SoCs. > > I have tested this on my Meson8m2 board by hacking the VPU driver to > not re-initialize the VPU (and to use the configuration set by u-boot). > With that hack I could get some image out of the CVBS connector. No > changes to the canvas driver were required. > > Due to lack of hardware I could not test Meson8, but I'm following (as > always) what the Amlogic 3.10 vendor kernel uses. > Meson8b is also not tested because u-boot of my EC-100 doesn't have > video output enabled (so I couldn't use the same hack I used on my > Meson8m2 board). > > This series meant to be applied on top of "Meson8b: add support for the > RTC on EC-100 and Odroid-C1" from [0] > > The series looks good to me, however I wonder if we should maybe add a new compatible ? The canvas IP before the GX* generation does not handle what Amlogic calls "endianness", the field that allows doing some byte-switching to get proper NV12/NV21. So the following defines are unusable: #define MESON_CANVAS_ENDIAN_SWAP16 0x1 #define MESON_CANVAS_ENDIAN_SWAP32 0x3 #define MESON_CANVAS_ENDIAN_SWAP64 0x7 #define MESON_CANVAS_ENDIAN_SWAP128 0xf It wouldn't change much functionally, but we could have e.g a warning if a m8 canvas user tries to set endianness even though it does nothing. Maxime > [0] https://patchwork.kernel.org/cover/10899509/ > > > Martin Blumenstingl (3): > ARM: dts: meson8: add the canvas module > ARM: dts: meson8m2: update the offset of the canvas module > ARM: dts: meson8b: add the canvas module > > arch/arm/boot/dts/meson8.dtsi | 21 +++++++++++++++++++++ > arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++ > arch/arm/boot/dts/meson8m2.dtsi | 10 ++++++++++ > 3 files changed, 52 insertions(+) > > -- > 2.21.0 > > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module 2019-04-13 18:54 ` Maxime Jourdan (?) @ 2019-04-18 19:50 ` Martin Blumenstingl -1 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-18 19:50 UTC (permalink / raw) To: Maxime Jourdan Cc: linux-amlogic, Kevin Hilman, mjourdan, Linux Kernel Mailing List, linux-arm-kernel Hi Maxime, On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > Hi Martin, > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > IP is used by the video decoder hardware as well as the VPU (video > > output) hardware. > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > yet. However, we can still add the canvas module to have it available > > once these drivers gain support for the older SoCs. > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > not re-initialize the VPU (and to use the configuration set by u-boot). > > With that hack I could get some image out of the CVBS connector. No > > changes to the canvas driver were required. > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > always) what the Amlogic 3.10 vendor kernel uses. > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > video output enabled (so I couldn't use the same hack I used on my > > Meson8m2 board). > > > > This series meant to be applied on top of "Meson8b: add support for the > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > The series looks good to me, however I wonder if we should maybe add a > new compatible ? > > The canvas IP before the GX* generation does not handle what Amlogic > calls "endianness", the field that allows doing some byte-switching to > get proper NV12/NV21. So the following defines are unusable: > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > #define MESON_CANVAS_ENDIAN_SWAP128 0xf I didn't know about this - thank you for pointing this out. your suggestions to add new compatible strings is a good idea for that case. Amlogic uses different defines for Meson8 and Meson8m2 in their vendor kernel and they keep Meson8b different. I will add three new compatibles, one for each SoC (Meson8, Meson8b, Meson8m2) just to be on the safe side if we discover differences in the canvas IP on these SoCs. what do you think? > It wouldn't change much functionally, but we could have e.g a warning > if a m8 canvas user tries to set endianness even though it does > nothing. this is a good idea, that will make it easier to spot why something doesn't work. we can also return -EINVAL, like you already do for the case where the canvas ID is already used. Martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-04-18 19:50 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-18 19:50 UTC (permalink / raw) To: Maxime Jourdan Cc: mjourdan, linux-amlogic, Linux Kernel Mailing List, linux-arm-kernel, Kevin Hilman Hi Maxime, On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > Hi Martin, > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > IP is used by the video decoder hardware as well as the VPU (video > > output) hardware. > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > yet. However, we can still add the canvas module to have it available > > once these drivers gain support for the older SoCs. > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > not re-initialize the VPU (and to use the configuration set by u-boot). > > With that hack I could get some image out of the CVBS connector. No > > changes to the canvas driver were required. > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > always) what the Amlogic 3.10 vendor kernel uses. > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > video output enabled (so I couldn't use the same hack I used on my > > Meson8m2 board). > > > > This series meant to be applied on top of "Meson8b: add support for the > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > The series looks good to me, however I wonder if we should maybe add a > new compatible ? > > The canvas IP before the GX* generation does not handle what Amlogic > calls "endianness", the field that allows doing some byte-switching to > get proper NV12/NV21. So the following defines are unusable: > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > #define MESON_CANVAS_ENDIAN_SWAP128 0xf I didn't know about this - thank you for pointing this out. your suggestions to add new compatible strings is a good idea for that case. Amlogic uses different defines for Meson8 and Meson8m2 in their vendor kernel and they keep Meson8b different. I will add three new compatibles, one for each SoC (Meson8, Meson8b, Meson8m2) just to be on the safe side if we discover differences in the canvas IP on these SoCs. what do you think? > It wouldn't change much functionally, but we could have e.g a warning > if a m8 canvas user tries to set endianness even though it does > nothing. this is a good idea, that will make it easier to spot why something doesn't work. we can also return -EINVAL, like you already do for the case where the canvas ID is already used. Martin _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-04-18 19:50 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-04-18 19:50 UTC (permalink / raw) To: Maxime Jourdan Cc: mjourdan, linux-amlogic, Linux Kernel Mailing List, linux-arm-kernel, Kevin Hilman Hi Maxime, On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > Hi Martin, > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > IP is used by the video decoder hardware as well as the VPU (video > > output) hardware. > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > yet. However, we can still add the canvas module to have it available > > once these drivers gain support for the older SoCs. > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > not re-initialize the VPU (and to use the configuration set by u-boot). > > With that hack I could get some image out of the CVBS connector. No > > changes to the canvas driver were required. > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > always) what the Amlogic 3.10 vendor kernel uses. > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > video output enabled (so I couldn't use the same hack I used on my > > Meson8m2 board). > > > > This series meant to be applied on top of "Meson8b: add support for the > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > The series looks good to me, however I wonder if we should maybe add a > new compatible ? > > The canvas IP before the GX* generation does not handle what Amlogic > calls "endianness", the field that allows doing some byte-switching to > get proper NV12/NV21. So the following defines are unusable: > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > #define MESON_CANVAS_ENDIAN_SWAP128 0xf I didn't know about this - thank you for pointing this out. your suggestions to add new compatible strings is a good idea for that case. Amlogic uses different defines for Meson8 and Meson8m2 in their vendor kernel and they keep Meson8b different. I will add three new compatibles, one for each SoC (Meson8, Meson8b, Meson8m2) just to be on the safe side if we discover differences in the canvas IP on these SoCs. what do you think? > It wouldn't change much functionally, but we could have e.g a warning > if a m8 canvas user tries to set endianness even though it does > nothing. this is a good idea, that will make it easier to spot why something doesn't work. we can also return -EINVAL, like you already do for the case where the canvas ID is already used. Martin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module 2019-04-18 19:50 ` Martin Blumenstingl (?) @ 2019-05-20 19:21 ` Maxime Jourdan -1 siblings, 0 replies; 24+ messages in thread From: Maxime Jourdan @ 2019-05-20 19:21 UTC (permalink / raw) To: Martin Blumenstingl Cc: Maxime Jourdan, linux-amlogic, Kevin Hilman, mjourdan, Linux Kernel Mailing List, linux-arm-kernel Hey Martin, so sorry for forgetting about this. On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Maxime, > > On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > > > Hi Martin, > > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > > <martin.blumenstingl@googlemail.com> wrote: > > > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > > IP is used by the video decoder hardware as well as the VPU (video > > > output) hardware. > > > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > > yet. However, we can still add the canvas module to have it available > > > once these drivers gain support for the older SoCs. > > > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > > not re-initialize the VPU (and to use the configuration set by u-boot). > > > With that hack I could get some image out of the CVBS connector. No > > > changes to the canvas driver were required. > > > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > > always) what the Amlogic 3.10 vendor kernel uses. > > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > > video output enabled (so I couldn't use the same hack I used on my > > > Meson8m2 board). > > > > > > This series meant to be applied on top of "Meson8b: add support for the > > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > > > > > The series looks good to me, however I wonder if we should maybe add a > > new compatible ? > > > > The canvas IP before the GX* generation does not handle what Amlogic > > calls "endianness", the field that allows doing some byte-switching to > > get proper NV12/NV21. So the following defines are unusable: > > > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > > #define MESON_CANVAS_ENDIAN_SWAP128 0xf > I didn't know about this - thank you for pointing this out. > > your suggestions to add new compatible strings is a good idea for that case. > Amlogic uses different defines for Meson8 and Meson8m2 in their vendor > kernel and they keep Meson8b different. > I will add three new compatibles, one for each SoC (Meson8, Meson8b, > Meson8m2) just to be on the safe side if we discover differences in > the canvas IP on these SoCs. > > what do you think? > Sure thing. Keep an eye out for any hints regarding the amount of canvases as well, I *think* I remember some old SoCs having only 192 but I haven't been able to find it again. > > It wouldn't change much functionally, but we could have e.g a warning > > if a m8 canvas user tries to set endianness even though it does > > nothing. > this is a good idea, that will make it easier to spot why something > doesn't work. > we can also return -EINVAL, like you already do for the case where the > canvas ID is already used. > Yes, returning an error is a good idea. Maxime > > Martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-05-20 19:21 ` Maxime Jourdan 0 siblings, 0 replies; 24+ messages in thread From: Maxime Jourdan @ 2019-05-20 19:21 UTC (permalink / raw) To: Martin Blumenstingl Cc: mjourdan, Kevin Hilman, Linux Kernel Mailing List, Maxime Jourdan, linux-amlogic, linux-arm-kernel Hey Martin, so sorry for forgetting about this. On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Maxime, > > On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > > > Hi Martin, > > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > > <martin.blumenstingl@googlemail.com> wrote: > > > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > > IP is used by the video decoder hardware as well as the VPU (video > > > output) hardware. > > > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > > yet. However, we can still add the canvas module to have it available > > > once these drivers gain support for the older SoCs. > > > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > > not re-initialize the VPU (and to use the configuration set by u-boot). > > > With that hack I could get some image out of the CVBS connector. No > > > changes to the canvas driver were required. > > > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > > always) what the Amlogic 3.10 vendor kernel uses. > > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > > video output enabled (so I couldn't use the same hack I used on my > > > Meson8m2 board). > > > > > > This series meant to be applied on top of "Meson8b: add support for the > > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > > > > > The series looks good to me, however I wonder if we should maybe add a > > new compatible ? > > > > The canvas IP before the GX* generation does not handle what Amlogic > > calls "endianness", the field that allows doing some byte-switching to > > get proper NV12/NV21. So the following defines are unusable: > > > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > > #define MESON_CANVAS_ENDIAN_SWAP128 0xf > I didn't know about this - thank you for pointing this out. > > your suggestions to add new compatible strings is a good idea for that case. > Amlogic uses different defines for Meson8 and Meson8m2 in their vendor > kernel and they keep Meson8b different. > I will add three new compatibles, one for each SoC (Meson8, Meson8b, > Meson8m2) just to be on the safe side if we discover differences in > the canvas IP on these SoCs. > > what do you think? > Sure thing. Keep an eye out for any hints regarding the amount of canvases as well, I *think* I remember some old SoCs having only 192 but I haven't been able to find it again. > > It wouldn't change much functionally, but we could have e.g a warning > > if a m8 canvas user tries to set endianness even though it does > > nothing. > this is a good idea, that will make it easier to spot why something > doesn't work. > we can also return -EINVAL, like you already do for the case where the > canvas ID is already used. > Yes, returning an error is a good idea. Maxime > > Martin _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-05-20 19:21 ` Maxime Jourdan 0 siblings, 0 replies; 24+ messages in thread From: Maxime Jourdan @ 2019-05-20 19:21 UTC (permalink / raw) To: Martin Blumenstingl Cc: mjourdan, Kevin Hilman, Linux Kernel Mailing List, Maxime Jourdan, linux-amlogic, linux-arm-kernel Hey Martin, so sorry for forgetting about this. On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > > Hi Maxime, > > On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > > > Hi Martin, > > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > > <martin.blumenstingl@googlemail.com> wrote: > > > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > > IP is used by the video decoder hardware as well as the VPU (video > > > output) hardware. > > > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > > yet. However, we can still add the canvas module to have it available > > > once these drivers gain support for the older SoCs. > > > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > > not re-initialize the VPU (and to use the configuration set by u-boot). > > > With that hack I could get some image out of the CVBS connector. No > > > changes to the canvas driver were required. > > > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > > always) what the Amlogic 3.10 vendor kernel uses. > > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > > video output enabled (so I couldn't use the same hack I used on my > > > Meson8m2 board). > > > > > > This series meant to be applied on top of "Meson8b: add support for the > > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > > > > > The series looks good to me, however I wonder if we should maybe add a > > new compatible ? > > > > The canvas IP before the GX* generation does not handle what Amlogic > > calls "endianness", the field that allows doing some byte-switching to > > get proper NV12/NV21. So the following defines are unusable: > > > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > > #define MESON_CANVAS_ENDIAN_SWAP128 0xf > I didn't know about this - thank you for pointing this out. > > your suggestions to add new compatible strings is a good idea for that case. > Amlogic uses different defines for Meson8 and Meson8m2 in their vendor > kernel and they keep Meson8b different. > I will add three new compatibles, one for each SoC (Meson8, Meson8b, > Meson8m2) just to be on the safe side if we discover differences in > the canvas IP on these SoCs. > > what do you think? > Sure thing. Keep an eye out for any hints regarding the amount of canvases as well, I *think* I remember some old SoCs having only 192 but I haven't been able to find it again. > > It wouldn't change much functionally, but we could have e.g a warning > > if a m8 canvas user tries to set endianness even though it does > > nothing. > this is a good idea, that will make it easier to spot why something > doesn't work. > we can also return -EINVAL, like you already do for the case where the > canvas ID is already used. > Yes, returning an error is a good idea. Maxime > > Martin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module 2019-05-20 19:21 ` Maxime Jourdan (?) @ 2019-05-20 19:36 ` Martin Blumenstingl -1 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-05-20 19:36 UTC (permalink / raw) To: Maxime Jourdan Cc: linux-amlogic, Kevin Hilman, mjourdan, Linux Kernel Mailing List, linux-arm-kernel Hi Maxime, On Mon, May 20, 2019 at 9:21 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > Hey Martin, so sorry for forgetting about this. > > On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > Hi Maxime, > > > > On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > > > > > Hi Martin, > > > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > > > <martin.blumenstingl@googlemail.com> wrote: > > > > > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > > > IP is used by the video decoder hardware as well as the VPU (video > > > > output) hardware. > > > > > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > > > yet. However, we can still add the canvas module to have it available > > > > once these drivers gain support for the older SoCs. > > > > > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > > > not re-initialize the VPU (and to use the configuration set by u-boot). > > > > With that hack I could get some image out of the CVBS connector. No > > > > changes to the canvas driver were required. > > > > > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > > > always) what the Amlogic 3.10 vendor kernel uses. > > > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > > > video output enabled (so I couldn't use the same hack I used on my > > > > Meson8m2 board). > > > > > > > > This series meant to be applied on top of "Meson8b: add support for the > > > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > > > > > > > > > The series looks good to me, however I wonder if we should maybe add a > > > new compatible ? > > > > > > The canvas IP before the GX* generation does not handle what Amlogic > > > calls "endianness", the field that allows doing some byte-switching to > > > get proper NV12/NV21. So the following defines are unusable: > > > > > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > > > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > > > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > > > #define MESON_CANVAS_ENDIAN_SWAP128 0xf > > I didn't know about this - thank you for pointing this out. > > > > your suggestions to add new compatible strings is a good idea for that case. > > Amlogic uses different defines for Meson8 and Meson8m2 in their vendor > > kernel and they keep Meson8b different. > > I will add three new compatibles, one for each SoC (Meson8, Meson8b, > > Meson8m2) just to be on the safe side if we discover differences in > > the canvas IP on these SoCs. > > > > what do you think? > > > > Sure thing. Keep an eye out for any hints regarding the amount of > canvases as well, I *think* I remember some old SoCs having only 192 > but I haven't been able to find it again. Meson6 and older are limited to 192, Meson8 and newer already support 256. source: [0] > > > It wouldn't change much functionally, but we could have e.g a warning > > > if a m8 canvas user tries to set endianness even though it does > > > nothing. > > this is a good idea, that will make it easier to spot why something > > doesn't work. > > we can also return -EINVAL, like you already do for the case where the > > canvas ID is already used. > > > > Yes, returning an error is a good idea. OK, I'll send an updated series later. Martin [0] https://github.com/endlessm/linux-meson/blob/5cb4882cdda584878a29132aeb9a90497a121df9/drivers/amlogic/canvas/canvas.c#L41 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-05-20 19:36 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-05-20 19:36 UTC (permalink / raw) To: Maxime Jourdan Cc: mjourdan, linux-amlogic, Linux Kernel Mailing List, linux-arm-kernel, Kevin Hilman Hi Maxime, On Mon, May 20, 2019 at 9:21 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > Hey Martin, so sorry for forgetting about this. > > On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > Hi Maxime, > > > > On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > > > > > Hi Martin, > > > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > > > <martin.blumenstingl@googlemail.com> wrote: > > > > > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > > > IP is used by the video decoder hardware as well as the VPU (video > > > > output) hardware. > > > > > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > > > yet. However, we can still add the canvas module to have it available > > > > once these drivers gain support for the older SoCs. > > > > > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > > > not re-initialize the VPU (and to use the configuration set by u-boot). > > > > With that hack I could get some image out of the CVBS connector. No > > > > changes to the canvas driver were required. > > > > > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > > > always) what the Amlogic 3.10 vendor kernel uses. > > > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > > > video output enabled (so I couldn't use the same hack I used on my > > > > Meson8m2 board). > > > > > > > > This series meant to be applied on top of "Meson8b: add support for the > > > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > > > > > > > > > The series looks good to me, however I wonder if we should maybe add a > > > new compatible ? > > > > > > The canvas IP before the GX* generation does not handle what Amlogic > > > calls "endianness", the field that allows doing some byte-switching to > > > get proper NV12/NV21. So the following defines are unusable: > > > > > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > > > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > > > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > > > #define MESON_CANVAS_ENDIAN_SWAP128 0xf > > I didn't know about this - thank you for pointing this out. > > > > your suggestions to add new compatible strings is a good idea for that case. > > Amlogic uses different defines for Meson8 and Meson8m2 in their vendor > > kernel and they keep Meson8b different. > > I will add three new compatibles, one for each SoC (Meson8, Meson8b, > > Meson8m2) just to be on the safe side if we discover differences in > > the canvas IP on these SoCs. > > > > what do you think? > > > > Sure thing. Keep an eye out for any hints regarding the amount of > canvases as well, I *think* I remember some old SoCs having only 192 > but I haven't been able to find it again. Meson6 and older are limited to 192, Meson8 and newer already support 256. source: [0] > > > It wouldn't change much functionally, but we could have e.g a warning > > > if a m8 canvas user tries to set endianness even though it does > > > nothing. > > this is a good idea, that will make it easier to spot why something > > doesn't work. > > we can also return -EINVAL, like you already do for the case where the > > canvas ID is already used. > > > > Yes, returning an error is a good idea. OK, I'll send an updated series later. Martin [0] https://github.com/endlessm/linux-meson/blob/5cb4882cdda584878a29132aeb9a90497a121df9/drivers/amlogic/canvas/canvas.c#L41 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/3] 32-bit Meson: add the canvas module @ 2019-05-20 19:36 ` Martin Blumenstingl 0 siblings, 0 replies; 24+ messages in thread From: Martin Blumenstingl @ 2019-05-20 19:36 UTC (permalink / raw) To: Maxime Jourdan Cc: mjourdan, linux-amlogic, Linux Kernel Mailing List, linux-arm-kernel, Kevin Hilman Hi Maxime, On Mon, May 20, 2019 at 9:21 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > Hey Martin, so sorry for forgetting about this. > > On Thu, Apr 18, 2019 at 9:50 PM Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: > > > > Hi Maxime, > > > > On Sat, Apr 13, 2019 at 8:54 PM Maxime Jourdan <maxi.jourdan@wanadoo.fr> wrote: > > > > > > Hi Martin, > > > On Sat, Apr 13, 2019 at 7:15 PM Martin Blumenstingl > > > <martin.blumenstingl@googlemail.com> wrote: > > > > > > > > This adds the canvas module on Meson8, Meson8b and Meson8m2. The canvas > > > > IP is used by the video decoder hardware as well as the VPU (video > > > > output) hardware. > > > > > > > > Neither the VPU nor the video decoder driver support the 32-bit SoCs > > > > yet. However, we can still add the canvas module to have it available > > > > once these drivers gain support for the older SoCs. > > > > > > > > I have tested this on my Meson8m2 board by hacking the VPU driver to > > > > not re-initialize the VPU (and to use the configuration set by u-boot). > > > > With that hack I could get some image out of the CVBS connector. No > > > > changes to the canvas driver were required. > > > > > > > > Due to lack of hardware I could not test Meson8, but I'm following (as > > > > always) what the Amlogic 3.10 vendor kernel uses. > > > > Meson8b is also not tested because u-boot of my EC-100 doesn't have > > > > video output enabled (so I couldn't use the same hack I used on my > > > > Meson8m2 board). > > > > > > > > This series meant to be applied on top of "Meson8b: add support for the > > > > RTC on EC-100 and Odroid-C1" from [0] > > > > > > > > > > > > > > The series looks good to me, however I wonder if we should maybe add a > > > new compatible ? > > > > > > The canvas IP before the GX* generation does not handle what Amlogic > > > calls "endianness", the field that allows doing some byte-switching to > > > get proper NV12/NV21. So the following defines are unusable: > > > > > > #define MESON_CANVAS_ENDIAN_SWAP16 0x1 > > > #define MESON_CANVAS_ENDIAN_SWAP32 0x3 > > > #define MESON_CANVAS_ENDIAN_SWAP64 0x7 > > > #define MESON_CANVAS_ENDIAN_SWAP128 0xf > > I didn't know about this - thank you for pointing this out. > > > > your suggestions to add new compatible strings is a good idea for that case. > > Amlogic uses different defines for Meson8 and Meson8m2 in their vendor > > kernel and they keep Meson8b different. > > I will add three new compatibles, one for each SoC (Meson8, Meson8b, > > Meson8m2) just to be on the safe side if we discover differences in > > the canvas IP on these SoCs. > > > > what do you think? > > > > Sure thing. Keep an eye out for any hints regarding the amount of > canvases as well, I *think* I remember some old SoCs having only 192 > but I haven't been able to find it again. Meson6 and older are limited to 192, Meson8 and newer already support 256. source: [0] > > > It wouldn't change much functionally, but we could have e.g a warning > > > if a m8 canvas user tries to set endianness even though it does > > > nothing. > > this is a good idea, that will make it easier to spot why something > > doesn't work. > > we can also return -EINVAL, like you already do for the case where the > > canvas ID is already used. > > > > Yes, returning an error is a good idea. OK, I'll send an updated series later. Martin [0] https://github.com/endlessm/linux-meson/blob/5cb4882cdda584878a29132aeb9a90497a121df9/drivers/amlogic/canvas/canvas.c#L41 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-05-20 19:37 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-13 17:15 [PATCH 0/3] 32-bit Meson: add the canvas module Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 17:15 ` [PATCH 1/3] ARM: dts: meson8: " Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 17:15 ` [PATCH 2/3] ARM: dts: meson8m2: update the offset of " Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 17:15 ` [PATCH 3/3] ARM: dts: meson8b: add " Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 17:15 ` Martin Blumenstingl 2019-04-13 18:54 ` [PATCH 0/3] 32-bit Meson: " Maxime Jourdan 2019-04-13 18:54 ` Maxime Jourdan 2019-04-13 18:54 ` Maxime Jourdan 2019-04-18 19:50 ` Martin Blumenstingl 2019-04-18 19:50 ` Martin Blumenstingl 2019-04-18 19:50 ` Martin Blumenstingl 2019-05-20 19:21 ` Maxime Jourdan 2019-05-20 19:21 ` Maxime Jourdan 2019-05-20 19:21 ` Maxime Jourdan 2019-05-20 19:36 ` Martin Blumenstingl 2019-05-20 19:36 ` Martin Blumenstingl 2019-05-20 19:36 ` Martin Blumenstingl
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.