Re: [PATCH 03/51] drm: add managed resources tied to drm_device
Hi Daniel,
I love your patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm_device-managed-resources-v4/20200303-071023
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/gpu/drm/drm_drv.c:843 drm_dev_release() error: dereferencing freed
memory 'dev'
#
https://github.com/0day-ci/linux/commit/5aba700d4c32ae5722a9931c959b13a6217a86e2
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 5aba700d4c32ae5722a9931c959b13a6217a86e2
vim +/dev +843 drivers/gpu/drm/drm_drv.c
099d1c290e2ebc drivers/gpu/drm/drm_stub.c David Herrmann 2014-01-29 826
static void drm_dev_release(struct kref *ref)
0dc8fe5985e01f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-02 827 {
099d1c290e2ebc drivers/gpu/drm/drm_stub.c David Herrmann 2014-01-29 828
struct drm_device *dev = container_of(ref, struct drm_device, ref);
8f6599da8e772f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-20 829
f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 830
if (dev->driver->release) {
f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 831
dev->driver->release(dev);
f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 832
} else {
f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 833
drm_dev_fini(dev);
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 834
}
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 835
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 836
drm_managed_release(dev);
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 837
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 838
if (!dev->driver->release && !dev->managed.final_kfree) {
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 839
WARN_ON(!list_empty(&dev->managed.resources));
0dc8fe5985e01f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-02 840
kfree(dev);
^^
Free
0dc8fe5985e01f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-02 841
}
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 842
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 @843
if (dev->managed.final_kfree)
^
Dereference
5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 844
kfree(dev->managed.final_kfree);
f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 845 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] [RFC] drm/virtgpu: modify uapi with stride/layer_stride fix
On Fri, Feb 28, 2020 at 01:01:49PM -0800, Chia-I Wu wrote: > On Wed, Oct 2, 2019 at 5:18 PM Gurchetan Singh > wrote: > > > > On Wed, Oct 2, 2019 at 1:49 AM Gerd Hoffmann wrote: > > > > > > On Tue, Oct 01, 2019 at 06:49:35PM -0700, Gurchetan Singh wrote: > > > > This doesn't really break userspace, since it always passes down > > > > 0 for stride/layer_stride currently. We could: > > > > > > > > (1) modify UAPI now and add a VIRTGPU_PARAM_STRIDE_FIX feature > > > > > > This I think. > > > But IMO it's not a fix, it is an added feature ... > > > > > > Also missing the big picture here. Why do we need this? > > > > Two reasons: > I don't fully get the picture, but drm_virtgpu_resource_create has > stride. Can we send that down in transfers? It's unused and suddenly caring about it has a good chance to break stuff ... cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Distribute switch variables for initialization
On Tue, Mar 3, 2020 at 5:39 AM Kees Cook wrote:
>
> On Wed, Feb 19, 2020 at 10:22:29PM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be automatically initialized with compiler instrumentation (as
> > they are not part of any execution flow). With GCC's proposed automatic
> > stack variable initialization feature, this triggers a warning (and they
> > don't get initialized). Clang's automatic stack variable initialization
> > (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> > doesn't initialize such variables[1]. Note that these warnings (or silent
> > skipping) happen before the dead-store elimination optimization phase,
> > so even when the automatic initializations are later elided in favor of
> > direct initializations, the warnings remain.
> >
> > To avoid these problems, move such variables into the "case" where
> > they're used or lift them up into the main function body.
> >
> > drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’:
> > drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be
> > executed [-Wswitch-unreachable]
> > 4395 | int sad_count;
> > | ^
> >
> > [1] https://bugs.llvm.org/show_bug.cgi?id=44916
> >
> > Signed-off-by: Kees Cook
>
> Ping. Can someone pick this up, please?
Whatever the reasons, but your original patch didn't make it through
to dri-devel. Can you pls resubmit?
Thanks, Daniel
>
> Thanks!
>
> -Kees
>
> > ---
> > drivers/gpu/drm/drm_edid.c |5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 805fb004c8eb..2941b65b427f 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4392,9 +4392,9 @@ static void drm_edid_to_eld(struct drm_connector
> > *connector, struct edid *edid)
> > dbl = cea_db_payload_len(db);
> >
> > switch (cea_db_tag(db)) {
> > - int sad_count;
> > + case AUDIO_BLOCK: {
> >
> > - case AUDIO_BLOCK:
> > + int sad_count;
> > /* Audio Data Block, contains SADs */
> > sad_count = min(dbl / 3, 15 -
> > total_sad_count);
> > if (sad_count >= 1)
> > @@ -4402,6 +4402,7 @@ static void drm_edid_to_eld(struct drm_connector
> > *connector, struct edid *edid)
> > &db[1], sad_count * 3);
> > total_sad_count += sad_count;
> > break;
> > + }
> > case SPEAKER_BLOCK:
> > /* Speaker Allocation Data Block */
> > if (dbl >= 1)
> >
>
> --
> Kees Cook
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] drm/sun4i: Add alpha property for sun8i UI layer
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
---
v2: Initial commit by mistake
v3:
- Picked `reviewed-by` line
V4:
- Changed author e-mail to avoid mail rejecting.
---
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 19f42004cebe..5278032567a3 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)
@@ -258,6 +279,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,
@@ -332,6 +355,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 v4 2/4] drm/sun4i: Add alpha property for sun8i and sun50i VI layer
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.
Do not add alpha property for V3s SOC that have DE2.0 and 2 VI planes.
Signed-off-by: Roman Stratiienko
Reviewed-by: Jernej Skrabec
---
v2: Initial version by mistake
v3:
- Skip adding & applying alpha property if VI count > 1
V4:
- Changed author e-mail address to avoid mail rejecting
- Picked reviewed-by line
---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 48 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 11 ++
2 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 2344938be3e4..f2469b5e97ee 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 if (mixer->cfg->vi_num == 1) {
+ 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,
@@ -472,6 +496,14 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
plane_cnt = mixer->cfg->ui_num + mixer->cfg->vi_num;
+ if (mixer->cfg->vi_num == 1 || mixer->cfg->is_de3) {
+ 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_GL
Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
Another thing: did you verify that the panel still runs at 60hz (and not
dropping frames to 30hz)? IIRC that was the behavior with lower clock.
On 3/2/20 10:28 PM, Jonathan Marek wrote:
On 3/2/20 10:13 PM, Brian Masney wrote:
On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
Hi,
This is a command mode panel and the the msm/mdp5 driver uses the
vrefresh
field for the actual refresh rate, while the dotclock field is used
for the
DSI clocks. The dotclock needed to be a bit higher than necessary
otherwise
the panel would not work.
If you want to get rid of the separate clock/vrefresh fields there would
need to be some changes to msm driver.
(note I hadn't made the patch with upstreaming in mind, the 15
value is
likely not optimal, just something that worked, this is something that
should have been checked with the downstream driver)
Is this the right clock frequency in the downstream MSM 3.4 kernel that
you're talking about?
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
No, I'm talking about the DSI clock (the driver for it is in
drm/msm/dsi/). For a command mode panel the front/back porches aren't
relevant, but the dsi pixel/byte clock need to be a bit higher than
1920x1080x60. Since 125498 is a little higher than 124416 that might be
enough (there is also rounding of the clock values to consider).
I don't see any obvious clock values in the downstream command mode
panel configuration:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
and everything appears to be working fine. You can add my Tested-by if
you end up applying this.
Tested-by: Brian Masney
Brian
On 3/2/20 3:34 PM, Ville Syrjala wrote:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Jonathan Marek
Cc: Brian Masney
Cc: Linus Walleij
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index b24fdf239440..f958d8dfd760 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
panasonic_vvx10f004b00 = {
};
static const struct drm_display_mode lg_acx467akm_7_mode = {
- .clock = 15,
+ .clock = 125498,
.hdisplay = 1080,
.hsync_start = 1080 + 2,
.hsync_end = 1080 + 2 + 2,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11
On 2020-03-02 21:34, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
TL/DR; I do not care if you change the refresh rate or the dotclock.
The whole entry for that panel in simple-panel is dubious. The panel
is really an LVDS panel (capable of both VESA/Jeida RGB888, selectable
with the SELLVDS pin). With Jeida you can, as usual, omit the 4th
data channel and use the panel with RGB666. In either case, you need
an LVDS signal and nothing else...
The panel can also rotate the picture 180 degrees using the RL/UD pin.
These options are of course not expressed in the simple panel driver
(and we have always used fixed signals for those pins in our designs,
IIRC). As far as I'm concerned, the panel can be removed from
simple-panel. Our device trees are nowadays correctly expressing the
hardware with an LVDS encoder between the RGB output and the panel
and points to the panel-lvds driver for the panel.
The reason that it is as it is, is that we obviously didn't understand
what we were doing when we added the entry, and this garbage was what
we came up with that produced a picture.
If you want to keep the panel in simple-panel despite all this, the
timing constraints are as follows:
Pixel clock 50-80 MHz,65 MHz typical
Horizontal period 1094-1720 clocks, 1344 typical
16.0-23.4 us 20.7 us
Horizontal enable1024 clocks, always
Vertical period776-990 lines,806 typical
13.3-18.0 ms 16.7 ms
Vertical enable 768 lines, always
Using a "long" (the datasheet is not very specific on this issue) vertical
period may introduce deterioration of display quality, flicker etc.
I don't think the division between front-porch/back-porch matters much.
That said, I have no idea whatsoever if others have started using this
panel entry. My guess is that it has zero users, but who can tell?
Cheers,
Peter
> Cc: Gustaf Lindström
> Cc: Peter Rosin
> Cc: Thierry Reding
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 7526af2d6d95..cb587de8c49e 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3026,7 +3026,7 @@ static const struct panel_desc sharp_lq123p1jx31 = {
> };
>
> static const struct drm_display_mode sharp_lq150x1lg11_mode = {
> - .clock = 71100,
> + .clock = 65722,
> .hdisplay = 1024,
> .hsync_start = 1024 + 168,
> .hsync_end = 1024 + 168 + 64,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] vgacon: Fix a UAF in vgacon_invert_region
When syzkaller tests, there is a UAF:
BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
8810
Read of size 2 by task syz-executor.1/16489
page:ea004000 count:0 mapcount:-127 mapping: (null)
index:0x0
page flags: 0xf()
page dumped because: kasan: bad access detected
CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
Call Trace:
[] dump_stack+0x1e/0x20
[] kasan_report+0x577/0x950
[] __asan_load2+0x62/0x80
[] vgacon_invert_region+0x9d/0x110
[] invert_screen+0xe5/0x470
[] set_selection+0x44b/0x12f0
[] tioclinux+0xee/0x490
[] vt_ioctl+0xff4/0x2670
[] tty_ioctl+0x46a/0x1a10
[] do_vfs_ioctl+0x5bd/0xc40
[] SyS_ioctl+0x132/0x170
[] system_call_fastpath+0x22/0x27
Memory state around the buggy address:
880fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
880fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
>8810: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
It can be reproduce in the linux mainline by the program:
#include
#include
#include
#include
#include
#include
#include
#include
struct tiocl_selection {
unsigned short xs; /* X start */
unsigned short ys; /* Y start */
unsigned short xe; /* X end */
unsigned short ye; /* Y end */
unsigned short sel_mode; /* selection mode */
};
#define TIOCL_SETSEL2
struct tiocl {
unsigned char type;
unsigned char pad;
struct tiocl_selection sel;
};
int main()
{
int fd = 0;
const char *dev = "/dev/char/4:1";
struct vt_consize v = {0};
struct tiocl tioc = {0};
fd = open(dev, O_RDWR, 0);
v.v_rows = 3346;
ioctl(fd, VT_RESIZEX, &v);
tioc.type = TIOCL_SETSEL;
ioctl(fd, TIOCLINUX, &tioc);
return 0;
}
When resize the screen, update the 'vc->vc_size_row' to the new_row_size,
but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base'
for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe
smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc
the offset, it maybe larger than the vga_vram_base in vgacon driver, then
bad access.
So, If the screen size larger than vga_vram, resize screen should be
failed. This alse fix CVE-2020-8649
Fixes: 0aec4867dca14 ("[PATCH] SVGATextMode fix")
Reported-by: Hulk Robot
Signed-off-by: Zhang Xiaoxu
---
drivers/video/console/vgacon.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index de7b8382aba9..9c216f707629 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1316,7 +1316,10 @@ static int vgacon_font_get(struct vc_data *c, struct
console_font *font)
static int vgacon_resize(struct vc_data *c, unsigned int width,
unsigned int height, unsigned int user)
{
- if (width % 2 || width > screen_info.orig_video_cols ||
+ if (width % 2 || width * height > vga_vram_size)
+ return -EINVAL;
+
+ if (width > screen_info.orig_video_cols ||
height > (screen_info.orig_video_lines * vga_default_font_height)/
c->vc_font.height)
/* let svgatextmode tinker with video timings and
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M
Hi Ville,
> Am 02.03.2020 um 21:34 schrieb Ville Syrjala :
>
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
Data sheet of COM37H3M99DTC says:
MIN TYP MAX
CLK frequency fCLK18 19.827 MHz
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv 646 650 700 H
HSYNC frequency fHSYNC -- 39.050.0Khz
HSYNC cycle time th 504 508 630 CLK
But data sheet of COM37H3M05DTC says
MIN TYP MAX
CLK frequency fCLK-- 22.426.3MHz (in VGA mode - there is
also an QVGA mode)
VSYNC Frequency fVSYNC 54 60 66 Hz
VSYNC cycle time tv -- 650 -- H
HSYNC frequency fHSYNC -- 39.3-- Khz
HSYNC cycle time th -- 570 -- CLK
So there are two different subvariants of the same panel.
If I remember correctly, the 05 is older (April 2010)
and the 99DTC newer (Dec 2011).
So 22 MHz isn't outside of either spec but may be higher
than needed for the 99DTC. I.e. the panel is probably
running at higher frame rate than 60 fps.
Hm. I think we should define some compromise. I.e.
.clock = 22230
.vrefresh = 60
.vtotal = 650
.htotal = 570
Probably we originally tried to do this with the parameter
set but got something wrong.
If you agree with this approach, I can try to figure out
the other parameters so that they should fit both panel
variants. I can only test with COM37H3M99DTC since I
do no longer have a device with COM37H3M05DTC.
In general it seems that the structure drm_display_mode
is overdetermined.
Either .clock could be calculated from .vrefresh (and
the other .vtotal and .htotal) or vice versa like I
did for the proposal above.
I haven't looked into the driver code, but would it be
possible to specify .clock = 0 (or leave it out) to
calculate it bottom up? This would avoid such inconsistencies.
On the other hand it is not easily visible any more
from the code if the clock is in range of the data
sheet limits.
BR and thanks,
Nikolaus
>
> Cc: H. Nikolaus Schaller
> Cc: Sam Ravnborg
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index ca72b73408e9..f9b4f84bffb3 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2617,7 +2617,7 @@ static const struct panel_desc ontat_yx700wv03 = {
> };
>
> static const struct drm_display_mode ortustech_com37h3m_mode = {
> - .clock = 22153,
> + .clock = 19842,
> .hdisplay = 480,
> .hsync_start = 480 + 8,
> .hsync_end = 480 + 8 + 10,
> --
> 2.24.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
.[PATCH v4 0/4] drm/sun4i: Improve alpha processing
Patches 1-2 already reviewed and ready to be applied. Patch 4 is RFC and require more testing on real hardware. [PATCH v4 1/4] drm/sun4i: Add alpha property for sun8i UI layer [PATCH v4 2/4] drm/sun4i: Add alpha property for sun8i and sun50i VI [PATCH v4 3/4] drm/sun4i: Add support for premulti/coverage blending [PATCH v4 4/4] RFC: drm/sun4i: Process alpha channel of most bottom layer drivers/gpu/drm/sun4i/sun8i_mixer.h| 2 + drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 50 drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 10 drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 72 +--- drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 16 ++ 5 files changed, 142 insertions(+), 8 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 6/8] MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller
Hi Nikolaus,
Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780
HDMI support. This requires a new driver, plus device tree and
configuration
modifications.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 32
++
1 file changed, 32 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index f928329b034b..391d4e1efd35 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -433,4 +433,36 @@
status = "disabled";
};
+
+ hdmi: hdmi@1018 {
+ compatible = "ingenic,jz4780-dw-hdmi";
+ reg = <0x1018 0x8000>;
+ reg-io-width = <4>;
+
+ clocks = <&cgu JZ4780_CLK_HDMI>, <&cgu JZ4780_CLK_AHB0>;
+ clock-names = "isfr" , "iahb";
+
+ assigned-clocks = <&cgu JZ4780_CLK_HDMI>;
+ assigned-clock-rates = <2700>;
I *think* this should go to the board file.
+
+ interrupt-parent = <&intc>;
+ interrupts = <3>;
+
+ /* ddc-i2c-bus = <&i2c4>; */
+
+ status = "disabled";
+ };
+
+ lcd: lcd@1305 {
The node name should be 'lcd-controller'.
+ compatible = "ingenic,jz4740-lcd";
The JZ4780's LCD controller is much newer than the JZ4740 one, so even
if it works with the "ingenic,jz4740-lcd" compatible string, you want
it as a fallback.
So this should be: compatible = "ingenic,jz4780-lcd",
"ingenic,jz4740-lcd".
That means the YAML should be updated too.
-Paul
+ reg = <0x1305 0x1800>;
+
+ clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
+ clock-names = "lcd", "lcd_pclk";
+
+ interrupt-parent = <&intc>;
+ interrupts = <31>;
+
+ status = "disabled";
+ };
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/bridge: dw-hdmi: Fix color space conversion detection
Hi Neil!
Dne ponedeljek, 02. marec 2020 ob 10:26:09 CET je Neil Armstrong napisal(a):
> Hi Jernej,
>
> On 29/02/2020 17:30, Jernej Skrabec wrote:
> > Currently, is_color_space_conversion() compares not only color spaces
> > but also formats. For example, function would return true if YCbCr 4:4:4
> > and YCbCr 4:2:2 would be set. Obviously in that case color spaces are
> > the same.
> >
> > Fix that by comparing if both values represent RGB color space.
> >
> > Fixes: b21f4b658df8 ("drm: imx: imx-hdmi: move imx-hdmi to
> > bridge/dw_hdmi")
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 24965e53d351..9d7bfb1cb213 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -956,7 +956,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
> >
> > static int is_color_space_conversion(struct dw_hdmi *hdmi)
> > {
> >
> > - return hdmi->hdmi_data.enc_in_bus_format !=
> > hdmi->hdmi_data.enc_out_bus_format; + return
> > hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format) !=
> > + hdmi_bus_fmt_is_rgb(hdmi-
>hdmi_data.enc_out_bus_format);
> >
> > }
> >
> > static int is_color_space_decimation(struct dw_hdmi *hdmi)
>
> I think in this case you should also fix the CEC enablement to:
you mean CSC, right?
> if (is_color_space_conversion(hdmi) || is_color_space_decimation(hdmi))
>
> in dw_hdmi_enable_video_path() otherwise CSC won't be enabled and will be
> bypassed in decimation case only.
>
Missed that one. I'll fix in v2.
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] RFC: drm/sun4i: Process alpha channel of most bottom layer
Allwinner display engine blender consists of 3 pipelined blending units. PIPE0->\ BLD0-\ PIPE1->/ BLD1-\ PIPE2->--/ BLD2->OUT PIPE3->/ This pipeline produces incorrect composition if PIPE0 buffer has alpha. Correct solution is to add one more blending step and mix PIPE0 with background, but it is not supported by the hardware. Use premultiplied alpha buffer of PIPE0 overlay channel as is. In this case we got same effect as mixing PIPE0 with black background. Signed-off-by: Roman Stratiienko --- v4: - Initial version, depends on other unmerged patches in the patchset. --- drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index dd6145f80c36..d94f4d8b9128 100644 --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c @@ -106,7 +106,7 @@ static void sun8i_ui_layer_update_alpha(struct sun8i_mixer *mixer, int channel, regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_PREMULTIPLY(bld_base), SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos), - SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos)); + zpos ? SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos) : 0); } static int sun8i_ui_layer_update_coord(struct sun8i_mixer *mixer, int channel, diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index e6d8a539614f..68a6843db4ab 100644 --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c @@ -108,7 +108,7 @@ static void sun8i_vi_layer_update_alpha(struct sun8i_mixer *mixer, int channel, regmap_update_bits(mixer->engine.regs, SUN8I_MIXER_BLEND_PREMULTIPLY(bld_base), SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos), - (mixer->cfg->is_de3) ? + (zpos != 0 && mixer->cfg->is_de3) ? SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos) : 0); } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 0/5] arm/arm64: mediatek: Fix mt8173 mmsys device probing
Dear all, Those patches are intended to solve an old standing issue on some Mediatek devices (mt8173, mt2701 and mt2712 are affected by this issue). Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver gets probed, which in effect breaks graphics on those devices. The MMSYS (Multimedia subsystem) in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display and MDP (Media Data Path) subsystem. On this series the clk driver is not a pure clock controller but a system controller that can provide access to the shared registers between the different drivers that need it (mediatek-drm and mediatek-mdp). Hence the MMSYS clk driver was moved to drivers/soc/mediatek and is the entry point (parent) which will trigger the probe of the corresponding mediatek-drm driver. **IMPORTANT** This series only fixes the issue on mt8173 to make it simple and as is the only platform I can test. Similar changes should be applied for mt2701 and mt2712 to have display working. For reference, here are the links to the old discussions: * v10: https://patchwork.kernel.org/project/linux-mediatek/list/?series=248505 * v9: https://patchwork.kernel.org/project/linux-clk/list/?series=247591 * v8: https://patchwork.kernel.org/project/linux-mediatek/list/?series=244891 * v7: https://patchwork.kernel.org/project/linux-mediatek/list/?series=241217 * v6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 * v5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=44063 * v4: * https://patchwork.kernel.org/patch/10530871/ * https://patchwork.kernel.org/patch/10530883/ * https://patchwork.kernel.org/patch/10530885/ * https://patchwork.kernel.org/patch/10530911/ * https://patchwork.kernel.org/patch/10530913/ * v3: * https://patchwork.kernel.org/patch/10367857/ * https://patchwork.kernel.org/patch/10367861/ * https://patchwork.kernel.org/patch/10367877/ * https://patchwork.kernel.org/patch/10367875/ * https://patchwork.kernel.org/patch/10367885/ * https://patchwork.kernel.org/patch/10367883/ * https://patchwork.kernel.org/patch/10367889/ * https://patchwork.kernel.org/patch/10367907/ * https://patchwork.kernel.org/patch/10367909/ * https://patchwork.kernel.org/patch/10367905/ * v2: No relevant discussion, see v3 * v1: * https://patchwork.kernel.org/patch/10016497/ * https://patchwork.kernel.org/patch/10016499/ * https://patchwork.kernel.org/patch/10016505/ * https://patchwork.kernel.org/patch/10016507/ Best regards, Enric Changes in v11: - Select CONFIG_MTK_MMSYS (CK) - Pass device pointer of mmsys device instead of config regs (CK) Changes in v10: - Update the binding documentation for the mmsys system controller. - Renamed to be generic mtk-mmsys - Add driver data support to be able to support diferent SoCs - Introduced a new patch to move routing control into mmsys driver. - Removed the patch to use regmap as is not needed anymore. - Match driver data to get display routing. Changes in v9: - Move mmsys to drivers/soc/mediatek (CK) - Do not move the display routing from the drm driver (CK) Changes in v8: - Be a builtin_platform_driver like other mediatek mmsys drivers. - New patch introduced in this series. Changes in v7: - Free clk_data->clks as well - Get rid of private data structure Enric Balletbo i Serra (3): dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller soc / drm: mediatek: Move routing control to mmsys device soc / drm: mediatek: Fix mediatek-drm device probing Matthias Brugger (2): drm/mediatek: Omit warning on probe defers soc: mediatek: Move mt8173 MMSYS to platform driver .../bindings/arm/mediatek/mediatek,mmsys.txt | 7 +- drivers/clk/mediatek/clk-mt8173.c | 104 - drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +- drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 259 +-- drivers/gpu/drm/mediatek/mtk_drm_ddp.h| 7 - drivers/gpu/drm/mediatek/mtk_drm_drv.c| 45 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h| 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c| 8 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +- drivers/soc/mediatek/Kconfig | 7 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-mmsys.c | 437 ++ include/linux/soc/mediatek/mtk-mmsys.h| 20 + 18 files changed, 537 insertions(+), 411 deletions(-) create mode 100644 drivers/soc/mediatek/mtk-mmsys.c create mode 100644 include/linux/soc/media
Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock
于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala
写到:
>From: Ville Syrjälä
>
>The currently listed dotclock disagrees with the currently
>listed vrefresh rate. Change the dotclock to match the vrefresh.
>
>Someone tell me which (if either) of the dotclock or vreresh is
>correct?
dotclock is correct and vrefresh is only a placeholder value.
>
>Cc: Icenowy Zheng
>Cc: Sam Ravnborg
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>index fddbfddf6566..8debee85f4ec 100644
>--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
>*panel)
> }
>
> static const struct drm_display_mode k101_im2ba02_default_mode = {
>- .clock = 7,
>+ .clock = 67286,
> .vrefresh = 60,
>
> .hdisplay = 800,
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] arm64: dts: rockchip: Describe PX30 GPU
PX30 SoCs feature an ARM Bifrost GPU.
Signed-off-by: Miquel Raynal
---
Hello, this change is just adding basic GPU support, more work is
needed on the devfreq/opp side to be sure everything works and is
properly described. Hence, this proposal aims at describing the HW
block only, not its hability to change voltages/frequencies.
Thanks,
Miquèl
arch/arm64/boot/dts/rockchip/px30.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index f99988b08244..7780e532d31b 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -997,6 +997,19 @@
status = "disabled";
};
+ gpu: gpu@ff40 {
+ compatible = "rockchip,px30-mali", "arm,mali-bifrost";
+ reg = <0x0 0xff40 0x0 0x4000>;
+ interrupts = ,
+,
+;
+ interrupt-names = "gpu", "mmu", "job";
+ clocks = <&cru SCLK_GPU>;
+ clock-names = "clk_mali";
+ power-domains = <&power PX30_PD_GPU>;
+ status = "disabled";
+ };
+
vopb: vop@ff46 {
compatible = "rockchip,px30-vop-big";
reg = <0x0 0xff46 0x0 0xefc>;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 5/5] soc / drm: mediatek: Fix mediatek-drm device probing
In the actual implementation the same compatible string
"mediatek,-mmsys" is used to bind the clock drivers
(drivers/soc/mediatek) as well as to the gpu driver
(drivers/gpu/drm/mediatek/mtk_drm_drv.c). This ends with the problem
that the only probed driver is the clock driver and there is no display
at all.
In any case having the same compatible string for two drivers is not
correct and should be fixed. To fix this, and maintain backward
compatibility, we can consider that the mmsys driver is the top-level
entry point for the multimedia subsystem, so is not a pure clock
controller but a system controller, and the drm driver is instantiated
by that MMSYS driver.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: CK Hu
---
Changes in v11: None
Changes in v10:
- Match driver data to get display routing.
Changes in v9:
- Do not move the display routing from the drm driver (CK)
Changes in v8:
- New patch introduced in this series.
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 31 --
drivers/soc/mediatek/mtk-mmsys.c | 6 +
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 208f9c5256ef..bb26e346750a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -422,9 +422,21 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static const struct of_device_id mtk_drm_of_ids[] = {
+ { .compatible = "mediatek,mt2701-mmsys",
+ .data = &mt2701_mmsys_driver_data},
+ { .compatible = "mediatek,mt2712-mmsys",
+ .data = &mt2712_mmsys_driver_data},
+ { .compatible = "mediatek,mt8173-mmsys",
+ .data = &mt8173_mmsys_driver_data},
+ { }
+};
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ struct device_node *phandle = dev->parent->of_node;
+ const struct of_device_id *of_id;
struct mtk_drm_private *private;
struct device_node *node;
struct component_match *match = NULL;
@@ -442,8 +454,14 @@ static int mtk_drm_probe(struct platform_device *pdev)
return -ENODEV;
}
+ of_id = of_match_node(mtk_drm_of_ids, phandle);
+ if (!of_id)
+ return -ENODEV;
+
+ private->data = of_id->data;
+
/* Iterate over sibling DISP function blocks */
- for_each_child_of_node(dev->of_node->parent, node) {
+ for_each_child_of_node(phandle->parent, node) {
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -575,22 +593,11 @@ static int mtk_drm_sys_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
mtk_drm_sys_resume);
-static const struct of_device_id mtk_drm_of_ids[] = {
- { .compatible = "mediatek,mt2701-mmsys",
- .data = &mt2701_mmsys_driver_data},
- { .compatible = "mediatek,mt2712-mmsys",
- .data = &mt2712_mmsys_driver_data},
- { .compatible = "mediatek,mt8173-mmsys",
- .data = &mt8173_mmsys_driver_data},
- { }
-};
-
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
.remove = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
- .of_match_table = mtk_drm_of_ids,
.pm = &mtk_drm_pm_ops,
},
};
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index bb99a05fb278..090dbab41160 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -379,6 +379,7 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
const struct mtk_mmsys_driver_data *data;
struct clk_onecell_data *clk_data;
struct device *dev = &pdev->dev;
+ struct platform_device *drm;
void __iomem *config_regs;
struct resource *mem;
int ret;
@@ -409,6 +410,11 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
if (ret)
return ret;
+ drm = platform_device_register_data(&pdev->dev, "mediatek-drm",
+ PLATFORM_DEVID_NONE, NULL, 0);
+ if (IS_ERR(drm))
+ return PTR_ERR(drm);
+
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 2/5] dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller
The mmsys system controller is not only a pure clock controller, so
update the binding documentation to reflect that apart from providing
clocks, it also provides routing and miscellaneous control registers.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
Reviewed-by: CK Hu
---
Changes in v11: None
Changes in v10:
- Update the binding documentation for the mmsys system controller.
Changes in v9: None
Changes in v8: None
Changes in v7: None
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 301eefbe1618..8d6a9d98e7a6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -1,7 +1,8 @@
Mediatek mmsys controller
-The Mediatek mmsys controller provides various clocks to the system.
+The Mediatek mmsys system controller provides clock control, routing control,
+and miscellaneous control in mmsys partition.
Required Properties:
@@ -15,13 +16,13 @@ Required Properties:
- "mediatek,mt8183-mmsys", "syscon"
- #clock-cells: Must be 1
-The mmsys controller uses the common clk binding from
+For the clock control, the mmsys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
-mmsys: clock-controller@1400 {
+mmsys: syscon@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
#clock-cells = <1>;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/omap: Prepare DSS for probing without legacy platform data
* Tomi Valkeinen [200302 10:29]: > On 27/02/2020 19:44, Tony Lindgren wrote: > > > > > FWIW, I dropped omapdss-boot-init.c in my patch series updating DSI > > > > code to use common panel infrastructure, so this will conflict. > > > > > > Hey that's great :) Sounds like we can set up an immutable branch > > > for just this $subject patch against v5.6-rc1 to resolve the > > > conflict. I can set it up for Tomi or Tomi can set it up for me, > > > whichever Tomi prefers. > > > > Do you want me to send you a pull request for just this one patch > > against v5.6-rc1? > > It's probably easier if Sebastian drops the removal patch, and instead > creates a patch that removes the panel-dsi-cm from > omapdss_of_fixups_whitelist. That change should not conflict, and > effectively makes the omapdss-boot-init.c a no-op. > > We can then remove the file later. OK for resolving the merge commit that works too. Tomi, so do you care to ack the $subject patch though so I can set up an immutable branch for us for the $subject patch? Or Tomi, do you want to set up an immutable branch for me for the $subject patch? Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bochs: Remove vga write
On Fri, Feb 28, 2020 at 1:57 AM Gerd Hoffmann wrote:
>
> On Thu, Feb 27, 2020 at 01:04:54PM -0800, Alistair Francis wrote:
> > The QEMU model for the Bochs display has no VGA memory section at offset
> > 0x400 [1]. By writing to this register Linux can create a write to
> > unassigned memory which depending on machine and architecture can result
> > in a store fault.
> >
> > I don't see any reference to this address at OSDev [2] or in the Bochs
> > source code.
> >
> > Removing this write still allows graphics to work inside QEMU with
> > the bochs-display.
>
> It's not that simple. The driver also handles the qemu stdvga (-device
> VGA, -device secondary-vga) which *does* need the vga port write.
> There is no way for the guest to figure whenever the device is
> secondary-vga or bochs-display.
>
> So how about fixing things on the host side? Does qemu patch below
> help?
That patch looks like it will fix the problem, but it doesn't seem
like the correct fix. I would rather avoid adding a large chunk of
dummy I/O to handle the two devices.
>
> Maybe another possible approach is to enable/disable vga access per
> arch. On x86 this doesn't cause any problems. I guess you are on
> risc-v?
I would prefer this option. I do see this on RISC-V, but I suspect the
issue will appear on other architectures (although how they handle I/O
failures in QEMU is a different story).
Can I just do the VGA write if x86?
Alistair
>
> cheers,
> Gerd
>
> diff --git a/hw/display/bochs-display.c b/hw/display/bochs-display.c
> index 62085f9fc063..e93e838243b8 100644
> --- a/hw/display/bochs-display.c
> +++ b/hw/display/bochs-display.c
> @@ -151,6 +151,26 @@ static const MemoryRegionOps bochs_display_qext_ops = {
> .endianness = DEVICE_LITTLE_ENDIAN,
> };
>
> +static uint64_t dummy_read(void *ptr, hwaddr addr, unsigned size)
> +{
> +return -1;
> +}
> +
> +static void dummy_write(void *ptr, hwaddr addr,
> +uint64_t val, unsigned size)
> +{
> +}
> +
> +static const MemoryRegionOps dummy_ops = {
> +.read = dummy_read,
> +.write = dummy_write,
> +.valid.min_access_size = 1,
> +.valid.max_access_size = 4,
> +.impl.min_access_size = 1,
> +.impl.max_access_size = 1,
> +.endianness = DEVICE_LITTLE_ENDIAN,
> +};
> +
> static int bochs_display_get_mode(BochsDisplayState *s,
> BochsDisplayMode *mode)
> {
> @@ -284,8 +304,8 @@ static void bochs_display_realize(PCIDevice *dev, Error
> **errp)
> memory_region_init_io(&s->qext, obj, &bochs_display_qext_ops, s,
>"qemu extended regs", PCI_VGA_QEXT_SIZE);
>
> -memory_region_init(&s->mmio, obj, "bochs-display-mmio",
> - PCI_VGA_MMIO_SIZE);
> +memory_region_init_io(&s->mmio, obj, &dummy_ops, NULL,
> + "bochs-display-mmio", PCI_VGA_MMIO_SIZE);
> memory_region_add_subregion(&s->mmio, PCI_VGA_BOCHS_OFFSET, &s->vbe);
> memory_region_add_subregion(&s->mmio, PCI_VGA_QEXT_OFFSET, &s->qext);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 1/5] drm/mediatek: Omit warning on probe defers
From: Matthias Brugger
It can happen that the mmsys clock drivers aren't probed before the
platform driver gets invoked. The platform driver used to print a warning
that the driver failed to get the clocks. Omit this error on
the defered probe path.
Signed-off-by: Matthias Brugger
Reviewed-by: CK Hu
Signed-off-by: Enric Balletbo i Serra
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 -
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 -
drivers/gpu/drm/mediatek/mtk_dpi.c| 12 +---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 3 ++-
drivers/gpu/drm/mediatek/mtk_dsi.c| 8 ++--
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +++-
7 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 6fb0d6983a4a..3ae9c810845b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -119,7 +119,10 @@ static int mtk_disp_color_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_color_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 891d80c73e04..28651bc579bc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -386,7 +386,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_ovl_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0cb848d64206..e04319fedf46 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -294,7 +294,10 @@ static int mtk_disp_rdma_probe(struct platform_device
*pdev)
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_rdma_funcs);
if (ret) {
- dev_err(dev, "Failed to initialize component: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to initialize component: %d\n",
+ ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 01fa8b8d763d..1b219edef541 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -701,21 +701,27 @@ static int mtk_dpi_probe(struct platform_device *pdev)
dpi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dpi->engine_clk)) {
ret = PTR_ERR(dpi->engine_clk);
- dev_err(dev, "Failed to get engine clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get engine clock: %d\n", ret);
+
return ret;
}
dpi->pixel_clk = devm_clk_get(dev, "pixel");
if (IS_ERR(dpi->pixel_clk)) {
ret = PTR_ERR(dpi->pixel_clk);
- dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get pixel clock: %d\n", ret);
+
return ret;
}
dpi->tvd_clk = devm_clk_get(dev, "pll");
if (IS_ERR(dpi->tvd_clk)) {
ret = PTR_ERR(dpi->tvd_clk);
- dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get tvdpll clock: %d\n", ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 13035c906035..b885f60f474c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -628,7 +628,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
if (!ddp->data->no_clk) {
ddp->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddp->clk)) {
- dev_err(dev, "Failed to get clock\n");
+
[PATCH V1 2/2] backlight: qcom-wled: Add support for WLED5 peripheral in PM8150L
Add support for WLED5 peripheral that is present on PM8150L PMICs. PM8150L WLED supports the following. - Two modulators and each sink can use any of the modulator - Multiple CABC selection options - Multiple brightness width selection (12 bits to 15 bits) Signed-off-by: Kiran Gunda --- .../bindings/leds/backlight/qcom-wled.yaml | 39 ++ drivers/video/backlight/qcom-wled.c| 463 ++--- 2 files changed, 452 insertions(+), 50 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index d334f81..e0dadc4 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -20,6 +20,7 @@ properties: - qcom,pm8941-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm8150l-wled reg: maxItems: 1 @@ -28,10 +29,23 @@ properties: maxItems: 1 description: brightness value on boot, value from 0-4095. + For pm8150l this value vary from 0-4095 or 0-32767 + depending on the brightness control mode. If CABC is + enabled 0-4095 range is used. allOf: - $ref: /schemas/types.yaml#/definitions/uint32 default: 2048 + max-brightness: +maxItems: 1 +description: + Maximum brightness level. Allowed values are, + for pmi8998 it is 0-4095. + For pm8150l, this can be either 4095 or 32767. + If CABC is enabled, this is capped to 4095. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + label: maxItems: 1 description: @@ -124,6 +138,31 @@ properties: value for PM8941 from 1 to 3. Default 2 For PMI8998 from 1 to 4. + qcom,modulator-sel: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + Selects the modulator used for brightness modulation. + Allowed values are, + 0 - Modulator A + 1 - Modulator B + If not specified, then modulator A will be used by default. + This property is applicable only to WLED5 peripheral. + + qcom,cabc-sel: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + Selects the CABC pin signal used for brightness modulation. + Allowed values are, + 0 - CABC disabled + 1 - CABC 1 + 2 - CABC 2 + 3 - External signal (e.g. LPG) is used for dimming + This property is applicable only to WLED5 peripheral. + interrupts: maxItems: 2 description: diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index 3d276b3..ebec649 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -19,6 +19,8 @@ #define WLED_DEFAULT_BRIGHTNESS2048 #define WLED_SOFT_START_DLY_US 1 #define WLED3_SINK_REG_BRIGHT_MAX 0xFFF +#define WLED5_SINK_REG_BRIGHT_MAX_12B 0xFFF +#define WLED5_SINK_REG_BRIGHT_MAX_15B 0x7FFF /* WLED3/WLED4 control registers */ #define WLED3_CTRL_REG_FAULT_STATUS0x08 @@ -40,6 +42,7 @@ #define WLED3_CTRL_REG_OVP 0x4d #define WLED3_CTRL_REG_OVP_MASK GENMASK(1, 0) +#define WLED5_CTRL_REG_OVP_MASK GENMASK(3, 0) #define WLED3_CTRL_REG_ILIMIT 0x4e #define WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0) @@ -101,6 +104,40 @@ #define WLED4_SINK_REG_BRIGHT(n) (0x57 + (n * 0x10)) +/* WLED5 specific sink registers */ +#define WLED5_SINK_REG_MOD_A_EN0x50 +#define WLED5_SINK_REG_MOD_B_EN0x60 +#define WLED5_SINK_REG_MOD_EN_MASKBIT(7) + +#define WLED5_SINK_REG_MOD_A_SRC_SEL 0x51 +#define WLED5_SINK_REG_MOD_B_SRC_SEL 0x61 +#define WLED5_SINK_REG_MOD_SRC_SEL_HIGH 0 +#define WLED5_SINK_REG_MOD_SRC_SEL_EXT0x03 +#define WLED5_SINK_REG_MOD_SRC_SEL_MASK GENMASK(1, 0) + +#define WLED5_SINK_REG_MOD_A_BRIGHTNESS_WIDTH_SEL 0x52 +#define WLED5_SINK_REG_MOD_B_BRIGHTNESS_WIDTH_SEL 0x62 +#define WLED5_SINK_REG_BRIGHTNESS_WIDTH_12B 0 +#define WLED5_SINK_REG_BRIGHTNESS_WIDTH_15B 1 + +#define WLED5_SINK_REG_MOD_A_BRIGHTNESS_LSB0x53 +#define WLED5_SINK_REG_MOD_A_BRIGHTNESS_MSB0x54 +#define WLED5_SINK_REG_MOD_B_BRIGHTNESS_LSB0x63 +#define WLED5_SINK_REG_MOD_B_BRIGHTNESS_MSB0x64 + +#define WLED5_SINK_REG_MOD_SYNC_BIT0x65 +#define WLED5_SINK_REG_SYNC_MOD_A_BIT BIT(0) +#define WLED5_SINK_REG_SYNC_M
[PATCH v11 3/5] soc: mediatek: Move mt8173 MMSYS to platform driver
From: Matthias Brugger
There is no strong reason for this to use CLK_OF_DECLARE instead of
being a platform driver. Plus, this driver provides clocks but also
a shared register space for the mediatek-drm and the mediatek-mdp
driver. So move to drivers/soc/mediatek as a platform driver.
Signed-off-by: Matthias Brugger
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: CK Hu
---
Changes in v11: None
Changes in v10:
- Renamed to be generic mtk-mmsys
- Add driver data support to be able to support diferent SoCs
Changes in v9:
- Move mmsys to drivers/soc/mediatek (CK)
Changes in v8:
- Be a builtin_platform_driver like other mediatek mmsys drivers.
Changes in v7:
- Free clk_data->clks as well
- Get rid of private data structure
drivers/clk/mediatek/clk-mt8173.c | 104
drivers/soc/mediatek/Kconfig | 7 ++
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-mmsys.c | 154 ++
4 files changed, 162 insertions(+), 104 deletions(-)
create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 537a7f49b0f7..8f898ac476c0 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -753,93 +753,6 @@ static const struct mtk_gate img_clks[] __initconst = {
GATE_IMG(CLK_IMG_FD, "img_fd", "mm_sel", 11),
};
-static const struct mtk_gate_regs mm0_cg_regs __initconst = {
- .set_ofs = 0x0104,
- .clr_ofs = 0x0108,
- .sta_ofs = 0x0100,
-};
-
-static const struct mtk_gate_regs mm1_cg_regs __initconst = {
- .set_ofs = 0x0114,
- .clr_ofs = 0x0118,
- .sta_ofs = 0x0110,
-};
-
-#define GATE_MM0(_id, _name, _parent, _shift) {\
- .id = _id, \
- .name = _name, \
- .parent_name = _parent, \
- .regs = &mm0_cg_regs, \
- .shift = _shift,\
- .ops = &mtk_clk_gate_ops_setclr,\
- }
-
-#define GATE_MM1(_id, _name, _parent, _shift) {\
- .id = _id, \
- .name = _name, \
- .parent_name = _parent, \
- .regs = &mm1_cg_regs, \
- .shift = _shift,\
- .ops = &mtk_clk_gate_ops_setclr,\
- }
-
-static const struct mtk_gate mm_clks[] __initconst = {
- /* MM0 */
- GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
- GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
- GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
- GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
- GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
- GATE_MM0(CLK_MM_MDP_RSZ0, "mm_mdp_rsz0", "mm_sel", 5),
- GATE_MM0(CLK_MM_MDP_RSZ1, "mm_mdp_rsz1", "mm_sel", 6),
- GATE_MM0(CLK_MM_MDP_RSZ2, "mm_mdp_rsz2", "mm_sel", 7),
- GATE_MM0(CLK_MM_MDP_TDSHP0, "mm_mdp_tdshp0", "mm_sel", 8),
- GATE_MM0(CLK_MM_MDP_TDSHP1, "mm_mdp_tdshp1", "mm_sel", 9),
- GATE_MM0(CLK_MM_MDP_WDMA, "mm_mdp_wdma", "mm_sel", 11),
- GATE_MM0(CLK_MM_MDP_WROT0, "mm_mdp_wrot0", "mm_sel", 12),
- GATE_MM0(CLK_MM_MDP_WROT1, "mm_mdp_wrot1", "mm_sel", 13),
- GATE_MM0(CLK_MM_FAKE_ENG, "mm_fake_eng", "mm_sel", 14),
- GATE_MM0(CLK_MM_MUTEX_32K, "mm_mutex_32k", "rtc_sel", 15),
- GATE_MM0(CLK_MM_DISP_OVL0, "mm_disp_ovl0", "mm_sel", 16),
- GATE_MM0(CLK_MM_DISP_OVL1, "mm_disp_ovl1", "mm_sel", 17),
- GATE_MM0(CLK_MM_DISP_RDMA0, "mm_disp_rdma0", "mm_sel", 18),
- GATE_MM0(CLK_MM_DISP_RDMA1, "mm_disp_rdma1", "mm_sel", 19),
- GATE_MM0(CLK_MM_DISP_RDMA2, "mm_disp_rdma2", "mm_sel", 20),
- GATE_MM0(CLK_MM_DISP_WDMA0, "mm_disp_wdma0", "mm_sel", 21),
- GATE_MM0(CLK_MM_DISP_WDMA1, "mm_disp_wdma1", "mm_sel", 22),
- GATE_MM0(CLK_MM_DISP_COLOR0, "mm_disp_color0", "mm_sel", 23),
- GATE_MM0(CLK_MM_DISP_COLOR1, "mm_disp_color1", "mm_sel", 24),
- GATE_MM0(CLK_MM_DISP_AAL, "mm_disp_aal", "mm_sel", 25),
- GATE_MM0(CLK_MM_DISP_GAMMA, "mm_disp_gamma", "mm_sel", 26),
- GATE_MM0(CLK_MM_DISP_UFOE, "mm_disp_ufoe", "mm_sel", 27),
- GATE_MM0(CLK_MM_DISP_SPLIT0, "mm_disp_split0", "mm_sel", 28),
- GATE_MM0(CLK_MM_DISP_SPLIT1, "mm_disp_split1", "mm_sel", 29),
- GATE_MM0(CLK_MM_DISP_MERGE, "mm_disp_merge", "mm_sel", 30),
- GATE_MM0(CLK_MM_DISP_OD, "mm_disp_od", "mm_sel", 31),
- /* MM1 */
- GATE_MM1(CLK_MM_DISP_PWM0MM, "mm_disp_pwm0mm", "mm_sel", 0),
- GATE_MM1(CLK_MM_DISP_PWM026M, "mm_disp_pwm026m", "pwm_sel", 1),
- GATE_MM1(CLK_MM_DISP_PWM1MM,
[PATCH v4 3/4] drm/sun4i: Add support for premulti/coverage blending mode handling
Argument:
All information below is author's understanding of underlying processes.
This information was obtained from DE2.0-3.0 datasheet analysis and
analysis of different DRM driver source code and commit messages.
Input buffers could have 2 ways of holding pixel alpha channel value.
1. Coverage means that in case of transparency - only alpha channel changes.
Example of 50% transparent white pixel: R=0xff B=0xff B=0xff A=0x7f
2. Premultiply means that RGB pixel values should be dimmed proportional to
alpha channel value. Alpha channel value has also to be set in this case.
Example of 50% transparent white pixel: R=0x7f B=0x7f B=0x7f A=0x7f
Userspace informs DRM/KMS which blending type frame buffer uses with
'pixel blend mode' property.
Allwinner DE2.0 and DE3.0 have 2 block of image processing:
Overlay and Blending. Both should aware of blending type are used in the buffer.
Overlay block uses this information to:
1. Unify blending types if more then 1 overlay channel are used. It can unify it
only as premultiplied by converting coverage to premultiplied.
2. Calculate correct pixel value in case of applying plane alpha.
For coverage alpha only alpha channel should be affected:
[Ro=Ri, Go=Gi, Bo=Bi, Ao=Ai*AGlobal]
For premultiplied alpha all 4 channels should be affected:
[Ro=Ri*AGlobal, Go=Gi*AGlobal, Bo=Bi*AGlobal, Ao=Ai*AGlobal]
Blending functional block should aware of blending type each pipe
channel uses. Otherwise image can't blend correctly.
In case we've specified premultiplied format for blending PIPE0, blender
converts premultiplied RGB values to original (divides by normalized Alpha).
In case for some reason pixel value after division exceeds 0xff, blender clamps
it to 0xff. [Was discovered in experimental way]
If image that passed through PIPE1-3 restored to coverage before mixing or used
in premultiplied form still require testing and out of scope of this patch.
Implementation:
1. Add blend property to UI channel
2. Add blend property to VI channel in case of DE3.0 used
3. Make all DE2.0 UI and DE3.0 VI overlay channels to use premultiply format.
Mark all blending pipes as premultiply except DE2.0 VI plane.
4. If DRM plane uses coverage blending format, set blending mode register
to convert it to premultiply.
Signed-off-by: Roman Stratiienko
--
v4:
- Initial version (Depends on unmerged patches from patchset)
---
drivers/gpu/drm/sun4i/sun8i_mixer.h| 2 ++
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 33 ++-
drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 5
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 36 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 5
5 files changed, 69 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 915479cc3077..8a18372938d5 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -70,6 +70,8 @@
#define SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(n)(0xf << ((n) << 2))
#define SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(n) ((n) << 2)
+#define SUN8I_MIXER_BLEND_PREMULTIPLY_EN(pipe) BIT(pipe)
+
#define SUN8I_MIXER_BLEND_OUTCTL_INTERLACEDBIT(1)
#define SUN50I_MIXER_BLEND_CSC_CTL_EN(ch) BIT(ch)
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index 5278032567a3..dd6145f80c36 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -73,10 +73,12 @@ 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)
+ int overlay, struct drm_plane *plane,
+ unsigned int zpos)
{
- u32 mask, val, ch_base;
+ u32 mask, val, ch_base, bld_base;
+ bld_base = sun8i_blender_base(mixer);
ch_base = sun8i_channel_base(mixer, channel);
mask = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK |
@@ -84,13 +86,27 @@ static void sun8i_ui_layer_update_alpha(struct sun8i_mixer
*mixer, int channel,
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;
+ if (plane->state->pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE) {
+ val |= SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_LAYER;
+ } else {
+ 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;
+
+ if (plane->state->pixel_blend_mode == DRM_MODE_BLEND_COVE
[PATCH v2 2/4] drm/prime: add support for virtio exported objects
This change exposes dma-buf's get_uuid callback to PRIME drivers.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_prime.c | 27 +++
include/drm/drm_drv.h | 15 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 86d9b0e45c8c..fc6e932a4fa6 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -779,6 +779,30 @@ int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct
vm_area_struct *vma)
}
EXPORT_SYMBOL(drm_gem_dmabuf_mmap);
+#ifdef CONFIG_VIRTIO
+/**
+ * drm_gem_dmabuf_get_uuid - dma_buf get_uuid implementation for GEM
+ * @dma_buf: buffer to query
+ * @uuid: uuid outparam
+ *
+ * Queries the buffer's virtio UUID. This can be used as the
+ * &dma_buf_ops.get_uuid callback. Calls into &drm_driver.gem_prime_get_uuid.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_gem_dmabuf_get_uuid(struct dma_buf *dma_buf, uuid_t *uuid)
+{
+ struct drm_gem_object *obj = dma_buf->priv;
+ struct drm_device *dev = obj->dev;
+
+ if (!dev->driver->gem_prime_get_uuid)
+ return -ENODEV;
+
+ return dev->driver->gem_prime_get_uuid(obj, uuid);
+}
+EXPORT_SYMBOL(drm_gem_dmabuf_get_uuid);
+#endif
+
static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = {
.cache_sgt_mapping = true,
.attach = drm_gem_map_attach,
@@ -789,6 +813,9 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
+#ifdef CONFIG_VIRTIO
+ .get_uuid = drm_gem_dmabuf_get_uuid,
+#endif
};
/**
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 77685ed7aa65..3cbe9aa6b44a 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -32,6 +32,10 @@
#include
+#ifdef CONFIG_VIRTIO
+#include
+#endif
+
struct drm_file;
struct drm_gem_object;
struct drm_master;
@@ -639,6 +643,17 @@ struct drm_driver {
int (*gem_prime_mmap)(struct drm_gem_object *obj,
struct vm_area_struct *vma);
+#ifdef CONFIG_VIRTIO
+ /**
+* @gem_prime_get_uuid
+*
+* get_uuid hook for GEM drivers. Retrieves the virtio uuid of the
+* given GEM buffer.
+*/
+ int (*gem_prime_get_uuid)(struct drm_gem_object *obj,
+ uuid_t *uuid);
+#endif
+
/**
* @dumb_create:
*
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING in idr_destroy
Hello, syzbot found the following crash on: HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10e978e3e0 kernel config: https://syzkaller.appspot.com/x/.config?x=5d2e033af114153f dashboard link: https://syzkaller.appspot.com/bug?extid=05835159fe322770fe3d compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14e978e3e0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10b1a819e0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+05835159fe322770f...@syzkaller.appspotmail.com R10: R11: 0246 R12: 006dbc2c R13: 7fc6b3362d90 R14: 0004 R15: 002d [ cut here ] WARNING: CPU: 0 PID: 12260 at lib/radix-tree.c:682 radix_tree_free_nodes lib/radix-tree.c:682 [inline] WARNING: CPU: 0 PID: 12260 at lib/radix-tree.c:682 idr_destroy+0x1ae/0x260 lib/radix-tree.c:1572 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 12260 Comm: syz-executor386 Not tainted 5.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fb/0x318 lib/dump_stack.c:118 panic+0x264/0x7a9 kernel/panic.c:221 __warn+0x209/0x210 kernel/panic.c:582 report_bug+0x1b6/0x2f0 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0xcf/0x1c0 arch/x86/kernel/traps.c:267 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:radix_tree_free_nodes lib/radix-tree.c:682 [inline] RIP: 0010:idr_destroy+0x1ae/0x260 lib/radix-tree.c:1572 Code: b5 63 f9 48 89 df 48 c7 c6 c0 0a 13 88 e8 6a ce 50 f9 4c 3b 65 b8 74 57 e8 cf b5 63 f9 4d 89 fc e9 67 ff ff ff e8 c2 b5 63 f9 <0f> 0b eb d5 89 f9 80 e1 07 38 c1 7c 84 e8 c0 de a0 f9 e9 7a ff ff RSP: 0018:c90005107ba0 EFLAGS: 00010293 RAX: 881363be RBX: 888087dba998 RCX: 888094062300 RDX: RSI: 0040 RDI: 888087dba988 RBP: c90005107be8 R08: 88136330 R09: ed1012a78181 R10: ed1012a78181 R11: R12: 888087dba980 R13: R14: dc00 R15: drm_mode_create_lease_ioctl+0x1347/0x1860 drivers/gpu/drm/drm_lease.c:583 drm_ioctl_kernel+0x2cf/0x410 drivers/gpu/drm/drm_ioctl.c:786 drm_ioctl+0x52f/0x890 drivers/gpu/drm/drm_ioctl.c:886 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl fs/ioctl.c:763 [inline] __do_sys_ioctl fs/ioctl.c:772 [inline] __se_sys_ioctl+0x113/0x190 fs/ioctl.c:770 __x64_sys_ioctl+0x7b/0x90 fs/ioctl.c:770 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x44a4b9 Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 9b cc fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fc6b3362d88 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 006dbc28 RCX: 0044a4b9 RDX: 2040 RSI: ffc6 RDI: 0003 RBP: 006dbc20 R08: 0001 R09: 0039 R10: R11: 0246 R12: 006dbc2c R13: 7fc6b3362d90 R14: 0004 R15: 002d Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/virtio: Support virtgpu exported resources
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
drivers/gpu/drm/virtio/virtgpu_drv.h | 19
drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++
drivers/gpu/drm/virtio/virtgpu_prime.c | 48 ++--
drivers/gpu/drm/virtio/virtgpu_vq.c| 62 ++
5 files changed, 133 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index ab4bed78e656..776e6667042e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -165,6 +165,7 @@ static unsigned int features[] = {
VIRTIO_GPU_F_VIRGL,
#endif
VIRTIO_GPU_F_EDID,
+ VIRTIO_GPU_F_RESOURCE_UUID,
};
static struct virtio_driver virtio_gpu_driver = {
.feature_table = features,
@@ -202,7 +203,9 @@ static struct drm_driver driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_mmap = drm_gem_prime_mmap,
+ .gem_prime_export = virtgpu_gem_prime_export,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
+ .gem_prime_get_uuid = virtgpu_gem_prime_get_uuid,
.gem_create_object = virtio_gpu_create_object,
.fops = &virtio_gpu_driver_fops,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index af9403e1cf78..4be84de73d86 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -49,6 +49,11 @@
#define DRIVER_MINOR 1
#define DRIVER_PATCHLEVEL 0
+#define UUID_NOT_INITIALIZED 0
+#define UUID_INITIALIZING 1
+#define UUID_INITIALIZED 2
+#define UUID_INITIALIZATION_FAILED 3
+
struct virtio_gpu_object_params {
uint32_t format;
uint32_t width;
@@ -75,6 +80,9 @@ struct virtio_gpu_object {
bool dumb;
bool created;
+
+ int uuid_state;
+ uuid_t uuid;
};
#define gem_to_virtio_gpu_obj(gobj) \
container_of((gobj), struct virtio_gpu_object, base.base)
@@ -196,6 +204,7 @@ struct virtio_gpu_device {
bool has_virgl_3d;
bool has_edid;
bool has_indirect;
+ bool has_resource_assign_uuid;
struct work_struct config_changed_work;
@@ -206,6 +215,8 @@ struct virtio_gpu_device {
struct virtio_gpu_drv_capset *capsets;
uint32_t num_capsets;
struct list_head cap_cache;
+
+ spinlock_t resource_export_lock;
};
struct virtio_gpu_fpriv {
@@ -338,6 +349,10 @@ void virtio_gpu_dequeue_fence_func(struct work_struct
*work);
void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev);
void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev);
+int
+virtio_gpu_cmd_resource_assign_uuid(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo);
+
/* virtio_gpu_display.c */
void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
@@ -366,6 +381,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_object **bo_ptr,
struct virtio_gpu_fence *fence);
/* virtgpu_prime.c */
+struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj,
+int flags);
+int virtgpu_gem_prime_get_uuid(struct drm_gem_object *obj,
+ uuid_t *uuid);
struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
struct sg_table *sgt);
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 4009c2f97d08..5a2aeb6d2f35 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -134,6 +134,7 @@ int virtio_gpu_init(struct drm_device *dev)
vgdev->dev = dev->dev;
spin_lock_init(&vgdev->display_info_lock);
+ spin_lock_init(&vgdev->resource_export_lock);
ida_init(&vgdev->ctx_id_ida);
ida_init(&vgdev->resource_ida);
init_waitqueue_head(&vgdev->resp_wq);
@@ -162,6 +163,9 @@ int virtio_gpu_init(struct drm_device *dev)
if (virtio_has_feature(vgdev->vdev, VIRTIO_RING_F_INDIRECT_DESC)) {
vgdev->has_indirect = true;
}
+ if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
+ vgdev->has_resource_assign_uuid = true;
+ }
DRM_INFO("features: %cvirgl %cedid\n",
vgdev->has_virgl_3d ? '+' : '-',
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 050d24c39a8f..12ceda34b4f9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu
Re: [PATCH 2/4] drm/bridge: dw-hdmi: Fix color space conversion detection
Dne ponedeljek, 02. marec 2020 ob 10:26:09 CET je Neil Armstrong napisal(a):
> Hi Jernej,
>
> On 29/02/2020 17:30, Jernej Skrabec wrote:
> > Currently, is_color_space_conversion() compares not only color spaces
> > but also formats. For example, function would return true if YCbCr 4:4:4
> > and YCbCr 4:2:2 would be set. Obviously in that case color spaces are
> > the same.
> >
> > Fix that by comparing if both values represent RGB color space.
> >
> > Fixes: b21f4b658df8 ("drm: imx: imx-hdmi: move imx-hdmi to
> > bridge/dw_hdmi")
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 24965e53d351..9d7bfb1cb213 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -956,7 +956,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
> >
> > static int is_color_space_conversion(struct dw_hdmi *hdmi)
> > {
> >
> > - return hdmi->hdmi_data.enc_in_bus_format !=
> > hdmi->hdmi_data.enc_out_bus_format; + return
> > hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format) !=
> > + hdmi_bus_fmt_is_rgb(hdmi-
>hdmi_data.enc_out_bus_format);
> >
> > }
> >
> > static int is_color_space_decimation(struct dw_hdmi *hdmi)
>
> I think in this case you should also fix the CEC enablement to:
> if (is_color_space_conversion(hdmi) || is_color_space_decimation(hdmi))
>
> in dw_hdmi_enable_video_path() otherwise CSC won't be enabled and will be
> bypassed in decimation case only.
On second thought, I think original implementation is correct, just misnamed.
Laurent, Neil, do you agree if I replace this patch with patch which renames
is_color_space_conversion() to is_conversion_needed() ?
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V1 0/2] Add support for WLED5
Currently, WLED driver supports only WLED4 peripherals that is present on pmi8998 and pm660L. This patch series converts the existing WLED4 bindings from .txt to .yaml format and adds the support for WLED5 peripheral that is present on PM8150L. PM8150L WLED supports the following. - Two modulators and each sink can use any of the modulator - Multiple CABC selection options - Multiple brightness width selection (12 bits to 15 bits) Kiran Gunda (2): backlight: qcom-wled: convert the wled bindings to .yaml format backlight: qcom-wled: Add support for WLED5 peripheral in PM8150L .../bindings/leds/backlight/qcom-wled.txt | 154 --- .../bindings/leds/backlight/qcom-wled.yaml | 223 ++ drivers/video/backlight/qcom-wled.c| 463 ++--- 3 files changed, 636 insertions(+), 204 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 3/8] drm: ingenic-drm: add MODULE_DEVICE_TABLE
Hi Nikolaus,
Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller
a écrit :
so that the driver can load by matching the device tree
if compiled as module.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 6d47ef7b148c..d8617096dd8e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -844,6 +844,8 @@ static const struct of_device_id
ingenic_drm_of_match[] = {
{ /* sentinel */ },
};
+MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
Please remove the blank line above the MODULE_DEVICE_TABLE() macro.
-Paul
+
static struct platform_driver ingenic_drm_driver = {
.driver = {
.name = "ingenic-drm",
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2 v2] drm/vmwgfx: Remove a few unused functions
I noticed that there is a prototype for vmw_fifo_ping_host_locked() but
no function. Then I looked further and noticed more functions which are
not used anymore or functions protoypes which remained after the
function was removed.
Remove unused function (prototypes).
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2: Also remove the "VGA registers." in struct vmw_private as per
Emil Velikov. It it is unused since commit a278724aa23c
("drm/vmwgfx: Implement fbdev on kms v2").
On 2020-02-28 11:42:46 [+], Emil Velikov wrote:
> Hi Sebastian,
Hi Emil,
> Seems like the last user was removed in 2015 with commit a278724aa23c
> ("drm/vmwgfx: Implement fbdev on kms v2").
>
> With this patch, the section of "VGA registers" in struct vmw_private
> becomes dead code.
> IMHO it would make sense to also remove those with this patch.
Okay, thanks, removed.
> HTH
> Emil
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 28 -
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 81 -
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 31 --
3 files changed, 140 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 86b69397d166e..5c8d643d99c0f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -479,19 +479,6 @@ struct vmw_private {
bool assume_16bpp;
bool has_sm4_1;
- /*
-* VGA registers.
-*/
-
- struct vmw_vga_topology_state vga_save[VMWGFX_MAX_DISPLAYS];
- uint32_t vga_width;
- uint32_t vga_height;
- uint32_t vga_bpp;
- uint32_t vga_bpl;
- uint32_t vga_pitchlock;
-
- uint32_t num_displays;
-
/*
* Framebuffer info.
*/
@@ -900,7 +887,6 @@ extern void vmw_fifo_commit(struct vmw_private *dev_priv,
uint32_t bytes);
extern void vmw_fifo_commit_flush(struct vmw_private *dev_priv, uint32_t
bytes);
extern int vmw_fifo_send_fence(struct vmw_private *dev_priv,
uint32_t *seqno);
-extern void vmw_fifo_ping_host_locked(struct vmw_private *, uint32_t reason);
extern void vmw_fifo_ping_host(struct vmw_private *dev_priv, uint32_t reason);
extern bool vmw_fifo_have_3d(struct vmw_private *dev_priv);
extern bool vmw_fifo_have_pitchlock(struct vmw_private *dev_priv);
@@ -947,7 +933,6 @@ extern struct ttm_placement vmw_mob_placement;
extern struct ttm_placement vmw_mob_ne_placement;
extern struct ttm_placement vmw_nonfixed_placement;
extern struct ttm_bo_driver vmw_bo_driver;
-extern int vmw_dma_quiescent(struct drm_device *dev);
extern int vmw_bo_map_dma(struct ttm_buffer_object *bo);
extern void vmw_bo_unmap_dma(struct ttm_buffer_object *bo);
extern const struct vmw_sg_table *
@@ -1085,8 +1070,6 @@ int vmw_fb_on(struct vmw_private *vmw_priv);
int vmw_kms_init(struct vmw_private *dev_priv);
int vmw_kms_close(struct vmw_private *dev_priv);
-int vmw_kms_save_vga(struct vmw_private *vmw_priv);
-int vmw_kms_restore_vga(struct vmw_private *vmw_priv);
int vmw_kms_cursor_bypass_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
void vmw_kms_cursor_post_execbuf(struct vmw_private *dev_priv);
@@ -1139,7 +1122,6 @@ int vmw_overlay_init(struct vmw_private *dev_priv);
int vmw_overlay_close(struct vmw_private *dev_priv);
int vmw_overlay_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-int vmw_overlay_stop_all(struct vmw_private *dev_priv);
int vmw_overlay_resume_all(struct vmw_private *dev_priv);
int vmw_overlay_pause_all(struct vmw_private *dev_priv);
int vmw_overlay_claim(struct vmw_private *dev_priv, uint32_t *out);
@@ -1186,10 +1168,6 @@ extern void vmw_otables_takedown(struct vmw_private
*dev_priv);
extern const struct vmw_user_resource_conv *user_context_converter;
-extern int vmw_context_check(struct vmw_private *dev_priv,
-struct ttm_object_file *tfile,
-int id,
-struct vmw_resource **p_res);
extern int vmw_context_define_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int vmw_extended_context_define_ioctl(struct drm_device *dev, void
*data,
@@ -1219,7 +1197,6 @@ vmw_context_get_dx_query_mob(struct vmw_resource
*ctx_res);
extern const struct vmw_user_resource_conv *user_surface_converter;
-extern void vmw_surface_res_free(struct vmw_resource *res);
extern int vmw_surface_destroy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int vmw_surface_define_ioctl(struct drm_device *dev, void *data,
@@ -1230,11 +1207,6 @@ extern int vmw_gb_surface_define_ioctl(struct drm_device
*dev, void *data,
struct drm_file *file_priv);
extern int vmw_gb_surface_reference_ioctl(struct drm_device *dev, vo
Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
Hi,
This is a command mode panel and the the msm/mdp5 driver uses the
vrefresh field for the actual refresh rate, while the dotclock field is
used for the DSI clocks. The dotclock needed to be a bit higher than
necessary otherwise the panel would not work.
If you want to get rid of the separate clock/vrefresh fields there would
need to be some changes to msm driver.
(note I hadn't made the patch with upstreaming in mind, the 15 value
is likely not optimal, just something that worked, this is something
that should have been checked with the downstream driver)
-Jonathan
On 3/2/20 3:34 PM, Ville Syrjala wrote:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Jonathan Marek
Cc: Brian Masney
Cc: Linus Walleij
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index b24fdf239440..f958d8dfd760 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00
= {
};
static const struct drm_display_mode lg_acx467akm_7_mode = {
- .clock = 15,
+ .clock = 125498,
.hdisplay = 1080,
.hsync_start = 1080 + 2,
.hsync_end = 1080 + 2 + 2,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 6/8] MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller
Hi Paul,
> Am 02.03.2020 um 20:27 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
>
> Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller a
> écrit :
>> From: Paul Boddie
>> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
>> HDMI support. This requires a new driver, plus device tree and configuration
>> modifications.
>> Signed-off-by: Paul Boddie
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> arch/mips/boot/dts/ingenic/jz4780.dtsi | 32 ++
>> 1 file changed, 32 insertions(+)
>> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> index f928329b034b..391d4e1efd35 100644
>> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> @@ -433,4 +433,36 @@
>> status = "disabled";
>> };
>> +
>> +hdmi: hdmi@1018 {
>> +compatible = "ingenic,jz4780-dw-hdmi";
>> +reg = <0x1018 0x8000>;
>> +reg-io-width = <4>;
>> +
>> +clocks = <&cgu JZ4780_CLK_HDMI>, <&cgu JZ4780_CLK_AHB0>;
>> +clock-names = "isfr" , "iahb";
>> +
>> +assigned-clocks = <&cgu JZ4780_CLK_HDMI>;
>> +assigned-clock-rates = <2700>;
>
> I *think* this should go to the board file.
Hm. I am not sure.
Can there be differences in HDMI between different boards so
that it needs to be defined there?
IMHO the HDMI subsystem is completely sitting on the jz4780 SoC
and clocked by the master clock. So boards should only differ in the
ESD protection and mechanical connector...
And status = "ok".
>
>> +
>> +interrupt-parent = <&intc>;
>> +interrupts = <3>;
>> +
>> +/* ddc-i2c-bus = <&i2c4>; */
>> +
>> +status = "disabled";
>> +};
>> +
>> +lcd: lcd@1305 {
>
> The node name should be 'lcd-controller'.
>
>> +compatible = "ingenic,jz4740-lcd";
>
> The JZ4780's LCD controller is much newer than the JZ4740 one, so even if it
> works with the "ingenic,jz4740-lcd" compatible string, you want it as a
> fallback.
> So this should be: compatible = "ingenic,jz4780-lcd", "ingenic,jz4740-lcd".
Ah, that is an interesting detail.
It could be the reason why the HDMI does not show an output signal yet.
If the jz4740-lcd and jz4780-lcd are not really 100% compatible.
I'll give it try asap.
If it does not help to get output signals, we need community members who
can test (i.e. own an CI20 board) and can help to identify the bug(s).
>
> That means the YAML should be updated too.
Ok.
BR,
Nikolaus
>
> -Paul
>
>> +reg = <0x1305 0x1800>;
>> +
>> +clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
>> +clock-names = "lcd", "lcd_pclk";
>> +
>> +interrupt-parent = <&intc>;
>> +interrupts = <31>;
>> +
>> +status = "disabled";
>> +};
>> };
>> --
>> 2.23.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 3/8] drm: ingenic-drm: add MODULE_DEVICE_TABLE
> Am 02.03.2020 um 20:21 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
>
> Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller a
> écrit :
>> so that the driver can load by matching the device tree
>> if compiled as module.
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/ingenic/ingenic-drm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
>> b/drivers/gpu/drm/ingenic/ingenic-drm.c
>> index 6d47ef7b148c..d8617096dd8e 100644
>> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
>> @@ -844,6 +844,8 @@ static const struct of_device_id ingenic_drm_of_match[]
>> = {
>> { /* sentinel */ },
>> };
>> +MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
>
> Please remove the blank line above the MODULE_DEVICE_TABLE() macro.
Ok.
>
> -Paul
>
>> +
>> static struct platform_driver ingenic_drm_driver = {
>> .driver = {
>> .name = "ingenic-drm",
>> --
>> 2.23.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 2/8] dt-bindings: display: add ingenic-jz4780-hdmi DT Schema
> Am 02.03.2020 um 20:19 schrieb Paul Cercueil : > > Hi Nikolaus, > > > Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller a > écrit : >> From: Sam Ravnborg >> Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC. >> Based on .txt binding from Zubair Lutfullah Kakakhel >> Signed-off-by: Sam Ravnborg >> Cc: Zubair Lutfullah Kakakhel >> Cc: H. Nikolaus Schaller >> Cc: Rob Herring >> Cc: devicet...@vger.kernel.org >> --- >> .../bindings/display/ingenic-jz4780-hdmi.yaml | 83 +++ >> 1 file changed, 83 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml >> diff --git >> a/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml >> b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml >> new file mode 100644 >> index ..9b71c427bd69 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml >> @@ -0,0 +1,83 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/display/ingenic-jz4780-hdmi.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Bindings for Ingenic JZ4780 HDMI Transmitter >> + >> +maintainers: >> + - Zubair Lutfullah Kakakhel >> + - H. Nikolaus Schaller > > Did Zubair write this glue driver? He's been MIA for a while, doesn't work at > ImgTec anymore, and this email doesn't work. He did write the original .txt version of [RFC v1 2/8] and Sam simply added him. > >> + >> +description: | >> + The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI >> 1.4 >> + TX controller IP with accompanying PHY IP. >> + >> +allOf: >> + - $ref: panel/panel-common.yaml# >> + >> +properties: >> + compatible: >> +items: >> + - const: ingenic,jz4780-hdmi >> + >> + reg: >> +maxItems: 1 >> +description: the address & size of the LCD controller registers > > Remove the description here, > >> + >> + reg-io-width: >> +const: 4 >> + >> + interrupts: >> +maxItems: 1 >> +description: Specifies the interrupt provided by parent > > and here. > > The rule is that if there is only one "reg", "interrupts" or "clocks" entry > then a description is not needed as it's pretty obvious what it's for. > >> + >> + clocks: >> +maxItems: 2 >> +description: Clock specifiers for isrf and iahb clocks > > You need two 'description:' like this: > > clocks: > items: > - description: ISRF clock > - description: IAHB clock Ok. BR and thanks, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 2/8] dt-bindings: display: add ingenic-jz4780-hdmi DT Schema
Hi Nikolaus,
Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller
a écrit :
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Cc: Zubair Lutfullah Kakakhel
Cc: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../bindings/display/ingenic-jz4780-hdmi.yaml | 83
+++
1 file changed, 83 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
new file mode 100644
index ..9b71c427bd69
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic-jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+ - Zubair Lutfullah Kakakhel
+ - H. Nikolaus Schaller
Did Zubair write this glue driver? He's been MIA for a while, doesn't
work at ImgTec anymore, and this email doesn't work.
+
+description: |
+ The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys
DesignWare HDMI 1.4
+ TX controller IP with accompanying PHY IP.
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: ingenic,jz4780-hdmi
+
+ reg:
+maxItems: 1
+description: the address & size of the LCD controller registers
Remove the description here,
+
+ reg-io-width:
+const: 4
+
+ interrupts:
+maxItems: 1
+description: Specifies the interrupt provided by parent
and here.
The rule is that if there is only one "reg", "interrupts" or "clocks"
entry then a description is not needed as it's pretty obvious what it's
for.
+
+ clocks:
+maxItems: 2
+description: Clock specifiers for isrf and iahb clocks
You need two 'description:' like this:
clocks:
items:
- description: ISRF clock
- description: IAHB clock
Cheers,
-Paul
+
+ clock-names:
+items:
+ - const: isfr
+ - const: iahb
+
+ ddc-i2c-bus: true
+ ports: true
+
+required:
+- compatible
+- clocks
+- clock-names
+- ports
+- reg-io-width
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <&i2c4>;
+interrupt-parent = <&intc>;
+interrupts = <3>;
+clocks = <&cgu JZ4780_CLK_HDMI>, <&cgu JZ4780_CLK_AHB0>;
+clock-names = "isfr", "iahb";
+
+ports {
+hdmi_in: port {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in_lcd: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&jz4780_out_hdmi>;
+};
+};
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: gpu: mali-bifrost: Add Rockchip PX30 compatible
Rockchip PX30 SoCs feature a Bifrost Mali GPU. Signed-off-by: Miquel Raynal --- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 5f1fd6d7ee0f..283ee0c274d1 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable reg: -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [virtio-dev] [PATCH v2 4/4] drm/virtio: Support virtgpu exported resources
> cmd_p->hdr.ctx_id = > > Before this completion of this hypercall, this resource can be > considered context local, while afterward it can be considered > "exported". Maybe I'm misunderstanding render contexts, but exporting a resource doesn't seem related to render contexts. The other resource management operations (e.g. creation, attaching a backing) don't take render contexts, and exporting a resource seems like the same sort of operation. It's not clear to me why exporting a resource would affect what render contexts a resource has been attached to, nor why the render contexts a resource has been attached to would affect exporting the resource. Also, from an implementation perspective, I don't see any struct virtio_gpu_fpriv to get the ctx_id from. -David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
On 3/2/20 10:13 PM, Brian Masney wrote:
On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
Hi,
This is a command mode panel and the the msm/mdp5 driver uses the vrefresh
field for the actual refresh rate, while the dotclock field is used for the
DSI clocks. The dotclock needed to be a bit higher than necessary otherwise
the panel would not work.
If you want to get rid of the separate clock/vrefresh fields there would
need to be some changes to msm driver.
(note I hadn't made the patch with upstreaming in mind, the 15 value is
likely not optimal, just something that worked, this is something that
should have been checked with the downstream driver)
Is this the right clock frequency in the downstream MSM 3.4 kernel that
you're talking about?
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
No, I'm talking about the DSI clock (the driver for it is in
drm/msm/dsi/). For a command mode panel the front/back porches aren't
relevant, but the dsi pixel/byte clock need to be a bit higher than
1920x1080x60. Since 125498 is a little higher than 124416 that might be
enough (there is also rounding of the clock values to consider).
I don't see any obvious clock values in the downstream command mode
panel configuration:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
and everything appears to be working fine. You can add my Tested-by if
you end up applying this.
Tested-by: Brian Masney
Brian
On 3/2/20 3:34 PM, Ville Syrjala wrote:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if either) of the dotclock or vreresh is
correct?
Cc: Jonathan Marek
Cc: Brian Masney
Cc: Linus Walleij
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index b24fdf239440..f958d8dfd760 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00
= {
};
static const struct drm_display_mode lg_acx467akm_7_mode = {
- .clock = 15,
+ .clock = 125498,
.hdisplay = 1080,
.hsync_start = 1080 + 2,
.hsync_end = 1080 + 2 + 2,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11 4/5] soc / drm: mediatek: Move routing control to mmsys device
Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
Those functions will allow DRM driver and others to control the data
path routing.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Matthias Brugger
---
Changes in v11:
- Select CONFIG_MTK_MMSYS (CK)
- Pass device pointer of mmsys device instead of config regs (CK)
Changes in v10:
- Introduced a new patch to move routing control into mmsys driver.
- Removed the patch to use regmap as is not needed anymore.
Changes in v9: None
Changes in v8: None
Changes in v7: None
drivers/gpu/drm/mediatek/Kconfig| 1 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/soc/mediatek/mtk-mmsys.c| 277
include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
8 files changed, 314 insertions(+), 282 deletions(-)
create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig
index fa5ffc4fe823..c420f5a3d33b 100644
--- a/drivers/gpu/drm/mediatek/Kconfig
+++ b/drivers/gpu/drm/mediatek/Kconfig
@@ -11,6 +11,7 @@ config DRM_MEDIATEK
select DRM_MIPI_DSI
select DRM_PANEL
select MEMORY
+ select MTK_MMSYS
select MTK_SMI
select VIDEOMODE_HELPERS
help
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index fd4042de12f2..f63a885e063c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,7 +29,7 @@
* @enabled: records whether crtc_enable succeeded
* @planes: array of 4 drm_plane structures, one for each overlay plane
* @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @mmsys_dev: pointer to the mmsys device for configuration registers
* @mutex: handle to one of the ten disp_mutex streams
* @ddp_comp_nr: number of components in ddp_comp
* @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -50,7 +51,7 @@ struct mtk_drm_crtc {
u32 cmdq_event;
#endif
- void __iomem*config_regs;
+ struct device *mmsys_dev;
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
@@ -296,9 +297,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
}
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
- mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
-mtk_crtc->ddp_comp[i]->id,
-mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
+ mtk_crtc->ddp_comp[i]->id,
+ mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_add_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -355,9 +356,9 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
mtk_crtc->ddp_comp[i]->id);
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->ddp_comp[i]->id,
- mtk_crtc->ddp_comp[i + 1]->id);
+ mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
+mtk_crtc->ddp_comp[i]->id,
+mtk_crtc->ddp_comp[i + 1]->id);
mtk_disp_mutex_remove_comp(mtk_crtc->mutex,
mtk_crtc->ddp_comp[i]->id);
}
@@ -758,7 +759,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
if (!mtk_crtc)
return -ENOMEM;
- mtk_crtc->config_regs = priv->config_regs;
+ mtk_crtc->mmsys_dev = priv->mmsys_dev;
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 b885f60f474c..014c1bbe1df2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -13,26 +13,6 @@
#include "mtk_drm_d
Re: Etnaviv issues on i.MX8M-Mini
On 26.02.20 17:05, Guido Günther wrote: > On Wed, Feb 26, 2020 at 04:54:35PM +0100, Lucas Stach wrote: >> On Mi, 2020-02-26 at 15:31 +, Schrempf Frieder wrote: >>> On 25.02.20 09:13, Frieder Schrempf wrote: Hi Lucas, On 24.02.20 12:08, Lucas Stach wrote: > On Mo, 2020-02-24 at 10:53 +, Schrempf Frieder wrote: >> Hi Lucas, >> >> On 24.02.20 11:37, Lucas Stach wrote: >>> Hi Frieder, >>> >>> On Mo, 2020-02-24 at 10:28 +, Schrempf Frieder wrote: On 20.02.20 19:58, Chris Healy wrote: > For the jerkey transitions, can you determine if this is a symptom of > a low framerate or dropped frames or something else? > > Perhaps you can start your app with > "GALLIUM_HUD=fps,cpu,draw-calls,frametime". This may give some > clues. The framerate seems ok. I get something between 50 and 70 FPS. I have a Qt demo app with a menu and an animated 'ball' that moves across the screen. When the menu is visible, the ball movement is really jerky (ball seems to 'jump back and forth' instead of moving linearly). As soon as I hide the menu and show the animation fullscreen, the movements are perfectly smooth. Running the same app with software rendering, everything looks good, too. No idea what that means, though. I probably need to look at the code of the app and do some more experiments to get a better idea of what might cause the distortion. Unless some of the graphics experts here already have an idea of what can cause and/or how to debug such an issue!? >>> >>> Which driver is used for the display side? It seems like the display >>> side doesn't properly handle the dma fences used to synchronize scanout >>> and rendering. >> >> I ported/picked the drivers for the LCDIF and DSI controllers from >> development branch of the 5.4-based vendor kernel [1] to our own >> v5.4-based kernel [2]. So it is quite probable, that something could be >> wrong here. > > Please just use DRM_MXSFB for the display side, instead of the > downstream driver. Hm, good idea. I somehow forgot about the fact, that there is an upstream driver for the LCDIF controller. On first try I couldn't get it to run on the i.MX8MM, but I suspect that's due to some reset, power-domain or clock setup, that is missing upstream. I will see if I can get any further with this. >>> >>> So I had a closer look and while the DRM_MXSFB looks ok on its own, I >>> have some problem with the rest of the i.MX8MM display subsystem. >>> >>> The vendor stack, that I'm currently using integrates into the imx-drm >>> master/core driver [1] that binds all the components of the display >>> subsystem, such as the LCDIF driver and the integrated SEC_DSIM DSI bridge. >>> >>> And because of my lack of DRM skills, I have no idea how to get the >>> DRM_MXSFB driver to bind to the imx-drm core, instead of running >>> separately and connecting directly to some panel as it is done for >>> i.MX23/28 and i.MX6SX/UL. >> >> It's a separate hardware and it's a pretty major design issue of the >> downstream driver that it integrates into imx-drm. You don't want this >> with the upstream driver. >> >> Maybe Guido (CCed) can give you some clues, as apparently he is using >> the mainline eLCDIF driver + some patches to drive the DSI display path >> on i.MX8MQ. A lot of this will probably be transferable to the i.MX8MM >> display path. > > Newer mxsfb supports attaching a bridge so if you make your DSI host > controller driver a DSI bridge mxsfb can drive it: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mxsfb/mxsfb_drv.c#n268 > > this should be similar to what was done for the imx8mq here (imx8mm > users a different ip core though): > > > https://source.puri.sm/guido.gunther/linux-imx8/commits/forward-upstream/next-20200217/mxsfb+nwl/v9-wip > > There's also some additional mxsfb patches by Robert floating around > which aren't mainline yet which the above branch also has. > > Which reminds me that i need to prepare and send out a v9. Thanks Lucas and Guido for pointing out the details! It's very unfortunate that i.MX8MQ and i.MX8MM don't share the same DSI ip core. It seems like I need to try coming up with a bridge driver for the Samsung DSIM DSI controller for a proper upstream solution. Thanks, Frieder ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux/virtio_gpu.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index 0c85914d9369..9721d58b4d58 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -50,6 +50,10 @@
* VIRTIO_GPU_CMD_GET_EDID
*/
#define VIRTIO_GPU_F_EDID1
+/*
+ * VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID
+ */
+#define VIRTIO_GPU_F_RESOURCE_UUID 2
enum virtio_gpu_ctrl_type {
VIRTIO_GPU_UNDEFINED = 0,
@@ -66,6 +70,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_CMD_GET_CAPSET_INFO,
VIRTIO_GPU_CMD_GET_CAPSET,
VIRTIO_GPU_CMD_GET_EDID,
+ VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID,
/* 3d commands */
VIRTIO_GPU_CMD_CTX_CREATE = 0x0200,
@@ -87,6 +92,7 @@ enum virtio_gpu_ctrl_type {
VIRTIO_GPU_RESP_OK_CAPSET_INFO,
VIRTIO_GPU_RESP_OK_CAPSET,
VIRTIO_GPU_RESP_OK_EDID,
+ VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
/* error responses */
VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
@@ -340,4 +346,17 @@ enum virtio_gpu_formats {
VIRTIO_GPU_FORMAT_R8G8B8X8_UNORM = 134,
};
+/* VIRTIO_GPU_CMD_RESOURCE_ASSIGN_UUID */
+struct virtio_gpu_resource_assign_uuid {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __le32 resource_id;
+ __le32 padding;
+};
+
+/* VIRTIO_GPU_RESP_OK_RESOURCE_UUID */
+struct virtio_gpu_resp_resource_uuid {
+ struct virtio_gpu_ctrl_hdr hdr;
+ __u8 uuid[16];
+};
+
#endif
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
On Fri, Feb 21, 2020 at 10:09 AM Neil Armstrong wrote:
>
> Amlogic uses a proprietary lossless image compression protocol and format
> for their hardware video codec accelerators, either video decoders or
> video input encoders.
>
> It considerably reduces memory bandwidth while writing and reading
> frames in memory.
>
> The underlying storage is considered to be 3 components, 8bit or 10-bit
> per component, YCbCr 420, single plane :
> - DRM_FORMAT_YUV420_8BIT
> - DRM_FORMAT_YUV420_10BIT
>
> This modifier will be notably added to DMA-BUF frames imported from the V4L2
> Amlogic VDEC decoder.
>
> At least two options are supported :
> - Scatter mode: the buffer is filled with a IOMMU scatter table referring
> to the encoder current memory layout. This mode if more efficient in terms
> of memory allocation but frames are not dumpable and only valid during until
> the buffer is freed and back in control of the encoder
> - Memory saving: when the pixel bpp is 8b, the size of the superblock can
> be reduced, thus saving memory.
>
> Signed-off-by: Neil Armstrong
> ---
> include/uapi/drm/drm_fourcc.h | 56 +++
> 1 file changed, 56 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8bc0b31597d8..8a6e87bacadb 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -309,6 +309,7 @@ extern "C" {
> #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
>
> /* add more to the end as needed */
>
> @@ -804,6 +805,61 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
>
> +/*
> + * Amlogic Video Framebuffer Compression modifiers
> + *
> + * Amlogic uses a proprietary lossless image compression protocol and format
> + * for their hardware video codec accelerators, either video decoders or
> + * video input encoders.
> + *
> + * It considerably reduces memory bandwidth while writing and reading
> + * frames in memory.
> + * Implementation details may be platform and SoC specific, and shared
> + * between the producer and the decoder on the same platform.
> + *
> + * The underlying storage is considered to be 3 components, 8bit or 10-bit
> + * per component YCbCr 420, single plane :
> + * - DRM_FORMAT_YUV420_8BIT
> + * - DRM_FORMAT_YUV420_10BIT
> + *
> + * The classic memory storage is composed of:
> + * - a body content organized in 64x32 superblocks with 4096 bytes per
> + * superblock in default mode.
> + * - a 32 bytes per 128x64 header block
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC_DEFAULT fourcc_mod_code(AMLOGIC, 0)
> +
> +/*
> + * Amlogic Video Framebuffer Compression Options
> + *
> + * Two optional features are available which may not supported/used on every
> + * SoCs and Compressed Framebuffer producers.
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
> +
> +/*
> + * Amlogic FBC Scatter Memory layout
> + *
> + * Indicates the header contains IOMMU references to the compressed
> + * frames content to optimize memory access and layout.
> + * In this mode, only the header memory address is needed, thus the
> + * content memory organization is tied to the current producer
> + * execution and cannot be saved/dumped.
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER (1ULL << 0)
> +
> +/*
> + * Amlogic FBC Memory Saving mode
> + *
> + * Indicates the storage is packed when pixel size is multiple of word
> + * boudaries, i.e. 8bit should be stored in this mode to save allocation
> + * memory.
> + *
> + * This mode reduces body layout to 3072 bytes per 64x32 superblock and
> + * 3200 bytes per 64x32 superblock combined with scatter mode.
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 1)
> +
> #if defined(__cplusplus)
> }
> #endif
> --
> 2.22.0
>
>
I'm the main developer of the V4L2 video decoder (H264, VP9..) on
amlogic platforms, which is a producer of such compressed frames.
Those modifiers suit well the combinations of options that can be
applied to the frames when created. I also helped testing the
following scenarios of decode+display on various SoCs:
- SM1: DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER (10-bit & 8-bit video)
- SM1: DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER +
DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (8-bit video)
- G12A: DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER (10-bit & 8-bit video)
- G12A: DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER +
DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (8-bit video)
- GXL: DRM_FORMAT_MOD_AMLOGIC_FBC_DEFAULT (10-bit & 8-bit video)
- GXL: DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (8-bit video)
Reviewed-by: Maxime Jourdan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/51] drm/inigenic: Use drmm_add_final_kfree
Hi Daniel,
Le jeu., févr. 27, 2020 at 19:14, Daniel Vetter
a écrit :
With this we can drop the final kfree from the release function.
Signed-off-by: Daniel Vetter
Cc: Paul Cercueil
Reviewed-by: Paul Cercueil
Cheers,
-Paul
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 9dfe7cb530e1..e2c832eb4e9a 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -490,11 +491,8 @@ static irqreturn_t ingenic_drm_irq_handler(int
irq, void *arg)
static void ingenic_drm_release(struct drm_device *drm)
{
- struct ingenic_drm *priv = drm_device_get_priv(drm);
-
drm_mode_config_cleanup(drm);
drm_dev_fini(drm);
- kfree(priv);
}
static int ingenic_drm_enable_vblank(struct drm_crtc *crtc)
@@ -639,6 +637,7 @@ static int ingenic_drm_probe(struct
platform_device *pdev)
kfree(priv);
return ret;
}
+ drmm_add_final_kfree(drm, priv);
drm_mode_config_init(drm);
drm->mode_config.min_width = 0;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/8] dt-bindings: display: add ingenic-jz4780-lcd DT Schema
Hi Nikolaus,
Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller
a écrit :
From: Sam Ravnborg
Add DT bindings for the LCD controller on the jz4780 SoC
Based on .txt binding from Zubair Lutfullah Kakakhel
If you mean Documentation/devicetree/bindings/display/ingenic,lcd.txt
then it was written by me.
Signed-off-by: Sam Ravnborg
Cc: Zubair Lutfullah Kakakhel
Cc: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../bindings/display/ingenic-jz4780-lcd.yaml | 78
+++
1 file changed, 78 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
diff --git
a/Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
b/Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
new file mode 100644
index ..c71415a3a342
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ingenic-jz4780-lcd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 LCD Controller
+
+maintainers:
+ - Zubair Lutfullah Kakakhel
+ - H. Nikolaus Schaller
I'm the author of the driver, please put me here; and remove Zubair,
which 1. didn't touch the DRM driver at all, and 2. isn't working at
ImgTec anymore. Also, no need to put yourself here, unless you maintain
the Ingenic DRM/KMS driver.
+
+description: |
+ LCD Controller is the Display Controller for the Ingenic JZ4780 SoC
+
+properties:
You should add a '$nodename' property.
+ compatible:
+items:
+ - const: ingenic,jz4780-lcd
The .txt lists more compatible strings. Please add them all.
+
+ reg:
+maxItems: 1
+description: the address & size of the LCD controller registers
Drop the description here,
+
+ interrupts:
+maxItems: 1
+description: Specifies the interrupt provided by parent
and here.
+
+ clocks:
+maxItems: 2
+description: Clock specifiers for the JZ4780_CLK_TVE
JZ4780_CLK_LCD0PIXCLK
Add one 'description:' per item.
+
+ clock-names:
+items:
+ - const: lcd_clk
+ - const: lcd_pixclk
+
+ port:
+type: object
+description: |
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+required:
+- compatible
+- reg
+- interrupts
+- clocks
+- clock-names
+- port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+lcd: jz4780-lcdk@0x1305 {
The node name does not comply with the DT spec, it should be
'lcd-controller'.
Cheers,
-Paul
+compatible = "ingenic,jz4780-lcd";
+reg = <0x1305 0x1800>;
+
+clocks = <&cgu JZ4780_CLK_TVE>, <&cgu JZ4780_CLK_LCD0PIXCLK>;
+clock-names = "lcd_clk", "lcd_pixclk";
+
+interrupt-parent = <&intc>;
+interrupts = <31>;
+
+jz4780_lcd_out: port {
+#address-cells = <1>;
+#size-cells = <0>;
+
+jz4780_out_hdmi: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&hdmi_in_lcd>;
+};
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] dma-buf: add support for virtio exported objects
This change adds a new dma-buf operation that allows dma-bufs to be used
by virtio drivers to share exported objects. The new operation allows
the importing driver to query the exporting driver for the UUID which
identifies the underlying exported object.
Signed-off-by: David Stevens
---
drivers/dma-buf/dma-buf.c | 14 ++
include/linux/dma-buf.h | 22 ++
2 files changed, 36 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d4097856c86b..a04632284ec2 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1158,6 +1158,20 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+#ifdef CONFIG_VIRTIO
+int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid)
+{
+ if (WARN_ON(!dmabuf) || !uuid)
+ return -EINVAL;
+
+ if (!dmabuf->ops->get_uuid)
+ return -ENODEV;
+
+ return dmabuf->ops->get_uuid(dmabuf, uuid);
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_uuid);
+#endif
+
#ifdef CONFIG_DEBUG_FS
static int dma_buf_debug_show(struct seq_file *s, void *unused)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index abf5459a5b9d..f5fecf8abe6a 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -251,6 +251,23 @@ struct dma_buf_ops {
void *(*vmap)(struct dma_buf *);
void (*vunmap)(struct dma_buf *, void *vaddr);
+
+#ifdef CONFIG_VIRTIO
+ /**
+* @get_uuid
+*
+* This is called by dma_buf_get_uuid to get the UUID which identifies
+* the buffer to virtio devices.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success or a negative error code on failure. On success uuid
+* will be populated with the buffer's UUID.
+*/
+ int (*get_uuid)(struct dma_buf *dmabuf, uuid_t *uuid);
+#endif
};
/**
@@ -444,4 +461,9 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
+
+#ifdef CONFIG_VIRTIO
+int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid);
+#endif
+
#endif /* __DMA_BUF_H__ */
--
2.25.0.265.gbab2e86ba0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Remove pointless NULL checks in dmub_psr_copy_settings
Clang warns:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.c:147:31: warning:
address of 'pipe_ctx->plane_res' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (!pipe_ctx || !&pipe_ctx->plane_res || !&pipe_ctx->stream_res)
~ ~~^
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.c:147:56: warning:
address of 'pipe_ctx->stream_res' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (!pipe_ctx || !&pipe_ctx->plane_res || !&pipe_ctx->stream_res)
~ ~~^~
2 warnings generated.
As long as pipe_ctx is not NULL, the address of members in this struct
cannot be NULL, which means these checks will always evaluate to false.
Fixes: 4c1a1335dfe0 ("drm/amd/display: Driverside changes to support PSR in
DMCUB")
Link: https://github.com/ClangBuiltLinux/linux/issues/915
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index 2c932c29f1f9..a9e1c01e9d9b 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -144,7 +144,7 @@ static bool dmub_psr_copy_settings(struct dmub_psr *dmub,
}
}
- if (!pipe_ctx || !&pipe_ctx->plane_res || !&pipe_ctx->stream_res)
+ if (!pipe_ctx)
return false;
// First, set the psr version
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/51] drm: add managed resources tied to drm_device
On Tue, Mar 03, 2020 at 11:04:06AM +0300, Dan Carpenter wrote:
> Hi Daniel,
>
> I love your patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm_device-managed-resources-v4/20200303-071023
> base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
> Reported-by: Dan Carpenter
>
> smatch warnings:
> drivers/gpu/drm/drm_drv.c:843 drm_dev_release() error: dereferencing freed
> memory 'dev'
>
> #
> https://github.com/0day-ci/linux/commit/5aba700d4c32ae5722a9931c959b13a6217a86e2
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 5aba700d4c32ae5722a9931c959b13a6217a86e2
> vim +/dev +843 drivers/gpu/drm/drm_drv.c
>
> 099d1c290e2ebc drivers/gpu/drm/drm_stub.c David Herrmann 2014-01-29 826
> static void drm_dev_release(struct kref *ref)
> 0dc8fe5985e01f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-02 827 {
> 099d1c290e2ebc drivers/gpu/drm/drm_stub.c David Herrmann 2014-01-29 828
> struct drm_device *dev = container_of(ref, struct drm_device, ref);
> 8f6599da8e772f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-20 829
> f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 830
> if (dev->driver->release) {
> f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 831
> dev->driver->release(dev);
> f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 832
> } else {
> f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 833
> drm_dev_fini(dev);
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 834
> }
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 835
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 836
> drm_managed_release(dev);
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 837
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 838
> if (!dev->driver->release && !dev->managed.final_kfree) {
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 839
> WARN_ON(!list_empty(&dev->managed.resources));
> 0dc8fe5985e01f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-02 840
> kfree(dev);
>
> ^^
> Free
>
> 0dc8fe5985e01f drivers/gpu/drm/drm_stub.c David Herrmann 2013-10-02 841
> }
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 842
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 @843
> if (dev->managed.final_kfree)
>
> ^
> Dereference
Drat, so much for me trying to get this to bisect properly (it's interim
code and will disappear, end is correct I think). I guess I'll try again.
-Daniel
>
> 5aba700d4c32ae drivers/gpu/drm/drm_drv.c Daniel Vetter 2020-03-02 844
> kfree(dev->managed.final_kfree);
> f30c92576af4bb drivers/gpu/drm/drm_drv.c Chris Wilson 2017-02-02 845 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
--
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 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7
On Mon, Mar 02, 2020 at 03:48:22PM -0500, Jonathan Marek wrote:
> Hi,
>
> This is a command mode panel and the the msm/mdp5 driver uses the vrefresh
> field for the actual refresh rate, while the dotclock field is used for the
> DSI clocks. The dotclock needed to be a bit higher than necessary otherwise
> the panel would not work.
>
> If you want to get rid of the separate clock/vrefresh fields there would
> need to be some changes to msm driver.
>
> (note I hadn't made the patch with upstreaming in mind, the 15 value is
> likely not optimal, just something that worked, this is something that
> should have been checked with the downstream driver)
Is this the right clock frequency in the downstream MSM 3.4 kernel that
you're talking about?
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/clock-8974.c#L3326
I don't see any obvious clock values in the downstream command mode
panel configuration:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L591
Anyways, I tried Ville's patch with the framebuffer, kmscube, and X11
and everything appears to be working fine. You can add my Tested-by if
you end up applying this.
Tested-by: Brian Masney
Brian
> On 3/2/20 3:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which (if either) of the dotclock or vreresh is
> > correct?
> >
> > Cc: Jonathan Marek
> > Cc: Brian Masney
> > Cc: Linus Walleij
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index b24fdf239440..f958d8dfd760 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -3996,7 +3996,7 @@ static const struct panel_desc_dsi
> > panasonic_vvx10f004b00 = {
> > };
> > static const struct drm_display_mode lg_acx467akm_7_mode = {
> > - .clock = 15,
> > + .clock = 125498,
> > .hdisplay = 1080,
> > .hsync_start = 1080 + 2,
> > .hsync_end = 1080 + 2 + 2,
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/bridge: dw-hdmi: Fix color space conversion detection
Dne ponedeljek, 02. marec 2020 ob 10:27:48 CET je Laurent Pinchart napisal(a):
> Hi Jernej,
>
> Thank you for the patch.
>
> On Sat, Feb 29, 2020 at 05:30:41PM +0100, Jernej Skrabec wrote:
> > Currently, is_color_space_conversion() compares not only color spaces
> > but also formats. For example, function would return true if YCbCr 4:4:4
> > and YCbCr 4:2:2 would be set. Obviously in that case color spaces are
> > the same.
> >
> > Fix that by comparing if both values represent RGB color space.
> >
> > Fixes: b21f4b658df8 ("drm: imx: imx-hdmi: move imx-hdmi to
> > bridge/dw_hdmi")
> > Signed-off-by: Jernej Skrabec
>
> This isn't implemented today, but could the CSC be used to convert
> between different YCbCr encodings ?
Yes, CSC offers great flexibility, but unfortunately that also means that you
have as much CSC matrices as there is possible conversions. This explodes
quickly, especially if you convert from one YCbCr encoding to another (BT.601,
BT.709, BT.2020) and also considering range (full, limited). If you don't mind
doing some calculations in code, this becames much simpler, but doing fixed
point arithmetic isn't fun. Is floating point arithmetic allowed in kernel?
I wrote a simple program to produce all those CSC matrices for sun4i-drm
driver: http://ix.io/2dak Note that it's for RGB <-> YUV conversion, but DW
HDMI has a bit different order. I believe it's GRB, but I'm not 100% sure.
You can also do various color adjustements, like brigthness, but that would
also mean that you have to multiply all matrices to get final one which you can
then write into registers.
Best regards,
Jernej
>
> In any case the patch is correct based on the current implementation, so
>
> Reviewed-by: Laurent Pinchart
>
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 24965e53d351..9d7bfb1cb213 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -956,7 +956,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
> >
> > static int is_color_space_conversion(struct dw_hdmi *hdmi)
> > {
> >
> > - return hdmi->hdmi_data.enc_in_bus_format !=
> > hdmi->hdmi_data.enc_out_bus_format; + return
> > hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format) !=
> > + hdmi_bus_fmt_is_rgb(hdmi-
>hdmi_data.enc_out_bus_format);
> >
> > }
> >
> > static int is_color_space_decimation(struct dw_hdmi *hdmi)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V1 1/2] backlight: qcom-wled: convert the wled bindings to .yaml format
Convert the qcom-wled bindings from .txt to .yaml format. Signed-off-by: Kiran Gunda --- .../bindings/leds/backlight/qcom-wled.txt | 154 - .../bindings/leds/backlight/qcom-wled.yaml | 184 + 2 files changed, 184 insertions(+), 154 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt deleted file mode 100644 index c06863b..000 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt +++ /dev/null @@ -1,154 +0,0 @@ -Binding for Qualcomm Technologies, Inc. WLED driver - -WLED (White Light Emitting Diode) driver is used for controlling display -backlight that is part of PMIC on Qualcomm Technologies, Inc. reference -platforms. The PMIC is connected to the host processor via SPMI bus. - -- compatible - Usage:required - Value type: - Definition: should be one of: - "qcom,pm8941-wled" - "qcom,pmi8998-wled" - "qcom,pm660l-wled" - -- reg - Usage:required - Value type: - Definition: Base address of the WLED modules. - -- default-brightness - Usage:optional - Value type: - Definition: brightness value on boot, value from: 0-4095. - Default: 2048 - -- label - Usage:required - Value type: - Definition: The name of the backlight device - -- qcom,cs-out - Usage:optional - Value type: - Definition: enable current sink output. - This property is supported only for PM8941. - -- qcom,cabc - Usage:optional - Value type: - Definition: enable content adaptive backlight control. - -- qcom,ext-gen - Usage:optional - Value type: - Definition: use externally generated modulator signal to dim. - This property is supported only for PM8941. - -- qcom,current-limit - Usage:optional - Value type: - Definition: mA; per-string current limit; value from 0 to 25 with - 1 mA step. Default 20 mA. - This property is supported only for pm8941. - -- qcom,current-limit-microamp - Usage:optional - Value type: - Definition: uA; per-string current limit; value from 0 to 3 with - 2500 uA step. Default 25 mA. - -- qcom,current-boost-limit - Usage:optional - Value type: - Definition: mA; boost current limit. - For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400, - 1680. Default: 805 mA. - For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300, - 1500. Default: 970 mA. - -- qcom,switching-freq - Usage:optional - Value type: -Definition: kHz; switching frequency; one of: 600, 640, 685, 738, - 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, - 4800, 9600. - Default: for pm8941: 1600 kHz - for pmi8998: 800 kHz - -- qcom,ovp - Usage:optional - Value type: - Definition: V; Over-voltage protection limit; one of: - 27, 29, 32, 35. Default: 29V - This property is supported only for PM8941. - -- qcom,ovp-millivolt - Usage:optional - Value type: - Definition: mV; Over-voltage protection limit; - For pmi8998: one of 18100, 19600, 29600, 31100. - Default 29600 mV. - If this property is not specified for PM8941, it - falls back to "qcom,ovp" property. - -- qcom,num-strings - Usage:optional - Value type: - Definition: #; number of led strings attached; - value: For PM8941 from 1 to 3. Default: 2 -For PMI8998 from 1 to 4. - -- interrupts - Usage:optional - Value type: - Definition: Interrupts associated with WLED. This should be - "short" and "ovp" interrupts. Interrupts can be - specified as per the encoding listed under - Documentation/devicetree/bindings/spmi/ - qcom,spmi-pmic-arb.txt. - -- interrupt-names - Usage:optional - Value type: - Definition: Interrupt names associated with the interrupts. - Must be "short" and "ovp". The short circuit detection - is not supported for PM8941. -
Re: [PATCH 31/51] drm/ingenic: Drop explicit drm_mode_config_cleanup call
Hi Daniel,
Le jeu., févr. 27, 2020 at 19:15, Daniel Vetter
a écrit :
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
v2: Explain why this cleanup is possible (Laurent).
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Paul Cercueil
Reviewed-by: Paul Cercueil
Cheers,
-Paul
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 192aaa4421a3..f5689521428e 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -489,11 +489,6 @@ static irqreturn_t ingenic_drm_irq_handler(int
irq, void *arg)
return IRQ_HANDLED;
}
-static void ingenic_drm_release(struct drm_device *drm)
-{
- drm_mode_config_cleanup(drm);
-}
-
static int ingenic_drm_enable_vblank(struct drm_crtc *crtc)
{
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
@@ -537,7 +532,6 @@ static struct drm_driver ingenic_drm_driver_data
= {
.gem_prime_mmap = drm_gem_cma_prime_mmap,
.irq_handler= ingenic_drm_irq_handler,
- .release= ingenic_drm_release,
};
static const struct drm_plane_funcs ingenic_drm_primary_plane_funcs
= {
@@ -638,7 +632,10 @@ static int ingenic_drm_probe(struct
platform_device *pdev)
}
drmm_add_final_kfree(drm, priv);
- drm_mode_config_init(drm);
+ ret = drm_mode_config_init(drm);
+ if (ret)
+ return ret;
+
drm->mode_config.min_width = 0;
drm->mode_config.min_height = 0;
drm->mode_config.max_width = soc_info->max_width;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/8] dt-bindings: display: add ingenic-jz4780-lcd DT Schema
Hi Paul,
> Am 02.03.2020 um 20:10 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
>
> Le ven., févr. 28, 2020 at 19:19, H. Nikolaus Schaller a
> écrit :
>> From: Sam Ravnborg
>> Add DT bindings for the LCD controller on the jz4780 SoC
>> Based on .txt binding from Zubair Lutfullah Kakakhel
>
> If you mean Documentation/devicetree/bindings/display/ingenic,lcd.txt then it
> was written by me.
Ah, ok. We didn't recognise this before. 6 eyes see more than 4...
I just did cherry-pick this old 4.0 patch from 2015 by Zubair
and it created a ingenic-jz4780-lcd.txt:
https://lore.kernel.org/patchwork/patch/547872/
and Sam was so kind to convert it to yaml.
>
>> Signed-off-by: Sam Ravnborg
>> Cc: Zubair Lutfullah Kakakhel
>> Cc: H. Nikolaus Schaller
>> Cc: Rob Herring
>> Cc: devicet...@vger.kernel.org
>> ---
>> .../bindings/display/ingenic-jz4780-lcd.yaml | 78 +++
>> 1 file changed, 78 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
>> diff --git
>> a/Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
>> b/Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
>> new file mode 100644
>> index ..c71415a3a342
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.yaml
>> @@ -0,0 +1,78 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/ingenic-jz4780-lcd.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Bindings for Ingenic JZ4780 LCD Controller
>> +
>> +maintainers:
>> + - Zubair Lutfullah Kakakhel
>> + - H. Nikolaus Schaller
>
> I'm the author of the driver, please put me here; and remove Zubair, which 1.
> didn't touch the DRM driver at all, and 2. isn't working at ImgTec anymore.
Yes that is true.
> Also, no need to put yourself here, unless you maintain the Ingenic DRM/KMS
> driver.
Agreed. That was suggested by Sam.
>
>> +
>> +description: |
>> + LCD Controller is the Display Controller for the Ingenic JZ4780 SoC
>> +
>> +properties:
>
> You should add a '$nodename' property.
>
>> + compatible:
>> +items:
>> + - const: ingenic,jz4780-lcd
>
> The .txt lists more compatible strings. Please add them all.
>
>> +
>> + reg:
>> +maxItems: 1
>> +description: the address & size of the LCD controller registers
>
> Drop the description here,
>
>> +
>> + interrupts:
>> +maxItems: 1
>> +description: Specifies the interrupt provided by parent
>
> and here.
>
>> +
>> + clocks:
>> +maxItems: 2
>> +description: Clock specifiers for the JZ4780_CLK_TVE
>> JZ4780_CLK_LCD0PIXCLK
>
> Add one 'description:' per item.
>
>> +
>> + clock-names:
>> +items:
>> + - const: lcd_clk
>> + - const: lcd_pixclk
>> +
>> + port:
>> +type: object
>> +description: |
>> + A port node with endpoint definitions as defined in
>> + Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +required:
>> +- compatible
>> +- reg
>> +- interrupts
>> +- clocks
>> +- clock-names
>> +- port
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +#include
>> +lcd: jz4780-lcdk@0x1305 {
>
> The node name does not comply with the DT spec, it should be 'lcd-controller'.
Ok, I think I'll review all so that it does match/replace
Documentation/devicetree/bindings/display/ingenic,lcd.txt
and no information is lost.
>
> Cheers,
> -Paul
BR and thanks,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] Support virtio cross-device resources
This patchset implements the current proposal for virtio cross-device resource sharing [1], with minor changes based on recent comments. It is expected that this will be used to import virtio resources into the virtio-video driver currently under discussion [2]. This patchset adds a new hook to dma-buf, for querying the dma-buf's underlying virtio UUID. This hook is then plumbed through DRM PRIME buffers, and finally implemented in virtgpu. [1] https://markmail.org/thread/jsaoqy7phrqdcpqu [2] https://markmail.org/thread/p5d3k566srtdtute v1 -> v2 changes: - Move get_uuid callback into main dma-buf ops (instead of placing it in a new flavor of dma-buf). - Rename new virtio commands and feature flag, and pull uapi changes into their own patch. David Stevens (4): dma-buf: add support for virtio exported objects drm/prime: add support for virtio exported objects virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature drm/virtio: Support virtgpu exported resources drivers/dma-buf/dma-buf.c | 14 ++ drivers/gpu/drm/drm_prime.c| 27 +++ drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ drivers/gpu/drm/virtio/virtgpu_drv.h | 19 drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 48 ++-- drivers/gpu/drm/virtio/virtgpu_vq.c| 62 ++ include/drm/drm_drv.h | 15 +++ include/linux/dma-buf.h| 22 + include/uapi/linux/virtio_gpu.h| 19 10 files changed, 230 insertions(+), 3 deletions(-) -- 2.25.0.265.gbab2e86ba0-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/bridge: dw-hdmi: Add support for RGB limited range
Hi Laurent!
Dne ponedeljek, 02. marec 2020 ob 10:53:54 CET je Laurent Pinchart napisal(a):
> Hi Jernej,
>
> Thank you for the patch.
>
> On Sat, Feb 29, 2020 at 05:30:43PM +0100, Jernej Skrabec wrote:
> > CEA 861 standard request that RGB quantization range is "limited" for
>
> s/request/requests/
>
> > CEA modes. Support that by adding CSC matrix which downscales values.
>
> Interesting, that's related to what I asked in the review of 2/4 :-)
>
> > This allows to proper color reproduction on TV and PC monitor at the
> > same time. In future, override property can be added, like "Broadcast
> > RGB" in i915 driver.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 36 +--
> > 1 file changed, 34 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 3d6021119942..101c90156fa0 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -92,6 +92,12 @@ static const u16 csc_coeff_rgb_in_eitu709[3][4] = {
> >
> > { 0x6756, 0x78ab, 0x2000, 0x0200 }
> >
> > };
> >
> > +static const u16 csc_coeff_rgb_limited[3][4] = {
>
> Could you name this to make it explicit that we're converting from RGB
> to RGB ? Maybe csc_coeff_rgb_full_to_rgb_limited ?
Ok.
>
> > + { 0x1B7C, 0x, 0x, 0x0020 },
> > + { 0x, 0x1B7C, 0x, 0x0020 },
> > + { 0x, 0x, 0x1B7C, 0x0020 }
>
> Lowercase hex constants please.
Ok.
>
> > +};
> > +
> >
> > struct hdmi_vmode {
> >
> > bool mdataenablepolarity;
> >
> > @@ -109,6 +115,7 @@ struct hdmi_data_info {
> >
> > unsigned int pix_repet_factor;
> > unsigned int hdcp_enable;
> > struct hdmi_vmode video_mode;
> >
> > + bool rgb_limited_range;
> >
> > };
> >
> > struct dw_hdmi_i2c {
> >
> > @@ -960,6 +967,13 @@ static int is_color_space_conversion(struct dw_hdmi
> > *hdmi)>
> > hdmi_bus_fmt_is_rgb(hdmi-
>hdmi_data.enc_out_bus_format);
> >
> > }
> >
> > +static int is_rgb_downscale_needed(struct dw_hdmi *hdmi)
> > +{
> > + return hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format) &&
> > + hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)
&&
> > + hdmi->hdmi_data.rgb_limited_range;
> > +}
> > +
> >
> > static int is_color_space_decimation(struct dw_hdmi *hdmi)
> > {
> >
> > if (!hdmi_bus_fmt_is_yuv422(hdmi->hdmi_data.enc_out_bus_format))
> >
> > @@ -1006,6 +1020,8 @@ static void dw_hdmi_update_csc_coeffs(struct dw_hdmi
> > *hdmi)>
> > csc_coeff =
&csc_coeff_rgb_in_eitu709;
> >
> > csc_scale = 0;
> >
> > }
> >
> > + } else if (is_rgb_downscale_needed(hdmi)) {
> > + csc_coeff = &csc_coeff_rgb_limited;
> >
> > }
> >
> > /* The CSC registers are sequential, alternating MSB then LSB */
> >
> > @@ -1615,6 +1631,18 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi,
> > struct drm_display_mode *mode)>
> > drm_hdmi_avi_infoframe_from_display_mode(&frame,
> >
> > &hdmi-
>connector, mode);
> >
> > + if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
> > + drm_hdmi_avi_infoframe_quant_range(&frame, &hdmi-
>connector,
> > + mode,
> > + hdmi-
>hdmi_data.rgb_limited_range ?
> > +
HDMI_QUANTIZATION_RANGE_LIMITED :
> > +
HDMI_QUANTIZATION_RANGE_FULL);
> > + } else {
> > + frame.quantization_range =
HDMI_QUANTIZATION_RANGE_DEFAULT;
> > + frame.ycc_quantization_range =
> > + HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> > + }
> > +
> >
> > if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
> >
> > frame.colorspace = HDMI_COLORSPACE_YUV444;
> >
> > else if (hdmi_bus_fmt_is_yuv422(hdmi-
>hdmi_data.enc_out_bus_format))
> >
> > @@ -1990,13 +2018,13 @@ static void dw_hdmi_enable_video_path(struct
> > dw_hdmi *hdmi)>
> > hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
> >
> > /* Enable csc path */
> >
> > - if (is_color_space_conversion(hdmi)) {
> > + if (is_color_space_conversion(hdmi) ||
is_rgb_downscale_needed(hdmi)) {
>
> I would fold this change in is_color_space_conversion(), and modify
> dw_hdmi_update_csc_coeffs() accordingly with something like
>
> if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format) &&
> hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
> if (hdmi->hdmi_data.enc_out_encoding ==
V4L2_YCBCR_ENC_601)
> csc_coeff = &csc_coeff_rgb_out_eitu601;
> else
> csc_coe
Re: [PATCH] drm/fourcc: Add bayer formats and modifiers
On Fri, 28 Feb 2020 17:31:35 +0100
Niklas Söderlund wrote:
> Bayer formats are used with cameras and contain green, red and blue
> components, with alternating lines of red and green, and blue and green
> pixels in different orders. For each block of 2x2 pixels there is one
> pixel with a red filter, two with a green filter, and one with a blue
> filter. The filters can be arranged in different patterns.
>
> Add DRM fourcc formats to describe the most common Bayer formats. Also
> add a modifiers to describe the custom packing layouts used by the Intel
> IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> specification.
>
> Signed-off-by: Niklas Söderlund
> ---
> include/uapi/drm/drm_fourcc.h | 95 +++
> 1 file changed, 95 insertions(+)
Hi,
here are some by-stander comments.
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8bc0b31597d80737..561d5a08ffd16b69 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -286,6 +286,62 @@ extern "C" {
> #define DRM_FORMAT_YVU444fourcc_code('Y', 'V', '2', '4') /*
> non-subsampled Cr (1) and Cb (2) planes */
>
>
> +/*
> + * Bayer formats
> + *
> + * Bayer formats contain green, red and blue components, with alternating
> lines
> + * of red and green, and blue and green pixels in different orders. For each
> + * block of 2x2 pixels there is one pixel with a red filter, two with a green
> + * filter, and one with a blue filter. The filters can be arranged in
> different
> + * patterns.
> + *
> + * For example, RGGB:
> + * row0: RGRGRGRG...
> + * row1: GBGBGBGB...
> + * row3: RGRGRGRG...
> + * row4: GBGBGBGB...
> + * ...
> + *
> + * Vendors have different methods to pack the sampling formats to increase
> data
> + * density. For this reason the fourcc only describes pixel sample size and
> the
> + * filter pattern for each block of 2x2 pixels. A modifier is needed to
> + * describe the memory layout.
> + *
> + * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR
> may
> + * be used to describe a layout where all samples are placed consecutively in
> + * memory. If the sample does not fit inside a single byte, the sample
> storage
> + * is extended to the minimum number of (little endian) bytes that can hold
> the
> + * sample and any unused most-significant bits are defined as padding.
"Minimum number of (little endian) bytes" is probably not quite right,
because you could end up with a 3-byte word for e.g. 18-bit samples,
and for those I don't think endianess is even a defined concept. Yes,
you don't add any >16 bit formats here, but being careful here avoids
having to face the question and confusion when someone does add such
formats.
Alternatively, do not even pretend to define any layout for samples >
16 bits, and leave it for the future to be defined if/when the need
arises.
> + *
> + * For example, SRGGB10:
> + * Each 10-bit sample is contained in 2 consecutive little endian bytes,
> where
> + * the 6 most-significant bits are unused.
Nitpick: I think you mean "10-bit sample is contained in a uint16 word
(little endian), ..."
"little endian byte" sounds like a strange concept to me, as it seems
to delve into the order of bits in a byte, MSB or LSB first. I suspect
most people would not even think of this, but I've been scarred by
reading the Pixman pixel format definitions.
> + */
> +
> +/* 8-bit Bayer formats */
> +#define DRM_FORMAT_SRGGB8fourcc_code('R', 'G', 'G', 'B')
The S in SRGGB is quite surprising to me. I saw it mentioned in IRC
that it is easy to read as sRGB and I agree. I would not know to
associate S with Bayer to begin with.
Why not e.g. DRM_FORMAT_BAYER_RGGB8?
> +#define DRM_FORMAT_SGRBG8fourcc_code('G', 'R', 'B', 'G')
> +#define DRM_FORMAT_SGBRG8fourcc_code('G', 'B', 'R', 'G')
> +#define DRM_FORMAT_SBGGR8fourcc_code('B', 'A', '8', '1')
> +
> +/* 10-bit Bayer formats */
> +#define DRM_FORMAT_SRGGB10 fourcc_code('R', 'G', '1', '0')
> +#define DRM_FORMAT_SGRBG10 fourcc_code('B', 'A', '1', '0')
> +#define DRM_FORMAT_SGBRG10 fourcc_code('G', 'B', '1', '0')
> +#define DRM_FORMAT_SBGGR10 fourcc_code('B', 'G', '1', '0')
> +
> +/* 12-bit Bayer formats */
> +#define DRM_FORMAT_SRGGB12 fourcc_code('R', 'G', '1', '2')
> +#define DRM_FORMAT_SGRBG12 fourcc_code('B', 'A', '1', '2')
Conflict:
#define DRM_FORMAT_BGRA fourcc_code('B', 'A', '1', '2') /* [15:0]
B:G:R:A 4:4:4:4 little endian */
Does the kernel not have a "self-test" that ensures that all format
codes (and why not modifiers as well) are unique?
> +#define DRM_FORMAT_SGBRG12 fourcc_code('G', 'B', '1', '2')
> +#define DRM_FORMAT_SBGGR12 fourcc_code('B', 'G', '1', '2')
> +
> +/* 14-bit Bayer formats */
> +#define DRM_FORMAT_SRGGB14 fourcc_code('R', 'G', '1', '4')
> +#define DRM_FORMAT_SGRBG14 fourcc_code('B', 'A', '1', '4')
> +#define DRM_FORMAT_SGBRG14 fourcc_code('G', 'B'
Re: [PATCH 09/51] drm/cirrus: Use drmm_add_final_kfree
On Tue, Mar 03, 2020 at 08:49:34AM +0100, Gerd Hoffmann wrote:
> > @@ -575,9 +574,12 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> >
> > dev = &cirrus->dev;
> > ret = drm_dev_init(dev, &cirrus_driver, &pdev->dev);
> > - if (ret)
> > - goto err_free_cirrus;
> > + if (ret) {
> > + kfree(cirrus);
> > + goto err_pci_release;
> > + }
> > dev->dev_private = cirrus;
> > + drmm_add_final_kfree(dev, cirrus);
>
> That doesn't look like an error path improvement.
> With patch #30 applied it'll looks alot better though.
> So maybe squash the patches?
Breaks the patch set evolution, there's a _lot_ of dependencies in here to
make sure we never break anything interim. But yeah that's why I created
this entire series, since with just the first part it's really not any
better. I also have a pile more ideas on top, so hopefully once this lands
I can get around to them and make everything even better :-)
Cheers, Daniel
>
> In any case:
> Acked-by: Gerd Hoffmann
>
> cheers,
> Gerd
>
--
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/simple-kms: Fix documentation for drm_simple_encoder_init()
On Tue, Mar 03, 2020 at 08:18:07AM +0100, Thomas Zimmermann wrote:
> Brings the documentation of drm_simple_encoder_init() in sync with the
> function's signature.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 63170ac6f2e8 ("drm/simple-kms: Add drm_simple_encoder_{init,create}()")
> Cc: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 5a2abe2dea3e..2fab80aaf52e 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -40,7 +40,7 @@ static const struct drm_encoder_funcs
> drm_simple_encoder_funcs_cleanup = {
> /**
> * drm_simple_encoder_init - Initialize a preallocated encoder
> * @dev: drm device
> - * @funcs: callbacks for this encoder
> + * @encoder: the encoder to initialize
> * @encoder_type: user visible type of the encoder
> *
> * Initialises a preallocated encoder that has no further functionality.
> --
> 2.25.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/simple-kms: Fix documentation for drm_simple_encoder_init()
On Tue, Mar 03, 2020 at 08:18:07AM +0100, Thomas Zimmermann wrote:
> Brings the documentation of drm_simple_encoder_init() in sync with the
> function's signature.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 63170ac6f2e8 ("drm/simple-kms: Add drm_simple_encoder_{init,create}()")
> Cc: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 5a2abe2dea3e..2fab80aaf52e 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -40,7 +40,7 @@ static const struct drm_encoder_funcs
> drm_simple_encoder_funcs_cleanup = {
> /**
> * drm_simple_encoder_init - Initialize a preallocated encoder
> * @dev: drm device
> - * @funcs: callbacks for this encoder
> + * @encoder: the encoder to initialize
> * @encoder_type: user visible type of the encoder
> *
> * Initialises a preallocated encoder that has no further functionality.
btw reading this I just realized ... who does the kfree on the memory
containing the encoder? The ->destroy hook doesn't do that, and without
that the only other option thus far is devm_kzalloc, which is wrong.
drmm_kzalloc would fix this, but we don't have that yet.
How does this work? Maybe add a FIXME note that right now this can only
really be used if the encoder is embedded into something else that's
getting freed ...
-Daniel
--
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/vblank: Fix documentation of VBLANK timestamp helper
On Tue, Mar 03, 2020 at 08:31:35AM +0100, Thomas Zimmermann wrote:
> Per-CRTC VBLANK information used to be addressed by device and pipe
> index. A call drm_crtc_vblank_helper_get_vblank_timestamp_internal()
> receives a pointer to the CRTC instead. Fix the documentation.
>
> Signed-off-by: Thomas Zimmermann
> Reported-by: Daniel Vetter
> Fixes: f1e2b6371c12 ("drm: Add get_scanout_position() to struct
> drm_crtc_helper_funcs")
> Cc: Thomas Zimmermann
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_vblank.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 47fc4339ec7f..da7b0b0c1090 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -592,8 +592,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
> /**
> * drm_crtc_vblank_helper_get_vblank_timestamp_internal - precise vblank
> *timestamp helper
> - * @dev: DRM device
> - * @pipe: index of CRTC whose vblank timestamp to retrieve
> + * @crtc: CRTC whose vblank timestamp to retrieve
> * @max_error: Desired maximum allowable error in timestamps (nanosecs)
> * On return contains true maximum error of timestamp
> * @vblank_time: Pointer to time which should receive the timestamp
> --
> 2.25.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
[PATCH] drm: add managed resources tied to drm_device
We have lots of these. And the cleanup code tends to be of dubious quality. The biggest wrong pattern is that developers use devm_, which ties the release action to the underlying struct device, whereas all the userspace visible stuff attached to a drm_device can long outlive that one (e.g. after a hotunplug while userspace has open files and mmap'ed buffers). Give people what they want, but with more correctness. Mostly copied from devres.c, with types adjusted to fit drm_device and a few simplifications - I didn't (yet) copy over everything. Since the types don't match code sharing looked like a hopeless endeavour. For now it's only super simplified, no groups, you can't remove actions (but kfree exists, we'll need that soon). Plus all specific to drm_device ofc, including the logging. Which I didn't bother to make compile-time optional, since none of the other drm logging is compile time optional either. One tricky bit here is the chicken&egg between allocating your drm_device structure and initiliazing it with drm_dev_init. For perfect onion unwinding we'd need to have the action to kfree the allocation registered before drm_dev_init registers any of its own release handlers. But drm_dev_init doesn't know where exactly the drm_device is emebedded into the overall structure, and by the time it returns it'll all be too late. And forcing drivers to be able clean up everything except the one kzalloc is silly. Work around this by having a very special final_kfree pointer. This also avoids troubles with the list head possibly disappearing from underneath us when we release all resources attached to the drm_device. v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless shuffling while getting everything into shape. v3: Add static to add/del_dr (Neil) Move typo fix to the right patch (Neil) v4: Enforce contract for drmm_add_final_kfree: Use ksize() to check that the drm_device is indeed contained somewhere in the final kfree(). Because we need that or the entire managed release logic blows up in a pile of use-after-frees. Motivated by a discussion with Laurent. v5: Review from Laurent: - %zu instead of casting size_t - header guards - sorting of includes - guarding of data assignment if we didn't allocate it for a NULL pointer - delete spurious newline - cast void* data parameter correctly in ->release call, no idea how this even worked before v3: Review from Sam - Add the kerneldoc for the managed sub-struct back in, even if it doesn't show up in the generated html somehow. - Explain why __always_inline. - Fix bisectability around the final kfree() in drm_dev_relase(). This is just interim code which will disappear again. - Some whitespace polish. - Add debug output when drmm_add_action or drmm_kmalloc fail. v4: My bisectability fix wasn't up to par as noticed by smatch. Cc: Dan Carpenter Cc: Sam Ravnborg Cc: Laurent Pinchart Cc: Neil Armstrong Cc: "Rafael J. Wysocki" Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-internals.rst | 6 + drivers/gpu/drm/Makefile| 3 +- drivers/gpu/drm/drm_drv.c | 12 +- drivers/gpu/drm/drm_internal.h | 3 + drivers/gpu/drm/drm_managed.c | 186 include/drm/drm_device.h| 15 +++ include/drm/drm_managed.h | 30 + include/drm/drm_print.h | 6 + 8 files changed, 259 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_managed.c create mode 100644 include/drm/drm_managed.h diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index a73320576ca9..a6b6145fda78 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -132,6 +132,12 @@ be unmapped; on many devices, the ROM address decoder is shared with other BARs, so leaving it mapped could cause undesired behaviour like hangs or memory corruption. +Managed Resources +- + +.. kernel-doc:: drivers/gpu/drm/drm_managed.c + :doc: managed resources + Bus-specific Device Registration and PCI Support diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 7f72ef5e7811..183c60048307 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -17,7 +17,8 @@ drm-y :=drm_auth.o drm_cache.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ - drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o + drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \ + drm_managed.o drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 9fcd6ab3c
[PATCH] drm: Cleanups after drmm_add_final_kfree rollout
A few things:
- Update the example driver in the documentation.
- We can drop the old kfree in drm_dev_release.
- Add a WARN_ON check in drm_dev_register to make sure everyone calls
drmm_add_final_kfree and there's no leaks.
v2: Restore the full cleanup, I accidentally left some moved code
behind when fixing the bisectability of the series.
Cc: Sam Ravnborg
Cc: Dan Carpenter
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 80cfd0f14475..1ee606b4a4f9 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -297,8 +297,6 @@ void drm_minor_release(struct drm_minor *minor)
*
* drm_mode_config_cleanup(drm);
* drm_dev_fini(drm);
- * kfree(priv->userspace_facing);
- * kfree(priv);
* }
*
* static struct drm_driver driver_drm_driver = {
@@ -326,10 +324,11 @@ void drm_minor_release(struct drm_minor *minor)
* kfree(drm);
* return ret;
* }
+ * drmm_add_final_kfree(drm, priv);
*
* drm_mode_config_init(drm);
*
- * priv->userspace_facing = kzalloc(..., GFP_KERNEL);
+ * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
* if (!priv->userspace_facing)
* return -ENOMEM;
*
@@ -838,10 +837,7 @@ static void drm_dev_release(struct kref *ref)
drm_managed_release(dev);
- if (!dev->driver->release && !dev->managed.final_kfree) {
- WARN_ON(!list_empty(&dev->managed.resources));
- kfree(dev);
- } else if (dev->managed.final_kfree)
+ if (dev->managed.final_kfree)
kfree(dev->managed.final_kfree);
}
@@ -959,6 +955,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
struct drm_driver *driver = dev->driver;
int ret;
+ WARN_ON(!dev->managed.final_kfree);
+
if (drm_dev_needs_global_mutex(dev))
mutex_lock(&drm_global_mutex);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/lima: save task info dump when task fail
On Fri, Feb 21, 2020 at 6:43 PM Qiang Yu wrote:
>
> Save all information to start a task which can be exported to user
> for debug usage. Dump file data format is specified in lima_dump.h
Looks like lima_sched.c is missing #include so
kbuild bot complains
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/lima/lima_device.c | 13 +++
> drivers/gpu/drm/lima/lima_device.h | 8 ++
> drivers/gpu/drm/lima/lima_dump.h | 77 +
> drivers/gpu/drm/lima/lima_sched.c | 128 +
> drivers/gpu/drm/lima/lima_sched.h | 7 ++
> 5 files changed, 233 insertions(+)
> create mode 100644 drivers/gpu/drm/lima/lima_dump.h
>
> diff --git a/drivers/gpu/drm/lima/lima_device.c
> b/drivers/gpu/drm/lima/lima_device.c
> index 19829b543024..42a00171fea5 100644
> --- a/drivers/gpu/drm/lima/lima_device.c
> +++ b/drivers/gpu/drm/lima/lima_device.c
> @@ -344,6 +344,12 @@ int lima_device_init(struct lima_device *ldev)
> if (err)
> goto err_out5;
>
> + ldev->dump.magic = LIMA_DUMP_MAGIC;
> + ldev->dump.version_major = LIMA_DUMP_MAJOR;
> + ldev->dump.version_minor = LIMA_DUMP_MINOR;
> + INIT_LIST_HEAD(&ldev->error_task_list);
> + mutex_init(&ldev->error_task_list_lock);
> +
> dev_info(ldev->dev, "bus rate = %lu\n", clk_get_rate(ldev->clk_bus));
> dev_info(ldev->dev, "mod rate = %lu", clk_get_rate(ldev->clk_gpu));
>
> @@ -370,6 +376,13 @@ int lima_device_init(struct lima_device *ldev)
> void lima_device_fini(struct lima_device *ldev)
> {
> int i;
> + struct lima_sched_error_task *et, *tmp;
> +
> + list_for_each_entry_safe(et, tmp, &ldev->error_task_list, list) {
> + list_del(&et->list);
> + kvfree(et);
> + }
> + mutex_destroy(&ldev->error_task_list_lock);
>
> lima_fini_pp_pipe(ldev);
> lima_fini_gp_pipe(ldev);
> diff --git a/drivers/gpu/drm/lima/lima_device.h
> b/drivers/gpu/drm/lima/lima_device.h
> index 31158d86271c..f17173f47f26 100644
> --- a/drivers/gpu/drm/lima/lima_device.h
> +++ b/drivers/gpu/drm/lima/lima_device.h
> @@ -6,8 +6,11 @@
>
> #include
> #include
> +#include
> +#include
>
> #include "lima_sched.h"
> +#include "lima_dump.h"
>
> enum lima_gpu_id {
> lima_gpu_mali400 = 0,
> @@ -94,6 +97,11 @@ struct lima_device {
>
> u32 *dlbu_cpu;
> dma_addr_t dlbu_dma;
> +
> + /* debug info */
> + struct lima_dump_head dump;
> + struct list_head error_task_list;
> + struct mutex error_task_list_lock;
> };
>
> static inline struct lima_device *
> diff --git a/drivers/gpu/drm/lima/lima_dump.h
> b/drivers/gpu/drm/lima/lima_dump.h
> new file mode 100644
> index ..ca243d99c51b
> --- /dev/null
> +++ b/drivers/gpu/drm/lima/lima_dump.h
> @@ -0,0 +1,77 @@
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> +/* Copyright 2020 Qiang Yu */
> +
> +#ifndef __LIMA_DUMP_H__
> +#define __LIMA_DUMP_H__
> +
> +#include
> +
> +/**
> + * dump file format for all the information to start a lima task
> + *
> + * top level format
> + * | magic code "LIMA" | format version | num tasks | data size |
> + * | reserved | reserved | reserved | reserved |
> + * | task 1 ID | task 1 size | num chunks | reserved | task 1 data |
> + * | task 2 ID | task 2 size | num chunks | reserved | task 2 data |
> + * ...
> + *
> + * task data format
> + * | chunk 1 ID | chunk 1 size | reserved | reserved | chunk 1 data |
> + * | chunk 2 ID | chunk 2 size | reserved | reserved | chunk 2 data |
> + * ...
> + *
> + */
> +
> +#define LIMA_DUMP_MAJOR 1
> +#define LIMA_DUMP_MINOR 0
> +
> +#define LIMA_DUMP_MAGIC 0x414d494c
> +
> +struct lima_dump_head {
> + __u32 magic;
> + __u16 version_major;
> + __u16 version_minor;
> + __u32 num_tasks;
> + __u32 size;
> + __u32 reserved[4];
> +};
> +
> +#define LIMA_DUMP_TASK_GP 0
> +#define LIMA_DUMP_TASK_PP 1
> +#define LIMA_DUMP_TASK_NUM 2
> +
> +struct lima_dump_task {
> + __u32 id;
> + __u32 size;
> + __u32 num_chunks;
> + __u32 reserved;
> +};
> +
> +#define LIMA_DUMP_CHUNK_FRAME 0
> +#define LIMA_DUMP_CHUNK_BUFFER1
> +#define LIMA_DUMP_CHUNK_PROCESS_NAME 2
> +#define LIMA_DUMP_CHUNK_PROCESS_ID3
> +#define LIMA_DUMP_CHUNK_NUM 4
> +
> +struct lima_dump_chunk {
> + __u32 id;
> + __u32 size;
> + __u32 reserved[2];
> +};
> +
> +struct lima_dump_chunk_buffer {
> + __u32 id;
> + __u32 size;
> + __u32 va;
> + __u32 reserved;
> +};
> +
> +struct lima_dump_chunk_pid {
> + __u32 id;
> + __u32 size;
> + __u32 pid;
> + __u32 reserved;
> +};
> +
> +#endif
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index 3886999b4533..cd1bf3ad9bb5 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -256,6 +256,132 @@ static struct dma_fence *lima_sched_run_job
Re: [PATCH v4 0/9] Huge page-table entries for TTM
On Fri 28-02-20 14:08:04, Thomas Hellström (VMware) wrote: > Andrew, Michal > > I'm wondering what's the best way here to get the patches touching mm > reviewed and accepted? I am sorry, but I am busy with other stuff and unlikely to find time to review this series. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Fix documentation for drm_simple_encoder_init()
Hi
Am 03.03.20 um 09:33 schrieb Daniel Vetter:
> On Tue, Mar 03, 2020 at 08:18:07AM +0100, Thomas Zimmermann wrote:
>> Brings the documentation of drm_simple_encoder_init() in sync with the
>> function's signature.
>>
>> Signed-off-by: Thomas Zimmermann
>> Fixes: 63170ac6f2e8 ("drm/simple-kms: Add
>> drm_simple_encoder_{init,create}()")
>> Cc: Sam Ravnborg
>> Cc: Maarten Lankhorst
>> Cc: Maxime Ripard
>> Cc: David Airlie
>> Cc: Daniel Vetter
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
>> b/drivers/gpu/drm/drm_simple_kms_helper.c
>> index 5a2abe2dea3e..2fab80aaf52e 100644
>> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
>> @@ -40,7 +40,7 @@ static const struct drm_encoder_funcs
>> drm_simple_encoder_funcs_cleanup = {
>> /**
>> * drm_simple_encoder_init - Initialize a preallocated encoder
>> * @dev: drm device
>> - * @funcs: callbacks for this encoder
>> + * @encoder: the encoder to initialize
>> * @encoder_type: user visible type of the encoder
>> *
>> * Initialises a preallocated encoder that has no further functionality.
>
> btw reading this I just realized ... who does the kfree on the memory
> containing the encoder? The ->destroy hook doesn't do that, and without
> that the only other option thus far is devm_kzalloc, which is wrong.
> drmm_kzalloc would fix this, but we don't have that yet.
>
> How does this work? Maybe add a FIXME note that right now this can only
> really be used if the encoder is embedded into something else that's
> getting freed ...
Good point. The function expects the driver to kfree the memory as part
of the final release. The drivers I saw did this, but adding an
additional note here is probably a good idea.
Best regards
Thomas
> -Daniel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/omap: Prepare DSS for probing without legacy platform data
On 24/02/2020 21:12, Tony Lindgren wrote: In order to probe display subsystem (DSS) components with ti-sysc interconnect target module without legacy platform data and using devicetree, we need to update dss probing a bit. In the device tree, we will be defining the data also for the interconnect target modules as DSS really is a private interconnect. There is some information about that in 4460 TRM in "Figure 10-3. DSS Integration" for example where it mentions "32-bit interconnect (SLX)". The changes we need to make are: 1. Parse also device tree subnodes for the compatible property fixup 2. Update the component code to consider device tree subnodes Cc: dri-devel@lists.freedesktop.org Cc: Jyri Sarha Cc: Laurent Pinchart Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren --- This is needed for dropping DSS platform data that I'll be posting seprately. If this looks OK, can you guys please test and ack? --- drivers/gpu/drm/omapdrm/dss/dss.c | 25 --- .../gpu/drm/omapdrm/dss/omapdss-boot-init.c | 25 +-- 2 files changed, 39 insertions(+), 11 deletions(-) Reviewed-by: Tomi Valkeinen This doesn't conflict with drm-next (with Laurent's recent patches), so it should be fine for you to have this in your branch. And not a biggie, but I wonder if the changes to these two files should be in separate patches, due to omapdss-boot-init going away. Well, probably doesn't matter. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/virtio: factor out the sg_table from virtio_gpu_object
Hi,
> struct virtio_gpu_object {
> struct drm_gem_shmem_object base;
> uint32_t hw_res_handle;
> -
> - struct sg_table *pages;
> uint32_t mapped;
> -
> bool dumb;
> bool created;
> };
> #define gem_to_virtio_gpu_obj(gobj) \
> container_of((gobj), struct virtio_gpu_object, base.base)
>
> +struct virtio_gpu_object_shmem {
> + struct virtio_gpu_object base;
> + struct sg_table *pages;
> +};
mapped can be moved too.
> @@ -600,10 +600,11 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct
> virtio_gpu_device *vgdev,
> + struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
Should we pass struct virtio_gpu_object_shmem to
virtio_gpu_cmd_transfer_to_host_2d (+friends) instead?
hostmem will not need transfers ...
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/virtio: make sure virtio_gpu_cleanup_object(..) only happens on shmem objects
> This function won't be useable for hostmem objects. > @@ -526,7 +526,8 @@ static void virtio_gpu_cmd_unref_cb(struct > virtio_gpu_device *vgdev, > bo = vbuf->resp_cb_data; > vbuf->resp_cb_data = NULL; > > - virtio_gpu_cleanup_object(bo); > + if (bo && virtio_gpu_is_shmem(bo)) > + virtio_gpu_cleanup_object(bo); Its not that simple, the virtio_gpu_resource_id_put() call in virtio_gpu_cleanup_object() is needed for all objects. We also must free all objects. I'd suggest to move the virtio_gpu_is_shmem() check to virtio_gpu_cleanup_object(). cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
On Fri, 21 Feb 2020 10:08:42 +0100
Neil Armstrong wrote:
> Amlogic uses a proprietary lossless image compression protocol and format
> for their hardware video codec accelerators, either video decoders or
> video input encoders.
>
> It considerably reduces memory bandwidth while writing and reading
> frames in memory.
>
> The underlying storage is considered to be 3 components, 8bit or 10-bit
> per component, YCbCr 420, single plane :
> - DRM_FORMAT_YUV420_8BIT
> - DRM_FORMAT_YUV420_10BIT
>
> This modifier will be notably added to DMA-BUF frames imported from the V4L2
> Amlogic VDEC decoder.
>
> At least two options are supported :
> - Scatter mode: the buffer is filled with a IOMMU scatter table referring
> to the encoder current memory layout. This mode if more efficient in terms
> of memory allocation but frames are not dumpable and only valid during until
> the buffer is freed and back in control of the encoder
> - Memory saving: when the pixel bpp is 8b, the size of the superblock can
> be reduced, thus saving memory.
>
> Signed-off-by: Neil Armstrong
> ---
> include/uapi/drm/drm_fourcc.h | 56 +++
> 1 file changed, 56 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8bc0b31597d8..8a6e87bacadb 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -309,6 +309,7 @@ extern "C" {
> #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
>
> /* add more to the end as needed */
>
> @@ -804,6 +805,61 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
>
> +/*
> + * Amlogic Video Framebuffer Compression modifiers
> + *
> + * Amlogic uses a proprietary lossless image compression protocol and format
> + * for their hardware video codec accelerators, either video decoders or
> + * video input encoders.
> + *
> + * It considerably reduces memory bandwidth while writing and reading
> + * frames in memory.
> + * Implementation details may be platform and SoC specific, and shared
> + * between the producer and the decoder on the same platform.
Hi,
after a lengthy IRC discussion on #dri-devel, this "may be platform and
SoC specific" is a problem.
It can be an issue in two ways:
- If something in the data acts like a sub-modifier, then advertising
support for one modifier does not really tell if the data layout is
supported or not.
- If you need to know the platform and/or SoC to be able to interpret
the data, it means the modifier is ill-defined and cannot be used in
inter-machine communication (e.g. Pipewire).
Neil mentioned the data contains a "header" that further specifies
things, but there is no specification about the header itself.
Therefore I don't think we can even know if the header contains
something that acts like a sub-modifier or not.
All this sounds like the modifier definitions here are not enough to
fully interpret the data. At the very least I would expect a reference
to a document explaining the "header", or even better, a kernel ReST
doc.
I wonder if this is at all suitable as a DRM format modifier as is. I
have been assuming that a modifier together with all the usual FB
parameters should be enough to interpret the stored data, but in this
case I have doubt it actually is.
I have no problem with proprietary data layouts as long as they are
fully specified.
I do feel like I would not be able to write a software decoder for this
set of modifiers given the details below.
Thanks,
pq
> + *
> + * The underlying storage is considered to be 3 components, 8bit or 10-bit
> + * per component YCbCr 420, single plane :
> + * - DRM_FORMAT_YUV420_8BIT
> + * - DRM_FORMAT_YUV420_10BIT
> + *
> + * The classic memory storage is composed of:
> + * - a body content organized in 64x32 superblocks with 4096 bytes per
> + * superblock in default mode.
> + * - a 32 bytes per 128x64 header block
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC_DEFAULT fourcc_mod_code(AMLOGIC, 0)
> +
> +/*
> + * Amlogic Video Framebuffer Compression Options
> + *
> + * Two optional features are available which may not supported/used on every
> + * SoCs and Compressed Framebuffer producers.
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
> +
> +/*
> + * Amlogic FBC Scatter Memory layout
> + *
> + * Indicates the header contains IOMMU references to the compressed
> + * frames content to optimize memory access and layout.
> + * In this mode, only the header memory address is needed, thus the
> + * content memory organization is tied to the current producer
> + * execution and cannot be saved/dumped.
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER (1ULL << 0)
> +
> +/*
> + * Amlogic FBC Memory Saving mode
> + *
> + * Indicates the storage is packed when pixel size is mu
[PATCH v6] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
v4: simplify quirk by setting flag on the GPU itself
v5: restructure quirk to make it easier to add new IDs
fix whitespace issues
fix potential NULL pointer access
update the quirk documentation
v6: move quirk into nouveau
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 56 +++
drivers/pci/pci.c | 8
include/linux/pci.h | 1 +
3 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2cd83849600f..51d3a7ba7731 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,59 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. Thise is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. Its unclear wheather
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *dev)
+{
+ struct pci_dev *bridge = pci_upstream_bridge(dev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ dev->parent_d3cold = 1;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +752,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
return 0;
fail_drm_dev_init:
@@ -737,6 +791,8 @@ nouveau_drm_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ /* revert our workaround */
+ pdev->parent_d3cold = false;
nouveau_drm_device_remove(dev);
}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 951099279192..6ece05723fa2 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -860,6 +860,14 @@ static int pci_raw_set_power_state(struct pci_dev *dev,
pci_power_t state)
|| (state == PCI_D2 && !dev->d2_support))
return -EIO;
+ /*
+* Power management can be disabled for certain devices as they don't
+* come back up later on runtime_resume. We rely on platform means to
+* cut power consumption instead (e.g. ACPI).
+*/
+ if (state != PCI_D0 && dev->parent_d3cold)
+ return 0;
+
Re: [PATCH 2/4] drm/bridge: dw-hdmi: Fix color space conversion detection
On 02/03/2020 17:42, Jernej Škrabec wrote:
> Dne ponedeljek, 02. marec 2020 ob 10:26:09 CET je Neil Armstrong napisal(a):
>> Hi Jernej,
>>
>> On 29/02/2020 17:30, Jernej Skrabec wrote:
>>> Currently, is_color_space_conversion() compares not only color spaces
>>> but also formats. For example, function would return true if YCbCr 4:4:4
>>> and YCbCr 4:2:2 would be set. Obviously in that case color spaces are
>>> the same.
>>>
>>> Fix that by comparing if both values represent RGB color space.
>>>
>>> Fixes: b21f4b658df8 ("drm: imx: imx-hdmi: move imx-hdmi to
>>> bridge/dw_hdmi")
>>> Signed-off-by: Jernej Skrabec
>>> ---
>>>
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>>> 24965e53d351..9d7bfb1cb213 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -956,7 +956,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>>>
>>> static int is_color_space_conversion(struct dw_hdmi *hdmi)
>>> {
>>>
>>> - return hdmi->hdmi_data.enc_in_bus_format !=
>>> hdmi->hdmi_data.enc_out_bus_format; + return
>>> hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format) !=
>>> + hdmi_bus_fmt_is_rgb(hdmi-
>> hdmi_data.enc_out_bus_format);
>>>
>>> }
>>>
>>> static int is_color_space_decimation(struct dw_hdmi *hdmi)
>>
>> I think in this case you should also fix the CEC enablement to:
>> if (is_color_space_conversion(hdmi) || is_color_space_decimation(hdmi))
>>
>> in dw_hdmi_enable_video_path() otherwise CSC won't be enabled and will be
>> bypassed in decimation case only.
>
> On second thought, I think original implementation is correct, just misnamed.
> Laurent, Neil, do you agree if I replace this patch with patch which renames
> is_color_space_conversion() to is_conversion_needed() ?
Sure,
Neil
>
> Best regards,
> Jernej
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 9/9] drm/vmwgfx: Hook up the helpers to align buffer objects
From: Thomas Hellstrom
Start using the helpers that align buffer object user-space addresses and
buffer object vram addresses to huge page boundaries.
This is to improve the chances of allowing huge page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/drm_file.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 13 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 40fae356d202..1df2fca608c3 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -932,3 +932,4 @@ unsigned long drm_get_unmapped_area(struct file *file,
return current->mm->get_unmapped_area(file, uaddr, len, pgoff, flags);
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+EXPORT_SYMBOL_GPL(drm_get_unmapped_area);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 827458f49112..77d85bc54ef0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1223,6 +1223,18 @@ static void vmw_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
+static unsigned long
+vmw_get_unmapped_area(struct file *file, unsigned long uaddr,
+ unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct drm_file *file_priv = file->private_data;
+ struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
+
+ return drm_get_unmapped_area(file, uaddr, len, pgoff, flags,
+&dev_priv->vma_manager);
+}
+
static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
void *ptr)
{
@@ -1394,6 +1406,7 @@ static const struct file_operations vmwgfx_driver_fops = {
.compat_ioctl = vmw_compat_ioctl,
#endif
.llseek = noop_llseek,
+ .get_unmapped_area = vmw_get_unmapped_area,
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index fe5b7293b8d1..4853bd95bf54 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -929,6 +929,7 @@ extern int vmw_mmap(struct file *filp, struct
vm_area_struct *vma);
extern void vmw_validation_mem_init_ttm(struct vmw_private *dev_priv,
size_t gran);
+
/**
* TTM buffer object driver - vmwgfx_ttm_buffer.c
*/
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index d8ea3dd10af0..34c721ab3ff3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -754,7 +754,7 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
- man->func = &ttm_bo_manager_func;
+ man->func = &vmw_thp_func;
man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/9] mm: Add vmf_insert_pfn_xxx_prot() for huge page-table entries
From: Thomas Hellstrom
For graphics drivers needing to modify the page-protection, add
huge page-table entries counterparts to vmf_insert_pfn_prot().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Acked-by: Christian König
---
include/linux/huge_mm.h | 41 +++--
mm/huge_memory.c| 38 --
2 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 5aca3d1bdb32..f63b0882c1b3 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -47,8 +47,45 @@ extern bool move_huge_pmd(struct vm_area_struct *vma,
unsigned long old_addr,
extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long addr, pgprot_t newprot,
int prot_numa);
-vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write);
-vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write);
+vm_fault_t vmf_insert_pfn_pmd_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write);
+
+/**
+ * vmf_insert_pfn_pmd - insert a pmd size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pmd size pfn. See vmf_insert_pfn() for additional info.
+ *
+ * Return: vm_fault_t value.
+ */
+static inline vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn,
+ bool write)
+{
+ return vmf_insert_pfn_pmd_prot(vmf, pfn, vmf->vma->vm_page_prot, write);
+}
+vm_fault_t vmf_insert_pfn_pud_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write);
+
+/**
+ * vmf_insert_pfn_pud - insert a pud size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pud size pfn. See vmf_insert_pfn() for additional info.
+ *
+ * Return: vm_fault_t value.
+ */
+static inline vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn,
+ bool write)
+{
+ return vmf_insert_pfn_pud_prot(vmf, pfn, vmf->vma->vm_page_prot, write);
+}
+
enum transparent_hugepage_flag {
TRANSPARENT_HUGEPAGE_FLAG,
TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index ff7a8b85c3ba..e7c69882861d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -824,11 +824,24 @@ static void insert_pfn_pmd(struct vm_area_struct *vma,
unsigned long addr,
pte_free(mm, pgtable);
}
-vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write)
+/**
+ * vmf_insert_pfn_pmd_prot - insert a pmd size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pmd size pfn. See vmf_insert_pfn() for additional info and
+ * also consult the vmf_insert_mixed_prot() documentation when
+ * @pgprot != @vmf->vma->vm_page_prot.
+ *
+ * Return: vm_fault_t value.
+ */
+vm_fault_t vmf_insert_pfn_pmd_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write)
{
unsigned long addr = vmf->address & PMD_MASK;
struct vm_area_struct *vma = vmf->vma;
- pgprot_t pgprot = vma->vm_page_prot;
pgtable_t pgtable = NULL;
/*
@@ -856,7 +869,7 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t
pfn, bool write)
insert_pfn_pmd(vma, addr, vmf->pmd, pfn, pgprot, write, pgtable);
return VM_FAULT_NOPAGE;
}
-EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd);
+EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd_prot);
#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
static pud_t maybe_pud_mkwrite(pud_t pud, struct vm_area_struct *vma)
@@ -902,11 +915,24 @@ static void insert_pfn_pud(struct vm_area_struct *vma,
unsigned long addr,
spin_unlock(ptl);
}
-vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write)
+/**
+ * vmf_insert_pfn_pud_prot - insert a pud size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pud size pfn. See vmf_insert_pfn() for additional info and
+ * also consult the vmf_insert_mixed_prot() documentation when
+ * @pgprot != @vmf->vma->vm_page_prot.
+ *
+ * Return: vm_fault_t value.
+ */
+vm_fault_t vmf_insert_pfn_pud_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write)
{
unsigned long addr = vmf->address & PUD_MASK;
struct vm_area_struct *vma = vmf->vma;
- pgprot_t pgpro
[PATCH v5 8/9] drm/vmwgfx: Introduce a huge page aligning TTM range manager
From: Thomas Hellstrom
Using huge page-table entries requires that the physical address of the
start of a buffer object is huge page size aligned.
Make a special version of the TTM range manager that accomplishes this,
but falls back to a smaller page size alignment (PUD->PMD, PMD->NORMAL)
to avoid eviction.
If other drivers want to use it in the future, it can be made a
TTM generic helper. Note that drivers can force eviction for a certain
alignment by assigning the TTM GPU alignment correspondingly.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/Makefile | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 7 ++
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 166
3 files changed, 174 insertions(+)
create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index c877a21a0739..421dd2a497a5 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -11,4 +11,5 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o
vmwgfx_drv.o \
vmwgfx_validation.o vmwgfx_page_dirty.o \
ttm_object.o ttm_lock.o
+vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index bb2757c98f0a..fe5b7293b8d1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1435,6 +1435,13 @@ vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
enum page_entry_size pe_size);
#endif
+/* Transparent hugepage support - vmwgfx_thp.c */
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+extern const struct ttm_mem_type_manager_func vmw_thp_func;
+#else
+#define vmw_thp_func ttm_bo_manager_func
+#endif
+
/**
* VMW_DEBUG_KMS - Debug output for kernel mode-setting
*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
new file mode 100644
index ..b7c816ba7166
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Huge page-table-entry support for IO memory.
+ *
+ * Copyright (C) 2007-2019 Vmware, Inc. All rights reservedd.
+ */
+#include "vmwgfx_drv.h"
+#include
+#include
+#include
+
+/**
+ * struct vmw_thp_manager - Range manager implementing huge page alignment
+ *
+ * @mm: The underlying range manager. Protected by @lock.
+ * @lock: Manager lock.
+ */
+struct vmw_thp_manager {
+ struct drm_mm mm;
+ spinlock_t lock;
+};
+
+static int vmw_thp_insert_aligned(struct drm_mm *mm, struct drm_mm_node *node,
+ unsigned long align_pages,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem,
+ unsigned long lpfn,
+ enum drm_mm_insert_mode mode)
+{
+ if (align_pages >= mem->page_alignment &&
+ (!mem->page_alignment || align_pages % mem->page_alignment == 0)) {
+ return drm_mm_insert_node_in_range(mm, node,
+ mem->num_pages,
+ align_pages, 0,
+ place->fpfn, lpfn, mode);
+ }
+
+ return -ENOSPC;
+}
+
+static int vmw_thp_get_node(struct ttm_mem_type_manager *man,
+ struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+ struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
+ struct drm_mm *mm = &rman->mm;
+ struct drm_mm_node *node;
+ unsigned long align_pages;
+ unsigned long lpfn;
+ enum drm_mm_insert_mode mode = DRM_MM_INSERT_BEST;
+ int ret;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+
+ lpfn = place->lpfn;
+ if (!lpfn)
+ lpfn = man->size;
+
+ mode = DRM_MM_INSERT_BEST;
+ if (place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
+
+ spin_lock(&rman->lock);
+ if (IS_ENABLED(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)) {
+ align_pages = (HPAGE_PUD_SIZE >> PAGE_SHIFT);
+ if (mem->num_pages >= align_pages) {
+ ret = vmw_thp_insert_aligned(mm, node, align_pages,
+place, mem, lpfn, mode);
+ if (!ret)
+ goto found_unlock;
+ }
+ }
[PATCH v5 7/9] drm: Add a drm_get_unmapped_area() helper
From: Thomas Hellstrom
Unaligned virtual addresses makes it unlikely that huge page-table entries
can be used.
So align virtual buffer object address huge page boundaries to the
underlying physical address huge page boundaries taking buffer object
sizes into account to determine when it might be possible to use huge
page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/drm_file.c | 136 +
include/drm/drm_file.h | 5 ++
2 files changed, 141 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 92d16724f949..40fae356d202 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -39,10 +39,13 @@
#include
#include
+#include
+
#include
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -796,3 +799,136 @@ struct file *mock_drm_getfile(struct drm_minor *minor,
unsigned int flags)
return file;
}
EXPORT_SYMBOL_FOR_TESTS_ONLY(mock_drm_getfile);
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * drm_addr_inflate() attempts to construct an aligned area by inflating
+ * the area size and skipping the unaligned start of the area.
+ * adapted from shmem_get_unmapped_area()
+ */
+static unsigned long drm_addr_inflate(unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags,
+ unsigned long huge_size)
+{
+ unsigned long offset, inflated_len;
+ unsigned long inflated_addr;
+ unsigned long inflated_offset;
+
+ offset = (pgoff << PAGE_SHIFT) & (huge_size - 1);
+ if (offset && offset + len < 2 * huge_size)
+ return addr;
+ if ((addr & (huge_size - 1)) == offset)
+ return addr;
+
+ inflated_len = len + huge_size - PAGE_SIZE;
+ if (inflated_len > TASK_SIZE)
+ return addr;
+ if (inflated_len < len)
+ return addr;
+
+ inflated_addr = current->mm->get_unmapped_area(NULL, 0, inflated_len,
+ 0, flags);
+ if (IS_ERR_VALUE(inflated_addr))
+ return addr;
+ if (inflated_addr & ~PAGE_MASK)
+ return addr;
+
+ inflated_offset = inflated_addr & (huge_size - 1);
+ inflated_addr += offset - inflated_offset;
+ if (inflated_offset > offset)
+ inflated_addr += huge_size;
+
+ if (inflated_addr > TASK_SIZE - len)
+ return addr;
+
+ return inflated_addr;
+}
+
+/**
+ * drm_get_unmapped_area() - Get an unused user-space virtual memory area
+ * suitable for huge page table entries.
+ * @file: The struct file representing the address space being mmap()'d.
+ * @uaddr: Start address suggested by user-space.
+ * @len: Length of the area.
+ * @pgoff: The page offset into the address space.
+ * @flags: mmap flags
+ * @mgr: The address space manager used by the drm driver. This argument can
+ * probably be removed at some point when all drivers use the same
+ * address space manager.
+ *
+ * This function attempts to find an unused user-space virtual memory area
+ * that can accommodate the size we want to map, and that is properly
+ * aligned to facilitate huge page table entries matching actual
+ * huge pages or huge page aligned memory in buffer objects. Buffer objects
+ * are assumed to start at huge page boundary pfns (io memory) or be
+ * populated by huge pages aligned to the start of the buffer object
+ * (system- or coherent memory). Adapted from shmem_get_unmapped_area.
+ *
+ * Return: aligned user-space address.
+ */
+unsigned long drm_get_unmapped_area(struct file *file,
+ unsigned long uaddr, unsigned long len,
+ unsigned long pgoff, unsigned long flags,
+ struct drm_vma_offset_manager *mgr)
+{
+ unsigned long addr;
+ unsigned long inflated_addr;
+ struct drm_vma_offset_node *node;
+
+ if (len > TASK_SIZE)
+ return -ENOMEM;
+
+ /*
+* @pgoff is the file page-offset the huge page boundaries of
+* which typically aligns to physical address huge page boundaries.
+* That's not true for DRM, however, where physical address huge
+* page boundaries instead are aligned with the offset from
+* buffer object start. So adjust @pgoff to be the offset from
+* buffer object start.
+*/
+ drm_vma_offset_lock_lookup(mgr);
+ node = drm_vma_offset_lookup_locked(mgr, pgoff, 1);
+ if (node)
+
[PATCH v5 0/9] Huge page-table entries for TTM
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables
huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code
take the same path as DAX when splitting huge- and giant page table entries,
(which currently means zapping the page-table entry and rely on re-faulting).
Patch 3 makes the mm code split existing huge page-table entries
on huge_fault fallbacks. Typically on COW or on buffer-objects that want
write-notify. COW and write-notification is always done on the lowest
page-table level. See the patch log message for additional considerations.
Patch 4 introduces functions to allow the graphics drivers to manipulate
the caching- and encryption flags of huge page-table entries without ugly
hacks.
Patch 5 implements the huge_fault handler in TTM.
This enables huge page-table entries, provided that the kernel is configured
to support transhuge pages, either by default or using madvise().
However, they are unlikely to be inserted unless the kernel buffer object
pfns and user-space addresses align perfectly. There are various options
here, but since buffer objects that reside in system pages typically start
at huge page boundaries if they are backed by huge pages, we try to enforce
buffer object starting pfns and user-space addresses to be huge page-size
aligned if their size exceeds a huge page-size. If pud-size transhuge
("giant") pages are enabled by the arch, the same holds for those.
Patch 6 implements a specialized huge_fault handler for vmwgfx.
The vmwgfx driver may perform dirty-tracking and needs some special code
to handle that correctly.
Patch 7 implements a drm helper to align user-space addresses according
to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for
graphics IO memory. This may later be reused by other graphics drivers
if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver.
A similar change is needed for graphics drivers that want a reasonable
likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned,
its size will NOT be inflated by this patchset. This means that the buffer
object tail will use smaller size page-table entries and thus no memory
overhead occurs. Drivers that want to pay the memory overhead price need to
implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to
work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing
using a modified kernel (to support 1GB page allocations) and a fake vmwgfx
TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO
memory resources.
Comments and suggestions welcome.
Thomas
Changes since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase
adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support
transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title.
Changes since v3:
* Added reviews and acks
* Implemented ugly but generic ttm_pgprot_is_wrprotecting() instead of arch
specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
[1]
The below test program generates the following gnu time output when run on a
vmwgfx-enabled kernel without the patch series:
4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k
0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k
0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal
graphics applications, but due to the aggressive buffer object caching in
vmwgfx user-space drivers the CPU time reduction is within the error marginal.
#include
#include
#include
#include
static void checkerr(int ret, const char *name)
{
if (ret < 0) {
perror(name);
exit(-1);
}
}
int main(int agc, const char *argv[])
{
struct drm_mode_create_dumb c_arg = {0};
struct drm_mode_map_dumb m_arg = {0};
struct drm_mode_destroy_dumb d_arg = {0};
int ret, i, fd;
void *map;
fd = open("/dev/dri/card0", O_RDWR);
checkerr(fd, argv[0]);
for (i = 0; i < 1; ++i) {
c_arg.bpp = 32;
c_arg.width = 1024;
c_arg.height = 1024;
ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &c_arg);
checkerr(fd, argv[0]);
m_arg.han
[PATCH v5 1/9] fs: Constify vma argument to vma_is_dax
From: Thomas Hellstrom
The function is used by upcoming vma_is_special_huge() with which we want
to use a const vma argument. Since for vma_is_dax() the vma argument is
only dereferenced for reading, constify it.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3cd4fe6b845e..2b38ce5b73ad 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3391,7 +3391,7 @@ static inline bool io_is_direct(struct file *filp)
return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
}
-static inline bool vma_is_dax(struct vm_area_struct *vma)
+static inline bool vma_is_dax(const struct vm_area_struct *vma)
{
return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
}
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/9] drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
From: Thomas Hellstrom
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.
Note that for huge page-faults to occur, either the kernel needs to be
compiled with trans-huge-pages always enabled, or the kernel needs to be
compiled with trans-huge-pages enabled using madvise, and the user-space
app needs to call madvise() to enable trans-huge pages on a per-mapping
basis.
Furthermore huge page-faults will not succeed unless buffer objects and
user-space addresses are aligned on huge page size boundaries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 161 -
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 3 +-
3 files changed, 161 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 389128b8c4dd..0af14835504c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -156,6 +156,89 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_vm_reserve);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/**
+ * ttm_bo_vm_insert_huge - Insert a pfn for PUD or PMD faults
+ * @vmf: Fault data
+ * @bo: The buffer object
+ * @page_offset: Page offset from bo start
+ * @fault_page_size: The size of the fault in pages.
+ * @pgprot: The page protections.
+ * Does additional checking whether it's possible to insert a PUD or PMD
+ * pfn and performs the insertion.
+ *
+ * Return: VM_FAULT_NOPAGE on successful insertion, VM_FAULT_FALLBACK if
+ * a huge fault was not possible, or on insertion error.
+ */
+static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,
+ struct ttm_buffer_object *bo,
+ pgoff_t page_offset,
+ pgoff_t fault_page_size,
+ pgprot_t pgprot)
+{
+ pgoff_t i;
+ vm_fault_t ret;
+ unsigned long pfn;
+ pfn_t pfnt;
+ struct ttm_tt *ttm = bo->ttm;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
+
+ /* Fault should not cross bo boundary. */
+ page_offset &= ~(fault_page_size - 1);
+ if (page_offset + fault_page_size > bo->num_pages)
+ goto out_fallback;
+
+ if (bo->mem.bus.is_iomem)
+ pfn = ttm_bo_io_mem_pfn(bo, page_offset);
+ else
+ pfn = page_to_pfn(ttm->pages[page_offset]);
+
+ /* pfn must be fault_page_size aligned. */
+ if ((pfn & (fault_page_size - 1)) != 0)
+ goto out_fallback;
+
+ /* Check that memory is contiguous. */
+ if (!bo->mem.bus.is_iomem) {
+ for (i = 1; i < fault_page_size; ++i) {
+ if (page_to_pfn(ttm->pages[page_offset + i]) != pfn + i)
+ goto out_fallback;
+ }
+ } else if (bo->bdev->driver->io_mem_pfn) {
+ for (i = 1; i < fault_page_size; ++i) {
+ if (ttm_bo_io_mem_pfn(bo, page_offset + i) != pfn + i)
+ goto out_fallback;
+ }
+ }
+
+ pfnt = __pfn_to_pfn_t(pfn, PFN_DEV);
+ if (fault_page_size == (HPAGE_PMD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pmd_prot(vmf, pfnt, pgprot, write);
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+ else if (fault_page_size == (HPAGE_PUD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pud_prot(vmf, pfnt, pgprot, write);
+#endif
+ else
+ WARN_ON_ONCE(ret = VM_FAULT_FALLBACK);
+
+ if (ret != VM_FAULT_NOPAGE)
+ goto out_fallback;
+
+ return VM_FAULT_NOPAGE;
+out_fallback:
+ count_vm_event(THP_FAULT_FALLBACK);
+ return VM_FAULT_FALLBACK;
+}
+#else
+static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,
+ struct ttm_buffer_object *bo,
+ pgoff_t page_offset,
+ pgoff_t fault_page_size,
+ pgprot_t pgprot)
+{
+ return VM_FAULT_FALLBACK;
+}
+#endif
+
/**
* ttm_bo_vm_fault_reserved - TTM fault helper
* @vmf: The struct vm_fault given as argument to the fault callback
@@ -163,6 +246,7 @@ EXPORT_SYMBOL(ttm_bo_vm_reserve);
* @num_prefault: Maximum number of prefault pages. The caller may want to
* specify this based on madvice settings and the size of the GPU object
* backed by the memory.
+ * @fault_page_size: The size of the fault in p
[PATCH v5 3/9] mm: Split huge pages on write-notify or COW
From: Thomas Hellstrom
The functions wp_huge_pmd() and wp_huge_pud() currently relies on the
huge_fault() callback to split huge page table entries if needed.
However for module users that requires export of the split_huge_xxx()
functionality which may be undesired. Instead split pre-existing huge
page-table entries on VM_FAULT_FALLBACK return.
We currently only do COW and write-notify on the PTE level, so if the
huge_fault() handler returns VM_FAULT_FALLBACK on wp faults,
split the huge pages and page-table entries. Also do this for huge PUDs
if there is no huge_fault() handler and the vma is not anonymous, similar
to how it's done for PMDs.
Note that fs/dax.c still does the splitting in the huge_fault() handler, but as
huge_fault() A follow-up patch can remove the dax.c split_huge_pmd() if needed.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Acked-by: Christian König
---
mm/memory.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 0bccc622e482..1e3fc1988790 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3932,11 +3932,14 @@ static inline vm_fault_t wp_huge_pmd(struct vm_fault
*vmf, pmd_t orig_pmd)
{
if (vma_is_anonymous(vmf->vma))
return do_huge_pmd_wp_page(vmf, orig_pmd);
- if (vmf->vma->vm_ops->huge_fault)
- return vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PMD);
+ if (vmf->vma->vm_ops->huge_fault) {
+ vm_fault_t ret = vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PMD);
- /* COW handled on pte level: split pmd */
- VM_BUG_ON_VMA(vmf->vma->vm_flags & VM_SHARED, vmf->vma);
+ if (!(ret & VM_FAULT_FALLBACK))
+ return ret;
+ }
+
+ /* COW or write-notify handled on pte level: split pmd. */
__split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL);
return VM_FAULT_FALLBACK;
@@ -3949,12 +3952,20 @@ static inline bool vma_is_accessible(struct
vm_area_struct *vma)
static vm_fault_t create_huge_pud(struct vm_fault *vmf)
{
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#if defined(CONFIG_TRANSPARENT_HUGEPAGE) &&\
+ defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
/* No support for anonymous transparent PUD pages yet */
if (vma_is_anonymous(vmf->vma))
- return VM_FAULT_FALLBACK;
- if (vmf->vma->vm_ops->huge_fault)
- return vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PUD);
+ goto split;
+ if (vmf->vma->vm_ops->huge_fault) {
+ vm_fault_t ret = vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PUD);
+
+ if (!(ret & VM_FAULT_FALLBACK))
+ return ret;
+ }
+split:
+ /* COW or write-notify not handled on PUD level: split pud.*/
+ __split_huge_pud(vmf->vma, vmf->pud, vmf->address);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
return VM_FAULT_FALLBACK;
}
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/9] mm: Introduce vma_is_special_huge
From: Thomas Hellstrom
For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages
and -page table entries, introduce vma_is_special_huge() that takes the
same codepaths as vma_is_dax().
The use of "special" follows the definition in memory.c, vm_normal_page():
"Special" mappings do not wish to be associated with a "struct page"
(either it doesn't exist, or it exists but they don't want to touch it)
For PAGE_SIZE pages, "special" is determined per page table entry to be
able to deal with COW pages. But since we don't have huge COW pages,
we can classify a vma as either "special huge" or "normal huge".
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Acked-by: Christian König
---
include/linux/mm.h | 17 +
mm/huge_memory.c | 6 +++---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 52269e56c514..e61cf3f609b4 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2863,6 +2863,23 @@ extern long copy_huge_page_from_user(struct page
*dst_page,
const void __user *usr_src,
unsigned int pages_per_huge_page,
bool allow_pagefault);
+
+/**
+ * vma_is_special_huge - Are transhuge page-table entries considered special?
+ * @vma: Pointer to the struct vm_area_struct to consider
+ *
+ * Whether transhuge page-table entries are considered "special" following
+ * the definition in vm_normal_page().
+ *
+ * Return: true if transhuge page-table entries should be considered special,
+ * false otherwise.
+ */
+static inline bool vma_is_special_huge(const struct vm_area_struct *vma)
+{
+ return vma_is_dax(vma) || (vma->vm_file &&
+ (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)));
+}
+
#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
#ifdef CONFIG_DEBUG_PAGEALLOC
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b08b199f9a11..ff7a8b85c3ba 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1802,7 +1802,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct
vm_area_struct *vma,
orig_pmd = pmdp_huge_get_and_clear_full(tlb->mm, addr, pmd,
tlb->fullmm);
tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
- if (vma_is_dax(vma)) {
+ if (vma_is_special_huge(vma)) {
if (arch_needs_pgtable_deposit())
zap_deposited_table(tlb->mm, pmd);
spin_unlock(ptl);
@@ -2066,7 +2066,7 @@ int zap_huge_pud(struct mmu_gather *tlb, struct
vm_area_struct *vma,
*/
pudp_huge_get_and_clear_full(tlb->mm, addr, pud, tlb->fullmm);
tlb_remove_pud_tlb_entry(tlb, pud, addr);
- if (vma_is_dax(vma)) {
+ if (vma_is_special_huge(vma)) {
spin_unlock(ptl);
/* No zero page support yet */
} else {
@@ -2175,7 +2175,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct
*vma, pmd_t *pmd,
*/
if (arch_needs_pgtable_deposit())
zap_deposited_table(mm, pmd);
- if (vma_is_dax(vma))
+ if (vma_is_special_huge(vma))
return;
page = pmd_page(_pmd);
if (!PageDirty(page) && pmd_dirty(_pmd))
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 6/9] drm/vmwgfx: Support huge page faults
From: Thomas Hellstrom
With vmwgfx dirty-tracking we need a specialized huge_fault
callback. Implement and hook it up.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 ++
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 74 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 5 +-
3 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 86b69397d166..bb2757c98f0a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1430,6 +1430,10 @@ void vmw_bo_dirty_unmap(struct vmw_buffer_object *vbo,
pgoff_t start, pgoff_t end);
vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf);
vm_fault_t vmw_bo_vm_mkwrite(struct vm_fault *vmf);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
+ enum page_entry_size pe_size);
+#endif
/**
* VMW_DEBUG_KMS - Debug output for kernel mode-setting
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
index 17a5dca7b921..cde3e07ebaf7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
@@ -473,7 +473,7 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf)
* a lot of unnecessary write faults.
*/
if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE)
- prot = vma->vm_page_prot;
+ prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED);
else
prot = vm_get_page_prot(vma->vm_flags);
@@ -486,3 +486,75 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf)
return ret;
}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
+ enum page_entry_size pe_size)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
+ vma->vm_private_data;
+ struct vmw_buffer_object *vbo =
+ container_of(bo, struct vmw_buffer_object, base);
+ pgprot_t prot;
+ vm_fault_t ret;
+ pgoff_t fault_page_size;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
+ bool is_cow_mapping =
+ (vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
+
+ switch (pe_size) {
+ case PE_SIZE_PMD:
+ fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
+ break;
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+ case PE_SIZE_PUD:
+ fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
+ break;
+#endif
+ default:
+ WARN_ON_ONCE(1);
+ return VM_FAULT_FALLBACK;
+ }
+
+ /* Always do write dirty-tracking and COW on PTE level. */
+ if (write && (READ_ONCE(vbo->dirty) || is_cow_mapping))
+ return VM_FAULT_FALLBACK;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return ret;
+
+ if (vbo->dirty) {
+ pgoff_t allowed_prefault;
+ unsigned long page_offset;
+
+ page_offset = vmf->pgoff -
+ drm_vma_node_start(&bo->base.vma_node);
+ if (page_offset >= bo->num_pages ||
+ vmw_resources_clean(vbo, page_offset,
+ page_offset + PAGE_SIZE,
+ &allowed_prefault)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out_unlock;
+ }
+
+ /*
+* Write protect, so we get a new fault on write, and can
+* split.
+*/
+ prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED);
+ } else {
+ prot = vm_get_page_prot(vma->vm_flags);
+ }
+
+ ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ return ret;
+
+out_unlock:
+ dma_resv_unlock(bo->base.resv);
+
+ return ret;
+}
+#endif
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index aa7e50f63b94..3c03b1746661 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -34,7 +34,10 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
.page_mkwrite = vmw_bo_vm_mkwrite,
.fault = vmw_bo_vm_fault,
.open = ttm_bo_vm_open,
- .close = ttm_bo_vm_close
+ .close = ttm_bo_vm_close,
+#ifdef
Re: [PATCH v4 0/9] Huge page-table entries for TTM
On 3/1/20 5:04 AM, Andrew Morton wrote: On Fri, 28 Feb 2020 14:08:04 +0100 Thomas Hellström (VMware) wrote: I'm wondering what's the best way here to get the patches touching mm reviewed and accepted? While drm people and VMware internal people have looked at them, I think the huge_fault() fallback splitting and the introduction of vma_is_special_huge() needs looking at more thoroughly. Apart from that, if possible, I think the best way to merge this series is also through a DRM tree. Patches 1-3 look OK to me. I just had a few commenting/changelogging niggles. Thanks for reviewing, Andrew. I just updated the series following your comments. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH resend 1/2] drm/i915: panel: Use intel_panel_compute_brightness() from pwm_setup_backlight()
Hi All,
On 2/21/20 6:29 PM, Hans de Goede wrote:
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.
Signed-off-by: Hans de Goede
ping? Any chance I can get a review from someone on this series?
Both patches are pretty trivial really...
Regards,
Hans
---
drivers/gpu/drm/i915/display/intel_panel.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7b3ec6eb3382..9ebee7d93414 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1843,6 +1843,7 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_panel *panel = &connector->panel;
const char *desc;
+ u32 level, ns;
int retval;
/* Get the right PWM chip for DSI backlight according to VBT */
@@ -1866,8 +1867,12 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
*/
pwm_apply_args(panel->backlight.pwm);
- retval = pwm_config(panel->backlight.pwm, CRC_PMIC_PWM_PERIOD_NS,
- CRC_PMIC_PWM_PERIOD_NS);
+ panel->backlight.min = 0; /* 0% */
+ panel->backlight.max = 100; /* 100% */
+ level = intel_panel_compute_brightness(connector, 100);
+ ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
+
+ retval = pwm_config(panel->backlight.pwm, ns, CRC_PMIC_PWM_PERIOD_NS);
if (retval < 0) {
DRM_ERROR("Failed to configure the pwm chip\n");
pwm_put(panel->backlight.pwm);
@@ -1875,11 +1880,10 @@ static int pwm_setup_backlight(struct intel_connector
*connector,
return retval;
}
- panel->backlight.min = 0; /* 0% */
- panel->backlight.max = 100; /* 100% */
- panel->backlight.level = DIV_ROUND_UP(
-pwm_get_duty_cycle(panel->backlight.pwm) * 100,
-CRC_PMIC_PWM_PERIOD_NS);
+ level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
+CRC_PMIC_PWM_PERIOD_NS);
+ panel->backlight.level =
+ intel_panel_compute_brightness(connector, level);
panel->backlight.enabled = panel->backlight.level != 0;
DRM_INFO("Using %s PWM for LCD backlight control\n", desc);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Hi,
On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> On Fri, 21 Feb 2020 10:08:42 +0100
> Neil Armstrong wrote:
>
> > Amlogic uses a proprietary lossless image compression protocol and format
> > for their hardware video codec accelerators, either video decoders or
> > video input encoders.
> >
> > It considerably reduces memory bandwidth while writing and reading
> > frames in memory.
> >
> > The underlying storage is considered to be 3 components, 8bit or 10-bit
> > per component, YCbCr 420, single plane :
> > - DRM_FORMAT_YUV420_8BIT
> > - DRM_FORMAT_YUV420_10BIT
> >
> > This modifier will be notably added to DMA-BUF frames imported from the V4L2
> > Amlogic VDEC decoder.
> >
> > At least two options are supported :
> > - Scatter mode: the buffer is filled with a IOMMU scatter table referring
> > to the encoder current memory layout. This mode if more efficient in terms
> > of memory allocation but frames are not dumpable and only valid during
> > until
> > the buffer is freed and back in control of the encoder
> > - Memory saving: when the pixel bpp is 8b, the size of the superblock can
> > be reduced, thus saving memory.
> >
> > Signed-off-by: Neil Armstrong
> > ---
> > include/uapi/drm/drm_fourcc.h | 56 +++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d8..8a6e87bacadb 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -309,6 +309,7 @@ extern "C" {
> > #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> > +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> >
> > /* add more to the end as needed */
> >
> > @@ -804,6 +805,61 @@ extern "C" {
> > */
> > #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
> >
> > +/*
> > + * Amlogic Video Framebuffer Compression modifiers
> > + *
> > + * Amlogic uses a proprietary lossless image compression protocol and
> > format
> > + * for their hardware video codec accelerators, either video decoders or
> > + * video input encoders.
> > + *
> > + * It considerably reduces memory bandwidth while writing and reading
> > + * frames in memory.
> > + * Implementation details may be platform and SoC specific, and shared
> > + * between the producer and the decoder on the same platform.
>
> Hi,
>
> after a lengthy IRC discussion on #dri-devel, this "may be platform and
> SoC specific" is a problem.
>
> It can be an issue in two ways:
>
> - If something in the data acts like a sub-modifier, then advertising
> support for one modifier does not really tell if the data layout is
> supported or not.
>
> - If you need to know the platform and/or SoC to be able to interpret
> the data, it means the modifier is ill-defined and cannot be used in
> inter-machine communication (e.g. Pipewire).
>
Playing devil's advocate, the comment sounds similar to
I915_FORMAT_MOD_{X,Y}_TILED:
* This format is highly platforms specific and not useful for cross-driver
* sharing. It exists since on a given platform it does uniquely identify the
* layout in a simple way for i915-specific userspace.
Isn't the statement that this for sharing between producer and decoder
_on the same platform_ a similar clause with the same effect?
What advantage is there to exposing the gory details? For Arm AFBC
it's necessary because IP on the SoC can be (likely to be) from
different vendors with different capabilities.
If this is only for talking between Amlogic IP on the same SoC, and
those devices support all the same "flavours", I don't see what is
gained by making userspace care about internals.
Thanks,
-Brian
> Neil mentioned the data contains a "header" that further specifies
> things, but there is no specification about the header itself.
> Therefore I don't think we can even know if the header contains
> something that acts like a sub-modifier or not.
>
> All this sounds like the modifier definitions here are not enough to
> fully interpret the data. At the very least I would expect a reference
> to a document explaining the "header", or even better, a kernel ReST
> doc.
>
> I wonder if this is at all suitable as a DRM format modifier as is. I
> have been assuming that a modifier together with all the usual FB
> parameters should be enough to interpret the stored data, but in this
> case I have doubt it actually is.
>
> I have no problem with proprietary data layouts as long as they are
> fully specified.
>
> I do feel like I would not be able to write a software decoder for this
> set of modifiers given the details below.
>
>
> Thanks,
> pq
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey wrote:
>
> Hi,
>
> On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > On Fri, 21 Feb 2020 10:08:42 +0100
> > Neil Armstrong wrote:
> >
> > > Amlogic uses a proprietary lossless image compression protocol and format
> > > for their hardware video codec accelerators, either video decoders or
> > > video input encoders.
> > >
> > > It considerably reduces memory bandwidth while writing and reading
> > > frames in memory.
> > >
> > > The underlying storage is considered to be 3 components, 8bit or 10-bit
> > > per component, YCbCr 420, single plane :
> > > - DRM_FORMAT_YUV420_8BIT
> > > - DRM_FORMAT_YUV420_10BIT
> > >
> > > This modifier will be notably added to DMA-BUF frames imported from the
> > > V4L2
> > > Amlogic VDEC decoder.
> > >
> > > At least two options are supported :
> > > - Scatter mode: the buffer is filled with a IOMMU scatter table referring
> > > to the encoder current memory layout. This mode if more efficient in
> > > terms
> > > of memory allocation but frames are not dumpable and only valid during
> > > until
> > > the buffer is freed and back in control of the encoder
> > > - Memory saving: when the pixel bpp is 8b, the size of the superblock can
> > > be reduced, thus saving memory.
> > >
> > > Signed-off-by: Neil Armstrong
> > > ---
> > > include/uapi/drm/drm_fourcc.h | 56 +++
> > > 1 file changed, 56 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > > index 8bc0b31597d8..8a6e87bacadb 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -309,6 +309,7 @@ extern "C" {
> > > #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> > > +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> > >
> > > /* add more to the end as needed */
> > >
> > > @@ -804,6 +805,61 @@ extern "C" {
> > > */
> > > #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
> > >
> > > +/*
> > > + * Amlogic Video Framebuffer Compression modifiers
> > > + *
> > > + * Amlogic uses a proprietary lossless image compression protocol and
> > > format
> > > + * for their hardware video codec accelerators, either video decoders or
> > > + * video input encoders.
> > > + *
> > > + * It considerably reduces memory bandwidth while writing and reading
> > > + * frames in memory.
> > > + * Implementation details may be platform and SoC specific, and shared
> > > + * between the producer and the decoder on the same platform.
> >
> > Hi,
> >
> > after a lengthy IRC discussion on #dri-devel, this "may be platform and
> > SoC specific" is a problem.
> >
> > It can be an issue in two ways:
> >
> > - If something in the data acts like a sub-modifier, then advertising
> > support for one modifier does not really tell if the data layout is
> > supported or not.
> >
> > - If you need to know the platform and/or SoC to be able to interpret
> > the data, it means the modifier is ill-defined and cannot be used in
> > inter-machine communication (e.g. Pipewire).
> >
>
> Playing devil's advocate, the comment sounds similar to
> I915_FORMAT_MOD_{X,Y}_TILED:
>
> * This format is highly platforms specific and not useful for cross-driver
> * sharing. It exists since on a given platform it does uniquely identify the
> * layout in a simple way for i915-specific userspace.
Yeah which we regret now. We need to now roll out a new set of
modifiers for at least some of the differences in these on the
modern-ish chips (the old crap is pretty much lost cause anyway).
This was kinda a nasty hack to smooth things over since we have epic
amounts of userspace, but it's really not a great idea (and no one
else really has epic amounts of existing userspace that uses tiling
flags everywhere, this is all new code).
-Daniel
> Isn't the statement that this for sharing between producer and decoder
> _on the same platform_ a similar clause with the same effect?
>
> What advantage is there to exposing the gory details? For Arm AFBC
> it's necessary because IP on the SoC can be (likely to be) from
> different vendors with different capabilities.
>
> If this is only for talking between Amlogic IP on the same SoC, and
> those devices support all the same "flavours", I don't see what is
> gained by making userspace care about internals.
The trouble is if you mix&match IP cores, and one of them supports
flavours A, B, C and the other C, D, E. But all you have is a single
magic modifier for "whatever the flavour is that soc prefers". So
someone gets to stuff this in DT.
Also eventually, maybe, perhaps ARM does grow up into the
client/server space with add-on pcie graphics, and at least for client
you very often end up with integrated + add-in pcie gpu. At that point
you really can't have magic per-soc modifiers anymore.
If people get confused I'm
Re: [PATCH v2] drm/etnaviv: rework perfmon query infrastructure
On Fr, 2020-02-28 at 11:37 +0100, Christian Gmeiner wrote:
> Report the correct perfmon domains and signals depending
> on the supported feature flags.
>
> Reported-by: Dan Carpenter
> Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christian Gmeiner
Thanks, applied to etnaviv/next.
Regards,
Lucas
>
> ---
> Changes V1 -> V2:
> - Handle domain == NULL case better to get rid of BUG_ON(..) usage.
> ---
> drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 59 ---
> 1 file changed, 52 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> index 8adbf2861bff..e6795bafcbb9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> @@ -32,6 +32,7 @@ struct etnaviv_pm_domain {
> };
>
> struct etnaviv_pm_domain_meta {
> + unsigned int feature;
> const struct etnaviv_pm_domain *domains;
> u32 nr_domains;
> };
> @@ -410,36 +411,78 @@ static const struct etnaviv_pm_domain doms_vg[] = {
>
> static const struct etnaviv_pm_domain_meta doms_meta[] = {
> {
> + .feature = chipFeatures_PIPE_3D,
> .nr_domains = ARRAY_SIZE(doms_3d),
> .domains = &doms_3d[0]
> },
> {
> + .feature = chipFeatures_PIPE_2D,
> .nr_domains = ARRAY_SIZE(doms_2d),
> .domains = &doms_2d[0]
> },
> {
> + .feature = chipFeatures_PIPE_VG,
> .nr_domains = ARRAY_SIZE(doms_vg),
> .domains = &doms_vg[0]
> }
> };
>
> +static unsigned int num_pm_domains(const struct etnaviv_gpu *gpu)
> +{
> + unsigned int num = 0, i;
> +
> + for (i = 0; i < ARRAY_SIZE(doms_meta); i++) {
> + const struct etnaviv_pm_domain_meta *meta = &doms_meta[i];
> +
> + if (gpu->identity.features & meta->feature)
> + num += meta->nr_domains;
> + }
> +
> + return num;
> +}
> +
> +static const struct etnaviv_pm_domain *pm_domain(const struct etnaviv_gpu
> *gpu,
> + unsigned int index)
> +{
> + const struct etnaviv_pm_domain *domain = NULL;
> + unsigned int offset = 0, i;
> +
> + for (i = 0; i < ARRAY_SIZE(doms_meta); i++) {
> + const struct etnaviv_pm_domain_meta *meta = &doms_meta[i];
> +
> + if (!(gpu->identity.features & meta->feature))
> + continue;
> +
> + if (meta->nr_domains < (index - offset)) {
> + offset += meta->nr_domains;
> + continue;
> + }
> +
> + domain = meta->domains + (index - offset);
> + }
> +
> + return domain;
> +}
> +
> int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
> struct drm_etnaviv_pm_domain *domain)
> {
> - const struct etnaviv_pm_domain_meta *meta = &doms_meta[domain->pipe];
> + const unsigned int nr_domains = num_pm_domains(gpu);
> const struct etnaviv_pm_domain *dom;
>
> - if (domain->iter >= meta->nr_domains)
> + if (domain->iter >= nr_domains)
> return -EINVAL;
>
> - dom = meta->domains + domain->iter;
> + dom = pm_domain(gpu, domain->iter);
> + if (!dom)
> + return -EINVAL;
>
> domain->id = domain->iter;
> domain->nr_signals = dom->nr_signals;
> strncpy(domain->name, dom->name, sizeof(domain->name));
>
> domain->iter++;
> - if (domain->iter == meta->nr_domains)
> + if (domain->iter == nr_domains)
> domain->iter = 0xff;
>
> return 0;
> @@ -448,14 +491,16 @@ int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
> int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
> struct drm_etnaviv_pm_signal *signal)
> {
> - const struct etnaviv_pm_domain_meta *meta = &doms_meta[signal->pipe];
> + const unsigned int nr_domains = num_pm_domains(gpu);
> const struct etnaviv_pm_domain *dom;
> const struct etnaviv_pm_signal *sig;
>
> - if (signal->domain >= meta->nr_domains)
> + if (signal->domain >= nr_domains)
> return -EINVAL;
>
> - dom = meta->domains + signal->domain;
> + dom = pm_domain(gpu, signal->domain);
> + if (!dom)
> + return -EINVAL;
>
> if (signal->iter >= dom->nr_signals)
> return -EINVAL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/etnaviv: Ignore MC bit when checking for runtime suspend
On Mo, 2020-03-02 at 20:13 +0100, Guido Günther wrote: > At least GC7000 fails to enter runtime suspend for long periods of time since > the MC becomes busy again even when the FE is idle. The rest of the series > makes detecting similar issues easier to debug in the future by checking > all known bits in debugfs and also warning in the EBUSY case. Thanks, series applied to etnaviv/next. > Tested on GC7000 with a reduced runtime delay of 50ms. Patches are > against next-20200226. I've already wondered if 200ms is too long, 50ms sounds more reasonable. Do you have any numbers on the power draw on the i.MX8M with idle GPU, vs. being fully power gated? Regards, Lucas > Thanks to Lucas Stach for pointing me in the right direction. > > Guido Günther (5): > drm/etnaviv: Fix typo in comment > drm/etnaviv: Update idle bits > drm/etnaviv: Consider all kwnown idle bits in debugfs > drm/etnaviv: Ignore MC when checking runtime suspend idleness > drm/etnaviv: Warn when GPU doesn't idle fast enough > > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26 ++ > drivers/gpu/drm/etnaviv/state_hi.xml.h | 7 +++ > 2 files changed, 29 insertions(+), 4 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 0/6] Add AFBC support for Rockchip
This series adds AFBC support for Rockchip. It is inspired by: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c This is the sixth iteration of the afbc series. Compared to v5 it simplifies the way afbc-related helpers are exposed to their users. A new struct drm_afbc_framebuffer is added, which stores afbc-related driver-specific data. Interested drivers need to explicitly allocate an instance of struct drm_afbc_framebuffer, use drm_gem_fb_init_with_funcs() call drm_gem_fb_afbc_init() and do their specific afbc-related checks. There are 3 interested drivers: malidp, komeda and rockchip and I only have rockchip hardware. As Liviu reports, due to the coronavirus outbreak, it is difficult to test komeda now, so, according to his suggestion, I purposedly omit changes to komeda. Malidp is changed accordingly, though, which is a proof that it can be done. Then adding afbc support for rockchip follows the malidp example. I kindly ask for reviewing the series. I need to mention that my ultimate goal is merging afbc for rockchip and I don't have other hardware, so some help from malidp developers/maintainers would be appreciated. Rebased onto drm-misc-next. v5..v6: - reworked the way afbc-specific helpers are exposed to drivers (Daniel) - not checking block size mask in drm_is_afbc (James) - fixed the test for afbc format (Boris) - documented unused afbc format modifier values in drm_afbc_get_superblock_wh() (Boris) - changed drm_is_afbc to a macro - renamed drm_gem_fb_lookup() to drm_gem_fb_objs_lookup() (James) - eliminated storing block/tile alignment constraint in struct drm_afbc_framebuffer (James) - eliminated storing afbc header alignment constraint in struct drm_afbc_framebuffer (James) - eliminated storing afbc payload's offset in struct drm_afbc_framebuffer (James) - moved to taking bpp value from drm_format_info except malidp which doesn't set it properly (James) - removed unrelated coding style fixes in rockchip (Boris) - consolidated 2-line error messages into one-liners in rockchip (Boris) - added checking that there is at most one AFBC plane in vop_crtc_atomic_check() (Boris) - added checking that AFBC format is indeed supported in rockchip_mod_supported() (Boris) - removed requirement of exactly one color plane in rockchip_mod_supported() - removed afbc_win hack in rockchip in favor of adding a field to crtc state and ensuring only one AFBC plane in crtc's atomic check (Boris) v4..v5: - used proper way of subclassing drm_framebuffer (Daniel Vetter) - added documentation to exported functions (Liviu Dudau) - reordered new functions in drm_gem_framebuffer_helper.c to make a saner diff (Liviu Dudau) - used "2" suffix instead of "_special" for the special version of size checks (Liviu Dudau) - dropped unnecessarily added condition in drm_get_format_info() (Liviu Dudau) - dropped "block_size = 0;" trick in framebuffer_check() (Daniel Vetter) - relaxed sticking to 80 characters per line rule in some cases v3..v4: - addressed (some) comments from Daniel Stone, Ezequiel Garcia, Daniel Vetter and James Qian Wang - thank you for input - refactored helpers to ease accommodating drivers with afbc needs - moved afbc checks to helpers - converted komeda, malidp and (the newly added) rockchip to use the afbc helpers - eliminated a separate, dedicated source code file v2..v3: - addressed (some) comments from Daniel Stone, Liviu Dudau, Daniel Vetter and Brian Starkey - thank you all In this iteration some rework has been done. The checking logic is now moved to framebuffer_check() so it is common to all drivers. But the common part is not good for komeda, so this series is not good for merging yet. I kindly ask for feedback whether the changes are in the right direction. I also kindly ask for input on how to accommodate komeda. The CONFIG_DRM_AFBC option has been eliminated in favour of adding drm_afbc.c to drm_kms_helper. v1..v2: - addressed comments from Daniel Stone, Ayan Halder, Mihail Atanassov - coding style fixes Andrzej Pietrasiewicz (6): drm/core: Allow drivers allocate a subclass of struct drm_framebuffer drm/core: Add drm_afbc_framebuffer and a corresponding helper drm/arm/malidp: Factor-in framebuffer creation drm/arm/malidp: Allocate an afbc-specific drm_framebuffer drm/arm/malidp: Switch to afbc helpers drm/rockchip: Add support for afbc drivers/gpu/drm/arm/malidp_drv.c | 150 ++- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 186 +-- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 32 +++- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 136 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 ++ drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 83 - include/drm/drm_framebuffer.h| 45 + include/drm/drm_gem_framebuffer_helper.h
[PATCHv6 2/6] drm/core: Add drm_afbc_framebuffer and a corresponding helper
The new struct contains afbc-specific data.
The new function can be used by drivers which support afbc to complete
the preparation of struct drm_afbc_framebuffer. It must be called after
allocating the said struct and calling drm_gem_fb_init_with_funcs().
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 121 +++
include/drm/drm_framebuffer.h| 45 +++
include/drm/drm_gem_framebuffer_helper.h | 11 ++
3 files changed, 177 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 388a080cd2df..2a30f5b6829f 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -21,6 +21,13 @@
#include
#include
+#define AFBC_HEADER_SIZE 16
+#define AFBC_TH_LAYOUT_ALIGNMENT 8
+#define AFBC_HDR_ALIGN 64
+#define AFBC_SUPERBLOCK_PIXELS 256
+#define AFBC_SUPERBLOCK_ALIGNMENT 128
+#define AFBC_TH_BODY_START_ALIGNMENT 4096
+
/**
* DOC: overview
*
@@ -302,6 +309,120 @@ drm_gem_fb_create_with_dirty(struct drm_device *dev,
struct drm_file *file,
}
EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
+/**
+ * drm_afbc_get_superblock_wh - extract afbc block width/height from modifier
+ * @modifier: the modifier to be looked at
+ * @w: address of a place to store the block width
+ * @h: address of a place to store the block height
+ *
+ * Returns: true if the modifier describes a supported block size
+ */
+bool drm_afbc_get_superblock_wh(u64 modifier, u32 *w, u32 *h)
+{
+ switch (modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ *w = 16;
+ *h = 16;
+ break;
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
+ *w = 32;
+ *h = 8;
+ break;
+ /* no user exists yet - fall through */
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
+ case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
+ default:
+ DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
+ modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
+ return false;
+ }
+ return true;
+}
+EXPORT_SYMBOL_GPL(drm_afbc_get_superblock_wh);
+
+static int drm_gem_afbc_min_size(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *mode_cmd,
+struct drm_afbc_framebuffer *afbc_fb)
+{
+ const struct drm_format_info *info;
+ u32 n_blocks, w_alignment, h_alignment, hdr_alignment;
+ u32 tmp_bpp; /* remove when all users properly encode cpp in
drm_format_info */
+
+ if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0],
&afbc_fb->block_width, &afbc_fb->block_height))
+ return -EINVAL;
+
+ /* tiled header afbc */
+ w_alignment = afbc_fb->block_width;
+ h_alignment = afbc_fb->block_height;
+ hdr_alignment = AFBC_HDR_ALIGN;
+ if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
+ w_alignment *= AFBC_TH_LAYOUT_ALIGNMENT;
+ h_alignment *= AFBC_TH_LAYOUT_ALIGNMENT;
+ hdr_alignment = AFBC_TH_BODY_START_ALIGNMENT;
+ }
+
+ afbc_fb->aligned_width = ALIGN(mode_cmd->width, w_alignment);
+ afbc_fb->aligned_height = ALIGN(mode_cmd->height, h_alignment);
+ afbc_fb->offset = mode_cmd->offsets[0];
+
+ /* Change to always using info->cpp[0] when all users properly encode
it */
+ info = drm_get_format_info(dev, mode_cmd);
+ tmp_bpp = info->cpp[0] ? info->cpp[0] * 8 : afbc_fb->bpp;
+
+ n_blocks = (afbc_fb->aligned_width * afbc_fb->aligned_height) /
AFBC_SUPERBLOCK_PIXELS;
+ afbc_fb->afbc_size = ALIGN(n_blocks * AFBC_HEADER_SIZE, hdr_alignment);
+ afbc_fb->afbc_size += n_blocks * ALIGN(tmp_bpp * AFBC_SUPERBLOCK_PIXELS
/ 8, AFBC_SUPERBLOCK_ALIGNMENT);
+
+ return 0;
+}
+
+/**
+ * drm_gem_fb_afbc_init() - Helper function for drivers using afbc to
+ * fill and validate all the afbc-specific
+ * struct drm_afbc_framebuffer members
+ *
+ * @dev: DRM device
+ * @afbc_fb: afbc-specific framebuffer
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ * @afbc_fb: afbc framebuffer
+ *
+ * This function can be used by drivers which support afbc to complete
+ * the preparation of struct drm_afbc_framebuffer. It must be called after
+ * allocating the said struct and calling drm_gem_fb_init_with_funcs().
+ *
+ * Returns:
+ * Zero on success or a negative error value on failure.
+ */
+int drm_gem_fb_afbc_init(struct drm_device *dev, const struct drm_mode_fb_cmd2
*mode_cmd,
+struct drm_afbc_framebuffer *afbc_fb)
+{
+ const struct drm_format_info *info;
+ struct drm_gem_object **objs;
+ int ret = -EINVAL, i;
+
+ objs
[PATCHv6 1/6] drm/core: Allow drivers allocate a subclass of struct drm_framebuffer
Allow allocating a specialized version of struct drm_framebuffer
by moving the actual fb allocation out of drm_gem_fb_create_with_funcs();
the respective functions names are adjusted to reflect that fact.
Please note, though, that standard size checks are performed on buffers,
so the drm_gem_fb_init_with_funcs() is useful for cases where those
standard size checks are appropriate or at least don't conflict the
checks to be performed in the specialized case.
Thanks to this change the drivers can call drm_gem_fb_init_with_funcs()
having allocated their special version of struct drm_framebuffer, exactly
the way the new version of drm_gem_fb_create_with_funcs() does.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 65 +++-
include/drm/drm_gem_framebuffer_helper.h | 5 ++
2 files changed, 56 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 3a7ace19a902..388a080cd2df 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -55,18 +55,14 @@ struct drm_gem_object *drm_gem_fb_get_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_gem_fb_get_obj);
static struct drm_framebuffer *
-drm_gem_fb_alloc(struct drm_device *dev,
+drm_gem_fb_init(struct drm_device *dev,
+struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object **obj, unsigned int num_planes,
const struct drm_framebuffer_funcs *funcs)
{
- struct drm_framebuffer *fb;
int ret, i;
- fb = kzalloc(sizeof(*fb), GFP_KERNEL);
- if (!fb)
- return ERR_PTR(-ENOMEM);
-
drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
for (i = 0; i < num_planes; i++)
@@ -123,10 +119,13 @@ int drm_gem_fb_create_handle(struct drm_framebuffer *fb,
struct drm_file *file,
EXPORT_SYMBOL(drm_gem_fb_create_handle);
/**
- * drm_gem_fb_create_with_funcs() - Helper function for the
- * &drm_mode_config_funcs.fb_create
- * callback
+ * drm_gem_fb_init_with_funcs() - Helper function for implementing
+ * &drm_mode_config_funcs.fb_create
+ * callback in cases when the driver
+ * allocates a subclass of
+ * struct drm_framebuffer
* @dev: DRM device
+ * @fb: framebuffer object
* @file: DRM file that holds the GEM handle(s) backing the framebuffer
* @mode_cmd: Metadata from the userspace framebuffer creation request
* @funcs: vtable to be used for the new framebuffer object
@@ -134,18 +133,21 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
* This function can be used to set &drm_framebuffer_funcs for drivers that
need
* custom framebuffer callbacks. Use drm_gem_fb_create() if you don't need to
* change &drm_framebuffer_funcs. The function does buffer size validation.
+ * The buffer size validation is for a general case, though, so users should
+ * pay attention to the checks being appropriate for them or, at least,
+ * non-conflicting.
*
* Returns:
* Pointer to a &drm_framebuffer on success or an error pointer on failure.
*/
struct drm_framebuffer *
-drm_gem_fb_create_with_funcs(struct drm_device *dev, struct drm_file *file,
-const struct drm_mode_fb_cmd2 *mode_cmd,
-const struct drm_framebuffer_funcs *funcs)
+drm_gem_fb_init_with_funcs(struct drm_device *dev, struct drm_framebuffer *fb,
+ struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ const struct drm_framebuffer_funcs *funcs)
{
const struct drm_format_info *info;
struct drm_gem_object *objs[4];
- struct drm_framebuffer *fb;
int ret, i;
info = drm_get_format_info(dev, mode_cmd);
@@ -175,7 +177,7 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct
drm_file *file,
}
}
- fb = drm_gem_fb_alloc(dev, mode_cmd, objs, i, funcs);
+ fb = drm_gem_fb_init(dev, fb, mode_cmd, objs, i, funcs);
if (IS_ERR(fb)) {
ret = PTR_ERR(fb);
goto err_gem_object_put;
@@ -189,6 +191,41 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev,
struct drm_file *file,
return ERR_PTR(ret);
}
+EXPORT_SYMBOL_GPL(drm_gem_fb_init_with_funcs);
+
+/**
+ * drm_gem_fb_create_with_funcs() - Helper function for the
+ * &drm_mode_config_funcs.fb_create
+ * callback
+ * @dev: DRM device
+ * @file: DRM file that holds the GEM handle(s) backing the framebuffer
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ * @funcs: vtable to be used for
[PATCHv6 3/6] drm/arm/malidp: Factor-in framebuffer creation
Consolidating framebuffer creation into one function will make it easier
to transition to generic afbc-aware helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 158 +--
1 file changed, 67 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 37d92a06318e..b53fc01baf2b 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -269,112 +269,88 @@ static const struct drm_mode_config_helper_funcs
malidp_mode_config_helpers = {
.atomic_commit_tail = malidp_atomic_commit_tail,
};
-static bool
-malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode_cmd)
+static struct drm_framebuffer *
+malidp_fb_create(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd)
{
- if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
- mode_cmd->modifier[0]) == false)
- return false;
+ if (mode_cmd->modifier[0]) {
+ int n_superblocks = 0;
+ const struct drm_format_info *info;
+ struct drm_gem_object *objs = NULL;
+ u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
+ u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
+
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0]) == false)
+ return ERR_PTR(-EINVAL);
- if (mode_cmd->offsets[0] != 0) {
- DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
- return false;
- }
+ if (mode_cmd->offsets[0] != 0) {
+ DRM_DEBUG_KMS("AFBC buffers' plane offset should be
0\n");
+ return ERR_PTR(-EINVAL);
+ }
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
- DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
- return false;
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
+ if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
+ DRM_DEBUG_KMS("AFBC buffers must be aligned to
16 pixels\n");
+ return ERR_PTR(-EINVAL);
+ }
+ break;
+ default:
+ DRM_DEBUG_KMS("Unsupported AFBC block size\n");
+ return ERR_PTR(-EINVAL);
}
- break;
- default:
- DRM_DEBUG_KMS("Unsupported AFBC block size\n");
- return false;
- }
- return true;
-}
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
+ afbc_superblock_height = 16;
+ afbc_superblock_width = 16;
+ break;
+ default:
+ DRM_DEBUG_KMS("AFBC superblock size is not
supported\n");
+ return ERR_PTR(-EINVAL);
+ }
-static bool
-malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
- struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- int n_superblocks = 0;
- const struct drm_format_info *info;
- struct drm_gem_object *objs = NULL;
- u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
- u32 afbc_superblock_width = 0, afbc_size = 0;
- int bpp = 0;
-
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- afbc_superblock_height = 16;
- afbc_superblock_width = 16;
- break;
- default:
- DRM_DEBUG_KMS("AFBC superblock size is not supported\n");
- return false;
- }
+ info = drm_get_format_info(dev, mode_cmd);
- info = drm_get_format_info(dev, mode_cmd);
+ n_superblocks = (mode_cmd->width / afbc_superblock_width) *
+ (mode_cmd->height / afbc_superblock_height);
- n_superblocks = (mode_cmd->width / afbc_superblock_width) *
- (mode_cmd->height / afbc_superblock_height);
+ bpp = malidp_format_get_bpp(info->format);
- bpp = malidp_format_get_bpp(info->format);
+ afbc_superblock_size =
+ (bpp * afbc_superblock_width * afbc_superblock_height)
+ / BITS_PER_BYTE;
- afbc_superblock_size = (bpp * afbc_superblock_
[PATCHv6 4/6] drm/arm/malidp: Allocate an afbc-specific drm_framebuffer
Prepare for using generic afbc helpers.
Use an existing helper which allows allocating a struct drm_framebuffer
in the driver.
afbc-specific checks should go after drm_gem_fb_init_with_funcs().
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 40 +---
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index b53fc01baf2b..c076d0fd5b28 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -269,10 +269,28 @@ static const struct drm_mode_config_helper_funcs
malidp_mode_config_helpers = {
.atomic_commit_tail = malidp_atomic_commit_tail,
};
+static const struct drm_framebuffer_funcs malidp_fb_funcs = {
+ .destroy= drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+};
+
static struct drm_framebuffer *
malidp_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
+ struct drm_afbc_framebuffer *afbc_fb;
+ struct drm_framebuffer *ret;
+
+ afbc_fb = kzalloc(sizeof(*afbc_fb), GFP_KERNEL);
+ if (!afbc_fb)
+ return ERR_PTR(-ENOMEM);
+
+ ret = drm_gem_fb_init_with_funcs(dev, &afbc_fb->base, file, mode_cmd,
&malidp_fb_funcs);
+ if (IS_ERR_OR_NULL(ret)) {
+ kfree(afbc_fb);
+ return ERR_PTR(-ENOMEM);
+ }
+
if (mode_cmd->modifier[0]) {
int n_superblocks = 0;
const struct drm_format_info *info;
@@ -283,23 +301,23 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
mode_cmd->modifier[0]) == false)
- return ERR_PTR(-EINVAL);
+ goto free_fb;
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be
0\n");
- return ERR_PTR(-EINVAL);
+ goto free_fb;
}
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to
16 pixels\n");
- return ERR_PTR(-EINVAL);
+ goto free_fb;
}
break;
default:
DRM_DEBUG_KMS("Unsupported AFBC block size\n");
- return ERR_PTR(-EINVAL);
+ goto free_fb;
}
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
@@ -309,7 +327,7 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
break;
default:
DRM_DEBUG_KMS("AFBC superblock size is not
supported\n");
- return ERR_PTR(-EINVAL);
+ goto free_fb;
}
info = drm_get_format_info(dev, mode_cmd);
@@ -334,26 +352,30 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
"should be same as width (=%u) * bpp
(=%u)\n",
(mode_cmd->pitches[0] * BITS_PER_BYTE),
mode_cmd->width, bpp);
- return ERR_PTR(-EINVAL);
+ goto free_fb;
}
objs = drm_gem_object_lookup(file, mode_cmd->handles[0]);
if (!objs) {
DRM_DEBUG_KMS("Failed to lookup GEM object\n");
- return ERR_PTR(-EINVAL);
+ goto free_fb;
}
if (objs->size < afbc_size) {
DRM_DEBUG_KMS("buffer size (%zu) too small for AFBC
buffer size = %u\n",
objs->size, afbc_size);
drm_gem_object_put_unlocked(objs);
- return ERR_PTR(-EINVAL);
+ goto free_fb;
}
drm_gem_object_put_unlocked(objs);
}
- return drm_gem_fb_create(dev, file, mode_cmd);
+ return ret;
+
+free_fb:
+ kfree(afbc_fb);
+ return ERR_PTR(-EINVAL);
}
static const struct drm_mode_config_funcs malidp_mode_config_funcs = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 5/6] drm/arm/malidp: Switch to afbc helpers
Use available afbc helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 44 +++-
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c076d0fd5b28..d50b246ce42b 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -291,12 +291,8 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
return ERR_PTR(-ENOMEM);
}
- if (mode_cmd->modifier[0]) {
- int n_superblocks = 0;
+ if (drm_is_afbc(mode_cmd->modifier[0])) {
const struct drm_format_info *info;
- struct drm_gem_object *objs = NULL;
- u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
- u32 afbc_superblock_width = 0, afbc_size = 0;
int bpp = 0;
if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
@@ -320,32 +316,9 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
goto free_fb;
}
- switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
- case AFBC_SIZE_16X16:
- afbc_superblock_height = 16;
- afbc_superblock_width = 16;
- break;
- default:
- DRM_DEBUG_KMS("AFBC superblock size is not
supported\n");
- goto free_fb;
- }
-
info = drm_get_format_info(dev, mode_cmd);
-
- n_superblocks = (mode_cmd->width / afbc_superblock_width) *
- (mode_cmd->height / afbc_superblock_height);
-
bpp = malidp_format_get_bpp(info->format);
- afbc_superblock_size =
- (bpp * afbc_superblock_width * afbc_superblock_height)
- / BITS_PER_BYTE;
-
- afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
- AFBC_SUPERBLK_ALIGNMENT);
- afbc_size += n_superblocks
- * ALIGN(afbc_superblock_size, AFBC_SUPERBLK_ALIGNMENT);
-
if ((mode_cmd->width * bpp) !=
(mode_cmd->pitches[0] * BITS_PER_BYTE)) {
DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE)
(=%u) "
@@ -355,20 +328,11 @@ malidp_fb_create(struct drm_device *dev, struct drm_file
*file,
goto free_fb;
}
- objs = drm_gem_object_lookup(file, mode_cmd->handles[0]);
- if (!objs) {
- DRM_DEBUG_KMS("Failed to lookup GEM object\n");
- goto free_fb;
- }
+ /* eliminate when cpp is properly encoded in drm_format_info */
+ afbc_fb->bpp = bpp;
- if (objs->size < afbc_size) {
- DRM_DEBUG_KMS("buffer size (%zu) too small for AFBC
buffer size = %u\n",
- objs->size, afbc_size);
- drm_gem_object_put_unlocked(objs);
+ if (drm_gem_fb_afbc_init(dev, mode_cmd, afbc_fb))
goto free_fb;
- }
-
- drm_gem_object_put_unlocked(objs);
}
return ret;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 6/6] drm/rockchip: Add support for afbc
This patch adds support for afbc handling. afbc is a compressed format
which reduces the necessary memory bandwidth.
Co-developed-by: Mark Yao
Signed-off-by: Mark Yao
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 32 -
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 136 +++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 83 +++-
5 files changed, 259 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index c5b06048124e..e33c2dcd0d4b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -30,6 +30,7 @@ struct rockchip_crtc_state {
int output_mode;
int output_bpc;
int output_flags;
+ bool enable_afbc;
};
#define to_rockchip_crtc_state(s) \
container_of(s, struct rockchip_crtc_state, base)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 221e72e71432..d153d84bca7b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -57,8 +57,38 @@ static const struct drm_mode_config_helper_funcs
rockchip_mode_config_helpers =
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
+static struct drm_framebuffer *
+rockchip_fb_create(struct drm_device *dev, struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ struct drm_afbc_framebuffer *afbc_fb;
+ struct drm_framebuffer *ret;
+
+ afbc_fb = kzalloc(sizeof(*afbc_fb), GFP_KERNEL);
+ if (!afbc_fb)
+ return ERR_PTR(-ENOMEM);
+
+ ret = drm_gem_fb_init_with_funcs(dev, &afbc_fb->base, file, mode_cmd,
&rockchip_drm_fb_funcs);
+ if (IS_ERR_OR_NULL(ret)) {
+ kfree(afbc_fb);
+ return ret;
+ }
+
+ if (drm_is_afbc(mode_cmd->modifier[0])) {
+ int r;
+
+ r = drm_gem_fb_afbc_init(dev, mode_cmd, afbc_fb);
+ if (r) {
+ kfree(afbc_fb);
+ ret = ERR_PTR(r);
+ }
+ }
+
+ return ret;
+}
+
static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
- .fb_create = drm_gem_fb_create_with_dirty,
+ .fb_create = rockchip_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index cecb2cc781f5..848d5e038f0a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -91,9 +91,21 @@
#define VOP_WIN_TO_INDEX(vop_win) \
((vop_win) - (vop_win)->vop->win)
+#define VOP_AFBC_SET(vop, name, v) \
+ do { \
+ if ((vop)->data->afbc) \
+ vop_reg_set((vop), &(vop)->data->afbc->name, 0, ~0, v,
#name); \
+ } while (0)
+
#define to_vop(x) container_of(x, struct vop, crtc)
#define to_vop_win(x) container_of(x, struct vop_win, base)
+#define AFBC_FMT_RGB5650x0
+#define AFBC_FMT_U8U8U8U8 0x5
+#define AFBC_FMT_U8U8U80x4
+
+#define AFBC_TILE_16x16BIT(4)
+
/*
* The coefficients of the following matrix are all fixed points.
* The format is S2.10 for the 3x3 part of the matrix, and S9.12 for the
offsets.
@@ -274,6 +286,29 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
}
}
+static int vop_convert_afbc_format(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ABGR:
+ return AFBC_FMT_U8U8U8U8;
+ case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_BGR888:
+ return AFBC_FMT_U8U8U8;
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_BGR565:
+ return AFBC_FMT_RGB565;
+ /* either of the below should not be reachable */
+ default:
+ DRM_WARN_ONCE("unsupported AFBC format[%08x]\n", format);
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
static uint16_t scl_vop_cal_scale(enum scale_mode mode, uint32_t src,
uint32_t dst, bool is_horizontal,
int vsu_mode, int *vskiplines)
@@ -598,6 +633,17 @@ static int vop_enable(struct drm_crtc *crtc, struct
drm_crtc_state *old_state)
vop_win_disable(vop, vop_win);
}
}
+
+ if (vop->data->afbc) {
+ struct rockchip_crtc_state *s;
+ /*
+* Disable AFB
Re: [PATCH 02/33] drm/panel-arm-versatile: Fix dotclock
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala wrote: > From: Ville Syrjälä > > The currently listed dotclocks disagree with the currently > listed vrefresh rates. Change the dotclocks to match the vrefresh. > > Someone tell me which (if either) of the dotclock or vreresh is > correct? I actually answered this in the mail thread where refresh was deleted: These dotclocks are correct. Delete the incorrect vrefresh instead. So please drop this patch. Thanks, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix_dp: Split bind() into probe() and real bind()
On 02.03.2020 15:26, Marek Szyprowski wrote:
> Analogix_dp driver acquires all its resources in ->bind() callback, what
> is a bit against the driver component based approach, where driver
> initialization is split into probe(), where all resources are gathered, and
> bind(), where objects are created and compound driver is initialized.
> Extract resource related operations to analogix_dp_probe() and
> analogix_dp_remove() and call them before/after registration of the device
> components from the main Exynos and Rockchip DP drivers.
>
> This fixes multiple tries of DRM compound driver bind() when example when
> DP PHY driver is not yet loaded/probed():
>
> [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
> exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops
> [exynosdrm])
> exynos-drm exynos-drm: bound 1445.mixer (ops mixer_component_ops
> [exynosdrm])
> exynos-dp 145b.dp-controller: no DP phy configured
> exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops
> exynos_dp_ops [exynosdrm]): -517
> exynos-drm exynos-drm: master bind failed: -517
> ...
> [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations
> exynos-drm exynos-drm: bound 1440.fimd (ops hdmi_enable [exynosdrm])
> exynos-drm exynos-drm: bound 1445.mixer (ops hdmi_enable [exynosdrm])
> exynos-drm exynos-drm: bound 145b.dp-controller (ops hdmi_enable
> [exynosdrm])
> exynos-drm exynos-drm: bound 1453.hdmi (ops hdmi_enable [exynosdrm])
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> Console: switching to colour frame buffer device 170x48
> exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device
> [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
> ...
>
> Signed-off-by: Marek Szyprowski
I hope someone with rockchip will test the patch.
I am little bit worried about power/resource management:
1. dp->clock enabled in probe.
2. pm_runtime enabled in bind.
Both seems to me too early, but it could be hw issue and should be
addressed in separate patches if possible.
As I understand the patch tries to split things without changing order
of calls, so for me it is OK:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> .../drm/bridge/analogix/analogix_dp_core.c| 33 ---
> drivers/gpu/drm/exynos/exynos_dp.c| 15 ++---
> .../gpu/drm/rockchip/analogix_dp-rockchip.c | 15 +
> include/drm/bridge/analogix_dp.h | 5 +--
> 4 files changed, 44 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index dfb59a5fefea..a89a03b66bf2 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1646,8 +1646,7 @@ static ssize_t analogix_dpaux_transfer(struct
> drm_dp_aux *aux,
> }
>
> struct analogix_dp_device *
> -analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
> - struct analogix_dp_plat_data *plat_data)
> +analogix_dp_probe(struct device *dev, struct analogix_dp_plat_data
> *plat_data)
> {
> struct platform_device *pdev = to_platform_device(dev);
> struct analogix_dp_device *dp;
> @@ -1750,22 +1749,30 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev,
> irq_flags, "analogix-dp", dp);
> if (ret) {
> dev_err(&pdev->dev, "failed to request irq\n");
> - goto err_disable_pm_runtime;
> + return ERR_PTR(ret);
> }
> disable_irq(dp->irq);
>
> + return dp;
> +}
> +EXPORT_SYMBOL_GPL(analogix_dp_probe);
> +
> +int analogix_dp_bind(struct analogix_dp_device *dp, struct drm_device
> *drm_dev)
> +{
> + int ret;
> +
> dp->drm_dev = drm_dev;
> dp->encoder = dp->plat_data->encoder;
>
> dp->aux.name = "DP-AUX";
> dp->aux.transfer = analogix_dpaux_transfer;
> - dp->aux.dev = &pdev->dev;
> + dp->aux.dev = dp->dev;
>
> ret = drm_dp_aux_register(&dp->aux);
> if (ret)
> - return ERR_PTR(ret);
> + return ret;
>
> - pm_runtime_enable(dev);
> + pm_runtime_enable(dp->dev);
>
> ret = analogix_dp_create_bridge(drm_dev, dp);
> if (ret) {
> @@ -1773,13 +1780,12 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev,
> goto err_disable_pm_runtime;
> }
>
> - return dp;
> + return 0;
>
> err_disable_pm_runtime:
> + pm_runtime_disable(dp->dev);
>
> - pm_runtime_disable(dev);
> -
> - return ERR_PTR(ret);
> + return ret;
> }
> EXPORT_SYMBOL_GPL(analogix_dp_bind);
>
> @@ -1796,10 +1802,15 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
>
> drm_dp_aux_unregister(&dp->aux);
> pm_runtime_disable(dp->dev);
> - clk_disable_unprepare(dp->clock);
> }
> EXPORT_SYMBOL_GPL(anal
Re: [PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28
On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc: Adam Ford
> Cc: Sam Ravnborg
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 225be4757a85..3a46b82722f5 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2277,7 +2277,7 @@ static const struct drm_display_mode
> mitsubishi_aa070mc01_mode = {
> };
>
> static const struct drm_display_mode logicpd_type_28_mode = {
> - .clock = 9000,
> + .clock = 9107,
This should be OK. The max dotclk frequency of this panel is 12MHz,
so 9.107MHz should be just fine.
Reviewed-by: Adam Ford
adam
> .hdisplay = 480,
> .hsync_start = 480 + 3,
> .hsync_end = 480 + 3 + 42,
> --
> 2.24.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
On Tue, 3 Mar 2020 12:37:16 +0100
Daniel Vetter wrote:
> On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > > On Fri, 21 Feb 2020 10:08:42 +0100
> > > Neil Armstrong wrote:
> > >
> > > > Amlogic uses a proprietary lossless image compression protocol and
> > > > format
> > > > for their hardware video codec accelerators, either video decoders or
> > > > video input encoders.
> > > >
> > > > It considerably reduces memory bandwidth while writing and reading
> > > > frames in memory.
> > > >
> > > > The underlying storage is considered to be 3 components, 8bit or 10-bit
> > > > per component, YCbCr 420, single plane :
> > > > - DRM_FORMAT_YUV420_8BIT
> > > > - DRM_FORMAT_YUV420_10BIT
> > > >
> > > > This modifier will be notably added to DMA-BUF frames imported from the
> > > > V4L2
> > > > Amlogic VDEC decoder.
> > > >
> > > > At least two options are supported :
> > > > - Scatter mode: the buffer is filled with a IOMMU scatter table
> > > > referring
> > > > to the encoder current memory layout. This mode if more efficient in
> > > > terms
> > > > of memory allocation but frames are not dumpable and only valid
> > > > during until
> > > > the buffer is freed and back in control of the encoder
> > > > - Memory saving: when the pixel bpp is 8b, the size of the superblock
> > > > can
> > > > be reduced, thus saving memory.
> > > >
> > > > Signed-off-by: Neil Armstrong
> > > > ---
> > > > include/uapi/drm/drm_fourcc.h | 56 +++
> > > > 1 file changed, 56 insertions(+)
> > > >
> > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > b/include/uapi/drm/drm_fourcc.h
> > > > index 8bc0b31597d8..8a6e87bacadb 100644
> > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > @@ -309,6 +309,7 @@ extern "C" {
> > > > #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
> > > > #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> > > > #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> > > > +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> > > >
> > > > /* add more to the end as needed */
> > > >
> > > > @@ -804,6 +805,61 @@ extern "C" {
> > > > */
> > > > #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
> > > >
> > > > +/*
> > > > + * Amlogic Video Framebuffer Compression modifiers
> > > > + *
> > > > + * Amlogic uses a proprietary lossless image compression protocol and
> > > > format
> > > > + * for their hardware video codec accelerators, either video decoders
> > > > or
> > > > + * video input encoders.
> > > > + *
> > > > + * It considerably reduces memory bandwidth while writing and reading
> > > > + * frames in memory.
> > > > + * Implementation details may be platform and SoC specific, and shared
> > > > + * between the producer and the decoder on the same platform.
> > >
> > > Hi,
> > >
> > > after a lengthy IRC discussion on #dri-devel, this "may be platform and
> > > SoC specific" is a problem.
> > >
> > > It can be an issue in two ways:
> > >
> > > - If something in the data acts like a sub-modifier, then advertising
> > > support for one modifier does not really tell if the data layout is
> > > supported or not.
> > >
> > > - If you need to know the platform and/or SoC to be able to interpret
> > > the data, it means the modifier is ill-defined and cannot be used in
> > > inter-machine communication (e.g. Pipewire).
> > >
> >
> > Playing devil's advocate, the comment sounds similar to
> > I915_FORMAT_MOD_{X,Y}_TILED:
> >
> > * This format is highly platforms specific and not useful for cross-driver
> > * sharing. It exists since on a given platform it does uniquely identify
> > the
> > * layout in a simple way for i915-specific userspace.
>
> Yeah which we regret now. We need to now roll out a new set of
> modifiers for at least some of the differences in these on the
> modern-ish chips (the old crap is pretty much lost cause anyway).
>
> This was kinda a nasty hack to smooth things over since we have epic
> amounts of userspace, but it's really not a great idea (and no one
> else really has epic amounts of existing userspace that uses tiling
> flags everywhere, this is all new code).
> -Daniel
>
> > Isn't the statement that this for sharing between producer and decoder
> > _on the same platform_ a similar clause with the same effect?
> >
> > What advantage is there to exposing the gory details? For Arm AFBC
> > it's necessary because IP on the SoC can be (likely to be) from
> > different vendors with different capabilities.
> >
> > If this is only for talking between Amlogic IP on the same SoC, and
> > those devices support all the same "flavours", I don't see what is
> > gained by making userspace care about internals.
>
> The trouble is if you mix&match IP cores, and one of them supports
> flavours A, B, C and the other C, D, E. But all you have is a single
> magic modifier for "whatever the f
Re: [PATCH libdrm] modetest: call drmModeCrtcSetGamma() only if add_property_optional returns true
Pretty sure the current code is right. If the GAMMA_LUT property can't
be set, it tries to set gamma the old-fashioned way.
On Tue, Mar 3, 2020 at 8:12 AM Devarsh Thakkar wrote:
>
> Hi Rohit,
>
> This makes sense to me as gamma was implemented as optional property.
> Reviewed-By: "Devarsh Thakkar "
>
> @emil.veli...@collabora.com, @imir...@alum.mit.edu, @Ville Syrjälä, Could you
> please ack and help merge this patch if it also look good to you ?
>
> Regards,
> Devarsh
>
> > -Original Message-
> > From: Rohit Visavalia
> > Sent: 27 February 2020 00:40
> > To: Rohit Visavalia ; dri-devel@lists.freedesktop.org;
> > imir...@alum.mit.edu; emil.veli...@collabora.com
> > Cc: Hyun Kwon ; Ranganathan Sk ; Dhaval
> > Rajeshbhai Shah ; Varunkumar Allagadapa
> > ; Devarsh Thakkar
> > Subject: RE: [PATCH libdrm] modetest: call drmModeCrtcSetGamma() only if
> > add_property_optional returns true
> >
> > Gentle reminder.
> >
> > + Ilia Mirkin, +Emil Velikov.
> >
> > Thanks & Regards,
> > Rohit
> >
> > > -Original Message-
> > > From: Rohit Visavalia [mailto:rohit.visava...@xilinx.com]
> > > Sent: Tuesday, February 25, 2020 3:08 PM
> > > To: dri-devel@lists.freedesktop.org
> > > Cc: Hyun Kwon ; Ranganathan Sk ;
> > > Dhaval Rajeshbhai Shah ; Varunkumar Allagadapa
> > > ; Devarsh Thakkar ; Rohit
> > > Visavalia
> > > Subject: [PATCH libdrm] modetest: call drmModeCrtcSetGamma() only if
> > > add_property_optional returns true
> > >
> > > gamma is a optional property then also it prints error message, so set
> > > gamma only if add_property_optional() returns true.
> > >
> > > Signed-off-by: Rohit Visavalia
> > > ---
> > > tests/modetest/modetest.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > > index b907ab3..379b9ea 100644
> > > --- a/tests/modetest/modetest.c
> > > +++ b/tests/modetest/modetest.c
> > > @@ -1138,7 +1138,7 @@ static void set_gamma(struct device *dev,
> > > unsigned crtc_id, unsigned fourcc)
> > >
> > > add_property_optional(dev, crtc_id, "DEGAMMA_LUT", 0);
> > > add_property_optional(dev, crtc_id, "CTM", 0);
> > > - if (!add_property_optional(dev, crtc_id, "GAMMA_LUT", blob_id)) {
> > > + if (add_property_optional(dev, crtc_id, "GAMMA_LUT", blob_id)) {
> > > uint16_t r[256], g[256], b[256];
> > >
> > > for (i = 0; i < 256; i++) {
> > > --
> > > 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
On Mon, Mar 02, 2020 at 04:08:59PM -0800, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
>
> v3:
> * Remove the edid parsing restriction for just DP (Nicholas)
> * Use drm_for_each_detailed_block (Ville)
> * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
>
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Kazlauskas, Nicholas
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_edid.c | 44 +
> include/drm/drm_connector.h | 22 +++
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ad41764a4ebe..e3f152180b6b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> }
> }
>
> +static
> +void get_adaptive_sync_range(struct detailed_timing *timing,
> + void *info_adaptive_sync)
> +{
> + struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
> + const struct detailed_non_pixel *data = &timing->data.other_data;
> + const struct detailed_data_monitor_range *range = &data->data.range;
> +
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)a
is_display_descriptor()
> + return;
> +
> + /*
> + * Check for flag range limits only. If flag == 1 then
> + * no additional timing information provided.
> + * Default GTF, GTF Secondary curve and CVT are not
> + * supported
> + */
> + if (range->flags != 1)
Pls name the flags.
> + return;
> +
> + adaptive_sync->min_vfreq = range->min_vfreq;
> + adaptive_sync->max_vfreq = range->max_vfreq;
> +}
> +
> +static
> +void drm_get_adaptive_sync_range(struct drm_connector *connector,
> + const struct edid *edid)
> +{
> + struct drm_display_info *info = &connector->display_info;
> +
> + if (!version_greater(edid, 1, 1))
> + return;
> +
> + drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
> + &info->adaptive_sync);
> +
> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
> + info->adaptive_sync.min_vfreq,
> + info->adaptive_sync.max_vfreq);
> +}
> +
> /* A connector has no EDID information, so we've got no EDID to compute
> quirks from. Reset
> * all of the values which would have been set from EDID
> */
> @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
> memset(&info->hdmi, 0, sizeof(info->hdmi));
>
> info->non_desktop = 0;
> + memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
> }
>
> u32 drm_add_display_info(struct drm_connector *connector, const struct edid
> *edid)
> @@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector
> *connector, const struct edid *edi
>
> info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>
> + drm_get_adaptive_sync_range(connector, edid);
> +
> DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>
> if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 0df7a95ca5d9..2b22c0fa42c4 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,23 @@ enum drm_panel_orientation {
> DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> };
>
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * &drm_display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min supported refresh rate in Hz from
> + * EDID's detailed monitor range.
> + * @max_vfreq: This is the max supported refresh rate in Hz from
> + * EDID's detailed monitor range
> + */
> +struct drm_adaptive_sync_info {
> + u8 min_vfreq;
> + u8 max_vfreq;
> +};
> +
> /*
> * This is a consolidated colorimetry list supported by HDMI and
> * DP protocol standard. The respective connectors will register
> @@ -473,6 +490,11 @@ struct drm_display_info {
>* @non_desktop: Non desktop display (HMD).
>*/
> bool non_desktop;
> +
> + /**
> + * @adaptive_sync: Adaptive Sync capabilities of the DP/eDP sink
> + */
> + st
