[PATCH] drm/lima: use drm_sched_fault for error task handling
drm_sched_job_timedout works with drm_sched_stop as a pair,
so we'd better use the drm_sched_fault helper to make the
error and timeout handling go the same path.
This also fixes application hang when task error.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_sched.c | 35 ---
drivers/gpu/drm/lima/lima_sched.h | 2 --
2 files changed, 9 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index f522c5f99729..a31a90c380b6 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -255,13 +255,17 @@ static struct dma_fence *lima_sched_run_job(struct
drm_sched_job *job)
return task->fence;
}
-static void lima_sched_handle_error_task(struct lima_sched_pipe *pipe,
-struct lima_sched_task *task)
+static void lima_sched_timedout_job(struct drm_sched_job *job)
{
+ struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
+ struct lima_sched_task *task = to_lima_task(job);
+
+ if (!pipe->error)
+ DRM_ERROR("lima job timeout\n");
+
drm_sched_stop(&pipe->base, &task->base);
- if (task)
- drm_sched_increase_karma(&task->base);
+ drm_sched_increase_karma(&task->base);
pipe->task_error(pipe);
@@ -284,16 +288,6 @@ static void lima_sched_handle_error_task(struct
lima_sched_pipe *pipe,
drm_sched_start(&pipe->base, true);
}
-static void lima_sched_timedout_job(struct drm_sched_job *job)
-{
- struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
- struct lima_sched_task *task = to_lima_task(job);
-
- DRM_ERROR("lima job timeout\n");
-
- lima_sched_handle_error_task(pipe, task);
-}
-
static void lima_sched_free_job(struct drm_sched_job *job)
{
struct lima_sched_task *task = to_lima_task(job);
@@ -318,15 +312,6 @@ static const struct drm_sched_backend_ops lima_sched_ops =
{
.free_job = lima_sched_free_job,
};
-static void lima_sched_error_work(struct work_struct *work)
-{
- struct lima_sched_pipe *pipe =
- container_of(work, struct lima_sched_pipe, error_work);
- struct lima_sched_task *task = pipe->current_task;
-
- lima_sched_handle_error_task(pipe, task);
-}
-
int lima_sched_pipe_init(struct lima_sched_pipe *pipe, const char *name)
{
unsigned int timeout = lima_sched_timeout_ms > 0 ?
@@ -335,8 +320,6 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
const char *name)
pipe->fence_context = dma_fence_context_alloc(1);
spin_lock_init(&pipe->fence_lock);
- INIT_WORK(&pipe->error_work, lima_sched_error_work);
-
return drm_sched_init(&pipe->base, &lima_sched_ops, 1, 0,
msecs_to_jiffies(timeout), name);
}
@@ -349,7 +332,7 @@ void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
void lima_sched_pipe_task_done(struct lima_sched_pipe *pipe)
{
if (pipe->error)
- schedule_work(&pipe->error_work);
+ drm_sched_fault(&pipe->base);
else {
struct lima_sched_task *task = pipe->current_task;
diff --git a/drivers/gpu/drm/lima/lima_sched.h
b/drivers/gpu/drm/lima/lima_sched.h
index 928af91c1118..1d814fecbcc0 100644
--- a/drivers/gpu/drm/lima/lima_sched.h
+++ b/drivers/gpu/drm/lima/lima_sched.h
@@ -68,8 +68,6 @@ struct lima_sched_pipe {
void (*task_fini)(struct lima_sched_pipe *pipe);
void (*task_error)(struct lima_sched_pipe *pipe);
void (*task_mmu_error)(struct lima_sched_pipe *pipe);
-
- struct work_struct error_work;
};
int lima_sched_task_init(struct lima_sched_task *task,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: declare constants as unsigned long.
On Tue, Dec 31, 2019 at 06:53:55PM -0500, Ilia Mirkin wrote:
> Probably want ULL for 32-bit arches to be correct here too.
>
Okay, I can convert them to ULL and send a v2.
Thanks,
wambui.
> 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
> >
__
[PATCH 00/16] constify copied structure
Make const static structures that are just copied into other structures.
The semantic patch that detects the opportunity for this change is as
follows: (http://coccinelle.lip6.fr/)
@r disable optional_qualifier@
identifier i,j;
position p;
@@
static struct i j@p = { ... };
@upd@
position p1;
identifier r.j;
expression e;
@@
e = j@p1
@ref@
position p2 != {r.p,upd.p1};
identifier r.j;
@@
j@p2
@script:ocaml depends on upd && !ref@
i << r.i;
j << r.j;
p << r.p;
@@
if j = (List.hd p).current_element
then Coccilib.print_main i p
---
arch/powerpc/sysdev/mpic.c |4 ++--
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c |2 +-
drivers/media/i2c/mt9v111.c |2 +-
drivers/media/platform/davinci/isif.c |2 +-
drivers/media/usb/cx231xx/cx231xx-dvb.c |2 +-
drivers/media/usb/dvb-usb-v2/anysee.c |4 ++--
drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c |2 +-
drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c|2 +-
drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c |2 +-
drivers/ptp/ptp_clockmatrix.c |2 +-
drivers/usb/gadget/udc/atmel_usba_udc.c |2 +-
drivers/video/fbdev/sa1100fb.c |2 +-
net/sunrpc/xdr.c|2 +-
sound/isa/ad1816a/ad1816a_lib.c |2 +-
sound/pci/hda/hda_controller.c |2 +-
sound/soc/qcom/qdsp6/q6asm-dai.c|2 +-
16 files changed, 18 insertions(+), 18 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/16] drm: bridge: dw-hdmi: constify copied structure
The dw_hdmi_hw structure is only copied into another structure,
so make it const.
The opportunity for this change was found using Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index 2b7539701b42..dd56996fe9c7 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -291,7 +291,7 @@ static irqreturn_t snd_dw_hdmi_irq(int irq, void *data)
return IRQ_HANDLED;
}
-static struct snd_pcm_hardware dw_hdmi_hw = {
+static const struct snd_pcm_hardware dw_hdmi_hw = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2] drm/msm/mdp5: enable autorefresh
On Sun, Dec 29, 2019 at 09:00:53PM -0500, Brian Masney wrote:
> 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.
After working to get the IOMMU up on msm8974, I suspect that the issue
that I describe above is caused by a device probe deferral, which
explains the intermittent nature of what I'm seeing. First driver load
sets up the autorefresh registers, sends a single START signal, then a
-EPROBE_DEFER is thrown later on. Second driver load lost the state, and
sends a second START signal and overloads the DSI.
If that's the case, then potentially the solution may be to do
both of the following:
1) Disable autorefresh when the driver is unloaded.
2) Before sending the START signal, check to make sure that autorefresh
is actually disabled.
I likely won't be able to work on any this until Sunday evening.
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/16] video: sa1100fb: constify copied structure
The monspecs structure is only copied into another structure,
so make it const.
The opportunity for this change was found using Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/video/fbdev/sa1100fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
index 4680cc3efb81..c77b43dbc256 100644
--- a/drivers/video/fbdev/sa1100fb.c
+++ b/drivers/video/fbdev/sa1100fb.c
@@ -1053,7 +1053,7 @@ static int sa1100fb_map_video_memory(struct sa1100fb_info
*fbi)
}
/* Fake monspecs to fill in fbinfo structure */
-static struct fb_monspecs monspecs = {
+static const struct fb_monspecs monspecs = {
.hfmin = 3,
.hfmax = 7,
.vfmin = 50,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] dt-bindings: display: Update few panel bindings with YAML
These panel bindings are owned by me, so updated all of them into YAML DT schema. Any inputs? Jagan. Jagan Teki (6): dt-bindings: display: panel: Convert feiyang,fy07024di26a30d to DT schema dt-bindings: display: panel: Convert sitronix,st7701 to DT schema MAINTAINERS: Update feiyang, st7701 panel bindings converted as YAML dt-bindings: display: panel: Convert friendlyarm,hd702e to DT schema dt-bindings: display: panel: Convert rocktech,rk070er9427 to DT schema dt-bindings: display: panel: Convert koe,tx31d200vm0baa to DT schema .../display/panel/feiyang,fy07024di26a30d.txt | 20 -- .../panel/feiyang,fy07024di26a30d.yaml| 50 +++ .../display/panel/friendlyarm,hd702e.txt | 32 -- .../display/panel/friendlyarm,hd702e.yaml | 47 ++ .../display/panel/koe,tx31d200vm0baa.txt | 25 .../display/panel/koe,tx31d200vm0baa.yaml | 37 +++ .../display/panel/rocktech,rk070er9427.txt| 25 .../display/panel/rocktech,rk070er9427.yaml | 37 +++ .../display/panel/sitronix,st7701.txt | 30 - .../display/panel/sitronix,st7701.yaml| 61 +++ MAINTAINERS | 4 +- 11 files changed, 234 insertions(+), 134 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt create mode 100644 Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt create mode 100644 Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt create mode 100644 Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt create mode 100644 Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] MAINTAINERS: Update feiyang, st7701 panel bindings converted as YAML
The feiyang,fy07024di26a30d.txt and sitronix,st7701.txt has been converted to YAML schemas, update MAINTAINERS to match them again. Signed-off-by: Jagan Teki --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8b2e6c68832d..4d6e4febd170 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5169,7 +5169,7 @@ DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS M: Jagan Teki S: Maintained F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c -F: Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt +F: Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS M: Hans de Goede @@ -5298,7 +5298,7 @@ DRM DRIVER FOR SITRONIX ST7701 PANELS M: Jagan Teki S: Maintained F: drivers/gpu/drm/panel/panel-sitronix-st7701.c -F: Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt +F: Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml DRM DRIVER FOR SITRONIX ST7586 PANELS M: David Lechner -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] dt-bindings: display: panel: Convert feiyang, fy07024di26a30d to DT schema
Convert the feiyang,fy07024di26a30d panel bindings to DT schema.
Signed-off-by: Jagan Teki
---
.../display/panel/feiyang,fy07024di26a30d.txt | 20
.../panel/feiyang,fy07024di26a30d.yaml| 50 +++
2 files changed, 50 insertions(+), 20 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
deleted file mode 100644
index 82caa7b65ae8..
---
a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel
-
-Required properties:
-- compatible: must be "feiyang,fy07024di26a30d"
-- reg: DSI virtual channel used by that screen
-- avdd-supply: analog regulator dc1 switch
-- dvdd-supply: 3v3 digital regulator
-- reset-gpios: a GPIO phandle for the reset pin
-
-Optional properties:
-- backlight: phandle for the backlight control.
-
-panel@0 {
- compatible = "feiyang,fy07024di26a30d";
- reg = <0>;
- avdd-supply = <®_dc1sw>;
- dvdd-supply = <®_dldo2>;
- reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
- backlight = <&backlight>;
-};
diff --git
a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
new file mode 100644
index ..16e2fedda49e
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/feiyang,fy07024di26a30d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel
+
+maintainers:
+ - Jagan Teki
+
+properties:
+ compatible:
+const: feiyang,fy07024di26a30d
+
+ reg:
+description: DSI virtual channel used by that screen
+
+ avdd-supply:
+description: analog regulator dc1 switch
+
+ dvdd-supply:
+description: 3v3 digital regulator
+
+ reset-gpios:
+description: a GPIO phandle for the reset pin
+
+ backlight:
+description: Backlight used by the panel
+$ref: "/schemas/types.yaml#/definitions/phandle"
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+panel@0 {
+compatible = "feiyang,fy07024di26a30d";
+reg = <0>;
+avdd-supply = <®_dc1sw>;
+dvdd-supply = <®_dldo2>;
+reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+backlight = <&backlight>;
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] dt-bindings: display: panel: Convert sitronix, st7701 to DT schema
Convert the sitronix,st7701 panel bindings to DT schema.
Signed-off-by: Jagan Teki
---
.../display/panel/sitronix,st7701.txt | 30 -
.../display/panel/sitronix,st7701.yaml| 61 +++
2 files changed, 61 insertions(+), 30 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
deleted file mode 100644
index ccd17597f1f6..
--- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Sitronix ST7701 based LCD panels
-
-ST7701 designed for small and medium sizes of TFT LCD display, is
-capable of supporting up to 480RGBX864 in resolution. It provides
-several system interfaces like MIPI/RGB/SPI.
-
-Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has
-inbuilt ST7701 chip.
-
-Required properties:
-- compatible: must be "sitronix,st7701" and one of
- * "techstar,ts8550b"
-- reset-gpios: a GPIO phandle for the reset pin
-
-Required properties for techstar,ts8550b:
-- reg: DSI virtual channel used by that screen
-- VCC-supply: analog regulator for MIPI circuit
-- IOVCC-supply: I/O system regulator
-
-Optional properties:
-- backlight: phandle for the backlight control.
-
-panel@0 {
- compatible = "techstar,ts8550b", "sitronix,st7701";
- reg = <0>;
- VCC-supply = <®_dldo2>;
- IOVCC-supply = <®_dldo2>;
- reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
- backlight = <&backlight>;
-};
diff --git
a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
new file mode 100644
index ..49e4b54ecf7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sitronix,st7701.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sitronix ST7701 based LCD panels
+
+maintainers:
+ - Jagan Teki
+
+description: |
+ ST7701 designed for small and medium sizes of TFT LCD display, is
+ capable of supporting up to 480RGBX864 in resolution. It provides
+ several system interfaces like MIPI/RGB/SPI.
+
+ Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has
+ inbuilt ST7701 chip.
+
+properties:
+ compatible:
+oneOf:
+ - const: sitronix,st7701
+ - items:
+ - const: techstar,ts8550b
+
+ reg:
+description: DSI virtual channel used by that screen
+
+ VCC-supply:
+description: analog regulator for MIPI circuit
+
+ IOVCC-supply:
+description: I/O system regulator
+
+ reset-gpios:
+description: a GPIO phandle for the reset pin
+
+ backlight:
+description: Backlight used by the panel
+$ref: "/schemas/types.yaml#/definitions/phandle"
+
+required:
+ - compatible
+ - reg
+ - VCC-supply
+ - IOVCC-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+panel@0 {
+compatible = "techstar,ts8550b", "sitronix,st7701";
+reg = <0>;
+VCC-supply = <®_dldo2>;
+IOVCC-supply = <®_dldo2>;
+reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+backlight = <&backlight>;
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] dt-bindings: display: panel: Convert friendlyarm, hd702e to DT schema
Convert the friendlyarm,hd702e panel bindings to DT schema.
Signed-off-by: Jagan Teki
---
.../display/panel/friendlyarm,hd702e.txt | 32 -
.../display/panel/friendlyarm,hd702e.yaml | 47 +++
2 files changed, 47 insertions(+), 32 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
deleted file mode 100644
index 6c9156fc3478..
--- a/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-FriendlyELEC HD702E 800x1280 LCD panel
-
-HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
-resolution. It has built in Goodix, GT9271 captive touchscreen
-with backlight adjustable via PWM.
-
-Required properties:
-- compatible: should be "friendlyarm,hd702e"
-- power-supply: regulator to provide the supply voltage
-
-Optional properties:
-- backlight: phandle of the backlight device attached to the panel
-
-Optional nodes:
-- Video port for LCD panel input.
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
-
-Example:
-
- panel {
- compatible ="friendlyarm,hd702e", "simple-panel";
- backlight = <&backlight>;
- power-supply = <&vcc3v3_sys>;
-
- port {
- panel_in_edp: endpoint {
- remote-endpoint = <&edp_out_panel>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.yaml
b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.yaml
new file mode 100644
index ..0509c34d98b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/friendlyarm,hd702e.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FriendlyELEC HD702E 800x1280 LCD panel
+
+maintainers:
+ - Jagan Teki
+ - Thierry Reding
+ - Sam Ravnborg
+
+description: |
+ HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
+ resolution. It has built in Goodix, GT9271 captive touchscreen
+ with backlight adjustable via PWM.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: friendlyarm,hd702e
+
+ power-supply:
+description: regulator to provide the supply voltage
+
+required:
+ - compatible
+ - power-supply
+
+additionalProperties: false
+
+examples:
+ - |
+panel {
+compatible ="friendlyarm,hd702e", "simple-panel";
+backlight = <&backlight>;
+power-supply = <&vcc3v3_sys>;
+
+port {
+panel_in_edp: endpoint {
+remote-endpoint = <&edp_out_panel>;
+};
+};
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] dt-bindings: display: panel: Convert koe, tx31d200vm0baa to DT schema
Convert the koe,tx31d200vm0baa panel bindings to DT schema.
Also, drop the description from legacy .txt since the yaml DT schema
of panel-common.yaml already have that information.
Signed-off-by: Jagan Teki
---
.../display/panel/koe,tx31d200vm0baa.txt | 25 -
.../display/panel/koe,tx31d200vm0baa.yaml | 37 +++
2 files changed, 37 insertions(+), 25 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
deleted file mode 100644
index 6a036ede3e28..
--- a/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
-
-Required properties:
-- compatible: should be "koe,tx31d200vm0baa"
-
-Optional properties:
-- backlight: phandle of the backlight device attached to the panel
-
-Optional nodes:
-- Video port for LVDS panel input.
-
-Example:
- panel {
- compatible = "koe,tx31d200vm0baa";
- backlight = <&backlight_lvds>;
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&lvds0_out>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.yaml
b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.yaml
new file mode 100644
index ..4b64e8ad8ec5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/koe,tx31d200vm0baa.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
+
+maintainers:
+ - Jagan Teki
+ - Thierry Reding
+ - Sam Ravnborg
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: koe,tx31d200vm0baa
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+panel {
+compatible = "koe,tx31d200vm0baa";
+backlight = <&backlight_lcd>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <&lvds0_out>;
+};
+};
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] dt-bindings: display: panel: Convert rocktech, rk070er9427 to DT schema
Convert the rocktech,rk070er9427 panel bindings to DT schema.
Also, drop the description from legacy .txt since the yaml DT schema
of panel-common.yaml already have that information.
Signed-off-by: Jagan Teki
---
.../display/panel/rocktech,rk070er9427.txt| 25 -
.../display/panel/rocktech,rk070er9427.yaml | 37 +++
2 files changed, 37 insertions(+), 25 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
b/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
deleted file mode 100644
index eb1fb9f8d1f4..
--- a/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
-
-Required properties:
-- compatible: should be "rocktech,rk070er9427"
-
-Optional properties:
-- backlight: phandle of the backlight device attached to the panel
-
-Optional nodes:
-- Video port for LCD panel input.
-
-Example:
- panel {
- compatible = "rocktech,rk070er9427";
- backlight = <&backlight_lcd>;
-
- port {
- lcd_panel_in: endpoint {
- remote-endpoint = <&lcd_display_out>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.yaml
b/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.yaml
new file mode 100644
index ..ac5aebfa4adc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/rocktech,rk070er9427.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/rocktech,rk070er9427.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
+
+maintainers:
+ - Jagan Teki
+ - Thierry Reding
+ - Sam Ravnborg
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: rocktech,rk070er9427
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+panel {
+compatible = "rocktech,rk070er9427";
+backlight = <&backlight_lcd>;
+
+port {
+lcd_panel_in: endpoint {
+remote-endpoint = <&lcd_display_out>;
+};
+};
+};
--
2.18.0.321.gffc6fa0e3
___
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
On 2019-12-31 4:47 pm, Martin Blumenstingl wrote:
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?
Indeed it does call regulator_get_optional(), but it then goes on to
treat the absence of a supposedly-optional regulator as a hard failure.
It doesn't seem very useful having a nice abstracted interface if users
still end up have to dance around and duplicate half the parsing in
order to work out whether it's worth calling or not - far better IMO if
it could just successfully set/put zero regulators in the cases where
the OPPs are behind a firmware/mailbox DVFS interface rather than
explicit in-kernel clock/regulator control.
That said, given that I think the current lima/panfrost users should all
be relatively simple with either 0 or 1 regulator, you could probably
just special-case -ENODEV and accept a spurious error message sometimes
for the sake of an immediate fix, then we can make general improvements
to the interface separately afterwards.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] pinctrl: Allow modules to use pinctrl_[un]register_mappings
Hi, On 30-12-2019 14:31, Linus Walleij wrote: On Mon, Dec 16, 2019 at 9:51 PM Hans de Goede wrote: Currently only the drivers/pinctrl/devicetree.c code allows registering pinctrl-mappings which may later be unregistered, all other mappings are assumed to be permanent. Non-dt platforms may also want to register pinctrl mappings from code which is build as a module, which requires being able to unregister the mapping when the module is unloaded to avoid dangling pointers. To allow unregistering the mappings the devicetree code uses 2 internal functions: pinctrl_register_map and pinctrl_unregister_map. pinctrl_register_map allows the devicetree code to tell the core to not memdup the mappings as it retains ownership of them and pinctrl_unregister_map does the unregistering, note this only works when the mappings where not memdupped. The only code relying on the memdup/shallow-copy done by pinctrl_register_mappings is arch/arm/mach-u300/core.c this commit replaces the __initdata with const, so that the shallow-copy is no longer necessary. After that we can get rid of the internal pinctrl_unregister_map function and just use pinctrl_register_mappings directly everywhere. This commit also renames pinctrl_unregister_map to pinctrl_unregister_mappings so that its naming matches its pinctrl_register_mappings counter-part and exports it. Together these 2 changes will allow non-dt platform code to register pinctrl-mappings from modules without breaking things on module unload (as they can now unregister the mapping on unload). Signed-off-by: Hans de Goede This v2 works fine for me, I applied it to this immutable branch in the pinctrl tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-pinctrl-unreg-mappings And pulled that into the pinctrl "devel" branch for v5.6. Please pull this immutable branch into the Intel DRM tree and apply the rest of the stuff on top! Great, thank you! Regards, Hans p.s. Happy New year everyone. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206017] Kernel 5.4.x unusable with GUI due to [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
https://bugzilla.kernel.org/show_bug.cgi?id=206017 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- There is no need to file another bug report. Let's keep this all in one place. -- 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
[Bug 206017] Kernel 5.4.x unusable with GUI due to [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
https://bugzilla.kernel.org/show_bug.cgi?id=206017 --- Comment #3 from udo (udo...@xs4all.nl) --- amdgpu.noretry=0 appears to help on 5.4.6. -- 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 15/16] drm: bridge: dw-hdmi: constify copied structure
Hi Julia,
Thank you for the patch.
On Wed, Jan 01, 2020 at 08:43:33AM +0100, Julia Lawall wrote:
> The dw_hdmi_hw structure is only copied into another structure,
> so make it const.
>
> The opportunity for this change was found using Coccinelle.
>
> Signed-off-by: Julia Lawall
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> index 2b7539701b42..dd56996fe9c7 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> @@ -291,7 +291,7 @@ static irqreturn_t snd_dw_hdmi_irq(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static struct snd_pcm_hardware dw_hdmi_hw = {
> +static const struct snd_pcm_hardware dw_hdmi_hw = {
> .info = SNDRV_PCM_INFO_INTERLEAVED |
> SNDRV_PCM_INFO_BLOCK_TRANSFER |
> SNDRV_PCM_INFO_MMAP |
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.5
Hi Dave, Daniel, Happy New Year! Fixes for 5.5. The following changes since commit e31d941c7dd797df37ea94958638a88723325c30: Merge tag 'drm-intel-fixes-2019-12-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-12-27 13:13:30 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.5-2020-01-01 for you to fetch changes up to 969e11529221a6a2a787cb3b63ccf9402f8d2e37: drm/amdgpu: correct RLC firmwares loading sequence (2020-01-01 09:26:09 -0500) amd-drm-fixes-5.5-2020-01-01: amdgpu: - ATPX regression fix - SMU metrics table locking fixes - gfxoff fix for raven - RLC firmware loading stability fix Alex Deucher (5): Revert "drm/amdgpu: simplify ATPX detection" drm/amdgpu/smu: add metrics table lock drm/amdgpu/smu: add metrics table lock for arcturus (v2) drm/amdgpu/smu: add metrics table lock for navi (v2) drm/amdgpu/smu: add metrics table lock for vega20 (v2) Evan Quan (1): drm/amdgpu: correct RLC firmwares loading sequence changzhu (1): drm/amdgpu: enable gfxoff for raven1 refresh drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 12 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h| 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 15 --- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 1 + drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 3 +++ drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 + drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 3 +++ drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 3 +++ 9 files changed, 28 insertions(+), 14 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH resend 0/2] drm/connector: Add support for specifying panel_orientation on the kernel cmdline
Hi all, Ping? it would be really nice if we can get these last 2 patches from my series for specifying panel_orientation on the kernel cmdline upstream. If someone can review the first patch (the second one has already been reviewed) then that would be great. Thanks & Regards, Hans On 16-12-2019 12:51, Hans de Goede wrote: Hi All, This is a resend of the last 2 remaining patches of my series for adding support for specifying panel_orientation on the kernel cmdline. I've already pushed the other 11 patches which were mostly cleanups / bug-fixes to the cmdline-parsing code and where all acked by Maxime to drm-misc-next. The first patch of these 2 still needs to be reviewed, if someone can review it that would be great. Once this is reviewed the question becomes how to merge this, both patches are mostly drm-misc material and the second patch depends on the changes I just pushed to drm-misc-next, so this series should probably be pushed to drm-misc-next, but it also makes some changes to i915 code. I've checked and there is no conflict with these patches as they apply to drm-misc-next vs drm-intel-next-queued (atm). So it should be fine to push these 2 patches to drm-misc-next and then do a back-merge to drm-intel-next-queued. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 04/11] drm/bridge: Make the bridge chain a double-linked list
Hi Boris, On Fri, Dec 27, 2019 at 01:21:31PM +0100, Boris Brezillon wrote: > On Fri, 27 Dec 2019 12:51:54 +0200 Laurent Pinchart wrote: > > On Fri, Dec 27, 2019 at 10:42:25AM +0100, Andrzej Hajda wrote: > > > On 24.12.2019 10:44, Boris Brezillon wrote: > > > > On Tue, 24 Dec 2019 10:16:49 +0100 Andrzej Hajda wrote: > > > >> On 23.12.2019 10:55, Marek Szyprowski wrote: > > > >>> On 16.12.2019 16:25, Boris Brezillon wrote: > > > On Mon, 16 Dec 2019 16:02:36 +0100 Marek Szyprowski wrote: > > > > On 16.12.2019 15:55, Boris Brezillon wrote: > > > >> On Mon, 16 Dec 2019 14:54:25 +0100 > > > >> Marek Szyprowski wrote: > > > >>> On 03.12.2019 15:15, Boris Brezillon wrote: > > > So that each element in the chain can easily access its > > > predecessor. > > > This will be needed to support bus format negotiation between > > > elements > > > of the bridge chain. > > > > > > Signed-off-by: Boris Brezillon > > > Reviewed-by: Neil Armstrong > > > Reviewed-by: Laurent Pinchart > > > > > > >>> > > > >>> I've noticed that this patch got merged to linux-next as commit > > > >>> 05193dc38197021894b17239fafbd2eb1afe5a45. Sadly it breaks booting > > > >>> of > > > >>> Samsung Exynos5250-based Arndale board. Booting stops after > > > >>> following > > > >>> messages: > > > >>> > > > >>> [drm] Exynos DRM: using 1440.fimd device for DMA mapping > > > >>> operations > > > >>> exynos-drm exynos-drm: bound 1440.fimd (ops > > > >>> fimd_component_ops) > > > >>> exynos-drm exynos-drm: bound 1445.mixer (ops > > > >>> mixer_component_ops) > > > >>> exynos-drm exynos-drm: bound 1450.dsi (ops > > > >>> exynos_dsi_component_ops) > > > >>> exynos-drm exynos-drm: bound 1453.hdmi (ops > > > >>> hdmi_component_ops) > > > >>> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > >>> [drm] No driver support for vblank timestamp query. > > > >>> [drm] Cannot find any crtc or sizes > > > >>> [drm] Cannot find any crtc or sizes > > > >>> [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0 > > > >>> > > > >>> I will try to debug this and provide more information soon. > > > >> > > > >> Can you try with this diff applied? > > > > > > > > This patch doesn't change anything. > > > > > > Okay. Can you do a list_for_each_entry() on both > > > encoder->bridge_chain > > > and dsi->bridge_chain (dump bridge pointers in a pr_info()) before > > > and > > > after the list_splice_init() call? > > > >>> > > > >>> encoder->bridge_chain contains only one element. dsi->drive_chain is > > > >>> empty. > > > >>> > > > >>> Replacing that list_splice() with > > > >>> INIT_LIST_HEAD(&encoder->bridge_chain) > > > >>> fixed the boot issue. > > > > > > > > If INIT_LIST_HEAD() worked, I don't understand why replacing the > > > > list_splice() call by a list_splice_init() (which doing a list_splice() > > > > + INIT_LIST_HEAD()) didn't fix the problem. Are you sure the > > > > list_splice_init() version doesn't work? > > > > > > > >>> It looks that this is related with the way the > > > >>> Exynos DSI handles bridges (in bridge and out brige?). Maybe Andrzej > > > >>> will give a bit more detailed comment and spread some light on this. > > > >>> > > > >> > > > >> Hi Marek, Boris, > > > >> > > > >> I have not followed latest patches due to high work load, my bad. Marek > > > >> thanks from pointing > > > >> > > > >> About ExynosDSI bridge handling: > > > >> > > > >> The order of calling encoder, bridge (and consequently panel) ops > > > >> enforced by DRM core (bridge->pre_enable, encoder->enable, > > > >> bridge->enable) does not fit to ExynosDSI hardware initialization > > > >> sequence, if I remember correctly it does not fit to whole MIPI DSI > > > >> standard (I think similar situation is with eDP). As a result DSI > > > >> drivers must use some ugly workarounds, rely on HW properly coping with > > > >> incorrect sequences, or, as in case of ExynosDSI driver, just avoid > > > >> using encoder->bridge chaining and call bridge ops by itself when > > > >> suitable. > > > > > > > > Yes, that's definitely hack-ish, and I proposed 2 solutions to address > > > > that in previous versions of this patchset, unfortunately I didn't get > > > > any feedback so I went for the less invasive option (keep the hack but > > > > adapt it to the double-linked list changes), which still lead to > > > > regressions :-/. > > > > > > > > Just a reminder of my 2 proposals: > > > > > > > > 1/ implement the bridge_ops->pre_enable/post_disable() hooks so you can > > > >split your enable/disable logic in 2 parts and make sure things are > > > >ready when the panel/next bridge tries to send DSI commands > > > > > > I
[Bug 201139] amdgpu: [drm] enabling link 1 failed: 15 (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201139 Nick Price (n...@spun.io) changed: What|Removed |Added CC||n...@spun.io --- Comment #8 from Nick Price (n...@spun.io) --- Seeing the same behavior on 5.3.0 fairly regularly - is there any other info I could provide to help? -- 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] drm/nouveau: remove set but unused variable.
On Tue, Dec 31, 2019 at 11:56:07PM +0300, Wambui Karuga wrote:
> 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;
Hm, reading the code (just from how stuff is named) I wonder whether the
original idea was that the calculation for us_p should us pclks, not
nvclks, but given that this code is as old as the initial nouveau merge
probably not a good idea to touch it. Plus I guess not many with a vintage
nv04 in working condition around to even test stuff ...
Ben, what should we do here?
-Daniel
> 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
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: use NULL for pointer assignment.
On Tue, Dec 31, 2019 at 11:57:34PM +0300, Wambui Karuga wrote: > 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 Reviewed-by: Daniel Vetter I'll check with Ben next week or so whether he wants to pick these up or whether I should stuff them into drm-misc-next. -Daniel > --- > 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 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: declare variable as __be16
On Mon, Dec 30, 2019 at 10:56:09PM +0300, Wambui Karuga wrote:
> 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
Applied to drm-misc-next, thanks for your patch!
-Daniel
> ---
> 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
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206053] New: Lock screen Black after idle with amdgpu.dc=1
https://bugzilla.kernel.org/show_bug.cgi?id=206053 Bug ID: 206053 Summary: Lock screen Black after idle with amdgpu.dc=1 Product: Drivers Version: 2.5 Kernel Version: 4.19+ Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: eutychio...@gmail.com Regression: No Created attachment 286565 --> https://bugzilla.kernel.org/attachment.cgi?id=286565&action=edit mydmesg I am having a system with rx 550 polaris using amdgpu kernel driver and Mesa 19.3+. when the screen gets idle locked with lightlocker,xscreensaver,xfce4-screensaver the screen cannot get signal back and i get a black screen. The screen lockers work because if i enter my passwd and press enter i can login in the desktop. Additional info: If i lock/blank the screen manually and move them mouse the screen gets the signal back like it should.Issue happens across Debian and Arch distributions.Monitor is connected with an hdmi 2.0 cable. Workaround: Adding amdgpu.dc=0 in grub resolves the issue for all screen lockers in my system, but disables amd display code. -- 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 v6, 02/14] drm/mediatek: move dsi/dpi select input into mtk_ddp_sel_in
Hi, Yongqiang:
On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> move dsi/dpi select input into mtk_ddp_sel_in
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 39700b9..91c9b19 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -376,6 +376,12 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id
> cur,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> *addr = DISP_REG_CONFIG_DSI_SEL;
> value = DSI_SEL_IN_BLS;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> + *addr = DISP_REG_CONFIG_DSI_SEL;
> + value = DSI_SEL_IN_RDMA;
In original code, this is set when cur == DDP_COMPONENT_BLS and next ==
DDP_COMPONENT_DPI0. Why do you change the condition?
Regards,
CK
> + } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DPI_SEL;
> + value = DPI_SEL_IN_BLS;
> } else {
> value = 0;
> }
> @@ -393,10 +399,6 @@ static void mtk_ddp_sout_sel(struct regmap *config_regs,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
> BLS_TO_DPI_RDMA1_TO_DSI);
> - regmap_write(config_regs, DISP_REG_CONFIG_DSI_SEL,
> - DSI_SEL_IN_RDMA);
> - regmap_write(config_regs, DISP_REG_CONFIG_DPI_SEL,
> - DPI_SEL_IN_BLS);
> }
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6, 13/14] drm/mediatek: add fifo_size into rdma private data
Hi, Yongqiang:
On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> the fifo size of rdma in mt8183 is different.
> rdma0 fifo size is 5k
> rdma1 fifo size is 2k
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 405afef..691480b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -62,6 +62,7 @@ struct mtk_disp_rdma {
> struct mtk_ddp_comp ddp_comp;
> struct drm_crtc *crtc;
> const struct mtk_disp_rdma_data *data;
> + u32 fifo_size;
> };
>
> static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> @@ -130,10 +131,16 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
> unsigned int threshold;
> unsigned int reg;
> struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> + u32 rdma_fifo_size;
>
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
>
> + if (rdma->fifo_size)
> + rdma_fifo_size = rdma->fifo_size;
> + else
> + rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
> +
> /*
>* Enable FIFO underflow since DSI and DPI can't be blocked.
>* Keep the FIFO pseudo size reset default of 8 KiB. Set the
> @@ -142,7 +149,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
>*/
> threshold = width * height * vrefresh * 4 * 7 / 100;
> reg = RDMA_FIFO_UNDERFLOW_EN |
> - RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> + RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
> writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
> }
> @@ -284,6 +291,18 @@ static int mtk_disp_rdma_probe(struct platform_device
> *pdev)
> return comp_id;
> }
>
> + if (of_find_property(dev->of_node, "mediatek,rdma_fifo_size", &ret)) {
"mediatek,rdma_fifo_size" does not exists in binding document.
> + ret = of_property_read_u32(dev->of_node,
> +"mediatek,rdma_fifo_size",
> +&priv->fifo_size);
> + if (ret) {
> + dev_err(dev, "Failed to get rdma fifo size\n");
> + return ret;
> + }
> +
> + priv->fifo_size *= SZ_1K;
Why not define fifo_size in 'bytes' ?
Regards,
CK
> + }
> +
> ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
> &mtk_disp_rdma_funcs);
> if (ret) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6, 04/14] drm/mediatek: add mmsys private data for ddp path config
Hi, Yongqiang:
On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> This patch add mmsys private data for ddp path config
> all these register offset and value will be different in future SOC
> add these define into mmsys private data
> u32 ovl0_mout_en;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dsi0;
> u32 dpi0_sel_in;
> u32 dpi0_sel_in_rdma1;
> u32 dsi0_sel_in;
> u32 dsi0_sel_in_rdma1;
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 63
> -
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 6
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 ++
> 5 files changed, 63 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index e47cf84..9aacbcf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -44,6 +44,7 @@ struct mtk_drm_crtc {
> boolpending_planes;
>
> struct regmap *config_regs;
> + const struct mtk_mmsys_reg_data *mmsys_reg_data;
> struct mtk_disp_mutex *mutex;
> unsigned intddp_comp_nr;
> struct mtk_ddp_comp **ddp_comp;
> @@ -283,6 +284,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> DRM_DEBUG_DRIVER("mediatek_ddp_ddp_path_setup\n");
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
> + mtk_crtc->mmsys_reg_data,
>mtk_crtc->ddp_comp[i]->id,
>mtk_crtc->ddp_comp[i + 1]->id);
> mtk_disp_mutex_add_comp(mtk_crtc->mutex,
> @@ -340,6 +342,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> mtk_disp_mutex_disable(mtk_crtc->mutex);
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
> + mtk_crtc->mmsys_reg_data,
> mtk_crtc->ddp_comp[i]->id,
> mtk_crtc->ddp_comp[i + 1]->id);
> mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
> @@ -649,6 +652,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> return -ENOMEM;
>
> mtk_crtc->config_regs = priv->config_regs;
> + mtk_crtc->mmsys_reg_data = priv->data->reg_data;
> mtk_crtc->ddp_comp_nr = path_len;
> mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
> sizeof(*mtk_crtc->ddp_comp),
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index f99f89a1..ea0ce32 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -168,6 +168,16 @@ struct mtk_ddp {
> const struct mtk_ddp_data *data;
> };
>
> +struct mtk_mmsys_reg_data {
> + u32 ovl0_mout_en;
> + u32 rdma1_sout_sel_in;
> + u32 rdma1_sout_dpi0;
> + u32 dpi0_sel_in;
> + u32 dpi0_sel_in_rdma1;
> + u32 dsi0_sel_in;
> + u32 dsi0_sel_in_rdma1;
This patch looks like a combination of two patches. One is a bug fix
that dsi0_sel_in and dsi0_sel_in_rdma1 are different in MT8173 and
MT2701. And the other is that ovl0_mout_en, rdma1_sout_sel_in,
rdma1_sout_dpi0, dpi0_sel_in, dpi0_sel_in_rdma1 are different in MT8183.
Regards,
CK
> +};
> +
> static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> @@ -246,17 +256,34 @@ struct mtk_ddp {
> .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
> };
>
> -static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> +const struct mtk_mmsys_reg_data mt2701_mmsys_reg_data = {
> + .ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL_MOUT_EN,
> + .dsi0_sel_in = DISP_REG_CONFIG_DSI_SEL,
> + .dsi0_sel_in_rdma1 = DSI_SEL_IN_RDMA,
> +};
> +
> +const struct mtk_mmsys_reg_data mt8173_mmsys_reg_data = {
> + .ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN,
> + .rdma1_sout_sel_in = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN,
> + .rdma1_sout_dpi0 = RDMA1_SOUT_DPI0,
> + .dpi0_sel_in = DISP_REG_CONFIG_DPI_SEL_IN,
> + .dpi0_sel_in_rdma1 = DPI0_SEL_IN_RDMA1,
> + .dsi0_sel_in = DISP_REG_CONFIG_DSIE_SEL_IN,
> + .dsi0_sel_in_rdma1 = DSI0_SEL_IN_RDMA1,
> +};
> +
> +static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
> + enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next,
>
Re: [PATCH v6, 14/14] drm/mediatek: add support for mediatek SOC MT8183
Hi, Yongqiang:
On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 69
>
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 48 ++
> 5 files changed, 142 insertions(+)
>
[snip]
> +
> +
> static int mtk_drm_kms_init(struct drm_device *drm)
> {
> struct mtk_drm_private *private = drm->dev_private;
> @@ -449,12 +477,22 @@ static void mtk_drm_unbind(struct device *dev)
> .data = (void *)MTK_DISP_OVL },
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = (void *)MTK_DISP_OVL },
> + { .compatible = "mediatek,mt8183-disp-ovl",
> + .data = (void *)MTK_DISP_OVL },
> + { .compatible = "mediatek,mt8183-disp-ovl-2l",
> + .data = (void *)MTK_DISP_OVL_2L },
> { .compatible = "mediatek,mt2701-disp-rdma",
> .data = (void *)MTK_DISP_RDMA },
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = (void *)MTK_DISP_RDMA },
> + { .compatible = "mediatek,mt8183-disp-rdma",
> + .data = (void *)MTK_DISP_RDMA },
> + { .compatible = "mediatek,mt8183-disp-rdma1",
"mediatek,mt8183-disp-rdma1" does not exist in binding document.
Regards,
CK
> + .data = (void *)MTK_DISP_RDMA },
> { .compatible = "mediatek,mt8173-disp-wdma",
> .data = (void *)MTK_DISP_WDMA },
> + { .compatible = "mediatek,mt8183-disp-ccorr",
> + .data = (void *)MTK_DISP_CCORR },
> { .compatible = "mediatek,mt2701-disp-color",
> .data = (void *)MTK_DISP_COLOR },
> { .compatible = "mediatek,mt8173-disp-color",
> @@ -463,22 +501,30 @@ static void mtk_drm_unbind(struct device *dev)
> .data = (void *)MTK_DISP_AAL},
> { .compatible = "mediatek,mt8173-disp-gamma",
> .data = (void *)MTK_DISP_GAMMA, },
> + { .compatible = "mediatek,mt8183-disp-dither",
> + .data = (void *)MTK_DISP_DITHER },
> { .compatible = "mediatek,mt8173-disp-ufoe",
> .data = (void *)MTK_DISP_UFOE },
> { .compatible = "mediatek,mt2701-dsi",
> .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi",
> .data = (void *)MTK_DSI },
> + { .compatible = "mediatek,mt8183-dsi",
> + .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt2701-dpi",
> .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8173-dpi",
> .data = (void *)MTK_DPI },
> + { .compatible = "mediatek,mt8183-dpi",
> + .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-disp-mutex",
> .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt2712-disp-mutex",
> .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-mutex",
> .data = (void *)MTK_DISP_MUTEX },
> + { .compatible = "mediatek,mt8183-disp-mutex",
> + .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt2701-disp-pwm",
> .data = (void *)MTK_DISP_BLS },
> { .compatible = "mediatek,mt8173-disp-pwm",
> @@ -672,6 +718,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops,
> mtk_drm_sys_suspend,
> .data = &mt2712_mmsys_driver_data},
> { .compatible = "mediatek,mt8173-mmsys",
> .data = &mt8173_mmsys_driver_data},
> + { .compatible = "mediatek,mt8183-mmsys",
> + .data = &mt8183_mmsys_driver_data},
> { }
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6, 02/14] drm/mediatek: move dsi/dpi select input into mtk_ddp_sel_in
Hi, Yongqiang:
On Thu, 2020-01-02 at 13:39 +0800, Yongqiang Niu wrote:
> On Thu, 2020-01-02 at 13:03 +0800, CK Hu wrote:
> > Hi, Yongqiang:
> >
> > On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> > > move dsi/dpi select input into mtk_ddp_sel_in
> > >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index 39700b9..91c9b19 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -376,6 +376,12 @@ static unsigned int mtk_ddp_sel_in(enum
> > > mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> > > *addr = DISP_REG_CONFIG_DSI_SEL;
> > > value = DSI_SEL_IN_BLS;
> > > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> > > + *addr = DISP_REG_CONFIG_DSI_SEL;
> > > + value = DSI_SEL_IN_RDMA;
> >
> > In original code, this is set when cur == DDP_COMPONENT_BLS and next ==
> > DDP_COMPONENT_DPI0. Why do you change the condition?
> >
> > Regards,
> > CK
>
> if bls connect with dpi0, rdma1 should connect with dsi0, the condition
> is same with before.
You suggest that two crtcs are both enabled. If only one crtc is
enabled, just one of these two would be set.
Regards,
CK
> >
> > > + } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > > + *addr = DISP_REG_CONFIG_DPI_SEL;
> > > + value = DPI_SEL_IN_BLS;
> > > } else {
> > > value = 0;
> > > }
> > > @@ -393,10 +399,6 @@ static void mtk_ddp_sout_sel(struct regmap
> > > *config_regs,
> > > } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > > regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
> > > BLS_TO_DPI_RDMA1_TO_DSI);
> > > - regmap_write(config_regs, DISP_REG_CONFIG_DSI_SEL,
> > > - DSI_SEL_IN_RDMA);
> > > - regmap_write(config_regs, DISP_REG_CONFIG_DPI_SEL,
> > > - DPI_SEL_IN_BLS);
> > > }
> > > }
> > >
> >
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6, 02/14] drm/mediatek: move dsi/dpi select input into mtk_ddp_sel_in
Hi, Yongqiang:
On Thu, 2020-01-02 at 14:21 +0800, Yongqiang Niu wrote:
> On Thu, 2020-01-02 at 14:02 +0800, CK Hu wrote:
> > Hi, Yongqiang:
> >
> > On Thu, 2020-01-02 at 13:39 +0800, Yongqiang Niu wrote:
> > > On Thu, 2020-01-02 at 13:03 +0800, CK Hu wrote:
> > > > Hi, Yongqiang:
> > > >
> > > > On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> > > > > move dsi/dpi select input into mtk_ddp_sel_in
> > > > >
> > > > > Signed-off-by: Yongqiang Niu
> > > > > ---
> > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++
> > > > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > index 39700b9..91c9b19 100644
> > > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > @@ -376,6 +376,12 @@ static unsigned int mtk_ddp_sel_in(enum
> > > > > mtk_ddp_comp_id cur,
> > > > > } else if (cur == DDP_COMPONENT_BLS && next ==
> > > > > DDP_COMPONENT_DSI0) {
> > > > > *addr = DISP_REG_CONFIG_DSI_SEL;
> > > > > value = DSI_SEL_IN_BLS;
> > > > > + } else if (cur == DDP_COMPONENT_RDMA1 && next ==
> > > > > DDP_COMPONENT_DSI0) {
> > > > > + *addr = DISP_REG_CONFIG_DSI_SEL;
> > > > > + value = DSI_SEL_IN_RDMA;
> > > >
> > > > In original code, this is set when cur == DDP_COMPONENT_BLS and next ==
> > > > DDP_COMPONENT_DPI0. Why do you change the condition?
> > > >
> > > > Regards,
> > > > CK
> > >
> > > if bls connect with dpi0, rdma1 should connect with dsi0, the condition
> > > is same with before.
> >
> > You suggest that two crtcs are both enabled. If only one crtc is
> > enabled, just one of these two would be set.
> >
> > Regards,
> > CK
>
> OK, i will modify like this
> else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DSI_SEL;
> value = DPI_SEL_IN_RDMA;
> }
> in mtk_ddp_sel_in.
>
> don't set DISP_REG_CONFIG_DPI_SEL to DPI_SEL_IN_BLS anymore, because
> DPI_SEL_IN_BLS is zero, it is same with hardware default setting.
In Bibby's case, there is only the path from BLS to DPI0 and has no path
from RDMA1 to DSI0, but it need to set these two register. Maybe its
setting is just for some SoC, so you may use the compatible name to
judge how to set this two register.
Regards,
CK
> >
> > > >
> > > > > + } else if (cur == DDP_COMPONENT_BLS && next ==
> > > > > DDP_COMPONENT_DPI0) {
> > > > > + *addr = DISP_REG_CONFIG_DPI_SEL;
> > > > > + value = DPI_SEL_IN_BLS;
> > > > > } else {
> > > > > value = 0;
> > > > > }
> > > > > @@ -393,10 +399,6 @@ static void mtk_ddp_sout_sel(struct regmap
> > > > > *config_regs,
> > > > > } else if (cur == DDP_COMPONENT_BLS && next ==
> > > > > DDP_COMPONENT_DPI0) {
> > > > > regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
> > > > > BLS_TO_DPI_RDMA1_TO_DSI);
> > > > > - regmap_write(config_regs, DISP_REG_CONFIG_DSI_SEL,
> > > > > - DSI_SEL_IN_RDMA);
> > > > > - regmap_write(config_regs, DISP_REG_CONFIG_DPI_SEL,
> > > > > - DPI_SEL_IN_BLS);
> > > > > }
> > > > > }
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6, 13/14] drm/mediatek: add fifo_size into rdma private data
Hi, Yongqiang:
On Thu, 2020-01-02 at 13:42 +0800, Yongqiang Niu wrote:
> On Thu, 2020-01-02 at 13:20 +0800, CK Hu wrote:
> > Hi, Yongqiang:
> >
> > On Thu, 2020-01-02 at 12:00 +0800, Yongqiang Niu wrote:
> > > the fifo size of rdma in mt8183 is different.
> > > rdma0 fifo size is 5k
> > > rdma1 fifo size is 2k
> > >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 21 -
> > > 1 file changed, 20 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > > index 405afef..691480b 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > > @@ -62,6 +62,7 @@ struct mtk_disp_rdma {
> > > struct mtk_ddp_comp ddp_comp;
> > > struct drm_crtc *crtc;
> > > const struct mtk_disp_rdma_data *data;
> > > + u32 fifo_size;
> > > };
> > >
> > > static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp
> > > *comp)
> > > @@ -130,10 +131,16 @@ static void mtk_rdma_config(struct mtk_ddp_comp
> > > *comp, unsigned int width,
> > > unsigned int threshold;
> > > unsigned int reg;
> > > struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> > > + u32 rdma_fifo_size;
> > >
> > > rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
> > > rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
> > >
> > > + if (rdma->fifo_size)
> > > + rdma_fifo_size = rdma->fifo_size;
> > > + else
> > > + rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
> > > +
> > > /*
> > >* Enable FIFO underflow since DSI and DPI can't be blocked.
> > >* Keep the FIFO pseudo size reset default of 8 KiB. Set the
> > > @@ -142,7 +149,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp
> > > *comp, unsigned int width,
> > >*/
> > > threshold = width * height * vrefresh * 4 * 7 / 100;
> > > reg = RDMA_FIFO_UNDERFLOW_EN |
> > > - RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> > > + RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> > > RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
> > > writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
> > > }
> > > @@ -284,6 +291,18 @@ static int mtk_disp_rdma_probe(struct
> > > platform_device *pdev)
> > > return comp_id;
> > > }
> > >
> > > + if (of_find_property(dev->of_node, "mediatek,rdma_fifo_size", &ret)) {
> >
> > "mediatek,rdma_fifo_size" does not exists in binding document.
> >
> > > + ret = of_property_read_u32(dev->of_node,
> > > +"mediatek,rdma_fifo_size",
> > > +&priv->fifo_size);
> > > + if (ret) {
> > > + dev_err(dev, "Failed to get rdma fifo size\n");
> > > + return ret;
> > > + }
> > > +
> > > + priv->fifo_size *= SZ_1K;
> >
> > Why not define fifo_size in 'bytes' ?
> >
> > Regards,
> > CK
>
> this is align the definition of fifo_size in mtk_disp_rdma_data, it is
> SZ_1K,
> and the macro RDMA_FIFO_PSEUDO_SIZE calculated with SZ_1K
I mean why not set the fifo size in bytes in device tree. So you need
not to do '*= SZ_1K' here. I think unit of fifo size in kernel is byte.
Regards,
CK
> >
> > > + }
> > > +
> > > ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
> > > &mtk_disp_rdma_funcs);
> > > if (ret) {
> >
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/sun4i: Use CRTC size instead of PRIMARY plane size as mixer frame.
Hi Roman,
Your domain has DMARC setup with the "reject" policy.
This means emails from your domain may be subsequently rejected by people
using email forwarders (such as @kernel.org) to forward to Gmail.
I suggest using another email address to send patches, or ask your IT
people to drop the policy to "quarantine", which makes the email go to
the SPAM folder instead of outright rejecting them.
ChenYu
On Thu, Jan 2, 2020 at 3:43 PM Jernej Škrabec wrote:
>
> Hi!
>
> Dne sreda, 01. januar 2020 ob 21:47:50 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: 5bb5f5dafa1a ("drm/sun4i: Reorganize UI layer code in DE2")
> > Signed-off-by: Roman Stratiienko
>
> This looks great now.
>
> Reviewed-by: Jernej Skrabec
>
> What happened to other patches in the series? It would be nice to have a cover
> letter for such cases, where you can explain reasons for dropped patches.
>
> Best regards,
> Jernej
>
> > ---
> > v2:
> > - Split commit in 2 parts
> > - Add Fixes line to the commit message
> >
> > v3:
> > - Address review comments of v2 + removed 3 local varibles
> > - Change 'Fixes' line
> >
> > Since I've put more changes from my side, please review/sign again.
> > ---
> > drivers/gpu/drm/sun4i/sun8i_mixer.c| 28
> > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 30 --
> > 2 files changed, 28 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 8b803eb903b8..658cf442c121
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -257,6 +257,33 @@ 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 size = SUN8I_MIXER_SIZE(mode->crtc_hdisplay, mode-
> >crtc_vdisplay);
> > + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> > + u32 bld_base = sun8i_blender_base(mixer);
> > + u32 val;
> > +
> > + DRM_DEBUG_DRIVER("Mode change, updating global size W: %u H: %u\n",
> > + mode->crtc_hdisplay, mode->crtc_vdisplay);
> > + regmap_write(mixer->engine.regs, SUN8I_MIXER_GLOBAL_SIZE, size);
> > + regmap_write(mixer->engine.regs,
> > + SUN8I_MIXER_BLEND_OUTSIZE(bld_base), size);
> > +
> > + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > + 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",
> > + val ? "on" : "off");
> > +}
> > +
> > static void sun8i_mixer_commit(struct sunxi_engine *engine)
> > {
> > DRM_DEBUG_DRIVER("Committing changes\n");
> > @@ -310,6 +337,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 4343ea9f8cf8..f01ac55191f1
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> > @@ -120,36 +120,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
Re: [PATCH 1/3] drm/i915: use true, false for bool variable in i915_debugfs.c
On Tue, 24 Dec 2019, Ma Feng wrote: > Fixes coccicheck warning: > > drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to > bool variable > drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to > bool variable > drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to > bool variable > drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to > bool variable > Thanks for the patches, but please resend either as a proper threaded series or unthreaded single patches. Patchwork did not recognize this, and failed to queue tests. Sorry for the inconvenience. BR, Jani. > Reported-by: Hulk Robot > Signed-off-by: Ma Feng > --- > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index d28468e..4ead86a 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -3075,9 +3075,9 @@ static ssize_t > i915_displayport_test_active_write(struct file *file, >* testing code, only accept an actual value of 1 here >*/ > if (val == 1) > - intel_dp->compliance.test_active = 1; > + intel_dp->compliance.test_active = true; > else > - intel_dp->compliance.test_active = 0; > + intel_dp->compliance.test_active = false; > } > } > drm_connector_list_iter_end(&conn_iter); > -- > 2.6.2 > -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
