Re: [PATCH] drm/nouveau: declare constants as unsigned long.
Probably want ULL for 32-bit arches to be correct here too.
On Tue, Dec 31, 2019 at 3:53 PM Wambui Karuga wrote:
>
> Explicitly declare constants are unsigned long to address the following
> sparse warnings:
> warning: constant is so big it is long
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> index ac87a3b6b7c9..506b358fcdb6 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> @@ -655,7 +655,7 @@ gf100_ram_new_(const struct nvkm_ram_func *func,
>
> static const struct nvkm_ram_func
> gf100_ram = {
> - .upper = 0x02,
> + .upper = 0x02UL,
> .probe_fbp = gf100_ram_probe_fbp,
> .probe_fbp_amount = gf100_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> index 70a06e3cd55a..3bc39895bbce 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
> @@ -43,7 +43,7 @@ gf108_ram_probe_fbp_amount(const struct nvkm_ram_func
> *func, u32 fbpao,
>
> static const struct nvkm_ram_func
> gf108_ram = {
> - .upper = 0x02,
> + .upper = 0x02UL,
> .probe_fbp = gf100_ram_probe_fbp,
> .probe_fbp_amount = gf108_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> index 456aed1f2a02..d01f32c0956a 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
> @@ -1698,7 +1698,7 @@ gk104_ram_new_(const struct nvkm_ram_func *func, struct
> nvkm_fb *fb,
>
> static const struct nvkm_ram_func
> gk104_ram = {
> - .upper = 0x02,
> + .upper = 0x02UL,
> .probe_fbp = gf100_ram_probe_fbp,
> .probe_fbp_amount = gf108_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> index 27c68e3f9772..e24ac664eb15 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
> @@ -33,7 +33,7 @@ gm107_ram_probe_fbp(const struct nvkm_ram_func *func,
>
> static const struct nvkm_ram_func
> gm107_ram = {
> - .upper = 0x10,
> + .upper = 0x10UL,
> .probe_fbp = gm107_ram_probe_fbp,
> .probe_fbp_amount = gf108_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> index 6b0cac1fe7b4..17994cbda54b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
> @@ -48,7 +48,7 @@ gm200_ram_probe_fbp_amount(const struct nvkm_ram_func
> *func, u32 fbpao,
>
> static const struct nvkm_ram_func
> gm200_ram = {
> - .upper = 0x10,
> + .upper = 0x10UL,
> .probe_fbp = gm107_ram_probe_fbp,
> .probe_fbp_amount = gm200_ram_probe_fbp_amount,
> .probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> index adb62a6beb63..7a07a6ed4578 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
> @@ -79,7 +79,7 @@ gp100_ram_probe_fbpa(struct nvkm_device *device, int fbpa)
>
> static const struct nvkm_ram_func
> gp100_ram = {
> - .upper = 0x10,
> + .upper = 0x10UL,
> .probe_fbp = gm107_ram_probe_fbp,
> .probe_fbp_amount = gm200_ram_probe_fbp_amount,
> .probe_fbpa_amount = gp100_ram_probe_fbpa,
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/fb: Extend format_info member arrays to handle four planes
From: Dhinakaran Pandiyan
addfb() uAPI has supported four planes for a while now, make format_info
compatible with that.
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Mika Kahola
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Imre Deak
Reviewed-by: Mika Kahola
---
include/drm/drm_fourcc.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 306d1efeb5e0..156b122c0ad5 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -78,7 +78,7 @@ struct drm_format_info {
* triplet @char_per_block, @block_w, @block_h for better
* describing the pixel format.
*/
- u8 cpp[3];
+ u8 cpp[4];
/**
* @char_per_block:
@@ -104,7 +104,7 @@ struct drm_format_info {
* information from their drm_mode_config.get_format_info hook
* if they want the core to be validating the pitch.
*/
- u8 char_per_block[3];
+ u8 char_per_block[4];
};
/**
@@ -113,7 +113,7 @@ struct drm_format_info {
* Block width in pixels, this is intended to be accessed through
* drm_format_info_block_width()
*/
- u8 block_w[3];
+ u8 block_w[4];
/**
* @block_h:
@@ -121,7 +121,7 @@ struct drm_format_info {
* Block height in pixels, this is intended to be accessed through
* drm_format_info_block_height()
*/
- u8 block_h[3];
+ u8 block_h[4];
/** @hsub: Horizontal chroma subsampling factor */
u8 hsub;
--
2.23.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/framebuffer: Format modifier for Intel Gen-12 media compression
From: Dhinakaran Pandiyan
Gen-12 display can decompress surfaces compressed by the media engine, add
a new modifier as the driver needs to know the surface was compressed by
the media or render engine.
v2: Update code comment describing the color plane order for YUV
semiplanar formats.
Cc: Nanley G Chery
Cc: Matt Roper
Cc: Ville Syrjälä
Cc: Mika Kahola
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
Signed-off-by: Imre Deak
Reviewed-by: Mika Kahola
---
include/uapi/drm/drm_fourcc.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 5ba481f49931..8bc0b31597d8 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -421,6 +421,19 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+/*
+ * Intel color control surfaces (CCS) for Gen-12 media compression
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
+ * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
+ * planes 2 and 3 for the respective CCS.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.23.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/sun4i: Add alpha property for sun8i UI layer
Hi!
Dne ponedeljek, 30. december 2019 ob 19:08:41 CET je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> DE2.0 and DE3.0 UI layers supports plane-global alpha channel.
> Add alpha property to the DRM plane and connect it to the
> corresponding registers in mixer.
>
> Signed-off-by: Roman Stratiienko
Reviewed-by: Jernej Skrabec
BTW, patch is marked as v2, but I don't see any changelog. What did you
change?
Best regards,
Jernej
> ---
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 29 ++
> drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 5 +
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index c87fd842918e..4343ea9f8cf8
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -72,6 +72,27 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer
> *mixer, int channel, }
> }
>
> +static void sun8i_ui_layer_update_alpha(struct sun8i_mixer *mixer, int
> channel, +int overlay, struct
drm_plane *plane)
> +{
> + u32 mask, val, ch_base;
> +
> + ch_base = sun8i_channel_base(mixer, channel);
> +
> + mask = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK |
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK;
> +
> + val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA(plane->state->alpha >>
8);
> +
> + val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_PIXEL :
> + SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_COMBINED;
> +
> + regmap_update_bits(mixer->engine.regs,
> +SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base,
overlay),
> +mask, val);
> +}
> +
> static int sun8i_ui_layer_update_coord(struct sun8i_mixer *mixer, int
> channel, int overlay, struct drm_plane *plane,
> unsigned int zpos)
> @@ -288,6 +309,8 @@ static void sun8i_ui_layer_atomic_update(struct
> drm_plane *plane,
>
> sun8i_ui_layer_update_coord(mixer, layer->channel,
> layer->overlay, plane, zpos);
> + sun8i_ui_layer_update_alpha(mixer, layer->channel,
> + layer->overlay, plane);
> sun8i_ui_layer_update_formats(mixer, layer->channel,
> layer->overlay, plane);
> sun8i_ui_layer_update_buffer(mixer, layer->channel,
> @@ -365,6 +388,12 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct
> drm_device *drm,
>
> plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
>
> + ret = drm_plane_create_alpha_property(&layer->plane);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't add alpha property\n");
> + return ERR_PTR(ret);
> + }
> +
> ret = drm_plane_create_zpos_property(&layer->plane, channel,
>0, plane_cnt -
1);
> if (ret) {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.h index f4ab1cf6cded..e3e32ee1178d
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
> @@ -40,6 +40,11 @@
> #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASKGENMASK(12, 8)
> #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET 8
> #define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASKGENMASK(31, 24)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA(x) ((x) << 24)
> +
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_PIXEL
((0) << 1)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_LAYER
((1) << 1)
> +#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_COMBINED ((2) << 1)
>
> struct sun8i_mixer;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: declare constants as unsigned long.
Explicitly declare constants are unsigned long to address the following
sparse warnings:
warning: constant is so big it is long
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
index ac87a3b6b7c9..506b358fcdb6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
@@ -655,7 +655,7 @@ gf100_ram_new_(const struct nvkm_ram_func *func,
static const struct nvkm_ram_func
gf100_ram = {
- .upper = 0x02,
+ .upper = 0x02UL,
.probe_fbp = gf100_ram_probe_fbp,
.probe_fbp_amount = gf100_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
index 70a06e3cd55a..3bc39895bbce 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf108.c
@@ -43,7 +43,7 @@ gf108_ram_probe_fbp_amount(const struct nvkm_ram_func *func,
u32 fbpao,
static const struct nvkm_ram_func
gf108_ram = {
- .upper = 0x02,
+ .upper = 0x02UL,
.probe_fbp = gf100_ram_probe_fbp,
.probe_fbp_amount = gf108_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
index 456aed1f2a02..d01f32c0956a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c
@@ -1698,7 +1698,7 @@ gk104_ram_new_(const struct nvkm_ram_func *func, struct
nvkm_fb *fb,
static const struct nvkm_ram_func
gk104_ram = {
- .upper = 0x02,
+ .upper = 0x02UL,
.probe_fbp = gf100_ram_probe_fbp,
.probe_fbp_amount = gf108_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
index 27c68e3f9772..e24ac664eb15 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm107.c
@@ -33,7 +33,7 @@ gm107_ram_probe_fbp(const struct nvkm_ram_func *func,
static const struct nvkm_ram_func
gm107_ram = {
- .upper = 0x10,
+ .upper = 0x10UL,
.probe_fbp = gm107_ram_probe_fbp,
.probe_fbp_amount = gf108_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
index 6b0cac1fe7b4..17994cbda54b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgm200.c
@@ -48,7 +48,7 @@ gm200_ram_probe_fbp_amount(const struct nvkm_ram_func *func,
u32 fbpao,
static const struct nvkm_ram_func
gm200_ram = {
- .upper = 0x10,
+ .upper = 0x10UL,
.probe_fbp = gm107_ram_probe_fbp,
.probe_fbp_amount = gm200_ram_probe_fbp_amount,
.probe_fbpa_amount = gf100_ram_probe_fbpa_amount,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
index adb62a6beb63..7a07a6ed4578 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgp100.c
@@ -79,7 +79,7 @@ gp100_ram_probe_fbpa(struct nvkm_device *device, int fbpa)
static const struct nvkm_ram_func
gp100_ram = {
- .upper = 0x10,
+ .upper = 0x10UL,
.probe_fbp = gm107_ram_probe_fbp,
.probe_fbp_amount = gm200_ram_probe_fbp_amount,
.probe_fbpa_amount = gp100_ram_probe_fbpa,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/sun4i: Add mode_set callback to the engine
Hi!
Dne nedelja, 29. december 2019 ob 17:28:26 CET je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> Create callback to update engine's registers on mode change.
>
> Signed-off-by: Roman Stratiienko
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> v2:
> - Split commit in 2 parts.
> - Add description to mode_set callback
> - Dropped 1 line from sun4i_crtc_mode_set_nofb()
> - Add struct drm_display_mode declaration (fix build warning)
> ---
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 3 +++
> drivers/gpu/drm/sun4i/sunxi_engine.h | 12
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> b/drivers/gpu/drm/sun4i/sun4i_crtc.c index 3a153648b369..f9c627d601c3
> 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> @@ -141,6 +141,9 @@ static void sun4i_crtc_mode_set_nofb(struct drm_crtc
> *crtc) struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
>
> sun4i_tcon_mode_set(scrtc->tcon, encoder, mode);
> +
> + if (scrtc->engine->ops->mode_set)
> + scrtc->engine->ops->mode_set(scrtc->engine, mode);
> }
>
> static const struct drm_crtc_helper_funcs sun4i_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h
> b/drivers/gpu/drm/sun4i/sunxi_engine.h index 548710a936d5..44102783ee3c
> 100644
> --- a/drivers/gpu/drm/sun4i/sunxi_engine.h
> +++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
> @@ -9,6 +9,7 @@
> struct drm_plane;
> struct drm_device;
> struct drm_crtc_state;
> +struct drm_display_mode;
>
> struct sunxi_engine;
>
> @@ -108,6 +109,17 @@ struct sunxi_engine_ops {
>* This function is optional.
>*/
> void (*vblank_quirk)(struct sunxi_engine *engine);
> +
> + /**
> + * @mode_set:
> + *
> + * This callback is used to update engine registers that
> + * responsible for display frame size other mode attributes.
> + *
> + * This function is optional.
> + */
> + void (*mode_set)(struct sunxi_engine *engine,
> + struct drm_display_mode *mode);
> };
>
> /**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
On Tue, 2019-12-31 at 11:38 +0100, Krzysztof Kozlowski wrote:
> On Tue, 31 Dec 2019 at 11:23, Artur Świgoń wrote:
> > >
> > > The order of patches should reflect first of all real dependency.
> > > Whether it compiles, works at all and does not break anything. Logical
> > > dependency of "when the feature will start working" is
> > > irrelevant to DTS because DTS goes in separate way and driver is
> > > independent of it.
> >
> > The order of patches does indeed reflect real dependency. I can also reorder
> > them (preserving the dependencies) so that DTS patches go first in the
> > series
> > if this is the more preferred way.
>
> It looks wrong then. Driver should not depend on DTS. I cannot find
> the patch changing bindings (should be first in patchset) which could
> also point to this problem.
>
> It seems you added requirement for interconnect properties while it
> should be rather optional.
No, there is no requirement for interconnect properties (other than that it
simply does not make any sense to use the interconnect driver code and not the
DTS properties for it in the long run).
In case of the exynos-bus driver (code: patch 05, DTS: patch 04) if the DTS
properties ('exynos,interconnect-parent-node') are missing, the new code handles
it gracefully returning NULL from exynos_bus_icc_get_parent() (it is not an
error condition).
In case of the exynos-mixer driver (code: patch 07, DTS: patch 06) if the DTS
property ('interconnects') is missing, of_icc_get() returns NULL and the code
does
not try to set any contraints for a NULL path. Same thing happens if
CONFIG_INTERCONNECT is 'n'.
The only case when something breaks is when you try to use the interconnect
consumer (implemented in patches 06 & 07) when there is no interconnect provider
(patches 04 & 05), in which case of_icc_get() returns an error (since it cannot
find a path). From what I understand, it probably makes sense to merge any
interconnect consumers one cycle later than the provider.
> > > > I still think the order of these patches is the most logical one for
> > > > someone
> > > > reading this RFC as a whole.
> > >
> > > I am sorry but it brings only confusion. DTS is orthogonal of the
> > > driver code. You could even post the patchset without DTS (although then
> > > it would raise questions where is the user of it, but still, you
> > > could).
> > >
> > > Further, DTS describes also hardware so you could send certain DTS
> > > patches without driver implementation to describe the hardware.
> > >
> > > Driver code and DTS are kind of different worlds so mixing them up for
> > > logical review does not really make any sense.
> > >
> > > Not mentioning it is different than most of other patches on mailing
> > > lists.
> > >
> > > BTW, it is the same as bindings which should (almost) always go first as
> > > separate patches.
> >
> > Thanks for elaborating on this, I appreciate it.
> > Regarding your original concern, patches 04 & 06 are separate for several
> > reasons, one of which is that they are related to two different drivers
> > (exynos-bus vs. exynos-mixer).
>
> It's okay then (for them to be split).
>
> >
> > > >
> > > > > In certain cases dependency on DTS changes is ok:
> > > > > 1. Cleaning up deprecated properties,
> > > > > 2. Ignoring the backward compatibility for e.g. new platforms.
> > > > >
> > > > > None of these are applicable here.
> > > > >
> > > > > You need to rework it, put DTS changes at the end. This clearly shows
> > > > > that there is no wrong dependency.
> > > > >
> > > > > >
> > > > > > > Adjust the title to match the contents - you are not adding
> > > > > > > bindings but
> > > > > > > properties to bus nodes. Also the prefix is ARM: (look at recent
> > > > > > > commits).
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > > > > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > > @@ -90,6 +90,7 @@
> > > > > > > > &bus_dmc {
> > > > > > > > exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > > > > > > vdd-supply = <&buck1_reg>;
> > > > > > > > + #interconnect-cells = <0>;
> > > > > > >
> > > > > > > This does not look like property of Odroid but Exynos4412 or
> > > > > > > Exynos4.
> > > > > >
> > > > > > Strangely enough, this file is where the 'exynos,parent-bus' (aka.
> > > > > > 'devfreq')
> > > > > > properties are located (and everything in this RFC concerns
> > > > > > devfreq).
> > > > >
> > > > > I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
> > > > > you elaborate?
> > > >
> > > > Currently a name change is being made: 'devfreq' -> 'exynos,parent-bus'
> > > > https://patchwork.kernel.org/patch/11304549/
> > > > (a dep
[PATCH] drm/nouveau: remove set but unused variable.
The local variable `pclks` is defined and set but not used and can
therefore be removed.
Issue found by coccinelle.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 362495535e69..f607a04d262d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -54,7 +54,7 @@ static void
nv04_calc_arb(struct nv_fifo_info *fifo, struct nv_sim_state *arb)
{
int pagemiss, cas, width, bpp;
- int nvclks, mclks, pclks, crtpagemiss;
+ int nvclks, mclks, crtpagemiss;
int found, mclk_extra, mclk_loop, cbs, m1, p1;
int mclk_freq, pclk_freq, nvclk_freq;
int us_m, us_n, us_p, crtc_drain_rate;
@@ -69,7 +69,6 @@ nv04_calc_arb(struct nv_fifo_info *fifo, struct nv_sim_state
*arb)
bpp = arb->bpp;
cbs = 128;
- pclks = 2;
nvclks = 10;
mclks = 13 + cas;
mclk_extra = 3;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
On Tue, 2019-12-31 at 11:02 +0100, Krzysztof Kozlowski wrote: > On Tue, Dec 31, 2019 at 10:41:47AM +0100, Artur Świgoń wrote: > > On Tue, 2019-12-31 at 10:22 +0100, Krzysztof Kozlowski wrote: > > > On Tue, Dec 31, 2019 at 08:18:01AM +0100, Artur Świgoń wrote: > > > > Hi, > > > > > > > > On Mon, 2019-12-30 at 16:44 +0100, Krzysztof Kozlowski wrote: > > > > > On Fri, Dec 20, 2019 at 12:56:50PM +0100, Artur Świgoń wrote: > > > > > > This patch adds the following properties to the Exynos4412 DT: > > > > > > - exynos,interconnect-parent-node: to declare connections between > > > > > > nodes in order to guarantee PM QoS requirements between nodes; > > > > > > - #interconnect-cells: required by the interconnect framework. > > > > > > > > > > > > Note that #interconnect-cells is always zero and node IDs are not > > > > > > hardcoded anywhere. > > > > > > > > > > > > Signed-off-by: Artur Świgoń > > > > > > --- > > > > > > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 + > > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > The order of patches is confusing. Patches 4 and 6 are split - do the > > > > > depend on 5? I doubt but... > > > > > > > > Let me elaborate: > > > > > > > > The order of the patches in this series is such that every subsequent > > > > patch adds some functionality (and, of course, applying patches > > > > one-by-one > > > > yields a working kernel at every step). Specifically for patches 04--07: > > > > > > > > -- patch 04 adds interconnect _provider_ properties for Exynos4412; > > > > -- patch 05 implements interconnect provider logic (depends on patch > > > > 04); > > > > -- patch 06 adds interconnect _consumer_ properties for Exynos4412 > > > > mixer; > > > > -- patch 07 implements interconnect consumer logic (depends on patches > > > > 05 & 06); > > > > > > > > My reasoning is that this order allows to e.g., merge the interconnect > > > > provider for exynos-bus and leave the consumers for later (not limited > > > > to > > > > the mixer). I hope this makes sense. > > > > > > It is wrong. The driver should not depend on DTS changes because: > > > 1. DTS always go through separate branch and tree, so last patch > > >will have to wait up to 3 cycles (!!!), > > > 2. You break backward compatibility. > > > > It is up to the definition of "depends". The driver is _not_ broken without > > the DTS patches, but the interconnect functionality will not be available. > > > > The only requirement is that if we want to have a working interconnect > > consumer, there needs to be a working interconnet provider (and I used > > the word "depends" to specify what needs what in order to work as intended). > > > > The order of patches should reflect first of all real dependency. > Whether it compiles, works at all and does not break anything. Logical > dependency of "when the feature will start working" is > irrelevant to DTS because DTS goes in separate way and driver is > independent of it. The order of patches does indeed reflect real dependency. I can also reorder them (preserving the dependencies) so that DTS patches go first in the series if this is the more preferred way. > > I still think the order of these patches is the most logical one for someone > > reading this RFC as a whole. > > I am sorry but it brings only confusion. DTS is orthogonal of the > driver code. You could even post the patchset without DTS (although then > it would raise questions where is the user of it, but still, you > could). > > Further, DTS describes also hardware so you could send certain DTS > patches without driver implementation to describe the hardware. > > Driver code and DTS are kind of different worlds so mixing them up for > logical review does not really make any sense. > > Not mentioning it is different than most of other patches on mailing > lists. > > BTW, it is the same as bindings which should (almost) always go first as > separate patches. Thanks for elaborating on this, I appreciate it. Regarding your original concern, patches 04 & 06 are separate for several reasons, one of which is that they are related to two different drivers (exynos-bus vs. exynos-mixer). > > > > > In certain cases dependency on DTS changes is ok: > > > 1. Cleaning up deprecated properties, > > > 2. Ignoring the backward compatibility for e.g. new platforms. > > > > > > None of these are applicable here. > > > > > > You need to rework it, put DTS changes at the end. This clearly shows > > > that there is no wrong dependency. > > > > > > > > > > > > Adjust the title to match the contents - you are not adding bindings > > > > > but > > > > > properties to bus nodes. Also the prefix is ARM: (look at recent > > > > > commits). > > > > > > > > OK. > > > > > > > > > > > > > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > > > > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > > > > > > index 4ce3d77a6704..d9d70eacfcaf 100644 > > > > > > ---
Re: [PATCH v2 3/4] drm/sun4i: Use CRTC size instead of PRIMARY plane size as mixer frame.
Hi!
Sorry that I missed few details in first review. Please take a look below.
Dne nedelja, 29. december 2019 ob 17:28:27 CET je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> According to DRM documentation the only difference between PRIMARY
> and OVERLAY plane is that each CRTC must have PRIMARY plane and
> OVERLAY are optional.
>
> Allow PRIMARY plane to have dimension different from full-screen.
>
> Fixes: 90212fffa4fc ("drm/sun4i: Use values calculated by atomic check")
This fixes tag doesn't seem to be a good choice. First time where code in
question was introduced was:
9d75b8c0b999 drm/sun4i: add support for Allwinner DE2 mixers
and it was later moved to sun8i_ui_layer.c in:
5bb5f5dafa1a drm/sun4i: Reorganize UI layer code in DE2
Not sure which one is better. You can also include both.
> Signed-off-by: Roman Stratiienko
> ---
> v2:
> - Split commit in 2 parts
> - Add Fixes line to the commit message
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 35 ++
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 30 --
> 2 files changed, 35 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c index d306ad5dc093..5d90a95ff855
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -257,6 +257,40 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32
> format) return NULL;
> }
>
> +static void sun8i_mode_set(struct sunxi_engine *engine,
> +struct drm_display_mode *mode)
> +{
> + u32 dst_w = mode->crtc_hdisplay;
> + u32 dst_h = mode->crtc_vdisplay;
Now that you moved code in separate function, "dst_" prefix doesn't make sense
anymore. Plain "width" and "height" work just fine.
> + u32 outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
> + bool interlaced = false;
No need to initialize above variable. This value is never used.
> + u32 val;
> + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> + u32 bld_base = sun8i_blender_base(mixer);
Not extremely important, but can you move above two lines to the top? At least
I prefer to have those lines sorted from longest to shortest as much as
possible.
Once above comments are addressed, code is:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> +
> + DRM_DEBUG_DRIVER("Mode change, updating global size W: %u H: %u\n",
> + dst_w, dst_h);
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_GLOBAL_SIZE,
> + outsize);
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_BLEND_OUTSIZE(bld_base), outsize);
> +
> + interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
> +
> + if (interlaced)
> + val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
> + else
> + val = 0;
> +
> + regmap_update_bits(mixer->engine.regs,
> +SUN8I_MIXER_BLEND_OUTCTL(bld_base),
> +SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
> +val);
> + DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
> + interlaced ? "on" : "off");
> +}
> +
> static void sun8i_mixer_commit(struct sunxi_engine *engine)
> {
> struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> @@ -356,6 +390,7 @@ static struct drm_plane **sun8i_layers_init(struct
> drm_device *drm, static const struct sunxi_engine_ops sun8i_engine_ops = {
> .commit = sun8i_mixer_commit,
> .layers_init= sun8i_layers_init,
> + .mode_set = sun8i_mode_set,
> };
>
> static struct regmap_config sun8i_mixer_regmap_config = {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index ee7c13d8710f..23c2f4b68c89
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -72,36 +72,6 @@ static int sun8i_ui_layer_update_coord(struct sun8i_mixer
> *mixer, int channel, insize = SUN8I_MIXER_SIZE(src_w, src_h);
> outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
>
> - if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
> - bool interlaced = false;
> - u32 val;
> -
> - DRM_DEBUG_DRIVER("Primary layer, updating global size
W: %u H: %u\n",
> - dst_w, dst_h);
> - regmap_write(mixer->engine.regs,
> - SUN8I_MIXER_GLOBAL_SIZE,
> - outsize);
> - regmap_write(mixer->engine.regs,
> - SUN8I_MIXER_BLEND_OUTSIZE(bld_base),
outsize);
> -
> - if (state->crtc)
> - interlaced = state->crtc->state-
>adjusted_mode.flags
> - & DRM_MODE_FLAG_INTERLACE;
> -
> - if (interlaced)
> - val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
> -
Re: [RFC v2 1/1] drm/lima: Add optional devfreq support
Hi Qiang,
On Tue, Dec 31, 2019 at 3:54 AM Qiang Yu wrote:
[...]
> > diff --git a/drivers/gpu/drm/lima/lima_sched.c
> > b/drivers/gpu/drm/lima/lima_sched.c
> > index f522c5f99729..851c496a168b 100644
> > --- a/drivers/gpu/drm/lima/lima_sched.c
> > +++ b/drivers/gpu/drm/lima/lima_sched.c
> > @@ -5,6 +5,7 @@
> > #include
> > #include
> >
> > +#include "lima_devfreq.h"
> > #include "lima_drv.h"
> > #include "lima_sched.h"
> > #include "lima_vm.h"
> > @@ -213,6 +214,8 @@ static struct dma_fence *lima_sched_run_job(struct
> > drm_sched_job *job)
> > */
> > ret = dma_fence_get(task->fence);
> >
> > + lima_devfreq_record_busy(pipe->ldev);
> > +
> > pipe->current_task = task;
> >
> > /* this is needed for MMU to work correctly, otherwise GP/PP
> > @@ -280,6 +283,8 @@ static void lima_sched_handle_error_task(struct
> > lima_sched_pipe *pipe,
> > pipe->current_vm = NULL;
> > pipe->current_task = NULL;
> >
> > + lima_devfreq_record_idle(pipe->ldev);
> > +
> > drm_sched_resubmit_jobs(&pipe->base);
> > drm_sched_start(&pipe->base, true);
> > }
> > @@ -348,6 +353,8 @@ void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
> >
> > void lima_sched_pipe_task_done(struct lima_sched_pipe *pipe)
> > {
> > + lima_devfreq_record_idle(pipe->ldev);
>
> This should be moved to the else {} part of the following code. As you
> have added the save
> idle record to the lima_sched_handle_error_task which is just the if
> {} part of the following
> code, so no need to call it twice for error tasks. BTW.
> lima_sched_handle_error_task is also
> used for timeout tasks, so add idle record in it is fine.
oh, that is a good catch - thank you!
I will fix that in the next version
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/1] drm/lima: Add optional devfreq support
Hi Robin,
On Mon, Dec 30, 2019 at 1:47 AM Robin Murphy wrote:
>
> On 2019-12-29 11:19 pm, Martin Blumenstingl wrote:
> > Hi Robin,
> >
> > On Sun, Dec 29, 2019 at 11:58 PM Robin Murphy wrote:
> >>
> >> Hi Martin,
> >>
> >> On 2019-12-27 5:37 pm, Martin Blumenstingl wrote:
> >>> Most platforms with a Mali-400 or Mali-450 GPU also have support for
> >>> changing the GPU clock frequency. Add devfreq support so the GPU clock
> >>> rate is updated based on the actual GPU usage when the
> >>> "operating-points-v2" property is present in the board.dts.
> >>>
> >>> The actual devfreq code is taken from panfrost_devfreq.c and modified so
> >>> it matches what the lima hardware needs:
> >>> - a call to dev_pm_opp_set_clkname() during initialization because there
> >>> are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks
> >>> the GPU so we need to control it using devfreq.
> >>> - locking when reading or writing the devfreq statistics because (unlike
> >>> than panfrost) we have multiple PP and GP IRQs which may finish jobs
> >>> concurrently.
> >>
> >> I gave this a quick try on my RK3328, and the clock scaling indeed kicks
> >> in nicely on the glmark2 scenes that struggle, however something appears
> >> to be missing in terms of regulator association, as the appropriate OPP
> >> voltages aren't reflected in the GPU supply (fortunately the initial
> >> voltage seems close enough to that of the highest OPP not to cause major
> >> problems, on my box at least). With panfrost on RK3399 I do see the
> >> supply voltage scaling accordingly, but I don't know my way around
> >> devfreq well enough to know what matters in the difference :/
> > first of all: thank you for trying this out! :-)
> >
> > does your kernel include commit 221bc77914cbcc ("drm/panfrost: Use
> > generic code for devfreq") for your panfrost test?
> > if I understand the devfreq API correct then I suspect with that
> > commit panfrost also won't change the voltage anymore.
>
> Oh, you're quite right - I was already considering that change as
> ancient history, but indeed it's only in 5.5-rc, while that board is
> still on 5.4.y release kernels. No wonder I couldn't make sense of how
> the (current) code could possibly be working :)
>
> I'll try the latest -rc kernel tomorrow to confirm (now that PCIe is
> hopefully fixed), but I'm already fairly confident you've called it
> correctly.
I just tested it with the lima driver (by undervolting the GPU by
0.05V) and it seems that dev_pm_opp_set_regulators is really needed.
I'll fix this in the next version of this patch and also submit a fix
for panfrost (I won't be able to test that though, so help is
appreciated in terms of testing :))
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: rockchip: Add PX30 DSI DPHY
Hi Heiko, Heiko Stuebner wrote on Tue, 31 Dec 2019 13:14:02 +0100: > Am Dienstag, 31. Dezember 2019, 12:56:14 CET schrieb Heiko Stuebner: > > Am Dienstag, 24. Dezember 2019, 15:38:59 CET schrieb Miquel Raynal: > > > Add the PHY which outputs MIPI DSI and LVDS. > > > > > > Signed-off-by: Miquel Raynal > > > > applied for 5.6 (picked early due to it being shared between lvds and dsi) > > and I've just added the VO powerdomain to the dsi-dphy node. > > While the TRM is not really forthcoming in telling me if the dphy needs > the power-domain as well, the vendor kernel does, so we should probably > just follow their example ;-) . Agreed! Miquèl ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
On Tue, 2019-12-31 at 10:22 +0100, Krzysztof Kozlowski wrote:
> On Tue, Dec 31, 2019 at 08:18:01AM +0100, Artur Świgoń wrote:
> > Hi,
> >
> > On Mon, 2019-12-30 at 16:44 +0100, Krzysztof Kozlowski wrote:
> > > On Fri, Dec 20, 2019 at 12:56:50PM +0100, Artur Świgoń wrote:
> > > > This patch adds the following properties to the Exynos4412 DT:
> > > > - exynos,interconnect-parent-node: to declare connections between
> > > > nodes in order to guarantee PM QoS requirements between nodes;
> > > > - #interconnect-cells: required by the interconnect framework.
> > > >
> > > > Note that #interconnect-cells is always zero and node IDs are not
> > > > hardcoded anywhere.
> > > >
> > > > Signed-off-by: Artur Świgoń
> > > > ---
> > > > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
> > > > 1 file changed, 5 insertions(+)
> > >
> > > The order of patches is confusing. Patches 4 and 6 are split - do the
> > > depend on 5? I doubt but...
> >
> > Let me elaborate:
> >
> > The order of the patches in this series is such that every subsequent
> > patch adds some functionality (and, of course, applying patches one-by-one
> > yields a working kernel at every step). Specifically for patches 04--07:
> >
> > -- patch 04 adds interconnect _provider_ properties for Exynos4412;
> > -- patch 05 implements interconnect provider logic (depends on patch 04);
> > -- patch 06 adds interconnect _consumer_ properties for Exynos4412 mixer;
> > -- patch 07 implements interconnect consumer logic (depends on patches
> > 05 & 06);
> >
> > My reasoning is that this order allows to e.g., merge the interconnect
> > provider for exynos-bus and leave the consumers for later (not limited to
> > the mixer). I hope this makes sense.
>
> It is wrong. The driver should not depend on DTS changes because:
> 1. DTS always go through separate branch and tree, so last patch
>will have to wait up to 3 cycles (!!!),
> 2. You break backward compatibility.
It is up to the definition of "depends". The driver is _not_ broken without
the DTS patches, but the interconnect functionality will not be available.
The only requirement is that if we want to have a working interconnect
consumer, there needs to be a working interconnet provider (and I used
the word "depends" to specify what needs what in order to work as intended).
I still think the order of these patches is the most logical one for someone
reading this RFC as a whole.
> In certain cases dependency on DTS changes is ok:
> 1. Cleaning up deprecated properties,
> 2. Ignoring the backward compatibility for e.g. new platforms.
>
> None of these are applicable here.
>
> You need to rework it, put DTS changes at the end. This clearly shows
> that there is no wrong dependency.
>
> >
> > > Adjust the title to match the contents - you are not adding bindings but
> > > properties to bus nodes. Also the prefix is ARM: (look at recent
> > > commits).
> >
> > OK.
> >
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > @@ -90,6 +90,7 @@
> > > > &bus_dmc {
> > > > exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > > vdd-supply = <&buck1_reg>;
> > > > + #interconnect-cells = <0>;
> > >
> > > This does not look like property of Odroid but Exynos4412 or Exynos4.
> >
> > Strangely enough, this file is where the 'exynos,parent-bus' (aka.
> > 'devfreq')
> > properties are located (and everything in this RFC concerns devfreq).
>
> I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
> you elaborate?
Currently a name change is being made: 'devfreq' -> 'exynos,parent-bus'
https://patchwork.kernel.org/patch/11304549/
(a dependency of this RFC; also available in devfreq-testing branch)
Best regards,
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: Add alpha property for sun8i and sun50i VI layer
Hi!
Dne ponedeljek, 30. december 2019 ob 19:08:42 CET je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> DE3.0 VI layers supports plane-global alpha channel.
> DE2.0 FCC block have GLOBAL_ALPHA register that can be used as alpha source
> for blender.
>
> Add alpha property to the DRM plane and connect it to the
> corresponding registers in the mixer.
>
> Signed-off-by: Roman Stratiienko
> ---
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 46 +-
> drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 11 ++
> 2 files changed, 49 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index 42d445d23773..db32a78c75d9
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> @@ -65,6 +65,36 @@ static void sun8i_vi_layer_enable(struct sun8i_mixer
> *mixer, int channel, }
> }
>
> +static void sun8i_vi_layer_update_alpha(struct sun8i_mixer *mixer, int
> channel, +int overlay, struct
drm_plane *plane)
> +{
> + u32 mask, val, ch_base;
> +
> + ch_base = sun8i_channel_base(mixer, channel);
> +
> + if (mixer->cfg->is_de3) {
> + mask = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK |
> +SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_MASK;
> + val = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA
> + (plane->state->alpha >> 8);
> +
> + val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
> +
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_PIXEL :
> +
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_COMBINED;
> +
> + regmap_update_bits(mixer->engine.regs,
> +
SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
> +
overlay),
> +mask, val);
> + } else {
> + regmap_update_bits(mixer->engine.regs,
> +
SUN8I_MIXER_FCC_GLOBAL_ALPHA_REG,
> +
SUN8I_MIXER_FCC_GLOBAL_ALPHA_MASK,
> +SUN8I_MIXER_FCC_GLOBAL_ALPHA
> + (plane->state->alpha >>
8));
In general, this is fine, except I don't know how this will work on V3. V3 is
the only SoC which have 2 VI layers in one mixer. I checked DE2 BSP sources
and only only one VI alpha is defined in FCC, also for V3. BSP driver also
doesn't use this field at all, so I don't know if they missed it or it's really
only one alpha for both VI layers. I don't have V3 board, so I can't do any
experiment. To be on the safe side, we could check if mixer has > 1 VI plane
and if it is DE2 and skip adding alpha property for such combination for now.
What do you think?
Best regards,
Jernej
> + }
> +}
> +
> static int sun8i_vi_layer_update_coord(struct sun8i_mixer *mixer, int
> channel, int overlay, struct drm_plane *plane,
> unsigned int zpos)
> @@ -248,14 +278,6 @@ static int sun8i_vi_layer_update_formats(struct
> sun8i_mixer *mixer, int channel, SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
> overlay),
> SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE,
val);
>
> - /* It seems that YUV formats use global alpha setting. */
> - if (mixer->cfg->is_de3)
> - regmap_update_bits(mixer->engine.regs,
> -
SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
> -
overlay),
> -
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK,
> -
SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA(0xff));
> -
> return 0;
> }
>
> @@ -373,6 +395,8 @@ static void sun8i_vi_layer_atomic_update(struct
> drm_plane *plane,
>
> sun8i_vi_layer_update_coord(mixer, layer->channel,
> layer->overlay, plane, zpos);
> + sun8i_vi_layer_update_alpha(mixer, layer->channel,
> + layer->overlay, plane);
> sun8i_vi_layer_update_formats(mixer, layer->channel,
> layer->overlay, plane);
> sun8i_vi_layer_update_buffer(mixer, layer->channel,
> @@ -464,6 +488,12 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
> drm_device *drm,
>
> plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
>
> + ret = drm_plane_create_alpha_property(&layer->plane);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't add alpha property\n");
> + return ERR_PTR(ret);
> + }
> +
> ret = drm_plane_create_zpos_property(&layer->plane, index,
>0, plane_cnt -
1);
> if (ret) {
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.h index e
[PATCH] drm/nouveau: use NULL for pointer assignment.
Replace the use of 0 in the pointer assignment with NULL to address the following sparse warning: drivers/gpu/drm/nouveau/nouveau_hwmon.c:744:29: warning: Using plain integer as NULL pointer Signed-off-by: Wambui Karuga --- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c b/drivers/gpu/drm/nouveau/nouveau_hwmon.c index d445c6f3fece..1c3104d20571 100644 --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c @@ -741,7 +741,7 @@ nouveau_hwmon_init(struct drm_device *dev) special_groups[i++] = &pwm_fan_sensor_group; } - special_groups[i] = 0; + special_groups[i] = NULL; hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev, &nouveau_chip_info, special_groups); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/1] drm/lima: Add optional devfreq support
Hi Robin,
On Tue, Dec 31, 2019 at 5:40 PM Robin Murphy wrote:
>
> On 2019-12-31 2:17 pm, Martin Blumenstingl wrote:
> > Hi Robin,
> >
> > On Mon, Dec 30, 2019 at 1:47 AM Robin Murphy wrote:
> >>
> >> On 2019-12-29 11:19 pm, Martin Blumenstingl wrote:
> >>> Hi Robin,
> >>>
> >>> On Sun, Dec 29, 2019 at 11:58 PM Robin Murphy
> >>> wrote:
>
> Hi Martin,
>
> On 2019-12-27 5:37 pm, Martin Blumenstingl wrote:
> > Most platforms with a Mali-400 or Mali-450 GPU also have support for
> > changing the GPU clock frequency. Add devfreq support so the GPU clock
> > rate is updated based on the actual GPU usage when the
> > "operating-points-v2" property is present in the board.dts.
> >
> > The actual devfreq code is taken from panfrost_devfreq.c and modified so
> > it matches what the lima hardware needs:
> > - a call to dev_pm_opp_set_clkname() during initialization because there
> > are two clocks on Mali-4x0 IPs. "core" is the one that actually
> > clocks
> > the GPU so we need to control it using devfreq.
> > - locking when reading or writing the devfreq statistics because (unlike
> > than panfrost) we have multiple PP and GP IRQs which may finish
> > jobs
> > concurrently.
>
> I gave this a quick try on my RK3328, and the clock scaling indeed kicks
> in nicely on the glmark2 scenes that struggle, however something appears
> to be missing in terms of regulator association, as the appropriate OPP
> voltages aren't reflected in the GPU supply (fortunately the initial
> voltage seems close enough to that of the highest OPP not to cause major
> problems, on my box at least). With panfrost on RK3399 I do see the
> supply voltage scaling accordingly, but I don't know my way around
> devfreq well enough to know what matters in the difference :/
> >>> first of all: thank you for trying this out! :-)
> >>>
> >>> does your kernel include commit 221bc77914cbcc ("drm/panfrost: Use
> >>> generic code for devfreq") for your panfrost test?
> >>> if I understand the devfreq API correct then I suspect with that
> >>> commit panfrost also won't change the voltage anymore.
> >>
> >> Oh, you're quite right - I was already considering that change as
> >> ancient history, but indeed it's only in 5.5-rc, while that board is
> >> still on 5.4.y release kernels. No wonder I couldn't make sense of how
> >> the (current) code could possibly be working :)
> >>
> >> I'll try the latest -rc kernel tomorrow to confirm (now that PCIe is
> >> hopefully fixed), but I'm already fairly confident you've called it
> >> correctly.
> > I just tested it with the lima driver (by undervolting the GPU by
> > 0.05V) and it seems that dev_pm_opp_set_regulators is really needed.
> > I'll fix this in the next version of this patch and also submit a fix
> > for panfrost (I won't be able to test that though, so help is
> > appreciated in terms of testing :))
>
> Yeah, I started hacking something up for panfrost yesterday, but at the
> point of realising the core OPP code wants refactoring to actually
> handle optional regulators without spewing errors, decided that was
> crossing the line into "work" and thus could wait until next week :D
I'm not sure what you mean, dev_pm_opp_set_regulators uses
regulator_get_optional.
doesn't that mean that it is optional already?
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/sun4i: Reimplement plane z position setting logic
Hi!
Dne nedelja, 29. december 2019 ob 17:28:25 CET je
roman.stratiie...@globallogic.com 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")
> Signed-off-by: Roman Stratiienko
> ---
> v2:
> - Use SUN8I_MIXER_MAX_LAYERS macro
> - Use plane_cnt instead of hard-coded number
> - Put initialization of channel_zpos into for loop
> - Add 'Fixes' line to the commit message
> - Minor clean-ups
> - Comments added
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 52 +-
> 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 | 39 +++
> 4 files changed, 66 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 8b803eb903b8..d306ad5dc093
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -259,8 +259,54 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32
> format)
>
> static void sun8i_mixer_commit(struct sunxi_engine *engine)
> {
> - DRM_DEBUG_DRIVER("Committing changes\n");
> + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> + u32 base = sun8i_blender_base(mixer);
> + int i, j = 0;
> + int channel_by_zpos[SUN8I_MIXER_MAX_LAYERS];
> + u32 route = 0, pipe_ctl = 0;
> + int plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
Can you please sort above lines by size (longest to shortest) as much as
possible?
> +
> + DRM_DEBUG_DRIVER("Update blender routing\n");
> + /* Assume that values in mixer->channel_zpos[] are unique except -1
*/
I would remove "Assume that" because it's guaranteed by zpos normalization in
DRM core.
> +
> + for (i = 0; i < plane_cnt; i++)
> + channel_by_zpos[i] = -1;
>
> + /* Sort by zpos */
> + for (i = 0; i < plane_cnt; i++) {
> + int zpos = mixer->channel_zpos[i];
> +
> + if (zpos >= 0 && zpos < plane_cnt)
> + channel_by_zpos[zpos] = i;
> + }
> +
> + /* Route enabled blending channels first */
> + for (i = 0; i < plane_cnt; 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 remaining routing fields to match disabled channel indices */
> + for (i = 0; i < SUN8I_MIXER_MAX_LAYERS && j <
SUN8I_MIXER_MAX_LAYERS;
> + i++) {
> + if (mixer->channel_zpos[i] < 0) {
> + route |= i <<
SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(j);
> + j++;
> + }
> + }
Is above for loop really necessary? If pipe is not enabled I don't think you
need to set a route.
> +
> + regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL(base),
> +SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK,
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,
>SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
> }
> @@ -485,10 +531,12 @@ static int sun8i_mixer_bind(struct device *dev, struct
> device *master, 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);
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h index c6cc94057faf..b193d9d1db66
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -13,6 +13,8 @@
> #include "sun8i_csc.h"
> #include "sunxi_engine.h"
>
> +#define SUN8I_MIXER_MAX_LAYERS 5
> +
> #define SUN8I_MIXER_SIZE(w, h) (((h) - 1) << 16 |
((w) - 1))
> #define SUN8I_MIXER_COORD(x, y) ((y) << 16 | (x))
>
> @@ -176,6 +178,9 @@ struct sun8i_mixer {
>
> struct clk *bus_clk;
> struct clk *mod_clk;
> +
>
Re: [PATCH] dt-bindings: display: Convert Allwinner display pipeline to schemas
On Thu, Dec 19, 2019 at 1:47 AM Maxime Ripard wrote: > > The Allwinner SoCs have a display engine composed of several controllers > assembled differently depending on the SoC, the number and type of output > they have, and the additional features they provide. A number of those are > supported in Linux, with the matching bindings. > > Now that we have the DT validation in place, let's split into separate file > and convert the device tree bindings for those controllers to schemas. > > Signed-off-by: Maxime Ripard > --- > .../allwinner,sun4i-a10-display-backend.yaml | 268 > .../allwinner,sun4i-a10-display-engine.yaml | 114 > .../allwinner,sun4i-a10-display-frontend.yaml | 116 > .../display/allwinner,sun4i-a10-hdmi.yaml | 159 + > .../display/allwinner,sun4i-a10-tcon.yaml | 560 +++ > .../allwinner,sun4i-a10-tv-encoder.yaml | 62 ++ > .../display/allwinner,sun6i-a31-drc.yaml | 115 > .../allwinner,sun8i-a83t-de2-mixer.yaml | 96 +++ > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 251 +++ > .../allwinner,sun8i-a83t-hdmi-phy.yaml| 77 +++ > .../display/allwinner,sun8i-r40-tcon-top.yaml | 258 +++ > .../display/allwinner,sun9i-a80-deu.yaml | 110 +++ > .../bindings/display/sunxi/sun4i-drm.txt | 637 -- > 13 files changed, 2186 insertions(+), 637 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tv-encoder.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun6i-a31-drc.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml > create mode 100644 > Documentation/devicetree/bindings/display/allwinner,sun9i-a80-deu.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > diff --git > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > new file mode 100644 > index ..d941c9cf07df > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > @@ -0,0 +1,268 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: > http://devicetree.org/schemas/display/allwinner,sun4i-a10-display-backend.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Allwinner A10 Display Engine Backend Device Tree Bindings > + > +maintainers: > + - Chen-Yu Tsai > + - Maxime Ripard > + > +description: | > + The display engine backend exposes layers and sprites to the system. > + > +properties: > + compatible: > +enum: > + - allwinner,sun4i-a10-display-backend > + - allwinner,sun5i-a13-display-backend > + - allwinner,sun6i-a31-display-backend > + - allwinner,sun7i-a20-display-backend > + - allwinner,sun8i-a23-display-backend > + - allwinner,sun8i-a33-display-backend > + - allwinner,sun9i-a80-display-backend > + > + reg: > +minItems: 1 > +maxItems: 2 > +items: > + - description: Display Backend registers > + - description: SAT registers > + > + reg-names: > +minItems: 1 > +maxItems: 2 > +items: > + - const: be > + - const: sat > + > + interrupts: > +maxItems: 1 > + > + clocks: > +minItems: 3 > +maxItems: 4 > +items: > + - description: The backend interface clock > + - description: The backend module clock > + - description: The backend DRAM clock > + - description: The SAT clock > + > + clock-names: > +minItems: 3 > +maxItems: 4 > +items: > + - const: ahb > + - const: mod > + - const: ram > + - const: sat > + > + resets: > +minItems: 1 > +maxItems: 2 > +items: > + - description: The Backend reset line > + - description: The SAT reset line > + > + reset-names: > +minItems: 1 > +maxItems: 2 > +items: > + - const: be > + - const: sat > + > + # FIXME: This should be made required eventually once every SoC will > + # have the MB
Re: [PATCH v1 1/1] dt-bindings: one binding file for all simple panels
On Tue, Dec 31, 2019 at 6:21 AM Sam Ravnborg wrote:
>
> Thierry - I would appreciate feedback from you on this approach!
For the record, I'm in favor of this.
>
> There is an increasing number of new simple panels.
> Common for all simple panels are that they have a
> mandatory power-supply and some of them have backlight and / or
> an enable gpio.
This is the key part I think. It must be clear that only panels with a
single supply meet the definition of 'simple panel'. The main
variation for current bindings are what properties are required or
not. Both backlight and enable gpio could be tied off on any given
platform so they can never really be required.
We'll also probably want to do a version for DSI panels which add 'reg'.
> The binding file to describe these panels adds overhead
> that really do not add value.
> The binding are known and there is nothing gained from a specific
> example as they all look alike.
>
> The following patch introduces a single panel-simple.yaml
> and converts two ampire bindings over to the new file.
>
> The conversion - if applied will have following effects:
>
> - The maintainer for the individual file will change
> There is no need for many different maintainers for a simple binding.
> We have the same situation with the panel-simple driver in the kernel.
>
> - The license will change to (GPL-2.0-only OR BSD-2-Clause)
> There is usually only a single line copied from the original
> file, a line that is often copied from a datasheet.
> This license change should be acceptable considered what little
> is copied.
> If the license change is not OK we can use a dedicated binding
> file in these cases.
>
> This is a follow-up on Rob's big patch converting a lot of panel bindings
> to individual files:
>
> "dt-bindings: display: Convert a bunch of panels to DT schema"
> https://patchwork.ozlabs.org/patch/1197683/
>
> The objectives with one file for all the simple panles are:
> - Make it simpler to add bindings for simple panels
> - Keep the number of bindings file lower and thus easier to find a
> relevant file to copy from when adding new panels.
> - Keep the binding documentation for simple panels more consistent
> - Make it simpler to add support for new panels
>
> Signed-off-by: Sam Ravnborg
> Cc: Thierry Reding
> Cc: Rob Herring
> Cc: Maxime Ripard
> Cc: Yannick Fertre
> Cc: Mark Rutland
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: devicet...@vger.kernel.org
> ---
> .../panel/ampire,am-480272h3tmqw-t01h.yaml| 42 --
> .../panel/ampire,am800480r3tmqwa1h.txt| 7 ---
> .../bindings/display/panel/panel-simple.yaml | 56 +++
> 3 files changed, 56 insertions(+), 49 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-simple.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
>
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
> deleted file mode 100644
> index c6e33e7f36d0..
> ---
> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0
> -%YAML 1.2
>
> -$id:
> http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
> -$schema: http://devicetree.org/meta-schemas/core.yaml#
> -
> -title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> -
> -maintainers:
> - - Yannick Fertre
> - - Thierry Reding
> -
> -allOf:
> - - $ref: panel-common.yaml#
> -
> -properties:
> - compatible:
> -const: ampire,am-480272h3tmqw-t01h
> -
> - power-supply: true
> - enable-gpios: true
> - backlight: true
> - port: true
> -
> -required:
> - - compatible
> -
> -additionalProperties: false
> -
> -examples:
> - - |
> -panel_rgb: panel {
> - compatible = "ampire,am-480272h3tmqw-t01h";
> - enable-gpios = <&gpioa 8 1>;
> - port {
> -panel_in_rgb: endpoint {
> - remote-endpoint = <&controller_out_rgb>;
> -};
> - };
> -};
> -
> -...
> diff --git
> a/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
>
> b/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
> deleted file mode 100644
> index 83e2cae1cc1b..
> ---
> a/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "ampire,am800480r3tmqwa1h"
> -
> -This binding is compatible with the simple-panel binding, which is specified
> -in simple-panel.txt in this directory.
> diff --git
>
Re: [RFC v2 1/1] drm/lima: Add optional devfreq support
On 2019-12-31 2:17 pm, Martin Blumenstingl wrote:
Hi Robin,
On Mon, Dec 30, 2019 at 1:47 AM Robin Murphy wrote:
On 2019-12-29 11:19 pm, Martin Blumenstingl wrote:
Hi Robin,
On Sun, Dec 29, 2019 at 11:58 PM Robin Murphy wrote:
Hi Martin,
On 2019-12-27 5:37 pm, Martin Blumenstingl wrote:
Most platforms with a Mali-400 or Mali-450 GPU also have support for
changing the GPU clock frequency. Add devfreq support so the GPU clock
rate is updated based on the actual GPU usage when the
"operating-points-v2" property is present in the board.dts.
The actual devfreq code is taken from panfrost_devfreq.c and modified so
it matches what the lima hardware needs:
- a call to dev_pm_opp_set_clkname() during initialization because there
are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks
the GPU so we need to control it using devfreq.
- locking when reading or writing the devfreq statistics because (unlike
than panfrost) we have multiple PP and GP IRQs which may finish jobs
concurrently.
I gave this a quick try on my RK3328, and the clock scaling indeed kicks
in nicely on the glmark2 scenes that struggle, however something appears
to be missing in terms of regulator association, as the appropriate OPP
voltages aren't reflected in the GPU supply (fortunately the initial
voltage seems close enough to that of the highest OPP not to cause major
problems, on my box at least). With panfrost on RK3399 I do see the
supply voltage scaling accordingly, but I don't know my way around
devfreq well enough to know what matters in the difference :/
first of all: thank you for trying this out! :-)
does your kernel include commit 221bc77914cbcc ("drm/panfrost: Use
generic code for devfreq") for your panfrost test?
if I understand the devfreq API correct then I suspect with that
commit panfrost also won't change the voltage anymore.
Oh, you're quite right - I was already considering that change as
ancient history, but indeed it's only in 5.5-rc, while that board is
still on 5.4.y release kernels. No wonder I couldn't make sense of how
the (current) code could possibly be working :)
I'll try the latest -rc kernel tomorrow to confirm (now that PCIe is
hopefully fixed), but I'm already fairly confident you've called it
correctly.
I just tested it with the lima driver (by undervolting the GPU by
0.05V) and it seems that dev_pm_opp_set_regulators is really needed.
I'll fix this in the next version of this patch and also submit a fix
for panfrost (I won't be able to test that though, so help is
appreciated in terms of testing :))
Yeah, I started hacking something up for panfrost yesterday, but at the
point of realising the core OPP code wants refactoring to actually
handle optional regulators without spewing errors, decided that was
crossing the line into "work" and thus could wait until next week :D
Cheers,
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205977] [amdgpu] Vega10 dpm defaults cause card to overvolt and overboost
https://bugzilla.kernel.org/show_bug.cgi?id=205977 --- Comment #1 from stefansp...@gmail.com --- Created attachment 286549 --> https://bugzilla.kernel.org/attachment.cgi?id=286549&action=edit Testcase: Manually disabling ACG Manually disabling ACG leads to max. clocks being accepted all the time, but this only shows that there is an issue with ACG and is not a proper bugfix. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: rockchip: Add PX30 DSI DPHY
Am Dienstag, 31. Dezember 2019, 12:56:14 CET schrieb Heiko Stuebner: > Am Dienstag, 24. Dezember 2019, 15:38:59 CET schrieb Miquel Raynal: > > Add the PHY which outputs MIPI DSI and LVDS. > > > > Signed-off-by: Miquel Raynal > > applied for 5.6 (picked early due to it being shared between lvds and dsi) and I've just added the VO powerdomain to the dsi-dphy node. While the TRM is not really forthcoming in telling me if the dphy needs the power-domain as well, the vendor kernel does, so we should probably just follow their example ;-) . Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: rockchip: Add PX30 DSI DPHY
Am Dienstag, 24. Dezember 2019, 15:38:59 CET schrieb Miquel Raynal: > Add the PHY which outputs MIPI DSI and LVDS. > > Signed-off-by: Miquel Raynal applied for 5.6 (picked early due to it being shared between lvds and dsi) Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave and Daniel, 2 fixes, 1 of which is marked for stable. drm-misc-fixes-2019-12-31: -sun4i: Fix double-free in connector/encoder cleanup (Stefan) -malidp: Make vtable static (Ben) Cc: Ben Dooks Cc: Stefan Mavrodiev Cheers, Sean The following changes since commit d16f0f61400074dbc75797ca5ef5c3d50f6c0ddf: Merge tag 'drm-fixes-5.5-2019-12-12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2019-12-13 14:50:01 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-12-31 for you to fetch changes up to ac2917b01992c098b8d4e6837115e3ca347fdd90: drm/arm/mali: make malidp_mw_connector_helper_funcs static (2019-12-20 15:23:51 +) -sun4i: Fix double-free in connector/encoder cleanup (Stefan) -malidp: Make vtable static (Ben) Cc: Ben Dooks Cc: Stefan Mavrodiev Ben Dooks (Codethink) (1): drm/arm/mali: make malidp_mw_connector_helper_funcs static Stefan Mavrodiev (1): drm/sun4i: hdmi: Remove duplicate cleanup calls drivers/gpu/drm/arm/malidp_mw.c| 2 +- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: use BUG_ON macro for debugging.
On Mon, Dec 30, 2019 at 2:41 PM Wambui Karuga wrote:
>
> As the if statement only checks for the value of the offset_name
> variable, it can be replaced by the more conscise BUG_ON macro for error
> reporting.
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index c7441fb8313e..0fe7907f5a7d 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -315,10 +315,7 @@ OUT_PKT7(struct msm_ringbuffer *ring, uint8_t opcode,
> uint16_t cnt)
> static inline bool adreno_reg_check(struct adreno_gpu *gpu,
> enum adreno_regs offset_name)
> {
> - if (offset_name >= REG_ADRENO_REGISTER_MAX ||
> - !gpu->reg_offsets[offset_name]) {
> - BUG();
> - }
> + BUG_ON(offset_name >= REG_ADRENO_REGISTER_MAX ||
> !gpu->reg_offsets[offset_name]);
>
Minor nit: This line is longer than 80 chars
Other than that,
Reviewed-by: Sean Paul
> /*
> * REG_SKIP is a special value that tell us that the register in
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix error returned by program_hpd_filter
On 2019-11-17 12:22 p.m., Aditya Pakki wrote: > program_hpd_filter() currently fails to check for the errors > returned in construct(). This patch returns error in > case of failure. > > Signed-off-by: Aditya Pakki > --- > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c > index ca20b150afcc..bbb648a50c41 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c > @@ -1379,9 +1379,8 @@ static bool construct( >* If GPIO isn't programmed correctly HPD might not rise or drain >* fast enough, leading to bounces. >*/ > - program_hpd_filter(link); > + return program_hpd_filter(link); We don't want program_hpd_filter to become a fatal error, which this would do. Though it would be good to print a warning if program_hpd_filter fails as it's unexpected and might lead to bugs with some displays. In many cases failing to program the HPD filter won't lead to adverse behavior. Harry > > - return true; > device_tag_fail: > link->link_enc->funcs->destroy(&link->link_enc); > link_enc_create_fail: > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
On 2019-12-30 11:00 p.m., Lin, Wayne wrote: > [AMD Official Use Only - Internal Distribution Only] > Make sure to select the correct AIP designation for public emails. See my email on that from yesterday. :) >> >> From: Wentland, Harry >> Sent: Monday, December 30, 2019 23:26 >> To: Lin, Wayne; dri-devel@lists.freedesktop.org; >> amd-...@lists.freedesktop.org >> Cc: ly...@redhat.com; Zuo, Jerry; Kazlauskas, Nicholas; Wentland, Harry >> Subject: Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ >> >> On 2019-12-30 2:05 a.m., Wayne Lin wrote: >>> [Why] >>> According to DP spec, it should shift left 4 digits for NO_STOP_BIT >>> in REMOTE_I2C_READ message. Not 5 digits. >>> >>> [How] >>> Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in >>> drm_dp_encode_sideband_req(). >>> >>> Signed-off-by: Wayne Lin >> >> Good catch. Looks like this has been there since the beginning of MST in >> the kernel. How did you find this? Did this cause bad EDID reads or some >> other problem? If so the commit message should probably mention it. >> >> Harry > Thanks for your time. > > I found this while I was trying to debug MST issues by using AUX monitor. > So far, I don't observe problems that relate to this under my test cases and > environment. > However, this bit might affect the I2C signal generated by I2C master, I will > mention more > in the commit message. > Thanks. Was just curious if you saw any real issues. Good find nevertheless and good patch. You can add my Reviewed-by: Harry Wentland Harry > Thanks. >> >>> --- >>> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c >>> b/drivers/gpu/drm/drm_dp_mst_topology.c >>> index 1d1bfa49ca2b..0557e225ff67 100644 >>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c >>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c >>> @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct >>> drm_dp_sideband_msg_req_body *req, >>> memcpy(&buf[idx], >>> req->u.i2c_read.transactions[i].bytes, >>> req->u.i2c_read.transactions[i].num_bytes); >>> idx += req->u.i2c_read.transactions[i].num_bytes; >>> >>> - buf[idx] = >>> (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5; >>> + buf[idx] = >>> (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4; >>> buf[idx] |= >>> (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); >>> idx++; >>> } >>> > -- > Wayne Lin > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 6/8] drm/print: add drm_dev_* logging functions
On Mon, 23 Dec 2019, Sam Ravnborg wrote: > Hi Jani. > > On Mon, Dec 23, 2019 at 01:29:19PM +0200, Jani Nikula wrote: >> On Sat, 21 Dec 2019, Sam Ravnborg wrote: >> > There are a lot of cases where we have a device * but no drm_device *. >> > Add drm_dev_* variants of the logging functions to cover these cases. >> >> So I know there are some valid cases where we only have struct device *, >> and instead of passing struct drm_device * will need the distinction >> between multiple struct device *. >> >> Not all current uses of DRM_DEV_* meet that criteria, however. I think >> I'd like to have those converted over to the drm_device based logging >> first, and then see what's left. Because I fear adding these will just >> lead to mass conversion from DRM_DEV_* to drm_dev_*, and the ball gets >> dropped there. > > Hmm... > $ git grep -E '(DRM_DEV_ERROR|DRM_DEV_INFO|DRM_DEV_WARN|DRM_DEV_DEBUG)' > 953 > There are 4 hits in drm/* - the rest is in drivers (no suprise). > > > $ git grep -E '(DRM_ERROR|DRM_INFO|DRM_WARN|DRM_DEBUG)' | wc -l > 8380 > There are 626 hits in drm/* - the rest in drivers. > > > So moving over all DRM_DEV looks doable with a lot of effort. It touches > all drivers. > But the non-DEV variants - thats just too much. > This is a lot of effort required before we can offer new drivers > a simple a logical logging solution. I guess that's part of the point. Do we even want to offer new non-dev based alternatives for (DRM_ERROR|DRM_INFO|DRM_WARN|DRM_DEBUG)? We'll end up carrying the alternatives for years. And face tons of churn for no real benefit. Why not just stick to the old ones when you're not using a drm device based alternative? Switching from non-dev based logging to drm device based logging, OTOH, is worth the churn. > On top of this - there is today no gain using drm_device * versus device *. > The output is exactly the same. For me and i915 the gain is in not having to do the dereference everywhere. Having drm device available is the more common case. If you go through the current DRM_DEV_* uses, a significant portion of them use drm->dev or have drm device readily available. Again, I'd prefer converting them over to drm device instead of just changing the call to another struct device based version. And then see how big the demand really is for struct device based logging before adding all possible variations of it. Could they do with less? Using drm device gives us the benefit that we can also add drm device based debug control if we want, for example to enable debug only for a certain device in a multi-GPU system. That option is not easily available with struct device based logging. > We should discuss what is required before we can offer the full solution > for new drivers. And how much the existing usage should hold this back. I guess I'm more concerned about existing drivers and the conversion than new drivers... BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] dt-bindings: one binding file for all simple panels
Thierry - I would appreciate feedback from you on this approach!
There is an increasing number of new simple panels.
Common for all simple panels are that they have a
mandatory power-supply and some of them have backlight and / or
an enable gpio.
The binding file to describe these panels adds overhead
that really do not add value.
The binding are known and there is nothing gained from a specific
example as they all look alike.
The following patch introduces a single panel-simple.yaml
and converts two ampire bindings over to the new file.
The conversion - if applied will have following effects:
- The maintainer for the individual file will change
There is no need for many different maintainers for a simple binding.
We have the same situation with the panel-simple driver in the kernel.
- The license will change to (GPL-2.0-only OR BSD-2-Clause)
There is usually only a single line copied from the original
file, a line that is often copied from a datasheet.
This license change should be acceptable considered what little
is copied.
If the license change is not OK we can use a dedicated binding
file in these cases.
This is a follow-up on Rob's big patch converting a lot of panel bindings
to individual files:
"dt-bindings: display: Convert a bunch of panels to DT schema"
https://patchwork.ozlabs.org/patch/1197683/
The objectives with one file for all the simple panles are:
- Make it simpler to add bindings for simple panels
- Keep the number of bindings file lower and thus easier to find a
relevant file to copy from when adding new panels.
- Keep the binding documentation for simple panels more consistent
- Make it simpler to add support for new panels
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Rob Herring
Cc: Maxime Ripard
Cc: Yannick Fertre
Cc: Mark Rutland
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: devicet...@vger.kernel.org
---
.../panel/ampire,am-480272h3tmqw-t01h.yaml| 42 --
.../panel/ampire,am800480r3tmqwa1h.txt| 7 ---
.../bindings/display/panel/panel-simple.yaml | 56 +++
3 files changed, 56 insertions(+), 49 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
delete mode 100644
Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
deleted file mode 100644
index c6e33e7f36d0..
---
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
+++ /dev/null
@@ -1,42 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
-$id:
http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
-
-maintainers:
- - Yannick Fertre
- - Thierry Reding
-
-allOf:
- - $ref: panel-common.yaml#
-
-properties:
- compatible:
-const: ampire,am-480272h3tmqw-t01h
-
- power-supply: true
- enable-gpios: true
- backlight: true
- port: true
-
-required:
- - compatible
-
-additionalProperties: false
-
-examples:
- - |
-panel_rgb: panel {
- compatible = "ampire,am-480272h3tmqw-t01h";
- enable-gpios = <&gpioa 8 1>;
- port {
-panel_in_rgb: endpoint {
- remote-endpoint = <&controller_out_rgb>;
-};
- };
-};
-
-...
diff --git
a/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
b/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
deleted file mode 100644
index 83e2cae1cc1b..
---
a/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
-
-Required properties:
-- compatible: should be "ampire,am800480r3tmqwa1h"
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
new file mode 100644
index ..711fac0a4d12
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-simple.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple panels
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+
+description: |
+ This binding file is a collection of the simple (dump) panels that
+ requires only a power-supply.
+ There are optionally a backlight and an enabl
[PATCH v3 7/9] dt-bindings: sun6i-dsi: Document R40 MIPI-DSI controller (w/ A64 fallback)
The MIPI DSI controller on Allwinner R40 is similar on the one on A64 like doesn't associate any DSI_SCLK gating. So, add R40 compatible and append A64 compatible as fallback. Signed-off-by: Jagan Teki --- Changes for v3: - update the binding in new yaml format .../bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml| 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml index d41ecb5e7f7c..138ffb6ae403 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml @@ -15,9 +15,11 @@ properties: "#size-cells": true compatible: -enum: - - allwinner,sun6i-a31-mipi-dsi - - allwinner,sun50i-a64-mipi-dsi +oneOf: + - const: allwinner,sun6i-a31-mipi-dsi + - const: allwinner,sun50i-a64-mipi-dsi + - items: + - const: allwinner,sun8i-r40-mipi-dsi reg: maxItems: 1 -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/9] drm/sun4i: tcon_top: Use clock name index macros
TCON TOP mux blocks in R40 are registering clock using
tcon top clock index numbers.
Right now the code is using, real numbers start with 0, but
we have proper macros that defined these name index numbers.
Use the existing macros, instead of real numbers for more
code readability.
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index 75d8e60c149d..e0b3c5330b9a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -194,19 +194,22 @@ static int sun8i_tcon_top_bind(struct device *dev, struct
device *master,
clk_data->hws[CLK_TCON_TOP_TV0] =
sun8i_tcon_top_register_gate(dev, "tcon-tv0", regs,
&tcon_top->reg_lock,
-TCON_TOP_TCON_TV0_GATE, 0);
+TCON_TOP_TCON_TV0_GATE,
+CLK_TCON_TOP_TV0);
if (quirks->has_tcon_tv1)
clk_data->hws[CLK_TCON_TOP_TV1] =
sun8i_tcon_top_register_gate(dev, "tcon-tv1", regs,
&tcon_top->reg_lock,
-TCON_TOP_TCON_TV1_GATE, 1);
+TCON_TOP_TCON_TV1_GATE,
+CLK_TCON_TOP_TV1);
if (quirks->has_dsi)
clk_data->hws[CLK_TCON_TOP_DSI] =
sun8i_tcon_top_register_gate(dev, "dsi", regs,
&tcon_top->reg_lock,
-TCON_TOP_TCON_DSI_GATE, 2);
+TCON_TOP_TCON_DSI_GATE,
+CLK_TCON_TOP_DSI);
for (i = 0; i < CLK_NUM; i++)
if (IS_ERR(clk_data->hws[i])) {
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] drm/sun4i: tcon: Add TCON LCD support for R40
TCON LCD0, LCD1 in allwinner R40, are used for managing
LCD interfaces like RGB, LVDS and DSI.
Like TCON TV0, TV1 these LCD0, LCD1 are also managed via
tcon top.
Add support for it, in tcon driver.
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index fad72799b8df..69611d38c844 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1470,6 +1470,13 @@ static const struct sun4i_tcon_quirks
sun8i_a83t_tv_quirks = {
.has_channel_1 = true,
};
+static const struct sun4i_tcon_quirks sun8i_r40_lcd_quirks = {
+ .supports_lvds = true,
+ .has_channel_0 = true,
+ /* TODO Need to support TCON output muxing via GPIO pins */
+ .set_mux= sun8i_r40_tcon_tv_set_mux,
+};
+
static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
.has_channel_1 = true,
.set_mux= sun8i_r40_tcon_tv_set_mux,
@@ -1500,6 +1507,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
&sun8i_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-tv", .data =
&sun8i_a83t_tv_quirks },
+ { .compatible = "allwinner,sun8i-r40-tcon-lcd", .data =
&sun8i_r40_lcd_quirks },
{ .compatible = "allwinner,sun8i-r40-tcon-tv", .data =
&sun8i_r40_tv_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data =
&sun9i_a80_tcon_lcd_quirks },
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DO NOT MERGE] [PATCH v3 9/9] ARM: dts: sun8i-r40: bananapi-m2-ultra: Enable Bananapi S070WV20-CT16
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M2U board.
DSI panel connected via board DSI port with,
- DCDC1 as VCC-DSI supply
- PH18 gpio for lcd enable pin
- PD17 gpio for lcd reset pin
- PD16 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 37 +++
1 file changed, 37 insertions(+)
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..99f84e6f15ce 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -45,6 +45,7 @@
#include "sun8i-r40.dtsi"
#include
+#include
/ {
model = "Banana Pi BPI-M2-Ultra";
@@ -55,6 +56,14 @@
serial0 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <2>;
+ enable-gpios = <&pio 7 16 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PH16
*/
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -117,6 +126,24 @@
status = "okay";
};
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ vcc-dsi-supply = <®_dcdc1>; /* VCC-DSI */
+ status = "okay";
+
+ panel@0 {
+ compatible = "bananapi,s070wv20-ct16-icn6211";
+ reg = <0>;
+ enable-gpio = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PH18
*/
+ reset-gpios = <&pio 7 17 GPIO_ACTIVE_HIGH>; /* LCD-RST: PH17 */
+ vdd-supply = <®_dcdc1>;
+ backlight = <&backlight>;
+ };
+};
+
&ehci1 {
status = "okay";
};
@@ -209,6 +236,12 @@
vcc-pg-supply = <®_dldo1>;
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
®_aldo2 {
regulator-min-microvolt = <250>;
regulator-max-microvolt = <250>;
@@ -295,6 +328,10 @@
regulator-name = "vdd1v2-sata";
};
+&tcon_lcd0 {
+ status = "okay";
+};
+
&tcon_tv0 {
status = "okay";
};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] dt-bindings: sun6i-dsi: Add R40 DPHY compatible (w/ A31 fallback)
The MIPI DSI PHY controller on Allwinner R40 is similar on the one on A31. Add R40 compatible and append A31 compatible as fallback. Signed-off-by: Jagan Teki --- Changes for v3: - update the binding in new yaml format .../devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml index 8841938050b2..0c283fe79402 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml @@ -18,6 +18,7 @@ properties: oneOf: - const: allwinner,sun6i-a31-mipi-dphy - items: + - const: allwinner,sun8i-r40-mipi-dphy - const: allwinner,sun50i-a64-mipi-dphy - const: allwinner,sun6i-a31-mipi-dphy -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/9] drm/sun4i: tcon_top: Register reset, clock gates in probe
TCON TOP is processing clock gates and reset control for
TV0, TV1 and DSI channels during bind and release the same
during unbind component ops.
The usual DSI initialization would setup all controller
clocks along with DPHY clocking during probe.
Since the actual clock gates (along with DSI clock gate)
are initialized during ton top bind, the DPHY is failed to
get the DSI clock during that time.
To solve, this circular dependency move the reset control,
clock gate registration from bind to probe and release the
same from unbind to remove.
This eventually give a chance DPHY to initialize the DSI
clock gate.
Signed-off-by: Jagan Teki
---
Changes for v3:
- fixed comments from Chen-Yu
- move reset control methods into probe
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 41 +-
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index e0b3c5330b9a..732ac19b4371 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -124,7 +124,22 @@ static struct clk_hw *sun8i_tcon_top_register_gate(struct
device *dev,
static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
void *data)
{
- struct platform_device *pdev = to_platform_device(dev);
+ return 0;
+}
+
+static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+}
+
+static const struct component_ops sun8i_tcon_top_ops = {
+ .bind = sun8i_tcon_top_bind,
+ .unbind = sun8i_tcon_top_unbind,
+};
+
+static int sun8i_tcon_top_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
struct clk_hw_onecell_data *clk_data;
struct sun8i_tcon_top *tcon_top;
const struct sun8i_tcon_top_quirks *quirks;
@@ -132,7 +147,7 @@ static int sun8i_tcon_top_bind(struct device *dev, struct
device *master,
void __iomem *regs;
int ret, i;
- quirks = of_device_get_match_data(&pdev->dev);
+ quirks = of_device_get_match_data(dev);
tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
if (!tcon_top)
@@ -226,22 +241,21 @@ static int sun8i_tcon_top_bind(struct device *dev, struct
device *master,
dev_set_drvdata(dev, tcon_top);
- return 0;
+ return component_add(dev, &sun8i_tcon_top_ops);
err_unregister_gates:
for (i = 0; i < CLK_NUM; i++)
if (!IS_ERR_OR_NULL(clk_data->hws[i]))
clk_hw_unregister_gate(clk_data->hws[i]);
- clk_disable_unprepare(tcon_top->bus);
err_assert_reset:
reset_control_assert(tcon_top->rst);
return ret;
}
-static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
- void *data)
+static int sun8i_tcon_top_remove(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
struct clk_hw_onecell_data *clk_data = tcon_top->clk_data;
int i;
@@ -253,21 +267,8 @@ static void sun8i_tcon_top_unbind(struct device *dev,
struct device *master,
clk_disable_unprepare(tcon_top->bus);
reset_control_assert(tcon_top->rst);
-}
-
-static const struct component_ops sun8i_tcon_top_ops = {
- .bind = sun8i_tcon_top_bind,
- .unbind = sun8i_tcon_top_unbind,
-};
-
-static int sun8i_tcon_top_probe(struct platform_device *pdev)
-{
- return component_add(&pdev->dev, &sun8i_tcon_top_ops);
-}
-static int sun8i_tcon_top_remove(struct platform_device *pdev)
-{
- component_del(&pdev->dev, &sun8i_tcon_top_ops);
+ component_del(dev, &sun8i_tcon_top_ops);
return 0;
}
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] dt-bindings: display: Add TCON LCD compatible for R40
Like TCON TV0, TV1 allwinner R40 has TCON LCD0, LCD1 which are managed via TCON TOP. Add tcon lcd compatible R40, the same compatible can handle TCON LCD0, LCD1. Signed-off-by: Jagan Teki Acked-by: Chen-Yu Tsai Reviewed-by: Rob Herring --- Changes for v3: - none Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 31ab72cba3d4..9e9c7f934202 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -160,6 +160,7 @@ Required properties: * allwinner,sun8i-a33-tcon * allwinner,sun8i-a83t-tcon-lcd * allwinner,sun8i-a83t-tcon-tv + * allwinner,sun8i-r40-tcon-lcd * allwinner,sun8i-r40-tcon-tv * allwinner,sun8i-v3s-tcon * allwinner,sun9i-a80-tcon-lcd -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] ARM: dts: sun8i: r40: Use tcon top clock index macros
tcon_tv0, tcon_tv1 nodes have a clock names of tcon-ch0, tcon-ch1 which are referring tcon_top clocks via index numbers like 0, 1 with CLK_TCON_TV0 and CLK_TCON_TV1 respectively. Use the macro in place of index numbers, for more code readability. Signed-off-by: Jagan Teki Reviewed-by: Chen-Yu Tsai --- Changes for v3: - none arch/arm/boot/dts/sun8i-r40.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi index c9c2688db66d..3faa35d43afa 100644 --- a/arch/arm/boot/dts/sun8i-r40.dtsi +++ b/arch/arm/boot/dts/sun8i-r40.dtsi @@ -44,6 +44,7 @@ #include #include #include +#include #include #include @@ -709,7 +710,7 @@ compatible = "allwinner,sun8i-r40-tcon-tv"; reg = <0x01c73000 0x1000>; interrupts = ; - clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>; + clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top CLK_TCON_TOP_TV0>; clock-names = "ahb", "tcon-ch1"; resets = <&ccu RST_BUS_TCON_TV0>; reset-names = "lcd"; @@ -752,7 +753,7 @@ compatible = "allwinner,sun8i-r40-tcon-tv"; reg = <0x01c74000 0x1000>; interrupts = ; - clocks = <&ccu CLK_BUS_TCON_TV1>, <&tcon_top 1>; + clocks = <&ccu CLK_BUS_TCON_TV1>, <&tcon_top CLK_TCON_TOP_TV1>; clock-names = "ahb", "tcon-ch1"; resets = <&ccu RST_BUS_TCON_TV1>; reset-names = "lcd"; -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] ARM: dts: sun8i: r40: Add MIPI DSI pipeline
Add MIPI DSI pipeline for Allwinner R40.
Unlike conventional Display pipeline in allwinner, R40 have
TCON TCOP which would interact various block like muxes,
tcon lcd, tcon_tv for better pipeline fitting.
For MIPI DSI pipeline, we have to configure the tcon_lcd0
block which would interact with tcon_top for upper pipeline
connections and dsi block for lower pipeline connections.
So, this patch created that pipeline by adding new nodes
for tcon_lcd0, dsi, dphy and connet them to make proper
pipeline fitting.
Signed-off-by: Jagan Teki
---
Changes for v3:
- drop clock-names in dsi node
arch/arm/boot/dts/sun8i-r40.dtsi | 72
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 3faa35d43afa..4c61e93d9a0b 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -628,6 +628,7 @@
tcon_top_mixer0_out_tcon_lcd0:
endpoint@0 {
reg = <0>;
+ remote-endpoint =
<&tcon_lcd0_in_tcon_top_mixer0>;
};
tcon_top_mixer0_out_tcon_lcd1:
endpoint@1 {
@@ -706,6 +707,45 @@
};
};
+ tcon_lcd0: lcd-controller@1c71000 {
+ compatible = "allwinner,sun8i-r40-tcon-lcd";
+ reg = <0x01c71000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON_LCD0>, <&ccu CLK_TCON_LCD0>;
+ clock-names = "ahb", "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON_LCD0>, <&ccu RST_BUS_LVDS>;
+ reset-names = "lcd", "lvds";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_lcd0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon_lcd0_in_tcon_top_mixer0:
endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon_top_mixer0_out_tcon_lcd0>;
+ };
+ };
+
+ tcon_lcd0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon_lcd0_out_dsi_out: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&dsi_in_tcon_lcd0_out>;
+ };
+ };
+ };
+ };
+
tcon_tv0: lcd-controller@1c73000 {
compatible = "allwinner,sun8i-r40-tcon-tv";
reg = <0x01c73000 0x1000>;
@@ -803,6 +843,38 @@
interrupts = ;
};
+ dsi: dsi@1ca {
+ compatible = "allwinner,sun8i-r40-mipi-dsi",
+"allwinner,sun50i-a64-mipi-dsi";
+ reg = <0x01ca 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_MIPI_DSI>;
+ resets = <&ccu RST_BUS_MIPI_DSI>;
+ phys = <&dphy>;
+ phy-names = "dphy";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ dsi_in_tcon_lcd0_out: endpoint {
+ remote-endpoint =
<&tcon_lcd0_out_dsi_out>;
+ };
+ };
+ };
+
+ dphy: d-phy@1ca1000 {
+ compatible = "allwinner,sun8i-r40-mipi-dphy",
+"allwinner,sun6i-a31-mipi-dphy";
+ reg = <0x01ca1000 0x1000>;
+ clocks = <&ccu CLK_BUS_MIPI_DSI>,
+<&tcon_top CLK_TCON_TOP_DSI>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_MIPI_DSI>;
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
hdmi: hdmi@1ee {
compatible = "allwin
[PATCH v3 0/9] drm/sun4i: Allwinner R40 MIPI-DSI support
This is v3 version for supporting MIPI-DSI on Allwinner R40 from initial version[1]. The controller look similar like, Allwinner A64 but with associated R40 TCON TOP for DSI pipeline. Changes for v3: - collect Rob, Chen-Yu r-b, a-b tags - move tcon top reset control methods into probe - rebase on drm-misc Changes for v2: - drop tcon top lcd clock patch - add TODO text while adding tcon lcd support - add patch for registering tcon top clock gates in probe - change tcon-ch0 in tcon_lcd0 to CLK_TCON_LCD0 - change mod clock in dphy to tcon_top with index 3 [1] https://patchwork.freedesktop.org/series/62062/ Any inputs? Jagan. Jagan Teki (9): dt-bindings: display: Add TCON LCD compatible for R40 drm/sun4i: tcon: Add TCON LCD support for R40 ARM: dts: sun8i: r40: Use tcon top clock index macros drm/sun4i: tcon_top: Use clock name index macros drm/sun4i: tcon_top: Register reset, clock gates in probe dt-bindings: sun6i-dsi: Add R40 DPHY compatible (w/ A31 fallback) dt-bindings: sun6i-dsi: Document R40 MIPI-DSI controller (w/ A64 fallback) ARM: dts: sun8i: r40: Add MIPI DSI pipeline [DO NOT MERGE] ARM: dts: sun8i-r40: bananapi-m2-ultra: Enable Bananapi S070WV20-CT16 .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 8 +- .../bindings/display/sunxi/sun4i-drm.txt | 1 + .../phy/allwinner,sun6i-a31-mipi-dphy.yaml| 1 + .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 37 + arch/arm/boot/dts/sun8i-r40.dtsi | 77 ++- drivers/gpu/drm/sun4i/sun4i_tcon.c| 8 ++ drivers/gpu/drm/sun4i/sun8i_tcon_top.c| 50 ++-- 7 files changed, 154 insertions(+), 28 deletions(-) -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
On Tue, 31 Dec 2019 at 11:23, Artur Świgoń wrote:
> >
> > The order of patches should reflect first of all real dependency.
> > Whether it compiles, works at all and does not break anything. Logical
> > dependency of "when the feature will start working" is
> > irrelevant to DTS because DTS goes in separate way and driver is
> > independent of it.
>
> The order of patches does indeed reflect real dependency. I can also reorder
> them (preserving the dependencies) so that DTS patches go first in the series
> if this is the more preferred way.
It looks wrong then. Driver should not depend on DTS. I cannot find
the patch changing bindings (should be first in patchset) which could
also point to this problem.
It seems you added requirement for interconnect properties while it
should be rather optional.
> > > I still think the order of these patches is the most logical one for
> > > someone
> > > reading this RFC as a whole.
> >
> > I am sorry but it brings only confusion. DTS is orthogonal of the
> > driver code. You could even post the patchset without DTS (although then
> > it would raise questions where is the user of it, but still, you
> > could).
> >
> > Further, DTS describes also hardware so you could send certain DTS
> > patches without driver implementation to describe the hardware.
> >
> > Driver code and DTS are kind of different worlds so mixing them up for
> > logical review does not really make any sense.
> >
> > Not mentioning it is different than most of other patches on mailing
> > lists.
> >
> > BTW, it is the same as bindings which should (almost) always go first as
> > separate patches.
>
> Thanks for elaborating on this, I appreciate it.
> Regarding your original concern, patches 04 & 06 are separate for several
> reasons, one of which is that they are related to two different drivers
> (exynos-bus vs. exynos-mixer).
It's okay then (for them to be split).
>
> > >
> > > > In certain cases dependency on DTS changes is ok:
> > > > 1. Cleaning up deprecated properties,
> > > > 2. Ignoring the backward compatibility for e.g. new platforms.
> > > >
> > > > None of these are applicable here.
> > > >
> > > > You need to rework it, put DTS changes at the end. This clearly shows
> > > > that there is no wrong dependency.
> > > >
> > > > >
> > > > > > Adjust the title to match the contents - you are not adding
> > > > > > bindings but
> > > > > > properties to bus nodes. Also the prefix is ARM: (look at recent
> > > > > > commits).
> > > > >
> > > > > OK.
> > > > >
> > > > > > >
> > > > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > > > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > @@ -90,6 +90,7 @@
> > > > > > > &bus_dmc {
> > > > > > > exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > > > > > vdd-supply = <&buck1_reg>;
> > > > > > > + #interconnect-cells = <0>;
> > > > > >
> > > > > > This does not look like property of Odroid but Exynos4412 or
> > > > > > Exynos4.
> > > > >
> > > > > Strangely enough, this file is where the 'exynos,parent-bus' (aka.
> > > > > 'devfreq')
> > > > > properties are located (and everything in this RFC concerns devfreq).
> > > >
> > > > I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
> > > > you elaborate?
> > >
> > > Currently a name change is being made: 'devfreq' -> 'exynos,parent-bus'
> > > https://patchwork.kernel.org/patch/11304549/
> > > (a dependency of this RFC; also available in devfreq-testing branch)
> >
> > I see. That property also does not look like board (Odroid) specific so
> > it should be moved to Exynos4412 DTSI.
>
> Makes sense to me. Just from looking at the patch I referenced above, there is
> a significant level of code duplication between
> * arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> * arch/arm/boot/dts/exynos4412-midas.dtsi
> * arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> with relation to the devfreq*/exynos,* properties.
If you have in mind all the nodes with "status=okay", it's fine to
duplicate them.
Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
On Tue, Dec 31, 2019 at 10:41:47AM +0100, Artur Świgoń wrote:
> On Tue, 2019-12-31 at 10:22 +0100, Krzysztof Kozlowski wrote:
> > On Tue, Dec 31, 2019 at 08:18:01AM +0100, Artur Świgoń wrote:
> > > Hi,
> > >
> > > On Mon, 2019-12-30 at 16:44 +0100, Krzysztof Kozlowski wrote:
> > > > On Fri, Dec 20, 2019 at 12:56:50PM +0100, Artur Świgoń wrote:
> > > > > This patch adds the following properties to the Exynos4412 DT:
> > > > > - exynos,interconnect-parent-node: to declare connections between
> > > > > nodes in order to guarantee PM QoS requirements between nodes;
> > > > > - #interconnect-cells: required by the interconnect framework.
> > > > >
> > > > > Note that #interconnect-cells is always zero and node IDs are not
> > > > > hardcoded anywhere.
> > > > >
> > > > > Signed-off-by: Artur Świgoń
> > > > > ---
> > > > > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
> > > > > 1 file changed, 5 insertions(+)
> > > >
> > > > The order of patches is confusing. Patches 4 and 6 are split - do the
> > > > depend on 5? I doubt but...
> > >
> > > Let me elaborate:
> > >
> > > The order of the patches in this series is such that every subsequent
> > > patch adds some functionality (and, of course, applying patches one-by-one
> > > yields a working kernel at every step). Specifically for patches 04--07:
> > >
> > > -- patch 04 adds interconnect _provider_ properties for Exynos4412;
> > > -- patch 05 implements interconnect provider logic (depends on patch 04);
> > > -- patch 06 adds interconnect _consumer_ properties for Exynos4412 mixer;
> > > -- patch 07 implements interconnect consumer logic (depends on patches
> > > 05 & 06);
> > >
> > > My reasoning is that this order allows to e.g., merge the interconnect
> > > provider for exynos-bus and leave the consumers for later (not limited to
> > > the mixer). I hope this makes sense.
> >
> > It is wrong. The driver should not depend on DTS changes because:
> > 1. DTS always go through separate branch and tree, so last patch
> >will have to wait up to 3 cycles (!!!),
> > 2. You break backward compatibility.
>
> It is up to the definition of "depends". The driver is _not_ broken without
> the DTS patches, but the interconnect functionality will not be available.
>
> The only requirement is that if we want to have a working interconnect
> consumer, there needs to be a working interconnet provider (and I used
> the word "depends" to specify what needs what in order to work as intended).
>
The order of patches should reflect first of all real dependency.
Whether it compiles, works at all and does not break anything. Logical
dependency of "when the feature will start working" is
irrelevant to DTS because DTS goes in separate way and driver is
independent of it.
> I still think the order of these patches is the most logical one for someone
> reading this RFC as a whole.
I am sorry but it brings only confusion. DTS is orthogonal of the
driver code. You could even post the patchset without DTS (although then
it would raise questions where is the user of it, but still, you
could).
Further, DTS describes also hardware so you could send certain DTS
patches without driver implementation to describe the hardware.
Driver code and DTS are kind of different worlds so mixing them up for
logical review does not really make any sense.
Not mentioning it is different than most of other patches on mailing
lists.
BTW, it is the same as bindings which should (almost) always go first as
separate patches.
>
> > In certain cases dependency on DTS changes is ok:
> > 1. Cleaning up deprecated properties,
> > 2. Ignoring the backward compatibility for e.g. new platforms.
> >
> > None of these are applicable here.
> >
> > You need to rework it, put DTS changes at the end. This clearly shows
> > that there is no wrong dependency.
> >
> > >
> > > > Adjust the title to match the contents - you are not adding bindings but
> > > > properties to bus nodes. Also the prefix is ARM: (look at recent
> > > > commits).
> > >
> > > OK.
> > >
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > @@ -90,6 +90,7 @@
> > > > > &bus_dmc {
> > > > > exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > > > vdd-supply = <&buck1_reg>;
> > > > > + #interconnect-cells = <0>;
> > > >
> > > > This does not look like property of Odroid but Exynos4412 or Exynos4.
> > >
> > > Strangely enough, this file is where the 'exynos,parent-bus' (aka.
> > > 'devfreq')
> > > properties are located (and everything in this RFC concerns devfreq).
> >
> > I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
> > you elaborate?
>
> Currently a name change is being made: '
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
Hi,
On Mon, 2019-12-30 at 16:44 +0100, Krzysztof Kozlowski wrote:
> On Fri, Dec 20, 2019 at 12:56:50PM +0100, Artur Świgoń wrote:
> > This patch adds the following properties to the Exynos4412 DT:
> > - exynos,interconnect-parent-node: to declare connections between
> > nodes in order to guarantee PM QoS requirements between nodes;
> > - #interconnect-cells: required by the interconnect framework.
> >
> > Note that #interconnect-cells is always zero and node IDs are not
> > hardcoded anywhere.
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
>
> The order of patches is confusing. Patches 4 and 6 are split - do the
> depend on 5? I doubt but...
Let me elaborate:
The order of the patches in this series is such that every subsequent
patch adds some functionality (and, of course, applying patches one-by-one
yields a working kernel at every step). Specifically for patches 04--07:
-- patch 04 adds interconnect _provider_ properties for Exynos4412;
-- patch 05 implements interconnect provider logic (depends on patch 04);
-- patch 06 adds interconnect _consumer_ properties for Exynos4412 mixer;
-- patch 07 implements interconnect consumer logic (depends on patches
05 & 06);
My reasoning is that this order allows to e.g., merge the interconnect
provider for exynos-bus and leave the consumers for later (not limited to
the mixer). I hope this makes sense.
> Adjust the title to match the contents - you are not adding bindings but
> properties to bus nodes. Also the prefix is ARM: (look at recent
> commits).
OK.
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > index 4ce3d77a6704..d9d70eacfcaf 100644
> > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > @@ -90,6 +90,7 @@
> > &bus_dmc {
> > exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > vdd-supply = <&buck1_reg>;
> > + #interconnect-cells = <0>;
>
> This does not look like property of Odroid but Exynos4412 or Exynos4.
Strangely enough, this file is where the 'exynos,parent-bus' (aka. 'devfreq')
properties are located (and everything in this RFC concerns devfreq).
Regards,
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/sun4i: Reimplement plane z position setting logic
Please HOLD this until v3.
I forgot about blender channel frame coords that updated according to
zpos and can have gap between channels.
I will also try to simplify this patch.
On Sun, Dec 29, 2019 at 6:28 PM wrote:
>
> 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")
> Signed-off-by: Roman Stratiienko
> ---
> v2:
> - Use SUN8I_MIXER_MAX_LAYERS macro
> - Use plane_cnt instead of hard-coded number
> - Put initialization of channel_zpos into for loop
> - Add 'Fixes' line to the commit message
> - Minor clean-ups
> - Comments added
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 52 +-
> 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 | 39 +++
> 4 files changed, 66 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index 8b803eb903b8..d306ad5dc093 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -259,8 +259,54 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32
> format)
>
> static void sun8i_mixer_commit(struct sunxi_engine *engine)
> {
> - DRM_DEBUG_DRIVER("Committing changes\n");
> + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> + u32 base = sun8i_blender_base(mixer);
> + int i, j = 0;
> + int channel_by_zpos[SUN8I_MIXER_MAX_LAYERS];
> + u32 route = 0, pipe_ctl = 0;
> + int plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
> +
> + DRM_DEBUG_DRIVER("Update blender routing\n");
> + /* Assume that values in mixer->channel_zpos[] are unique except -1 */
> +
> + for (i = 0; i < plane_cnt; i++)
> + channel_by_zpos[i] = -1;
>
> + /* Sort by zpos */
> + for (i = 0; i < plane_cnt; i++) {
> + int zpos = mixer->channel_zpos[i];
> +
> + if (zpos >= 0 && zpos < plane_cnt)
> + channel_by_zpos[zpos] = i;
> + }
> +
> + /* Route enabled blending channels first */
> + for (i = 0; i < plane_cnt; 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 remaining routing fields to match disabled channel indices */
> + for (i = 0; i < SUN8I_MIXER_MAX_LAYERS && j < SUN8I_MIXER_MAX_LAYERS;
> +i++) {
> + if (mixer->channel_zpos[i] < 0) {
> + route |= i << SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(j);
> + j++;
> + }
> + }
> +
> + regmap_update_bits(mixer->engine.regs,
> SUN8I_MIXER_BLEND_PIPE_CTL(base),
> + SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 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,
> SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
> }
> @@ -485,10 +531,12 @@ static int sun8i_mixer_bind(struct device *dev, struct
> device *master,
> 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);
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> index c6cc94057faf..b193d9d1db66 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -13,6 +13,8 @@
> #include "sun8i_csc.h"
> #include "sunxi_engine.h"
>
> +#define SUN8I_MIXER_MAX_LAYERS 5
> +
> #define SUN8I_MIXER_SIZE(w, h) (((h) - 1) << 16 | ((w) - 1))
> #define SUN8I_MIXER_COORD(x, y)((y) << 16 | (x))
>
> @@ -176,6 +178,9 @@ struct sun8i_mixer {
>
> struct clk *bus_clk;
> struct clk *mod_clk;
> +
> + /* -1 means that layer is disabled */
> +
[PATCH V2] drm/v3d: remove duplicated kfree in v3d_submit_cl_ioctl
kfree() was called for the same variable twice within an if branch.
Fix it by deleting a duplicate function call.
Fixes: 29cd13cfd762 ("drm/v3d: Fix memory leak in v3d_submit_cl_ioctl")
Signed-off-by: yu kuai
---
drivers/gpu/drm/v3d/v3d_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 549dde83408b..37515e47b47e 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
ret = v3d_job_init(v3d, file_priv, &bin->base,
v3d_job_free, args->in_sync_bcl);
if (ret) {
- kfree(bin);
v3d_job_put(&render->base);
kfree(bin);
return ret;
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/hisilicon: get the BO from drm_fb rather than hibmc_fb
since we can get the BO from drm_fb rather than hibmc_fb,do not need the hibmc_fb.so we delete the local variable hibmc_fb. Signed-off-by: Tian Tao Signed-off-by: Gong junjie --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c index 6bf4334..12b38ac 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c @@ -105,14 +105,12 @@ static void hibmc_plane_atomic_update(struct drm_plane *plane, s64 gpu_addr = 0; unsigned int line_l; struct hibmc_drm_private *priv = plane->dev->dev_private; - struct hibmc_framebuffer *hibmc_fb; struct drm_gem_vram_object *gbo; if (!state->fb) return; - hibmc_fb = to_hibmc_framebuffer(state->fb); - gbo = drm_gem_vram_of_gem(hibmc_fb->obj); + gbo = drm_gem_vram_of_gem(state->fb->obj[0]); gpu_addr = drm_gem_vram_offset(gbo); if (WARN_ON_ONCE(gpu_addr < 0)) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/nouveau/nv04: Use match_string() helper to simplify the code
match_string() returns the array index of a matching string.
Use it instead of the open-coded implementation.
Signed-off-by: YueHaibing
---
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index 03466f0..3a9489e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -644,16 +644,13 @@ static int nv17_tv_create_resources(struct drm_encoder
*encoder,
int i;
if (nouveau_tv_norm) {
- for (i = 0; i < num_tv_norms; i++) {
- if (!strcmp(nv17_tv_norm_names[i], nouveau_tv_norm)) {
- tv_enc->tv_norm = i;
- break;
- }
- }
-
- if (i == num_tv_norms)
+ i = match_string(nv17_tv_norm_names, num_tv_norms,
+nouveau_tv_norm);
+ if (i < 0)
NV_WARN(drm, "Invalid TV norm setting \"%s\"\n",
nouveau_tv_norm);
+ else
+ tv_enc->tv_norm = i;
}
drm_mode_create_tv_properties(dev, num_tv_norms, nv17_tv_norm_names);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: declare variable as __be16
Declare the temp variable as __be16 to address the following sparse
warning:
drivers/gpu/drm/panel/panel-lg-lg4573.c:45:20: warning: incorrect type in
initializer (different base types)
drivers/gpu/drm/panel/panel-lg-lg4573.c:45:20:expected unsigned short
[unsigned] [usertype] temp
drivers/gpu/drm/panel/panel-lg-lg4573.c:45:20:got restricted __be16
[usertype]
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/panel/panel-lg-lg4573.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-lg4573.c
b/drivers/gpu/drm/panel/panel-lg-lg4573.c
index 20235ff0bbc4..b262b53dbd85 100644
--- a/drivers/gpu/drm/panel/panel-lg-lg4573.c
+++ b/drivers/gpu/drm/panel/panel-lg-lg4573.c
@@ -42,7 +42,7 @@ static int lg4573_spi_write_u16(struct lg4573 *ctx, u16 data)
struct spi_transfer xfer = {
.len = 2,
};
- u16 temp = cpu_to_be16(data);
+ __be16 temp = cpu_to_be16(data);
struct spi_message msg;
dev_dbg(ctx->panel.dev, "writing data: %x\n", data);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/sun4i: Reimplement plane z position setting logic
False alarm. Since DRM sets normalized ZPOS there should be no gaps
and all should work as expected.
On Mon, Dec 30, 2019 at 1:25 PM Roman Stratiienko
wrote:
>
> Please HOLD this until v3.
> I forgot about blender channel frame coords that updated according to
> zpos and can have gap between channels.
> I will also try to simplify this patch.
>
> On Sun, Dec 29, 2019 at 6:28 PM wrote:
> >
> > 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")
> > Signed-off-by: Roman Stratiienko
> > ---
> > v2:
> > - Use SUN8I_MIXER_MAX_LAYERS macro
> > - Use plane_cnt instead of hard-coded number
> > - Put initialization of channel_zpos into for loop
> > - Add 'Fixes' line to the commit message
> > - Minor clean-ups
> > - Comments added
> > ---
> > drivers/gpu/drm/sun4i/sun8i_mixer.c| 52 +-
> > 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 | 39 +++
> > 4 files changed, 66 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > index 8b803eb903b8..d306ad5dc093 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -259,8 +259,54 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32
> > format)
> >
> > static void sun8i_mixer_commit(struct sunxi_engine *engine)
> > {
> > - DRM_DEBUG_DRIVER("Committing changes\n");
> > + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> > + u32 base = sun8i_blender_base(mixer);
> > + int i, j = 0;
> > + int channel_by_zpos[SUN8I_MIXER_MAX_LAYERS];
> > + u32 route = 0, pipe_ctl = 0;
> > + int plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
> > +
> > + DRM_DEBUG_DRIVER("Update blender routing\n");
> > + /* Assume that values in mixer->channel_zpos[] are unique except -1
> > */
> > +
> > + for (i = 0; i < plane_cnt; i++)
> > + channel_by_zpos[i] = -1;
> >
> > + /* Sort by zpos */
> > + for (i = 0; i < plane_cnt; i++) {
> > + int zpos = mixer->channel_zpos[i];
> > +
> > + if (zpos >= 0 && zpos < plane_cnt)
> > + channel_by_zpos[zpos] = i;
> > + }
> > +
> > + /* Route enabled blending channels first */
> > + for (i = 0; i < plane_cnt; 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 remaining routing fields to match disabled channel indices */
> > + for (i = 0; i < SUN8I_MIXER_MAX_LAYERS && j <
> > SUN8I_MIXER_MAX_LAYERS;
> > +i++) {
> > + if (mixer->channel_zpos[i] < 0) {
> > + route |= i << SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(j);
> > + j++;
> > + }
> > + }
> > +
> > + regmap_update_bits(mixer->engine.regs,
> > SUN8I_MIXER_BLEND_PIPE_CTL(base),
> > + SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 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,
> > SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
> > }
> > @@ -485,10 +531,12 @@ static int sun8i_mixer_bind(struct device *dev,
> > struct device *master,
> > 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);
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > index c6cc94057faf..b193d9d1db66 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> > @@ -13,6 +13,8 @@
> > #include "sun8i_csc.h"
> > #include "sunxi_engine.h"
> >
>
[PATCH v2 3/4] drm/sun4i: Use CRTC size instead of PRIMARY plane size as mixer frame.
From: Roman Stratiienko
According to DRM documentation the only difference between PRIMARY
and OVERLAY plane is that each CRTC must have PRIMARY plane and
OVERLAY are optional.
Allow PRIMARY plane to have dimension different from full-screen.
Fixes: 90212fffa4fc ("drm/sun4i: Use values calculated by atomic check")
Signed-off-by: Roman Stratiienko
---
v2:
- Split commit in 2 parts
- Add Fixes line to the commit message
---
drivers/gpu/drm/sun4i/sun8i_mixer.c| 35 ++
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 30 --
2 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index d306ad5dc093..5d90a95ff855 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -257,6 +257,40 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32
format)
return NULL;
}
+static void sun8i_mode_set(struct sunxi_engine *engine,
+ struct drm_display_mode *mode)
+{
+ u32 dst_w = mode->crtc_hdisplay;
+ u32 dst_h = mode->crtc_vdisplay;
+ u32 outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
+ bool interlaced = false;
+ u32 val;
+ struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
+ u32 bld_base = sun8i_blender_base(mixer);
+
+ DRM_DEBUG_DRIVER("Mode change, updating global size W: %u H: %u\n",
+dst_w, dst_h);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_GLOBAL_SIZE,
+outsize);
+ regmap_write(mixer->engine.regs,
+SUN8I_MIXER_BLEND_OUTSIZE(bld_base), outsize);
+
+ interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
+
+ if (interlaced)
+ val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
+ else
+ val = 0;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_OUTCTL(bld_base),
+ SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
+ val);
+ DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
+interlaced ? "on" : "off");
+}
+
static void sun8i_mixer_commit(struct sunxi_engine *engine)
{
struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
@@ -356,6 +390,7 @@ static struct drm_plane **sun8i_layers_init(struct
drm_device *drm,
static const struct sunxi_engine_ops sun8i_engine_ops = {
.commit = sun8i_mixer_commit,
.layers_init= sun8i_layers_init,
+ .mode_set = sun8i_mode_set,
};
static struct regmap_config sun8i_mixer_regmap_config = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index ee7c13d8710f..23c2f4b68c89 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -72,36 +72,6 @@ static int sun8i_ui_layer_update_coord(struct sun8i_mixer
*mixer, int channel,
insize = SUN8I_MIXER_SIZE(src_w, src_h);
outsize = SUN8I_MIXER_SIZE(dst_w, dst_h);
- if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
- bool interlaced = false;
- u32 val;
-
- DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
-dst_w, dst_h);
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_GLOBAL_SIZE,
-outsize);
- regmap_write(mixer->engine.regs,
-SUN8I_MIXER_BLEND_OUTSIZE(bld_base), outsize);
-
- if (state->crtc)
- interlaced = state->crtc->state->adjusted_mode.flags
- & DRM_MODE_FLAG_INTERLACE;
-
- if (interlaced)
- val = SUN8I_MIXER_BLEND_OUTCTL_INTERLACED;
- else
- val = 0;
-
- regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_BLEND_OUTCTL(bld_base),
- SUN8I_MIXER_BLEND_OUTCTL_INTERLACED,
- val);
-
- DRM_DEBUG_DRIVER("Switching display mixer interlaced mode %s\n",
-interlaced ? "on" : "off");
- }
-
/* Set height and width */
DRM_DEBUG_DRIVER("Layer source offset X: %d Y: %d\n",
state->src.x1 >> 16, state->src.y1 >> 16);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: use BUG_ON macro for debugging.
As the if statement only checks for the value of the offset_name
variable, it can be replaced by the more conscise BUG_ON macro for error
reporting.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index c7441fb8313e..0fe7907f5a7d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -315,10 +315,7 @@ OUT_PKT7(struct msm_ringbuffer *ring, uint8_t opcode,
uint16_t cnt)
static inline bool adreno_reg_check(struct adreno_gpu *gpu,
enum adreno_regs offset_name)
{
- if (offset_name >= REG_ADRENO_REGISTER_MAX ||
- !gpu->reg_offsets[offset_name]) {
- BUG();
- }
+ BUG_ON(offset_name >= REG_ADRENO_REGISTER_MAX ||
!gpu->reg_offsets[offset_name]);
/*
* REG_SKIP is a special value that tell us that the register in
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/sun4i: Add alpha property for sun8i and sun50i VI layer
From: Roman Stratiienko
DE3.0 VI layers supports plane-global alpha channel.
DE2.0 FCC block have GLOBAL_ALPHA register that can be used as alpha source
for blender.
Add alpha property to the DRM plane and connect it to the
corresponding registers in the mixer.
Signed-off-by: Roman Stratiienko
---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 46 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 11 ++
2 files changed, 49 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 42d445d23773..db32a78c75d9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -65,6 +65,36 @@ static void sun8i_vi_layer_enable(struct sun8i_mixer *mixer,
int channel,
}
}
+static void sun8i_vi_layer_update_alpha(struct sun8i_mixer *mixer, int channel,
+ int overlay, struct drm_plane *plane)
+{
+ u32 mask, val, ch_base;
+
+ ch_base = sun8i_channel_base(mixer, channel);
+
+ if (mixer->cfg->is_de3) {
+ mask = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK |
+ SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_MASK;
+ val = SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA
+ (plane->state->alpha >> 8);
+
+ val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
+ SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_PIXEL :
+ SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MODE_COMBINED;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
+ overlay),
+ mask, val);
+ } else {
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_FCC_GLOBAL_ALPHA_REG,
+ SUN8I_MIXER_FCC_GLOBAL_ALPHA_MASK,
+ SUN8I_MIXER_FCC_GLOBAL_ALPHA
+ (plane->state->alpha >> 8));
+ }
+}
+
static int sun8i_vi_layer_update_coord(struct sun8i_mixer *mixer, int channel,
int overlay, struct drm_plane *plane,
unsigned int zpos)
@@ -248,14 +278,6 @@ static int sun8i_vi_layer_update_formats(struct
sun8i_mixer *mixer, int channel,
SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base, overlay),
SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODE, val);
- /* It seems that YUV formats use global alpha setting. */
- if (mixer->cfg->is_de3)
- regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base,
- overlay),
- SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA_MASK,
- SUN50I_MIXER_CHAN_VI_LAYER_ATTR_ALPHA(0xff));
-
return 0;
}
@@ -373,6 +395,8 @@ static void sun8i_vi_layer_atomic_update(struct drm_plane
*plane,
sun8i_vi_layer_update_coord(mixer, layer->channel,
layer->overlay, plane, zpos);
+ sun8i_vi_layer_update_alpha(mixer, layer->channel,
+ layer->overlay, plane);
sun8i_vi_layer_update_formats(mixer, layer->channel,
layer->overlay, plane);
sun8i_vi_layer_update_buffer(mixer, layer->channel,
@@ -464,6 +488,12 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
+ ret = drm_plane_create_alpha_property(&layer->plane);
+ if (ret) {
+ dev_err(drm->dev, "Couldn't add alpha property\n");
+ return ERR_PTR(ret);
+ }
+
ret = drm_plane_create_zpos_property(&layer->plane, index,
0, plane_cnt - 1);
if (ret) {
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
index eaa6076f5dbc..48c399e1c86d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.h
@@ -29,14 +29,25 @@
#define SUN8I_MIXER_CHAN_VI_VDS_UV(base) \
((base) + 0xfc)
+#define SUN8I_MIXER_FCC_GLOBAL_ALPHA_REG \
+ (0xAA000 + 0x90)
+
+#define SUN8I_MIXER_FCC_GLOBAL_ALPHA(x)((x) << 24)
+#define SUN8I_MIXER_FCC_GLOBAL_ALPHA_MASK GENMASK(31, 24)
+
#define SUN8I_MIXER_CHAN_VI_LAYER_ATTR_EN BIT(0)
/* RGB mode should be set for RGB formats and cleared for YCbCr */
#define SUN8I_MIXER_CHAN_VI_LAYER_ATTR_RGB_MODEBIT(15)
#define SUN8I_MIXER_CHAN_VI_LAYER_ATTR_FBFMT_OFFSET8
#define SUN8
Re: [PATCH] drm/hisilicon: Checked the resolution is valid before connector
Hi tiantao,
Thanks for the patches.
I see you sent two patches about resolution. Could you just send them as a
series?
Xinliang
On Sat, 28 Dec 2019 at 08:59, Tian Tao wrote:
> In the previous version, the callback function mode_valid of
> drm_connector_helper_funcs directly returned MODE_OK. Now we will
> ensure that the resolution is correct and return MODE_OK, otherwise
> return MODE_NOMODE.
>
> Signed-off-by: Tian Tao
> Signed-off-by: Gong junjie
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 41
> ++--
> 1 file changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> index 6d98fdc..3d08210 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> @@ -11,22 +11,59 @@
> * Jianhua Li
> */
>
> +#include
> #include
> #include
> +#include
> #include
>
> #include "hibmc_drm_drv.h"
> #include "hibmc_drm_regs.h"
>
> +static const struct hibmc_resolution {
> + int w;
> + int h;
> +} hibmc_modetables[] = {
> + {640, 480}, {800, 600}, {1024, 768}, {1152, 864}, {1280, 768},
> + {1280, 720}, {1280, 960}, {1280, 1024}, {1440, 900}, {1600, 900},
> + {1600, 1200}, {1920, 1080}, {1920, 1200}
> +};
> +
> +static int hibmc_valid_mode(int w, int h)
> +{
> + int size = sizeof(hibmc_modetables) / sizeof(struct
> hibmc_resolution);
> + int i;
> +
> + for (i = 0; i < size; i++) {
> + if (hibmc_modetables[i].w == w && hibmc_modetables[i].h ==
> h)
> + return 0;
> + }
> +
> + return -1;
> +}
> +
> static int hibmc_connector_get_modes(struct drm_connector *connector)
> {
> - return drm_add_modes_noedid(connector, 800, 600);
> + int count;
> +
> + drm_connector_update_edid_property(connector, NULL);
> + count = drm_add_modes_noedid(connector, 1920, 1200);
> + drm_set_preferred_mode(connector, 1024, 768);
> +
> + return count;
> }
>
> static enum drm_mode_status hibmc_connector_mode_valid(struct
> drm_connector *connector,
> struct drm_display_mode *mode)
> {
> - return MODE_OK;
> + int vrefresh = drm_mode_vrefresh(mode);
> +
> + if (vrefresh < 59 || vrefresh > 61)
> + return MODE_NOMODE;
> + else if (hibmc_valid_mode(mode->hdisplay, mode->vdisplay) != 0)
> + return MODE_NOMODE;
> + else
> + return MODE_OK;
> }
>
> static const struct drm_connector_helper_funcs
> --
> 2.7.4
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/sun4i: Add alpha property for sun8i UI layer
From: Roman Stratiienko
DE2.0 and DE3.0 UI layers supports plane-global alpha channel.
Add alpha property to the DRM plane and connect it to the
corresponding registers in mixer.
Signed-off-by: Roman Stratiienko
---
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 29 ++
drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 5 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index c87fd842918e..4343ea9f8cf8 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -72,6 +72,27 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer,
int channel,
}
}
+static void sun8i_ui_layer_update_alpha(struct sun8i_mixer *mixer, int channel,
+ int overlay, struct drm_plane *plane)
+{
+ u32 mask, val, ch_base;
+
+ ch_base = sun8i_channel_base(mixer, channel);
+
+ mask = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK |
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK;
+
+ val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA(plane->state->alpha >> 8);
+
+ val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_PIXEL :
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_COMBINED;
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, overlay),
+ mask, val);
+}
+
static int sun8i_ui_layer_update_coord(struct sun8i_mixer *mixer, int channel,
int overlay, struct drm_plane *plane,
unsigned int zpos)
@@ -288,6 +309,8 @@ static void sun8i_ui_layer_atomic_update(struct drm_plane
*plane,
sun8i_ui_layer_update_coord(mixer, layer->channel,
layer->overlay, plane, zpos);
+ sun8i_ui_layer_update_alpha(mixer, layer->channel,
+ layer->overlay, plane);
sun8i_ui_layer_update_formats(mixer, layer->channel,
layer->overlay, plane);
sun8i_ui_layer_update_buffer(mixer, layer->channel,
@@ -365,6 +388,12 @@ struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct
drm_device *drm,
plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
+ ret = drm_plane_create_alpha_property(&layer->plane);
+ if (ret) {
+ dev_err(drm->dev, "Couldn't add alpha property\n");
+ return ERR_PTR(ret);
+ }
+
ret = drm_plane_create_zpos_property(&layer->plane, channel,
0, plane_cnt - 1);
if (ret) {
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
index f4ab1cf6cded..e3e32ee1178d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.h
@@ -40,6 +40,11 @@
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(12, 8)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET8
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK GENMASK(31, 24)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA(x)((x) << 24)
+
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_PIXEL((0) <<
1)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_LAYER((1) <<
1)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_COMBINED ((2) << 1)
struct sun8i_mixer;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/sun4i: Reimplement plane z position setting logic
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")
Signed-off-by: Roman Stratiienko
---
v2:
- Use SUN8I_MIXER_MAX_LAYERS macro
- Use plane_cnt instead of hard-coded number
- Put initialization of channel_zpos into for loop
- Add 'Fixes' line to the commit message
- Minor clean-ups
- Comments added
---
drivers/gpu/drm/sun4i/sun8i_mixer.c| 52 +-
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 | 39 +++
4 files changed, 66 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 8b803eb903b8..d306ad5dc093 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -259,8 +259,54 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32
format)
static void sun8i_mixer_commit(struct sunxi_engine *engine)
{
- DRM_DEBUG_DRIVER("Committing changes\n");
+ struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
+ u32 base = sun8i_blender_base(mixer);
+ int i, j = 0;
+ int channel_by_zpos[SUN8I_MIXER_MAX_LAYERS];
+ u32 route = 0, pipe_ctl = 0;
+ int plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
+
+ DRM_DEBUG_DRIVER("Update blender routing\n");
+ /* Assume that values in mixer->channel_zpos[] are unique except -1 */
+
+ for (i = 0; i < plane_cnt; i++)
+ channel_by_zpos[i] = -1;
+ /* Sort by zpos */
+ for (i = 0; i < plane_cnt; i++) {
+ int zpos = mixer->channel_zpos[i];
+
+ if (zpos >= 0 && zpos < plane_cnt)
+ channel_by_zpos[zpos] = i;
+ }
+
+ /* Route enabled blending channels first */
+ for (i = 0; i < plane_cnt; 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 remaining routing fields to match disabled channel indices */
+ for (i = 0; i < SUN8I_MIXER_MAX_LAYERS && j < SUN8I_MIXER_MAX_LAYERS;
+i++) {
+ if (mixer->channel_zpos[i] < 0) {
+ route |= i << SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(j);
+ j++;
+ }
+ }
+
+ regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL(base),
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 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,
SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
}
@@ -485,10 +531,12 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
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);
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index c6cc94057faf..b193d9d1db66 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -13,6 +13,8 @@
#include "sun8i_csc.h"
#include "sunxi_engine.h"
+#define SUN8I_MIXER_MAX_LAYERS 5
+
#define SUN8I_MIXER_SIZE(w, h) (((h) - 1) << 16 | ((w) - 1))
#define SUN8I_MIXER_COORD(x, y)((y) << 16 | (x))
@@ -176,6 +178,9 @@ struct sun8i_mixer {
struct clk *bus_clk;
struct clk *mod_clk;
+
+ /* -1 means that layer is disabled */
+ int channel_zpos[SUN8I_MIXER_MAX_LAYERS];
};
static inline struct sun8i_mixer *
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index c87fd842918e..ee7c13d8710f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -24,12 +24,10 @@
#include "sun8i_ui_scaler.h"
static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer, int channel,
-
[PATCH RFC v2] drm/msm/mdp5: enable autorefresh
Since the introduction of commit 2d99ced787e3 ("drm/msm: async commit
support"), command-mode panels began throwing the following errors:
msm fd90.mdss: pp done time out, lm=0
Let's fix this by enabling the autorefresh feature that's available in
the MDP starting at version 1.0. This will cause the MDP to
automatically send a frame to the panel every time the panel invokes the
TE signal, which will trigger the PP_DONE IRQ. This requires only
sending a single START signal for command-mode panels.
This gives us a counter for command-mode panels that we can use to
implement async commit support for the MDP5 in a follow up patch.
Signed-off-by: Brian Masney
Suggested-by: Jeffrey Hugo
Fixes: 2d99ced787e3 ("drm/msm: async commit support")
---
Changes since v1:
- Send a single start command to kick off the pipeline.
The reason I marked this patch as a RFC is that the display during some
small percentage of boots will stop updating after a minute or so, and
the ping pong IRQs stop. Most of the time it works with no issues and I
haven't been able to find a way to reproduce the issue. I tried
suspending the phone by toggling /sys/power/state since I thought that
the issue could potentially be related to power management.
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 17 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c | 31 ---
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.h | 3 +--
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 05cc04f729d6..39dd144295b3 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -436,6 +436,8 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,
spin_unlock_irqrestore(&mdp5_kms->dev->event_lock, flags);
}
+ mdp5_ctl_disable(mdp5_cstate->ctl, &mdp5_cstate->pipeline);
+
mdp5_crtc->enabled = false;
}
@@ -456,6 +458,7 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
{
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
+ struct mdp5_pipeline *pipeline = &mdp5_cstate->pipeline;
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct device *dev = &mdp5_kms->pdev->dev;
@@ -493,9 +496,21 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
mdp_irq_register(&mdp5_kms->base, &mdp5_crtc->err);
- if (mdp5_cstate->cmd_mode)
+ if (mdp5_cstate->cmd_mode) {
mdp_irq_register(&mdp5_kms->base, &mdp5_crtc->pp_done);
+ /*
+* Enable autorefresh so we get regular ping/pong IRQs.
+* - Bit 31 is the enable bit
+* - Bits 0-15 represent the frame count, specifically how many
+* TE events before the MDP sends a frame.
+*/
+ mdp5_write(mdp5_kms,
+ REG_MDP5_PP_AUTOREFRESH_CONFIG(pipeline->mixer->pp),
+ BIT(31) | BIT(0));
+ crtc_flush_all(crtc);
+ }
+
mdp5_crtc->enabled = true;
}
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
index 030279d7b64b..965757d4f356 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
@@ -50,6 +50,13 @@ struct mdp5_ctl {
bool flush_pending;
struct mdp5_ctl *pair; /* Paired CTL to be flushed together */
+
+ /*
+* The command mode panels are ran with autorefresh enabled. Only a
+* single START command can be sent so keep track on a per ping pong
+* basis.
+*/
+ bool start_sent_by_pp[4];
};
struct mdp5_ctl_manager {
@@ -191,7 +198,8 @@ static bool start_signal_needed(struct mdp5_ctl *ctl,
case INTF_WB:
return true;
case INTF_DSI:
- return intf->mode == MDP5_INTF_DSI_MODE_COMMAND;
+ return intf->mode == MDP5_INTF_DSI_MODE_COMMAND &&
+ !ctl->start_sent_by_pp[pipeline->mixer->pp];
default:
return false;
}
@@ -204,13 +212,17 @@ static bool start_signal_needed(struct mdp5_ctl *ctl,
* executed in order to kick off operation and activate all layers.
* e.g.: DSI command mode, Writeback
*/
-static void send_start_signal(struct mdp5_ctl *ctl)
+static void send_start_signal(struct mdp5_ctl *ctl,
+ struct mdp5_pipeline *pipeline)
{
unsigned long flags;
spin_lock_irqsave(&ctl->hw_lock, flags);
ctl_write(ctl, REG_MDP5_CTL_START(ctl->id), 1);
spin_unlock_irqrestore(&ctl->hw_lock, flags);
+
+ if (pipeline->intf->mode == MDP5_INTF_DSI_MODE_COMMAND)
+ ctl->start_sent_by_pp[pipeline->mixer->pp] = true;
}
/**
@@ -234,7 +246,7 @@ int mdp5_ctl_set_enc
[PATCH v24 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Jitao Shi This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi Reviewed-by: Daniel Kurtz [uli: followed API changes, removed FW update feature] Signed-off-by: Ulrich Hecht Signed-off-by: Enric Balletbo i Serra Tested-by: Hsin-Yi Wang Reviewed-by: Ezequiel Garcia --- One of the reviews from Laurent was to use 'i2c_new_ancillary_device'. I didn't change this for two reasons. 1) It doesn't have a devm version, so the remove path is more simple using the devm_i2c_new_dummy_device family. 2) IIUC the ancillary function is useful when you want to retrieve the address from the firmware or DT, that's not really the case here, as we have a base address and fixed offset to the base address which I think is not configurable. Let me know if you still think that I should use the ancillary call. Changes in v24: - Fix GPIO polarity as all GPIO descriptors should be handled as active high (Laurent Pinchart) - Make static ps8640_bridge_attach (Ezequiel Garcia) - Use a define for the number of lanes (Ezequiel Garcia) Changes in v23: - Merge mute/unmute functions into one (Nicolas Boichat) - Use enum for ENABLE/DISABLE instead of bool (Ezequiel Garcia) - Rename mute/unmute to vdo_control and fix error messages (Nicolas Boichat and Enric) - Add space between address and address parameter 'address%02x' (Nicolas Boichat) - Add Tested-by Hsin-Yi - Added me as author after the refactor Changes in v22: - Remove sysfs attributes because are not really used (Enric Balletbo) - Use enum for address page offsets (Ezequiel Garcia) - Remove enable tracking (Enric Balletbo) - Use panel_bridge API (Laurent Pinchart) - Do not use kernel-doc format for non kernel-doc formatted commands (Enric Balletbo) - Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia) - Use time_is_after_jiffies idiom (Ezequiel Garcia) - Remove unused macros (Ezequiel Garcia) - Fix weird alignment in dsi->mode_flags (Laurent Pinchart) - Use drm_of_find_panel_or_bridge helper (Laurent Pinchart) - Remove mode-sel-gpios as is not used (Laurent Pinchart) - Remove error messages to get gpios as the core will already report it (Enric Balletbo) - Remove redundant message getting the regulators (Laurent Pinchart) - Rename sleep-gpios to powerdown-gpios (Laurent Pinchart) - Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent Pinchart) - Fix race with userspace accessing the sysfs attributes (Laurent Pinchart) - Remove id_table as is only used on DR platforms (Laurent Pinchart) - Convert to new i2c device probe() (Laurent Pinchart) - Use i2c_smbus_read/write helpers instead of open coding it (Laurent Pinchart) - Remove unnused global variables (Laurent Pinchart) - Remove unnused fields in ps8640 struct (Laurent Pinchart) - Remove commented-out headers (Laurent Pinchart) Changes in v21: - Use devm_i2c_new_dummy_device and fix build issue using deprecated i2c_new_dummy - Fix build issue due missing drm_bridge.h - Do not remove in ps8640_remove device managed resources Changes in v19: - fixed return value of ps8640_probe() when no panel is found Changes in v18: - followed DRM API changes - use DEVICE_ATTR_RO() - remove firmware update code - add SPDX identifier Changes in v17: - remove some unused head files. - add macros for ps8640 pages. - remove ddc_i2c client - add mipi_dsi_device_register_full - remove the manufacturer from the name and i2c_device_id Changes in v16: - Disable ps8640 DSI MCS Function. - Rename gpios name more clearly. - Tune the ps8640 power on sequence. Changes in v15: - Drop drm_connector_(un)register calls from parade ps8640. The main DRM driver mtk_drm_drv now calls drm_connector_register_all() after drm_dev_register() in the mtk_drm_bind() function. That function should iterate over all connectors and call drm_connector_register() for each of them. So, remove drm_connector_(un)register calls from parade ps8640. Changes in v14: - update copyright info. - change bridge_to_ps8640 and connector_to_ps8640 to inline function. - fix some coding style. - use sizeof as array counter. - use drm_get_edid when read edid. - add mutex when firmware updating. Changes in v13: - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 *data, u16 data_len) - fix PAGE2_SW_REST tyro. - move the buf[3] init to entrance of the function. Changes in v12: - fix hw_chip_id build warning Changes in v11: - Remove depends on I2C, add DRM depends - Reuse ps8640_write_bytes() in ps8640_write_byte() - Use timer check for polling like the routines in - Fix no drm_connector_unregister/drm_connector_cleanup when ps8640_bridge_attach fail - Check the ps8640 hardware id in ps8640_validate_firmware - Remove fw_version check - Move ps8640_validate_firmware before ps8640_enter_bl - Add ddc_i2c unregister when probe fail and ps8640_remove drivers/gpu/drm/bridge/Kconfig | 11 + drivers/gpu/drm/bridge/Makefile
[PATCH v24 0/2] drm/bridge: PS8640 MIPI-to-eDP bridge
Hi all,
This is another version of the driver. Note that the driver changed
significally and is a more simply because now is using the panel_bridge
helpers. Apart from this, I addressed the comments from Maxime, Laurent
and Ezequiel.
This bridge is required to have the embedded display working on an Acer
Chromebook R13 ("Elm"). Hopefully we are a bit more close to have this
driver merged. If more changes are required, please let me know and I
will work on it.
Note: Along these around 20 revisions of this driver I was unable to
reconstruct the full changelog history, so I'm skipping this. Sorry
about that, I promise I'll maintain the changelog for future revisions.
Thanks,
Enric
Changes in v24:
- Fix GPIO polarity as all GPIO descriptors should be handled as active high
(Laurent Pinchart)
- Make static ps8640_bridge_attach (Ezequiel Garcia)
- Use a define for the number of lanes (Ezequiel Garcia)
Changes in v23:
- Merge mute/unmute functions into one (Nicolas Boichat)
- Use enum for ENABLE/DISABLE instead of bool (Ezequiel Garcia)
- Rename mute/unmute to vdo_control and fix error messages (Nicolas Boichat and
Enric)
- Add space between address and address parameter 'address%02x' (Nicolas
Boichat)
- Add Tested-by Hsin-Yi
- Added me as author after the refactor
Changes in v22:
- Migrate to YAML format (Maxime Ripart)
- Remove mode-sel property.
- Rename sleep-gpios to powerdown-gpios.
- Remove sysfs attributes because are not really used (Enric Balletbo)
- Use enum for address page offsets (Ezequiel Garcia)
- Remove enable tracking (Enric Balletbo)
- Use panel_bridge API (Laurent Pinchart)
- Do not use kernel-doc format for non kernel-doc formatted commands (Enric
Balletbo)
- Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia)
- Use time_is_after_jiffies idiom (Ezequiel Garcia)
- Remove unused macros (Ezequiel Garcia)
- Fix weird alignment in dsi->mode_flags (Laurent Pinchart)
- Use drm_of_find_panel_or_bridge helper (Laurent Pinchart)
- Remove mode-sel-gpios as is not used (Laurent Pinchart)
- Remove error messages to get gpios as the core will already report it (Enric
Balletbo)
- Remove redundant message getting the regulators (Laurent Pinchart)
- Rename sleep-gpios to powerdown-gpios (Laurent Pinchart)
- Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent
Pinchart)
- Fix race with userspace accessing the sysfs attributes (Laurent Pinchart)
- Remove id_table as is only used on DR platforms (Laurent Pinchart)
- Convert to new i2c device probe() (Laurent Pinchart)
- Use i2c_smbus_read/write helpers instead of open coding it (Laurent Pinchart)
- Remove unnused global variables (Laurent Pinchart)
- Remove unnused fields in ps8640 struct (Laurent Pinchart)
- Remove commented-out headers (Laurent Pinchart)
Changes in v21:
- Use devm_i2c_new_dummy_device and fix build issue using deprecated
i2c_new_dummy
- Fix build issue due missing drm_bridge.h
- Do not remove in ps8640_remove device managed resources
Changes in v19:
- fixed return value of ps8640_probe() when no panel is found
Changes in v18:
- followed DRM API changes
- use DEVICE_ATTR_RO()
- remove firmware update code
- add SPDX identifier
Changes in v17:
- remove some unused head files.
- add macros for ps8640 pages.
- remove ddc_i2c client
- add mipi_dsi_device_register_full
- remove the manufacturer from the name and i2c_device_id
Changes in v16:
- Disable ps8640 DSI MCS Function.
- Rename gpios name more clearly.
- Tune the ps8640 power on sequence.
Changes in v15:
- Drop drm_connector_(un)register calls from parade ps8640.
The main DRM driver mtk_drm_drv now calls
drm_connector_register_all() after drm_dev_register() in the
mtk_drm_bind() function. That function should iterate over all
connectors and call drm_connector_register() for each of them.
So, remove drm_connector_(un)register calls from parade ps8640.
Changes in v14:
- update copyright info.
- change bridge_to_ps8640 and connector_to_ps8640 to inline function.
- fix some coding style.
- use sizeof as array counter.
- use drm_get_edid when read edid.
- add mutex when firmware updating.
Changes in v13:
- add const on data, ps8640_write_bytes(struct i2c_client *client, const u8
*data, u16 data_len)
- fix PAGE2_SW_REST tyro.
- move the buf[3] init to entrance of the function.
Changes in v12:
- fix hw_chip_id build warning
Changes in v11:
- Remove depends on I2C, add DRM depends
- Reuse ps8640_write_bytes() in ps8640_write_byte()
- Use timer check for polling like the routines in
- Fix no drm_connector_unregister/drm_connector_cleanup when
ps8640_bridge_attach fail
- Check the ps8640 hardware id in ps8640_validate_firmware
- Remove fw_version check
- Move ps8640_validate_firmware before ps8640_enter_bl
- Add ddc_i2c unregister when probe fail and ps8640_remove
Jitao Shi (2):
Documentation: bridge: Add documentation for ps8640 DT properties
drm/bridge: Add I2C based driver for ps8640
[PATCH v2 2/4] drm/sun4i: Add mode_set callback to the engine
From: Roman Stratiienko
Create callback to update engine's registers on mode change.
Signed-off-by: Roman Stratiienko
---
v2:
- Split commit in 2 parts.
- Add description to mode_set callback
- Dropped 1 line from sun4i_crtc_mode_set_nofb()
- Add struct drm_display_mode declaration (fix build warning)
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 3 +++
drivers/gpu/drm/sun4i/sunxi_engine.h | 12
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 3a153648b369..f9c627d601c3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -141,6 +141,9 @@ static void sun4i_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
sun4i_tcon_mode_set(scrtc->tcon, encoder, mode);
+
+ if (scrtc->engine->ops->mode_set)
+ scrtc->engine->ops->mode_set(scrtc->engine, mode);
}
static const struct drm_crtc_helper_funcs sun4i_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h
b/drivers/gpu/drm/sun4i/sunxi_engine.h
index 548710a936d5..44102783ee3c 100644
--- a/drivers/gpu/drm/sun4i/sunxi_engine.h
+++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
@@ -9,6 +9,7 @@
struct drm_plane;
struct drm_device;
struct drm_crtc_state;
+struct drm_display_mode;
struct sunxi_engine;
@@ -108,6 +109,17 @@ struct sunxi_engine_ops {
* This function is optional.
*/
void (*vblank_quirk)(struct sunxi_engine *engine);
+
+ /**
+* @mode_set:
+*
+* This callback is used to update engine registers that
+* responsible for display frame size other mode attributes.
+*
+* This function is optional.
+*/
+ void (*mode_set)(struct sunxi_engine *engine,
+struct drm_display_mode *mode);
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/1] drm/lima: Add optional devfreq support
Hi Robin,
On Sun, Dec 29, 2019 at 11:58 PM Robin Murphy wrote:
>
> Hi Martin,
>
> On 2019-12-27 5:37 pm, Martin Blumenstingl wrote:
> > Most platforms with a Mali-400 or Mali-450 GPU also have support for
> > changing the GPU clock frequency. Add devfreq support so the GPU clock
> > rate is updated based on the actual GPU usage when the
> > "operating-points-v2" property is present in the board.dts.
> >
> > The actual devfreq code is taken from panfrost_devfreq.c and modified so
> > it matches what the lima hardware needs:
> > - a call to dev_pm_opp_set_clkname() during initialization because there
> >are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks
> >the GPU so we need to control it using devfreq.
> > - locking when reading or writing the devfreq statistics because (unlike
> >than panfrost) we have multiple PP and GP IRQs which may finish jobs
> >concurrently.
>
> I gave this a quick try on my RK3328, and the clock scaling indeed kicks
> in nicely on the glmark2 scenes that struggle, however something appears
> to be missing in terms of regulator association, as the appropriate OPP
> voltages aren't reflected in the GPU supply (fortunately the initial
> voltage seems close enough to that of the highest OPP not to cause major
> problems, on my box at least). With panfrost on RK3399 I do see the
> supply voltage scaling accordingly, but I don't know my way around
> devfreq well enough to know what matters in the difference :/
first of all: thank you for trying this out! :-)
does your kernel include commit 221bc77914cbcc ("drm/panfrost: Use
generic code for devfreq") for your panfrost test?
if I understand the devfreq API correct then I suspect with that
commit panfrost also won't change the voltage anymore.
this is probably due to a missing call to dev_pm_opp_set_regulators()
which is supposed to attach the regulator to the devfreq instance.
I didn't notice this yet because on Amlogic SoCs the voltage is the
same for all OPPs.
I'll debug this in the next days and send an updated patch (and drop
the RFC prefix if there are no more comments).
Regards
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 7/7] drm: exynos: mixer: Add interconnect support
Hi,
On Tue, 2019-12-24 at 13:56 +0900, Inki Dae wrote:
> Hi,
>
> 19. 12. 20. 오후 8:56에 Artur Świgoń 이(가) 쓴 글:
> > From: Marek Szyprowski
> >
> > This patch adds interconnect support to exynos-mixer. The mixer works
> > the same as before when CONFIG_INTERCONNECT is 'n'.
> >
> > Co-developed-by: Artur Świgoń
> > Signed-off-by: Artur Świgoń
> > Signed-off-by: Marek Szyprowski
> > ---
> > drivers/gpu/drm/exynos/exynos_mixer.c | 71 +--
> > 1 file changed, 66 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> > b/drivers/gpu/drm/exynos/exynos_mixer.c
> > index 6cfdb95fef2f..a7e7240a055f 100644
> > --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> > @@ -13,6 +13,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -97,6 +98,7 @@ struct mixer_context {
> > struct exynos_drm_crtc *crtc;
> > struct exynos_drm_plane planes[MIXER_WIN_NR];
> > unsigned long flags;
> > + struct icc_path *soc_path;
> >
> > int irq;
> > void __iomem*mixer_regs;
> > @@ -931,6 +933,40 @@ static void mixer_disable_vblank(struct
> > exynos_drm_crtc *crtc)
> > mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
> > }
> >
> > +static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
> > +{
> > + struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
> > + struct mixer_context *ctx = crtc->ctx;
> > + unsigned long bw, bandwidth = 0;
> > + int i, j, sub;
> > +
> > + if (!ctx->soc_path)
> > + return;
> > +
> > + for (i = 0; i < MIXER_WIN_NR; i++) {
> > + struct drm_plane *plane = &ctx->planes[i].base;
> > + const struct drm_format_info *format;
> > +
> > + if (plane->state && plane->state->crtc && plane->state->fb) {
> > + format = plane->state->fb->format;
> > + bw = mode->hdisplay * mode->vdisplay *
> > + drm_mode_vrefresh(mode);
> > + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > + bw /= 2;
> > + for (j = 0; j < format->num_planes; j++) {
> > + sub = j ? (format->vsub * format->hsub) : 1;
> > + bandwidth += format->cpp[j] * bw / sub;
> > + }
> > + }
> > + }
> > +
> > + /* add 20% safety margin */
> > + bandwidth = bandwidth / 4 * 5;
> > +
> > + dev_dbg(ctx->dev, "exynos-mixer: safe bandwidth %ld Bps\n", bandwidth);
> > + icc_set_bw(ctx->soc_path, Bps_to_icc(bandwidth), 0);
> > +}
> > +
> > static void mixer_atomic_begin(struct exynos_drm_crtc *crtc)
> > {
> > struct mixer_context *ctx = crtc->ctx;
> > @@ -982,6 +1018,7 @@ static void mixer_atomic_flush(struct exynos_drm_crtc
> > *crtc)
> > if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
> > return;
> >
> > + mixer_set_memory_bandwidth(crtc);
> > mixer_enable_sync(mixer_ctx);
> > exynos_crtc_handle_event(crtc);
> > }
> > @@ -1029,6 +1066,7 @@ static void mixer_disable(struct exynos_drm_crtc
> > *crtc)
> > for (i = 0; i < MIXER_WIN_NR; i++)
> > mixer_disable_plane(crtc, &ctx->planes[i]);
> > > +mixer_set_memory_bandwidth(crtc);
>
> Your intention is to set peak and average bandwidth to 0 at disabling mixer
> device?
Yes. In general, setting the requested bandwidth to zero means "do not override
the devfreq setting" because only constraints of type DEV_PM_QOS_MIN_FREQUENCY
are used (cf. patch 05 of this series). I will make sure to reflect that in the
commit message.
Moreover, this RFC does not really make use of the peak bandwidth (yet). It is
set to zero in this patch and ignored in patch 05 (cf. exynos_bus_icc_set()).
Only the average bandwidth is translated to a minimum frequency constraint,
overriding devfreq if necessary.
A possible modification to mixer_set_memory_bandwidth() could be:
- bandwidth = bandwidth / 4 * 5;
+ peak_bandwidth = bandwidth / 4 * 5;
in mixer_set_memory_bandwidth() plus some additional logic in
exynos_bus_icc_set().
Best regards,
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/hisilicon: Add new clock/resolution configurations
Add the three new pll config for corresponding resolution 1440x900 and
1600x900, 640x480 for hibmc
Signed-off-by: Tian Tao
Signed-off-by: Gong junjie
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 3 +++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index f1ce6cb..6bf4334 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -40,6 +40,7 @@ struct hibmc_dislay_pll_config {
};
static const struct hibmc_dislay_pll_config hibmc_pll_table[] = {
+ {640, 480, CRT_PLL1_HS_25MHZ, CRT_PLL2_HS_25MHZ},
{800, 600, CRT_PLL1_HS_40MHZ, CRT_PLL2_HS_40MHZ},
{1024, 768, CRT_PLL1_HS_65MHZ, CRT_PLL2_HS_65MHZ},
{1152, 864, CRT_PLL1_HS_80MHZ_1152, CRT_PLL2_HS_80MHZ},
@@ -47,6 +48,8 @@ static const struct hibmc_dislay_pll_config hibmc_pll_table[]
= {
{1280, 720, CRT_PLL1_HS_74MHZ, CRT_PLL2_HS_74MHZ},
{1280, 960, CRT_PLL1_HS_108MHZ, CRT_PLL2_HS_108MHZ},
{1280, 1024, CRT_PLL1_HS_108MHZ, CRT_PLL2_HS_108MHZ},
+ {1440, 900, CRT_PLL1_HS_106MHZ, CRT_PLL2_HS_106MHZ},
+ {1600, 900, CRT_PLL1_HS_108MHZ, CRT_PLL2_HS_108MHZ},
{1600, 1200, CRT_PLL1_HS_162MHZ, CRT_PLL2_HS_162MHZ},
{1920, 1080, CRT_PLL1_HS_148MHZ, CRT_PLL2_HS_148MHZ},
{1920, 1200, CRT_PLL1_HS_193MHZ, CRT_PLL2_HS_193MHZ},
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
index 9b7e859..17b30c3 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
@@ -179,6 +179,7 @@
#define CRT_PLL1_HS_74MHZ 0x23941dc2
#define CRT_PLL1_HS_80MHZ 0x23941001
#define CRT_PLL1_HS_80MHZ_1152 0x23540fc2
+#define CRT_PLL1_HS_106MHZ 0x237C1641
#define CRT_PLL1_HS_108MHZ 0x23b41b01
#define CRT_PLL1_HS_162MHZ 0x23480681
#define CRT_PLL1_HS_148MHZ 0x23541dc2
@@ -191,6 +192,7 @@
#define CRT_PLL2_HS_78MHZ 0x50E147AE
#define CRT_PLL2_HS_74MHZ 0x602B6AE7
#define CRT_PLL2_HS_80MHZ 0x7000
+#define CRT_PLL2_HS_106MHZ 0x0075c28f
#define CRT_PLL2_HS_108MHZ 0x8000
#define CRT_PLL2_HS_162MHZ 0xA000
#define CRT_PLL2_HS_148MHZ 0xB0CD
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/sun4i: Update mixer's internal registers after initialization
From: Roman Stratiienko
At system start blink of u-boot ghost framebuffer can be observed.
Fix it.
Fixes: 9d75b8c0b999 ("drm/sun4i: add support for Allwinner DE2 mixers")
Signed-off-by: Roman Stratiienko
Reviewed-by: Jernej Skrabec
---
v2:
- Picked 'Reviewed-by' line
- Added 'Fixes' line
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 5d90a95ff855..86711d8a9c84 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -576,6 +576,9 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL(base),
SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 0);
+ regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_DBUFF,
+SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
+
return 0;
err_disable_bus_clk:
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon: Added three new resolutions and changed the alignment to 128 Bytes
Hi Daniel: Thanks you very much ,I will follow your suggestion to split this to three patches. Best 在 2019/12/30 18:23, Daniel Stone 写道: Hi Tian, On Sat, 28 Dec 2019 at 01:14, Tian Tao wrote: @@ -118,11 +119,9 @@ static void hibmc_plane_atomic_update(struct drm_plane *plane, writel(gpu_addr, priv->mmio + HIBMC_CRT_FB_ADDRESS); reg = state->fb->width * (state->fb->format->cpp[0]); - /* now line_pad is 16 */ - reg = PADDING(16, reg); line_l = state->fb->width * state->fb->format->cpp[0]; - line_l = PADDING(16, line_l); + line_l = PADDING(128, line_l); The 'line length' here is the 'stride' field of the FB. Stride is set by userspace when allocating the buffer, and the kernel must not attempt to guess what userspace set. You should use state->fb->strides[0] directly here, and in your atomic_check() function, make sure that the framebuffer stride is correctly aligned. Please split this into a separate change. Your commit has three changes in it, which should all be separate commits: * enforce 128-byte stride alignment (is this a hardware limit?) * get the BO from drm_fb rather than hibmc_fb (can hibmc_fb->obj just be removed now?) * add new clock/resolution configurations Cheers, Daniel . ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v24 1/2] Documentation: bridge: Add documentation for ps8640 DT properties
From: Jitao Shi
Add documentation for DT properties supported by
ps8640 DSI-eDP converter.
Signed-off-by: Jitao Shi
Acked-by: Rob Herring
Reviewed-by: Philipp Zabel
Signed-off-by: Ulrich Hecht
Signed-off-by: Enric Balletbo i Serra
---
I maintained the ack from Rob Herring and the review from Philipp
because in essence the only thing I did is migrate to YAML format and
check that no errors are reported via dtbs_check. Just let me know if
you're not agree.
Apart from this note that I removed the mode-sel property because is not
used and I renamed sleep-gpios to powerdown-gpios.
Changes in v24: None
Changes in v23: None
Changes in v22:
- Migrate to YAML format (Maxime Ripart)
- Remove mode-sel property.
- Rename sleep-gpios to powerdown-gpios.
Changes in v21: None
Changes in v19: None
Changes in v18: None
Changes in v17: None
Changes in v16: None
Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
.../bindings/display/bridge/ps8640.yaml | 112 ++
1 file changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
new file mode 100644
index ..5dff93641bea
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ps8640.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPI DSI to eDP Video Format Converter Device Tree Bindings
+
+maintainers:
+ - Nicolas Boichat
+ - Enric Balletbo i Serra
+
+description: |
+ The PS8640 is a low power MIPI-to-eDP video format converter supporting
+ mobile devices with embedded panel resolutions up to 2048 x 1536. The
+ device accepts a single channel of MIPI DSI v1.1, with up to four lanes
+ plus clock, at a transmission rate up to 1.5Gbit/sec per lane. The
+ device outputs eDP v1.4, one or two lanes, at a link rate of up to
+ 3.24Gbit/sec per lane.
+
+properties:
+ compatible:
+const: parade,ps8640
+
+ reg:
+maxItems: 1
+description: Base I2C address of the device.
+
+ powerdown-gpios:
+maxItems: 1
+description: GPIO connected to active low powerdown.
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active low reset.
+
+ vdd12-supply:
+maxItems: 1
+description: Regulator for 1.2V digital core power.
+
+ vdd33-supply:
+maxItems: 1
+description: Regulator for 3.3V digital core power.
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+ Documentation/devicetree/bindings/graph.txt
+properties:
+ port@0:
+type: object
+description: |
+ Video port for DSI input
+
+ port@1:
+type: object
+description: |
+ Video port for eDP output (panel or connector).
+
+required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - powerdown-gpios
+ - reset-gpios
+ - vdd12-supply
+ - vdd33-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ps8640: edp-bridge@18 {
+compatible = "parade,ps8640";
+reg = <0x18>;
+powerdown-gpios = <&pio 116 GPIO_ACTIVE_LOW>;
+reset-gpios = <&pio 115 GPIO_ACTIVE_LOW>;
+vdd12-supply = <&ps8640_fixed_1v2>;
+vdd33-supply = <&mt6397_vgp2_reg>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+ps8640_in: endpoint {
+remote-endpoint = <&dsi0_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+ps8640_out: endpoint {
+remote-endpoint = <&panel_in>;
+ };
+};
+};
+};
+};
+
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2] drm/msm/mdp5: enable autorefresh
Since the introduction of commit 2d99ced787e3 ("drm/msm: async commit
support"), command-mode panels began throwing the following errors:
msm fd90.mdss: pp done time out, lm=0
Let's fix this by enabling the autorefresh feature that's available in
the MDP starting at version 1.0. This will cause the MDP to
automatically send a frame to the panel every time the panel invokes the
TE signal, which will trigger the PP_DONE IRQ. This requires only
sending a single START signal for command-mode panels.
This gives us a counter for command-mode panels that we can use to
implement async commit support for the MDP5 in a follow up patch.
Signed-off-by: Brian Masney
Suggested-by: Jeffrey Hugo
Fixes: 2d99ced787e3 ("drm/msm: async commit support")
---
Changes since v1:
- Send a single start command to kick off the pipeline.
The reason I marked this patch as a RFC is that the display during some
small percentage of boots will stop updating after a minute or so, and
the ping pong IRQs stop. Most of the time it works with no issues and I
haven't been able to find a way to reproduce the issue. I tried
suspending the phone by toggling /sys/power/state since I thought that
the issue could potentially be related to power management.
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 17 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c | 31 ---
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.h | 3 +--
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 05cc04f729d6..39dd144295b3 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -436,6 +436,8 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,
spin_unlock_irqrestore(&mdp5_kms->dev->event_lock, flags);
}
+ mdp5_ctl_disable(mdp5_cstate->ctl, &mdp5_cstate->pipeline);
+
mdp5_crtc->enabled = false;
}
@@ -456,6 +458,7 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
{
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
+ struct mdp5_pipeline *pipeline = &mdp5_cstate->pipeline;
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct device *dev = &mdp5_kms->pdev->dev;
@@ -493,9 +496,21 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
mdp_irq_register(&mdp5_kms->base, &mdp5_crtc->err);
- if (mdp5_cstate->cmd_mode)
+ if (mdp5_cstate->cmd_mode) {
mdp_irq_register(&mdp5_kms->base, &mdp5_crtc->pp_done);
+ /*
+* Enable autorefresh so we get regular ping/pong IRQs.
+* - Bit 31 is the enable bit
+* - Bits 0-15 represent the frame count, specifically how many
+* TE events before the MDP sends a frame.
+*/
+ mdp5_write(mdp5_kms,
+ REG_MDP5_PP_AUTOREFRESH_CONFIG(pipeline->mixer->pp),
+ BIT(31) | BIT(0));
+ crtc_flush_all(crtc);
+ }
+
mdp5_crtc->enabled = true;
}
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
index 030279d7b64b..965757d4f356 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
@@ -50,6 +50,13 @@ struct mdp5_ctl {
bool flush_pending;
struct mdp5_ctl *pair; /* Paired CTL to be flushed together */
+
+ /*
+* The command mode panels are ran with autorefresh enabled. Only a
+* single START command can be sent so keep track on a per ping pong
+* basis.
+*/
+ bool start_sent_by_pp[4];
};
struct mdp5_ctl_manager {
@@ -191,7 +198,8 @@ static bool start_signal_needed(struct mdp5_ctl *ctl,
case INTF_WB:
return true;
case INTF_DSI:
- return intf->mode == MDP5_INTF_DSI_MODE_COMMAND;
+ return intf->mode == MDP5_INTF_DSI_MODE_COMMAND &&
+ !ctl->start_sent_by_pp[pipeline->mixer->pp];
default:
return false;
}
@@ -204,13 +212,17 @@ static bool start_signal_needed(struct mdp5_ctl *ctl,
* executed in order to kick off operation and activate all layers.
* e.g.: DSI command mode, Writeback
*/
-static void send_start_signal(struct mdp5_ctl *ctl)
+static void send_start_signal(struct mdp5_ctl *ctl,
+ struct mdp5_pipeline *pipeline)
{
unsigned long flags;
spin_lock_irqsave(&ctl->hw_lock, flags);
ctl_write(ctl, REG_MDP5_CTL_START(ctl->id), 1);
spin_unlock_irqrestore(&ctl->hw_lock, flags);
+
+ if (pipeline->intf->mode == MDP5_INTF_DSI_MODE_COMMAND)
+ ctl->start_sent_by_pp[pipeline->mixer->pp] = true;
}
/**
@@ -234,7 +246,7 @@ int mdp5_ctl_set_enc
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
On Tue, Dec 31, 2019 at 08:18:01AM +0100, Artur Świgoń wrote:
> Hi,
>
> On Mon, 2019-12-30 at 16:44 +0100, Krzysztof Kozlowski wrote:
> > On Fri, Dec 20, 2019 at 12:56:50PM +0100, Artur Świgoń wrote:
> > > This patch adds the following properties to the Exynos4412 DT:
> > > - exynos,interconnect-parent-node: to declare connections between
> > > nodes in order to guarantee PM QoS requirements between nodes;
> > > - #interconnect-cells: required by the interconnect framework.
> > >
> > > Note that #interconnect-cells is always zero and node IDs are not
> > > hardcoded anywhere.
> > >
> > > Signed-off-by: Artur Świgoń
> > > ---
> > > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
> > > 1 file changed, 5 insertions(+)
> >
> > The order of patches is confusing. Patches 4 and 6 are split - do the
> > depend on 5? I doubt but...
>
> Let me elaborate:
>
> The order of the patches in this series is such that every subsequent
> patch adds some functionality (and, of course, applying patches one-by-one
> yields a working kernel at every step). Specifically for patches 04--07:
>
> -- patch 04 adds interconnect _provider_ properties for Exynos4412;
> -- patch 05 implements interconnect provider logic (depends on patch 04);
> -- patch 06 adds interconnect _consumer_ properties for Exynos4412 mixer;
> -- patch 07 implements interconnect consumer logic (depends on patches
> 05 & 06);
>
> My reasoning is that this order allows to e.g., merge the interconnect
> provider for exynos-bus and leave the consumers for later (not limited to
> the mixer). I hope this makes sense.
It is wrong. The driver should not depend on DTS changes because:
1. DTS always go through separate branch and tree, so last patch
will have to wait up to 3 cycles (!!!),
2. You break backward compatibility.
In certain cases dependency on DTS changes is ok:
1. Cleaning up deprecated properties,
2. Ignoring the backward compatibility for e.g. new platforms.
None of these are applicable here.
You need to rework it, put DTS changes at the end. This clearly shows
that there is no wrong dependency.
>
> > Adjust the title to match the contents - you are not adding bindings but
> > properties to bus nodes. Also the prefix is ARM: (look at recent
> > commits).
>
> OK.
>
> > >
> > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > @@ -90,6 +90,7 @@
> > > &bus_dmc {
> > > exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > vdd-supply = <&buck1_reg>;
> > > + #interconnect-cells = <0>;
> >
> > This does not look like property of Odroid but Exynos4412 or Exynos4.
>
> Strangely enough, this file is where the 'exynos,parent-bus' (aka. 'devfreq')
> properties are located (and everything in this RFC concerns devfreq).
I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
you elaborate?
Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: Add missing vmalloc header
The Rockship DRM GEM code uses vmap()/vunmap() so vmalloc header must be included to avoid warnings like (on IA64, compile tested): drivers/gpu/drm/rockchip/rockchip_drm_gem.c: In function ‘rockchip_gem_alloc_iommu’: drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:20: error: implicit declaration of function ‘vmap’ [-Werror=implicit-function-declaration] Reported-by: kbuild test robot Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c index 7582d0e6a60a..0d1884684dcb 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c @@ -6,6 +6,7 @@ #include #include +#include #include #include -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
