2018-08-02 15:01 GMT+02:00 Jerome Brunet :
> What I don't like is precisely that you need to expose this 'struct ops' to
> the
> consumer. I would prefer an API for this (it can be a 1:1 mapping). The canvas
> should remain some abstract object you get from DT.
>
> IMO, this is the same as a
Hi Jerome,
2018-08-02 10:39 GMT+02:00 Jerome Brunet :
> I looks like the consumer of your 'canvas' devices must know how the canvas
> device is organized internally. Maybe something better can be done ?
>
> Your canvas driver could provide a consumer API, for example:
> meson_canvas_get(): to
for a standalone, lock-aware canvas provider module.
Currently, canvas code lies in the drm/meson module as it is the sole
user.
This patchset adds such canvas provider module and converts drm/meson to
using it, stripping/moving the current canvas code.
Maxime Jourdan (4):
soc: amlogic: add meson-canvas
-by: Maxime Jourdan
---
.../bindings/display/amlogic,meson-vpu.txt| 9 +--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 7 +-
drivers/gpu/drm/meson/Kconfig | 1 +
drivers/gpu/drm/meson/Makefile| 2 +-
drivers/gpu/drm/meson/meson_canvas.c | 70
API
- Added comments
- Hid the of-node probe code behind meson_canvas_get
- Changed device lock to a spinlock with irqsave
[0]: https://lkml.org/lkml/2018/8/1/1512
Maxime Jourdan (4):
soc: amlogic: add meson-canvas driver
dt-bindings: soc: amlogic: add meson-canvas documentation
ARM64
-by: Maxime Jourdan
Tested-by: Neil Armstrong
---
.../bindings/display/amlogic,meson-vpu.txt| 9 +--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 7 +-
drivers/gpu/drm/meson/Kconfig | 1 +
drivers/gpu/drm/meson/Makefile| 2 +-
drivers/gpu/drm/meson
2018-08-10 0:41 GMT+02:00 Rob Herring :
> Hi, this is an automated email from Rob's (experimental) review bot. I
> found a couple of common problems with your patch. Please see below.
>
> On Wed, 1 Aug 2018 20:51:28 +0200, Maxime Jourdan wrote:
>> This removes the meson_c
This is the first step into converting the meson/drm driver to use
the canvas module.
If a canvas provider node is detected in DT, use it. Otherwise,
fall back to what is currently being done.
Signed-off-by: Maxime Jourdan
---
drivers/gpu/drm/meson/Kconfig | 1 +
drivers/gpu/drm/meson
Allows using the new canvas provider module if present.
Signed-off-by: Maxime Jourdan
---
Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
b/Documentation
Hi Neil,
On Mon, Nov 5, 2018 at 1:51 PM Neil Armstrong wrote:
>
> Hi Maxime,
>
> On 05/11/2018 11:45, Maxime Jourdan wrote:
> > The meson DRM driver currently uses constant, static canvas indexes.
> >
> > This is not optimal and could conflict with other d
.
In the future, the current way of doing things will be deprecated.
Maxime Jourdan (2):
dt-bindings: display: amlogic, meson-vpu: Add optional canvas provider
node
drm/meson: Use optional canvas provider
.../bindings/display/amlogic,meson-vpu.txt| 2 +
drivers/gpu/drm/meson/Kconfig
.c
> create mode 100644 drivers/gpu/drm/meson/meson_overlay.h
>
Tested by rendering video with:
- gstreamer 1.14.4 using kmssink
- ffmpeg-drm (https://github.com/Elyotna/ffmpeg-drm),
by applying this patch on top of the video decoder patch series.
Used different resolutions and pixel aspect r
Hi Neil,
On Wed, Dec 12, 2018 at 10:55 AM Neil Armstrong wrote:
>
> Hi Maxime,
>
> On 10/12/2018 10:28, Maxime Jourdan wrote:
> > In case we are using simplefb or another conflicting framebuffer, make
> > the call to drm_fb_helper_remove_conflicting_framebuffers()
>
On Mon, Dec 10, 2018 at 10:05 AM Maxime Jourdan wrote:
>
> In case we are using simplefb or another conflicting framebuffer, make
> the call to drm_fb_helper_remove_conflicting_framebuffers()
>
> Signed-off-by: Maxime Jourdan
> ---
> drivers/gpu/drm/m
In case we are using simplefb or another conflicting framebuffer, make
the call to drm_fb_helper_remove_conflicting_framebuffers()
Signed-off-by: Maxime Jourdan
---
drivers/gpu/drm/meson/meson_drv.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/meson
In case we are using simplefb or another conflicting framebuffer, make
the call to drm_fb_helper_remove_conflicting_framebuffers()
Signed-off-by: Maxime Jourdan
---
drivers/gpu/drm/meson/meson_drv.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/meson
venc_vic_mode {
> unsigned int vic;
> union meson_hdmi_venc_mode *mode;
> @@ -717,6 +843,9 @@ struct meson_hdmi_venc_vic_mode {
> { 34, _hdmi_encp_mode_1080p30 },
> { 31, _hdmi_encp_mode_1080p50 },
> { 16, _hdmi_encp_mode_1080p60 },
> + { 93, _hdmi_en
gt; return;
> }
>
> @@ -895,6 +940,6 @@ void meson_vclk_setup(struct meson_drm *priv, unsigned
> int target,
>params[freq].pll_od1, params[freq].pll_od2,
> params[freq].pll_od3, params[freq].vid_pll_div,
>
be randomly
"shifted" with black patches, and this was particularly visible with
subtitles.
Things seem OK now. Thanks!
Tested-by: Maxime Jourdan
Reviewed-by: Maxime Jourdan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ejects modes whith clock > max_tmds_clock if
> the max_tmds_clock is specified. This will only reject
> 4:2:0 HDMI2.0 modes, who reports a clock > max_tmds_clock.
>
> Reported-by: Maxime Jourdan
> Fixes: d7d8fb7046b6 ("drm/meson: add HDMI div40 TMDS mode")
> Sig
failed with return code
>
> Fixes: 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider module")
> Cc: Maxime Jourdan
> Cc: Neil Armstrong
> Cc: Kevin Hilman
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-k
Hi Neil,
On Fri, Feb 1, 2019 at 1:08 PM Neil Armstrong wrote:
>
> This patch adds support for the YUV420 output from the Amlogic Meson SoCs
> Video Processing Unit to the HDMI Controller.
>
> The YUV420 is obtained by generating a YUV444 pixel stream like
> the classic HDMI display modes, but
anvas"
for more information.
This series also incorporates a probing fix proposed by Neil Armstrong [1]
although rewritten because of heavy code changes in the corresponding
location.
[1] https://lkml.org/lkml/2019/2/4/152
Maxime Jourdan (2):
dt-bindings: display: amlogic, meson-vpu: exclu
vas node.
[1] https://patchwork.kernel.org/cover/10573771/
[2] https://patchwork.freedesktop.org/series/52076/
Signed-off-by: Maxime Jourdan
---
.../devicetree/bindings/display/amlogic,meson-vpu.txt| 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/d
Now that the DMC register range is no longer in the bindings, remove any
mention towards it and exclusively use the meson-canvas module.
Signed-off-by: Maxime Jourdan
---
drivers/gpu/drm/meson/Makefile| 2 +-
drivers/gpu/drm/meson/meson_canvas.c | 73 ---
drivers
Hi Neil,
On Mon, Feb 4, 2019 at 10:55 AM Neil Armstrong wrote:
>
> When meson_canvas is not yet probed, meson_canvas_get returns -EPROBE_DEFER.
>
> Handle this case but deferring the probe of the drm driver aswell.
>
> Fixes: 66cae477c380 ("drm/meson: Use optional canvas provider")
>
entation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
> F: Documentation/gpu/meson.rst
> T: git git://anongit.freedesktop.org/drm/drm-misc
>
> --
> 2.22.0
>
Reviewed-by: Maxime Jourdan
ions of options that can be
applied to the frames when created. I also helped testing the
following scenarios of decode+display on various SoCs:
- SM1: DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER (10-bit & 8-bit video)
- SM1: DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER +
DRM_FORMAT
28 matches
Mail list logo
