From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "Neil Armstrong" <narmstrong@baylibre.com>,
nouveau@lists.freedesktop.org, "Guido Günther" <agx@sigxcpu.org>,
dri-devel@lists.freedesktop.org,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Sam Ravnborg" <sam@ravnborg.org>,
"Jagan Teki" <jagan@amarulasolutions.com>,
"Thomas Hellstrom" <thellstrom@vmware.com>,
"Joonyoung Shim" <jy0922.shim@samsung.com>,
"Stefan Mavrodiev" <stefan@olimex.com>,
"Jerry Han" <hanxu5@huaqin.corp-partner.google.com>,
"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Robert Chiras" <robert.chiras@nxp.com>,
"Icenowy Zheng" <icenowy@aosc.io>,
"Jonas Karlman" <jonas@kwiboo.se>,
intel-gfx@lists.freedesktop.org,
linux-amlogic@lists.infradead.org,
"Vincent Abriou" <vincent.abriou@st.com>,
"Jernej Skrabec" <jernej.skrabec@siol.net>,
"Purism Kernel Team" <kernel@puri.sm>,
"Seung-Woo Kim" <sw0312.kim@samsung.com>
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 17:45:06 +0200 [thread overview]
Message-ID: <20200225154506.GF13686@intel.com> (raw)
In-Reply-To: <3ca785f2-9032-aaf9-0965-8657d31116ba@samsung.com>
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> >>> a bit of space and avoids the cached value getting out of sync
> >>> with reality.
> >>>
> >>> Mostly done with cocci, with the following manual fixups:
> >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> >>> - Fix __MODE() macro in ch7006_mode.c
> >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> >>> - Remove leftover comment from samsung_s6d16d0_mode
> >> ...
> >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> index 41444a73c980..47b37fef7ee8 100644
> >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type versatile_panels[] = {
> >>> .vsync_start = 240 + 5,
> >>> .vsync_end = 240 + 5 + 6,
> >>> .vtotal = 240 + 5 + 6 + 5,
> >>> - .vrefresh = 116,
> >>
> >> Are you sure vrefresh calculated (from totals and clock) is different
> >> than this field? If not, we risk regressions.
> >>
> >> This case is OK, but there is plenty other cases.
> > IIRC I did spot check a few of them. But which code exactly do you think
> > is abusing vrefresh and thus could break?
>
>
> I guess suspect/potential victim is every code which uses
> drm_mode_vrefresh - after this patch the function can return different
> value(if there are differences between provided and calculated vrefresh).
>
> Quick examples where output of this function matters:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
Already looks quite sketchy due to rounding.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
msleep() is in no way accurate so looks rather sketchy as well.
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
Another thing that suffers from rounding issues.
So to me these all look like code that someone should fix regardless.
--
Ville Syrjälä
Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "Neil Armstrong" <narmstrong@baylibre.com>,
nouveau@lists.freedesktop.org, "Guido Günther" <agx@sigxcpu.org>,
dri-devel@lists.freedesktop.org,
"Thierry Reding" <thierry.reding@gmail.com>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Sam Ravnborg" <sam@ravnborg.org>,
"Jagan Teki" <jagan@amarulasolutions.com>,
"Thomas Hellstrom" <thellstrom@vmware.com>,
"Joonyoung Shim" <jy0922.shim@samsung.com>,
"Stefan Mavrodiev" <stefan@olimex.com>,
"Jerry Han" <hanxu5@huaqin.corp-partner.google.com>,
"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Robert Chiras" <robert.chiras@nxp.com>,
"Icenowy Zheng" <icenowy@aosc.io>,
"Jonas Karlman" <jonas@kwiboo.se>,
intel-gfx@lists.freedesktop.org,
linux-amlogic@lists.infradead.org,
"Vincent Abriou" <vincent.abriou@st.com>,
"Jernej Skrabec" <jernej.skrabec@siol.net>,
"Purism Kernel Team" <kernel@puri.sm>,
"Seung-Woo Kim" <sw0312.kim@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 17:45:06 +0200 [thread overview]
Message-ID: <20200225154506.GF13686@intel.com> (raw)
In-Reply-To: <3ca785f2-9032-aaf9-0965-8657d31116ba@samsung.com>
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> >>> a bit of space and avoids the cached value getting out of sync
> >>> with reality.
> >>>
> >>> Mostly done with cocci, with the following manual fixups:
> >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> >>> - Fix __MODE() macro in ch7006_mode.c
> >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> >>> - Remove leftover comment from samsung_s6d16d0_mode
> >> ...
> >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> index 41444a73c980..47b37fef7ee8 100644
> >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type versatile_panels[] = {
> >>> .vsync_start = 240 + 5,
> >>> .vsync_end = 240 + 5 + 6,
> >>> .vtotal = 240 + 5 + 6 + 5,
> >>> - .vrefresh = 116,
> >>
> >> Are you sure vrefresh calculated (from totals and clock) is different
> >> than this field? If not, we risk regressions.
> >>
> >> This case is OK, but there is plenty other cases.
> > IIRC I did spot check a few of them. But which code exactly do you think
> > is abusing vrefresh and thus could break?
>
>
> I guess suspect/potential victim is every code which uses
> drm_mode_vrefresh - after this patch the function can return different
> value(if there are differences between provided and calculated vrefresh).
>
> Quick examples where output of this function matters:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
Already looks quite sketchy due to rounding.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
msleep() is in no way accurate so looks rather sketchy as well.
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
Another thing that suffers from rounding issues.
So to me these all look like code that someone should fix regardless.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "Neil Armstrong" <narmstrong@baylibre.com>,
nouveau@lists.freedesktop.org, "Guido Günther" <agx@sigxcpu.org>,
dri-devel@lists.freedesktop.org,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Sam Ravnborg" <sam@ravnborg.org>,
"Jagan Teki" <jagan@amarulasolutions.com>,
"Thomas Hellstrom" <thellstrom@vmware.com>,
"Joonyoung Shim" <jy0922.shim@samsung.com>,
"Stefan Mavrodiev" <stefan@olimex.com>,
"Jerry Han" <hanxu5@huaqin.corp-partner.google.com>,
"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Robert Chiras" <robert.chiras@nxp.com>,
"Icenowy Zheng" <icenowy@aosc.io>,
"Jonas Karlman" <jonas@kwiboo.se>,
intel-gfx@lists.freedesktop.org,
linux-amlogic@lists.infradead.org,
"Vincent Abriou" <vincent.abriou@st.com>,
"Jernej Skrabec" <jernej.skrabec@siol.net>,
"Purism Kernel Team" <kernel@puri.sm>,
"Seung-Woo Kim" <sw0312.kim@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>
Subject: Re: [Intel-gfx] [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 17:45:06 +0200 [thread overview]
Message-ID: <20200225154506.GF13686@intel.com> (raw)
In-Reply-To: <3ca785f2-9032-aaf9-0965-8657d31116ba@samsung.com>
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> >>> a bit of space and avoids the cached value getting out of sync
> >>> with reality.
> >>>
> >>> Mostly done with cocci, with the following manual fixups:
> >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> >>> - Fix __MODE() macro in ch7006_mode.c
> >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> >>> - Remove leftover comment from samsung_s6d16d0_mode
> >> ...
> >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> index 41444a73c980..47b37fef7ee8 100644
> >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type versatile_panels[] = {
> >>> .vsync_start = 240 + 5,
> >>> .vsync_end = 240 + 5 + 6,
> >>> .vtotal = 240 + 5 + 6 + 5,
> >>> - .vrefresh = 116,
> >>
> >> Are you sure vrefresh calculated (from totals and clock) is different
> >> than this field? If not, we risk regressions.
> >>
> >> This case is OK, but there is plenty other cases.
> > IIRC I did spot check a few of them. But which code exactly do you think
> > is abusing vrefresh and thus could break?
>
>
> I guess suspect/potential victim is every code which uses
> drm_mode_vrefresh - after this patch the function can return different
> value(if there are differences between provided and calculated vrefresh).
>
> Quick examples where output of this function matters:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
Already looks quite sketchy due to rounding.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
msleep() is in no way accurate so looks rather sketchy as well.
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
Another thing that suffers from rounding issues.
So to me these all look like code that someone should fix regardless.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: "Neil Armstrong" <narmstrong@baylibre.com>,
nouveau@lists.freedesktop.org, "Guido Günther" <agx@sigxcpu.org>,
dri-devel@lists.freedesktop.org,
"Thierry Reding" <thierry.reding@gmail.com>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Sam Ravnborg" <sam@ravnborg.org>,
"Jagan Teki" <jagan@amarulasolutions.com>,
"Thomas Hellstrom" <thellstrom@vmware.com>,
"Joonyoung Shim" <jy0922.shim@samsung.com>,
"Stefan Mavrodiev" <stefan@olimex.com>,
"Jerry Han" <hanxu5@huaqin.corp-partner.google.com>,
"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Robert Chiras" <robert.chiras@nxp.com>,
"Icenowy Zheng" <icenowy@aosc.io>,
"Jonas Karlman" <jonas@kwiboo.se>,
intel-gfx@lists.freedesktop.org,
linux-amlogic@lists.infradead.org,
"Vincent Abriou" <vincent.abriou@st.com>,
"Jernej Skrabec" <jernej.skrabec@siol.net>,
"Purism Kernel Team" <kernel@puri.sm>,
"Seung-Woo Kim" <sw0312.kim@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>
Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh
Date: Tue, 25 Feb 2020 17:45:06 +0200 [thread overview]
Message-ID: <20200225154506.GF13686@intel.com> (raw)
In-Reply-To: <3ca785f2-9032-aaf9-0965-8657d31116ba@samsung.com>
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> >>> a bit of space and avoids the cached value getting out of sync
> >>> with reality.
> >>>
> >>> Mostly done with cocci, with the following manual fixups:
> >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> >>> - Fix __MODE() macro in ch7006_mode.c
> >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> >>> - Remove leftover comment from samsung_s6d16d0_mode
> >> ...
> >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> index 41444a73c980..47b37fef7ee8 100644
> >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type versatile_panels[] = {
> >>> .vsync_start = 240 + 5,
> >>> .vsync_end = 240 + 5 + 6,
> >>> .vtotal = 240 + 5 + 6 + 5,
> >>> - .vrefresh = 116,
> >>
> >> Are you sure vrefresh calculated (from totals and clock) is different
> >> than this field? If not, we risk regressions.
> >>
> >> This case is OK, but there is plenty other cases.
> > IIRC I did spot check a few of them. But which code exactly do you think
> > is abusing vrefresh and thus could break?
>
>
> I guess suspect/potential victim is every code which uses
> drm_mode_vrefresh - after this patch the function can return different
> value(if there are differences between provided and calculated vrefresh).
>
> Quick examples where output of this function matters:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
Already looks quite sketchy due to rounding.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
msleep() is in no way accurate so looks rather sketchy as well.
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
Another thing that suffers from rounding issues.
So to me these all look like code that someone should fix regardless.
--
Ville Syrjälä
Intel
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2020-02-25 15:45 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 20:35 [PATCH 00/12] drm: Put drm_display_mode on diet Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 01/12] drm: Nuke mode->hsync Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-20 10:55 ` Emil Velikov
2020-02-20 10:55 ` Emil Velikov
2020-02-21 16:04 ` Ville Syrjälä
2020-02-21 16:04 ` Ville Syrjälä
2020-02-21 16:55 ` Emil Velikov
2020-02-21 16:55 ` Emil Velikov
2020-02-19 20:35 ` [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-20 10:56 ` Emil Velikov
2020-02-20 10:56 ` [Intel-gfx] " Emil Velikov
2020-02-25 0:49 ` Inki Dae
2020-02-19 20:35 ` [PATCH 03/12] drm/i915: Introduce some local intel_dp variables Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-20 11:13 ` Emil Velikov
2020-02-20 11:13 ` Emil Velikov
2020-02-19 20:35 ` [PATCH 04/12] drm: Nuke mode->vrefresh Ville Syrjala
2020-02-19 20:35 ` Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` Ville Syrjala
2020-02-20 12:00 ` Emil Velikov
2020-02-20 12:00 ` Emil Velikov
2020-02-20 12:00 ` [Intel-gfx] " Emil Velikov
2020-02-20 12:00 ` Emil Velikov
2020-02-22 12:32 ` Sam Ravnborg
2020-02-22 12:32 ` Sam Ravnborg
2020-02-22 12:32 ` [Intel-gfx] " Sam Ravnborg
2020-02-22 12:32 ` Sam Ravnborg
2020-02-24 13:14 ` Ville Syrjälä
2020-02-24 13:14 ` Ville Syrjälä
2020-02-24 13:14 ` [Intel-gfx] " Ville Syrjälä
2020-02-24 13:14 ` Ville Syrjälä
2020-02-24 14:14 ` Andrzej Hajda
2020-02-24 14:14 ` Andrzej Hajda
2020-02-24 14:14 ` [Intel-gfx] " Andrzej Hajda
2020-02-24 14:14 ` Andrzej Hajda
2020-02-25 11:21 ` Ville Syrjälä
2020-02-25 11:21 ` Ville Syrjälä
2020-02-25 11:21 ` [Intel-gfx] " Ville Syrjälä
2020-02-25 11:21 ` Ville Syrjälä
2020-02-25 15:19 ` Andrzej Hajda
2020-02-25 15:19 ` Andrzej Hajda
2020-02-25 15:19 ` [Intel-gfx] " Andrzej Hajda
2020-02-25 15:19 ` Andrzej Hajda
2020-02-25 15:45 ` Ville Syrjälä [this message]
2020-02-25 15:45 ` Ville Syrjälä
2020-02-25 15:45 ` [Intel-gfx] " Ville Syrjälä
2020-02-25 15:45 ` Ville Syrjälä
2020-02-25 19:27 ` Ville Syrjälä
2020-02-25 19:27 ` [Intel-gfx] " Ville Syrjälä
2020-02-25 19:27 ` Ville Syrjälä
2020-02-25 21:52 ` Linus Walleij
2020-02-25 21:52 ` Linus Walleij
2020-02-25 21:52 ` [Intel-gfx] " Linus Walleij
2020-02-25 21:52 ` Linus Walleij
2020-02-19 20:35 ` [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` Ville Syrjala
2020-02-20 11:24 ` Emil Velikov
2020-02-20 11:24 ` [Intel-gfx] " Emil Velikov
2020-02-20 11:24 ` Emil Velikov
2020-02-20 15:33 ` Ville Syrjälä
2020-02-20 15:33 ` [Intel-gfx] " Ville Syrjälä
2020-02-20 15:33 ` Ville Syrjälä
2020-02-20 18:14 ` Daniel Vetter
2020-02-20 18:14 ` [Intel-gfx] " Daniel Vetter
2020-02-20 18:14 ` Daniel Vetter
2020-02-19 20:35 ` [PATCH 06/12] drm: Shrink {width,height}_mm to u16 Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-20 12:48 ` Emil Velikov
2020-02-20 12:48 ` Emil Velikov
2020-02-19 20:35 ` [PATCH 07/12] drm: Shrink mode->type to u8 Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-20 18:17 ` Daniel Vetter
2020-02-20 18:17 ` Daniel Vetter
2020-02-19 20:35 ` [PATCH 08/12] drm: Make mode->flags u32 Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 09/12] drm: Shrink drm_display_mode timings Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-20 18:19 ` Daniel Vetter
2020-02-20 18:19 ` Daniel Vetter
2020-02-20 18:47 ` Ville Syrjälä
2020-02-20 18:47 ` Ville Syrjälä
2020-02-21 16:13 ` Sam Ravnborg
2020-02-21 16:13 ` [Intel-gfx] " Sam Ravnborg
2020-02-21 17:27 ` Sam Ravnborg
2020-02-21 17:27 ` [Intel-gfx] " Sam Ravnborg
2020-02-24 13:06 ` Ville Syrjälä
2020-02-24 13:06 ` [Intel-gfx] " Ville Syrjälä
2020-02-19 20:35 ` [PATCH 10/12] drm: Flatten drm_mode_vrefresh() Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-19 20:35 ` [PATCH 11/12] drm: Shrink mode->private_flags Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-21 16:15 ` Sam Ravnborg
2020-02-21 16:15 ` [Intel-gfx] " Sam Ravnborg
2020-02-24 13:23 ` Ville Syrjälä
2020-02-24 13:23 ` [Intel-gfx] " Ville Syrjälä
2020-02-19 20:35 ` [PATCH 12/12] drm: pahole struct drm_display_mode Ville Syrjala
2020-02-19 20:35 ` [Intel-gfx] " Ville Syrjala
2020-02-20 12:53 ` Emil Velikov
2020-02-20 12:53 ` [Intel-gfx] " Emil Velikov
2020-02-19 20:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Put drm_display_mode on diet Patchwork
2020-02-19 21:18 ` [PATCH 00/12] " Ville Syrjälä
2020-02-19 21:18 ` [Intel-gfx] " Ville Syrjälä
2020-02-19 21:21 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-02-20 13:21 ` [PATCH 00/12] " Emil Velikov
2020-02-20 13:21 ` [Intel-gfx] " Emil Velikov
2020-02-20 14:27 ` Ville Syrjälä
2020-02-20 14:27 ` [Intel-gfx] " Ville Syrjälä
2020-02-20 15:34 ` Ville Syrjälä
2020-02-20 15:34 ` Ville Syrjälä
2020-02-21 11:32 ` Jani Nikula
2020-02-21 11:32 ` Jani Nikula
2020-02-21 11:43 ` Ville Syrjälä
2020-02-21 11:43 ` Ville Syrjälä
2020-02-21 14:42 ` Daniel Vetter
2020-02-21 14:42 ` Daniel Vetter
2020-02-21 15:40 ` Ville Syrjälä
2020-02-21 15:40 ` Ville Syrjälä
2020-02-21 16:09 ` Ville Syrjälä
2020-02-21 16:09 ` Ville Syrjälä
2020-02-21 17:16 ` Daniel Vetter
2020-02-21 17:16 ` Daniel Vetter
2020-02-21 17:49 ` Ville Syrjälä
2020-02-21 17:49 ` Ville Syrjälä
2020-02-20 17:01 ` Emil Velikov
2020-02-20 17:01 ` [Intel-gfx] " Emil Velikov
2020-02-21 15:09 ` Linus Walleij
2020-02-21 15:09 ` [Intel-gfx] " Linus Walleij
2020-02-21 18:26 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200225154506.GF13686@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=agx@sigxcpu.org \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hanxu5@huaqin.corp-partner.google.com \
--cc=icenowy@aosc.io \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=jy0922.shim@samsung.com \
--cc=kernel@puri.sm \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-graphics-maintainer@vmware.com \
--cc=narmstrong@baylibre.com \
--cc=nouveau@lists.freedesktop.org \
--cc=robert.chiras@nxp.com \
--cc=sam@ravnborg.org \
--cc=stefan@olimex.com \
--cc=sw0312.kim@samsung.com \
--cc=thellstrom@vmware.com \
--cc=vincent.abriou@st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.