Re: [PATCH] drm/hisilicon: Deleted the drm_device declaration
Hi,
just a few nits.
Am 25.09.20 um 08:49 schrieb Tian Tao:
> drm_framebuffer.h contains drm/drm_device.h and struct drm_device is
contains -> includes
> already declared in this file, so there is no need to declare struct
declared -> defined
> drm_device in hibm_drm_drv.h.
>
> Signed-off-by: Tian Tao
Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index 87d2aad..6a63502 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -22,8 +22,6 @@
> #include
> #include
>
> -struct drm_device;
> -
> struct hibmc_connector {
> struct drm_connector base;
>
>
--
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
[PATCH 2/3] Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
syzbot has reported an issue in the framebuffer layer, where a malicious
user may overflow our built-in font data buffers.
In order to perform a reliable range check, subsystems need to know
`FONTDATAMAX` for each built-in font. Unfortunately, our font descriptor,
`struct console_font` does not contain `FONTDATAMAX`, and is part of the
UAPI, making it infeasible to modify it.
For user-provided fonts, the framebuffer layer resolves this issue by
reserving four extra words at the beginning of data buffers. Later,
whenever a function needs to access them, it simply uses the following
macros:
#define REFCOUNT(fd)(((int *)(fd))[-1])
#define FNTSIZE(fd) (((int *)(fd))[-2])
#define FNTCHARCNT(fd) (((int *)(fd))[-3])
#define FNTSUM(fd) (((int *)(fd))[-4])
#define FONT_EXTRA_WORDS 4
Recently we have gathered all the above macros to . Let us
do the same thing for built-in fonts, prepend four extra words (including
`FONTDATAMAX`) to their data buffers, so that subsystems can use these
macros for all fonts, no matter built-in or user-provided.
This patch depends on patch "fbdev, newport_con: Move FONT_EXTRA_WORDS
macros into linux/font.h".
Cc: sta...@vger.kernel.org
Link:
https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfd
Signed-off-by: Peilin Ye
---
include/linux/font.h | 5 +
lib/fonts/font_10x18.c | 9 -
lib/fonts/font_6x10.c | 9 +
lib/fonts/font_6x11.c | 9 -
lib/fonts/font_7x14.c | 9 -
lib/fonts/font_8x16.c | 9 -
lib/fonts/font_8x8.c | 9 -
lib/fonts/font_acorn_8x8.c | 9 ++---
lib/fonts/font_mini_4x6.c | 8
lib/fonts/font_pearl_8x8.c | 9 -
lib/fonts/font_sun12x22.c | 9 -
lib/fonts/font_sun8x16.c | 7 ---
lib/fonts/font_ter16x32.c | 9 -
13 files changed, 56 insertions(+), 54 deletions(-)
diff --git a/include/linux/font.h b/include/linux/font.h
index 40ed008d7dad..59faa80f586d 100644
--- a/include/linux/font.h
+++ b/include/linux/font.h
@@ -67,4 +67,9 @@ extern const struct font_desc *get_default_font(int xres, int
yres,
#define FONT_EXTRA_WORDS 4
+struct font_data {
+ unsigned int extra[FONT_EXTRA_WORDS];
+ const unsigned char data[];
+} __packed;
+
#endif /* _VIDEO_FONT_H */
diff --git a/lib/fonts/font_10x18.c b/lib/fonts/font_10x18.c
index 532f0ff89a96..0e2deac97da0 100644
--- a/lib/fonts/font_10x18.c
+++ b/lib/fonts/font_10x18.c
@@ -8,8 +8,8 @@
#define FONTDATAMAX 9216
-static const unsigned char fontdata_10x18[FONTDATAMAX] = {
-
+static struct font_data fontdata_10x18 = {
+ { 0, 0, FONTDATAMAX, 0 }, {
/* 0 0x00 '^@' */
0x00, 0x00, /* 00 */
0x00, 0x00, /* 00 */
@@ -5129,8 +5129,7 @@ static const unsigned char fontdata_10x18[FONTDATAMAX] = {
0x00, 0x00, /* 00 */
0x00, 0x00, /* 00 */
0x00, 0x00, /* 00 */
-
-};
+} };
const struct font_desc font_10x18 = {
@@ -5138,7 +5137,7 @@ const struct font_desc font_10x18 = {
.name = "10x18",
.width = 10,
.height = 18,
- .data = fontdata_10x18,
+ .data = fontdata_10x18.data,
#ifdef __sparc__
.pref = 5,
#else
diff --git a/lib/fonts/font_6x10.c b/lib/fonts/font_6x10.c
index 09b2cc03435b..87da8acd07db 100644
--- a/lib/fonts/font_6x10.c
+++ b/lib/fonts/font_6x10.c
@@ -1,8 +1,10 @@
// SPDX-License-Identifier: GPL-2.0
#include
-static const unsigned char fontdata_6x10[] = {
+#define FONTDATAMAX 2560
+static struct font_data fontdata_6x10 = {
+ { 0, 0, FONTDATAMAX, 0 }, {
/* 0 0x00 '^@' */
0x00, /* */
0x00, /* */
@@ -3074,14 +3076,13 @@ static const unsigned char fontdata_6x10[] = {
0x00, /* */
0x00, /* */
0x00, /* */
-
-};
+} };
const struct font_desc font_6x10 = {
.idx= FONT6x10_IDX,
.name = "6x10",
.width = 6,
.height = 10,
- .data = fontdata_6x10,
+ .data = fontdata_6x10.data,
.pref = 0,
};
diff --git a/lib/fonts/font_6x11.c b/lib/fonts/font_6x11.c
index d7136c33f1f0..5e975dfa10a5 100644
--- a/lib/fonts/font_6x11.c
+++ b/lib/fonts/font_6x11.c
@@ -9,8 +9,8 @@
#define FONTDATAMAX (11*256)
-static const unsigned char fontdata_6x11[FONTDATAMAX] = {
-
+static struct font_data fontdata_6x11 = {
+ { 0, 0, FONTDATAMAX, 0 }, {
/* 0 0x00 '^@' */
0x00, /* */
0x00, /* */
@@ -3338,8 +3338,7 @@ static const unsigned char fontdata_6x11[FONTDATAMAX] = {
0x00, /* */
0x00, /* */
0x00, /* */
-
-};
+} };
const struct font_desc font_vga_6x11 = {
@@ -3347,7 +3346,7 @@ const struct font_desc font_vga_6x11 = {
.name = "ProFont6x11",
.width = 6,
.height = 11,
- .data = fontdata_6x11,
+ .data = fontdata_6x11.data,
[PATCH 2/2] dt-bindings: display: sii902x: Add supply bindings
The sii902x chip family requires IO and core voltages to reach the correct voltage before chip initialization. Add binding for describing the two supplies. Signed-off-by: Alexandru Gagniuc --- Documentation/devicetree/bindings/display/bridge/sii902x.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index 0d1db3f9da84..02c21b584741 100644 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt @@ -8,6 +8,8 @@ Optional properties: - interrupts: describe the interrupt line used to inform the host about hotplug events. - reset-gpios: OF device-tree gpio specification for RST_N pin. + - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V) + - cvcc12-supply: Digital Core Supply Voltage (1.2V) HDMI audio properties: - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin @@ -54,6 +56,8 @@ Example: compatible = "sil,sii9022"; reg = <0x39>; reset-gpios = <&pioA 1 0>; + iovcc-supply = <&v3v3_hdmi>; + cvcc12-supply = <&v1v2_hdmi>; #sound-dai-cells = <0>; sil,i2s-data-lanes = < 0 1 2 >; -- 2.25.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
cc back a few others who were unintentionally dropped from the thread earlier.
Someone (at Google) helped me dig into this a little more and they
found a document titled "eDP Backlight Brightness bit alignment" sent
out for review in January 2017. I registered for a new account (google
is a member) and have access to the document; here is the URL for
those who also have access:
https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth,
it seems like Lyude's contact Bill Lempesis uploaded this
change-request document, so I think we can reach out to him if we have
further questions. It's actually unclear to me what the status of this
change request is, and whether it's been officially accepted. But I
think it can be seen as some official advice on how we can move
forward here.
Basically, this is a change request to the spec which acknowledges
that, despite the original spec implying that the
most-significant-bits were relevant here, many implementations used
the least-significant-bits. In defense of most-significant it laid out
some similar arguments to what Ville was saying. But it ends up
saying:
> Unfortunately, the most common interpretation that we have
> encountered is case 1 in the example above. TCON vendors
> tend to align the valid bits to the LSBs, not the MSBs.
Instead of changing the default defined functionality (as some earlier
version of this doc apparently suggested), this doc prefers to
allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future
backlight devices can specify to the Source how to program them:
00: the current functionality, i,e. no defined interpretation
01: aligned to most-significant bits
10: aligned to least-significant bits
11: reserved
It also says "[Sources] should only need panel-specific workarounds
for the currently available panels."
So I believe this document is an acknowledgement of many
implementations having their alignment to the least-significant bits,
and (to my eyes) clearly validates that the spec "should" be the
opposite. If we believe the doc's claim that "the most common
interpretation" is least-significant, it seems to me that it would
require more quirks if we made most-significant the default
implementation.
Ville mentioned at some point earlier that we should try to match the
spec, whereas Lyude mentioned we should prefer to do what the majority
of machines do. What do you both think of this new development?
I will also look into whether my specific device supports this
extension, and in that case I'll volunteer to implement this new
functionality in the driver.
Thanks for your time,
Kevin
On Tue, Sep 22, 2020 at 3:30 PM Lyude Paul wrote:
>
> Hi! Since I got dropped from the thread, many responses inline
>
> On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> > +Lyude
> > I notice that Lyude email was somehow dropped from the thread.
> > Lyude was the person who submitted the patch for Thinkpad and should
> > know the OUI of the panel.
>
> no need - currently because of some confusion that got caused by the Intel HDR
> backlight interface being the only backlight interface that works properly on
> a lot of panels (many panels will advertise both interfaces, but might only
> work with the Intel one), we actually rely on a small allowlist of "approved"
> panels for enabling DPCD backlight control.
>
> …however, many of these panels are annoying and don't actually provide a
> reliable enough OUID to use for quirk detection, which is why we had to add
> EDID quirk detection as a temporary workaround for this. The current list of
> panels lives in drm_dp_helper.c:
>
> /*
> * Some devices have unreliable OUIDs where they don't set the device ID
> * correctly, and as a result we need to use the EDID for finding additional
> * DP quirks in such cases.
> */
> static const struct edid_quirk edid_quirk_list[] = {
> /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
> * only supports DPCD backlight controls
> */
> { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> /*
> * Some Dell CML 2020 systems have panels support both AUX and PWM
> * backlight control, and some only support AUX backlight control. All
> * said panels start up in AUX mode by default, and we don't have any
> * support for disabling HDR mode on these panels which would be
> * required to switch to PWM backlight control mode (plus, I'm not
> * even sure we want PWM backlight controls over DPCD backlight
> * controls anyway...). Until we have a better way of detecting these,
> * force DPCD backlight mode on all of them.
> */
> { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
> BIT(DP_QUIRK_FORCE_DPC
[PATCH 6/6] drm/vc4: hdmi: Enable 10/12 bpc output
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 68 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 -
3 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 21d20c8494e8..1c4dc774d56e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,6 +76,17 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
+
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
+
+#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
+
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
+
# define VC4_HD_M_SW_RST BIT(2)
# define VC4_HD_M_ENABLE BIT(0)
@@ -177,6 +188,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
*connector)
kfree(connector->state);
+ conn_state->base.max_bpc = 8;
+ conn_state->base.max_requested_bpc = 8;
+
__drm_atomic_helper_connector_reset(connector, &conn_state->base);
drm_atomic_helper_connector_tv_reset(connector);
}
@@ -224,12 +238,20 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
vc4_hdmi->ddc);
drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
+ /*
+* Some of the properties below require access to state, like bpc.
+* Allocate some default initial connector state with our reset helper.
+*/
+ if (connector->funcs->reset)
+ connector->funcs->reset(connector);
+
/* Create and attach TV margin props to this connector. */
ret = drm_mode_create_tv_margin_properties(dev);
if (ret)
return ret;
drm_connector_attach_tv_margin_properties(connector);
+ drm_connector_attach_max_bpc_property(connector, 8, 16);
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT);
@@ -495,6 +517,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
bool enable)
}
static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -538,7 +561,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
}
+
static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -558,6 +583,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
mode->crtc_vsync_end -
interlaced,
VC4_HDMI_VERTB_VBP));
+ unsigned char gcp;
+ bool gcp_en;
+ u32 reg;
HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
HDMI_WRITE(HDMI_HORZA,
@@ -583,6 +611,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
+ switch (state->max_bpc) {
+ case 12:
+ gcp = 6;
+ gcp_en = true;
+ break;
+ case 10:
+ gcp = 5;
+ gcp_en = true;
+ break;
+ case 8:
+ default:
+ gcp = 4;
+ gcp_en = false;
+ break;
+ }
+
+ reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
+ reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
+VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
+ reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE) |
+ VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH);
+ HDMI_WRITE(HDMI_DEEP_COLOR_CONFIG_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_WORD_1);
+ reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+ reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+ HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_CONFIG);
+ reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
+ reg |= gcp_en ? VC5_HDMI_GCP_CONFIG_GCP_ENABLE : 0;
+
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
Hi!
On Thu, Sep 24, 2020 at 02:42:18PM +, David Laight wrote:
> > On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > > Hi all,
> > >
> > > syzbot has reported [1] a global out-of-bounds read issue in
> > > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > > value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
> > > font data buffers, declared in lib/fonts/font_*.c:
> ...
> > > (drivers/video/fbdev/core/fbcon.c)
> > > if (font->width <= 8) {
> > > j = vc->vc_font.height;
> > > + if (font->charcount * j > FNTSIZE(fontdata))
> > > + return -EINVAL;
>
> Can that still go wrong because the multiply wraps?
Thank you for bringing this up!
The resizing of `vc_font.height` happened in vt_resizex():
(drivers/tty/vt/vt_ioctl.c)
if (v.v_clin > 32)
return -EINVAL;
[...]
for (i = 0; i < MAX_NR_CONSOLES; i++) {
[...]
if (v.v_clin)
vcp->vc_font.height = v.v_clin;
^^
It does check if `v.v_clin` is greater than 32. And, currently, all
built-in fonts have a `charcount` of 256.
Therefore, for built-in fonts and resizing happened in vt_resizex(), it
cannot cause an interger overflow.
However I am not very sure about user-provided fonts, and if there are
other functions that can resize `height` or even `charcount` to a really
huge value, but I will do more investigation and think about it.
Thank you,
Peilin Ye
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/bridge: sii902x: Enable I/O and core VCC supplies if present
On 9/24/20 3:22 PM, Fabio Estevam wrote:
Hi Fabio,
On Thu, Sep 24, 2020 at 5:16 PM Alexandru Gagniuc wrote:
+ ret = regulator_enable(sii902x->cvcc12);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable cvcc12 supply: %d\n", ret);
+ regulator_disable(sii902x->iovcc);
+ return PTR_ERR(sii902x->cvcc12);
return ret;
Thank you for catching that. I will fix it in v2.
ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
@@ -1012,11 +1052,11 @@ static int sii902x_probe(struct i2c_client *client,
regmap_read(sii902x->regmap, SII902X_INT_STATUS, &status);
regmap_write(sii902x->regmap, SII902X_INT_STATUS, status);
- if (client->irq > 0) {
+ if (sii902x->i2c->irq > 0) {
Unrelated change.
[snip]
Unrelated change.
[snip]
Unrelated change.
[snip]
Unrelated change.
The i2c initialization is moved into a separate function. Hence 'client'
is no longer available. Instead, it can be accessed via 'sii902x->i2c'.
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] video: Remove set but not used variable
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/sis/300vtbl.h:1064:28: warning:
‘SiS300_CHTVVCLKSONTSC’ defined but not used [-Wunused-const-variable=]
Reported-by: Hulk Robot
Signed-off-by: Li Heng
---
drivers/video/fbdev/sis/300vtbl.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/sis/300vtbl.h
b/drivers/video/fbdev/sis/300vtbl.h
index e4b4a26..26b19f7 100644
--- a/drivers/video/fbdev/sis/300vtbl.h
+++ b/drivers/video/fbdev/sis/300vtbl.h
@@ -1061,8 +1061,6 @@ static const unsigned char SiS300_CHTVVCLKUNTSC[] = {
0x29,0x29,0x29,0x29,0x2a,
static const unsigned char SiS300_CHTVVCLKONTSC[] = {
0x2c,0x2c,0x2c,0x2c,0x2d,0x2b };
-static const unsigned char SiS300_CHTVVCLKSONTSC[] = {
0x2c,0x2c,0x2c,0x2c,0x2d,0x2b };
-
static const unsigned char SiS300_CHTVVCLKUPAL[] = {
0x2f,0x2f,0x2f,0x2f,0x2f,0x31 };
static const unsigned char SiS300_CHTVVCLKOPAL[] = {
0x2f,0x2f,0x2f,0x2f,0x30,0x32 };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/vc4: hdmi: Store pixel frequency in the connector state
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 44 ++-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5e4ebb51a750..21d20c8494e8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -192,6 +192,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -609,9 +610,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -623,7 +644,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
? 2 : 1);
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -788,6 +809,26 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
*encoder)
{
}
+static int vc4_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ unsigned long long pixel_rate = mode->clock * 1000;
+
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ pixel_rate *= 2;
+
+ if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
+ return -EINVAL;
+
+ vc4_state->pixel_rate = pixel_rate;
+
+ return 0;
+}
+
static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
const struct drm_display_mode *mode)
@@ -801,6 +842,7 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
}
static const struct drm_encoder_helper_funcs vc4_hdmi_encoder_helper_funcs = {
+ .atomic_check = vc4_hdmi_encoder_atomic_check,
.mode_valid = vc4_hdmi_encoder_mode_valid,
.disable = vc4_hdmi_encoder_disable,
.enable = vc4_hdmi_encoder_enable,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index d53d9fd88bfe..dbe2393ae043 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -171,6 +171,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/vc4: hdmi: Support the 10/12 bit output
Hi, Here's some patches to enable the HDR output in the RPi4 HDMI controller. This needed a quite intrusive rework in the first patch to allow a CRTC to have access to the whole DRM state at atomic_enable / atomic_disable time. Let me know what you think, Maxime Maxime Ripard (6): drm/atomic: Pass the full state to CRTC atomic enable/disable drm/vc4: hvs: Align the HVS atomic hooks to the new API drm/vc4: Pass the atomic state to encoder hooks drm/vc4: hdmi: Create a custom connector state drm/vc4: hdmi: Store pixel frequency in the connector state drm/vc4: hdmi: Enable 10/12 bpc output drivers/gpu/drm/arc/arcpgu_crtc.c| 4 +- drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 8 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +- drivers/gpu/drm/arm/malidp_crtc.c| 6 +- drivers/gpu/drm/armada/armada_crtc.c | 8 +- drivers/gpu/drm/ast/ast_mode.c | 6 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4 +- drivers/gpu/drm/drm_atomic_helper.c | 4 +- drivers/gpu/drm/drm_simple_kms_helper.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 6 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 4 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +- drivers/gpu/drm/imx/dcss/dcss-crtc.c | 8 +- drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 4 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- drivers/gpu/drm/meson/meson_crtc.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c| 4 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 4 +- drivers/gpu/drm/mxsfb/mxsfb_kms.c| 4 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +- drivers/gpu/drm/qxl/qxl_display.c| 4 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +- drivers/gpu/drm/sti/sti_crtc.c | 4 +- drivers/gpu/drm/stm/ltdc.c | 4 +- drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 +- drivers/gpu/drm/tegra/dc.c | 8 +- drivers/gpu/drm/tidss/tidss_crtc.c | 6 +- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +- drivers/gpu/drm/vboxvideo/vbox_mode.c| 4 +- drivers/gpu/drm/vc4/vc4_crtc.c | 26 +-- drivers/gpu/drm/vc4/vc4_drv.h| 14 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 154 +++- drivers/gpu/drm/vc4/vc4_hdmi.h | 12 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 +- drivers/gpu/drm/vc4/vc4_hvs.c| 8 +- drivers/gpu/drm/vc4/vc4_txp.c| 8 +- drivers/gpu/drm/virtio/virtgpu_display.c | 4 +- drivers/gpu/drm/vkms/vkms_crtc.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +- drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +- drivers/gpu/drm/zte/zx_vou.c | 4 +- include/drm/drm_modeset_helper_vtables.h | 13 +- 48 files changed, 313 insertions(+), 129 deletions(-) base-commit: e742b35e5978d6a679adba2440eb91b0cba513f3 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Add missing struct identifier
fix warnings reported by make W=1
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:195: warning: cannot
understand function prototype: 'const struct dpu_intr_reg
dpu_intr_set[] = '
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:252: warning: cannot
understand function prototype: 'const struct dpu_irq_type
dpu_irq_map[] = '
Signed-off-by: Tian Tao
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index d84a84f..38482b1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -190,7 +190,7 @@ struct dpu_irq_type {
};
/**
- * List of DPU interrupt registers
+ * struct dpu_intr_reg - List of DPU interrupt registers
*/
static const struct dpu_intr_reg dpu_intr_set[] = {
{
@@ -246,8 +246,9 @@ static const struct dpu_intr_reg dpu_intr_set[] = {
};
/**
- * IRQ mapping table - use for lookup an irq_idx in this table that have
- * a matching interface type and instance index.
+ * struct dpu_irq_type - IRQ mapping table use for lookup an irq_idx in this
+ * table that have a matching interface type and
+ * instance index.
*/
static const struct dpu_irq_type dpu_irq_map[] = {
/* BEGIN MAP_RANGE: 0-31, INTR */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h
drivers/video/console/newport_con.c is borrowing FONT_EXTRA_WORDS macros
from drivers/video/fbdev/core/fbcon.h. To keep things simple, move all
definitions into .
Since newport_con now uses four extra words, initialize the fourth word in
newport_set_font() properly.
Cc: sta...@vger.kernel.org
Signed-off-by: Peilin Ye
---
drivers/video/console/newport_con.c | 7 +--
drivers/video/fbdev/core/fbcon.h| 7 ---
drivers/video/fbdev/core/fbcon_rotate.c | 1 +
drivers/video/fbdev/core/tileblit.c | 1 +
include/linux/font.h| 8
5 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/video/console/newport_con.c
b/drivers/video/console/newport_con.c
index 72f146d047d9..cd51b7a17a21 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -35,12 +35,6 @@
#define FONT_DATA ((unsigned char *)font_vga_8x16.data)
-/* borrowed from fbcon.c */
-#define REFCOUNT(fd) (((int *)(fd))[-1])
-#define FNTSIZE(fd)(((int *)(fd))[-2])
-#define FNTCHARCNT(fd) (((int *)(fd))[-3])
-#define FONT_EXTRA_WORDS 3
-
static unsigned char *font_data[MAX_NR_CONSOLES];
static struct newport_regs *npregs;
@@ -522,6 +516,7 @@ static int newport_set_font(int unit, struct console_font
*op)
FNTSIZE(new_data) = size;
FNTCHARCNT(new_data) = op->charcount;
REFCOUNT(new_data) = 0; /* usage counter */
+ FNTSUM(new_data) = 0;
p = new_data;
for (i = 0; i < op->charcount; i++) {
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 20dea853765f..5ee153ba977e 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -152,13 +152,6 @@ static inline int attr_col_ec(int shift, struct vc_data
*vc,
#define attr_bgcol_ec(bgshift, vc, info) attr_col_ec(bgshift, vc, info, 0)
#define attr_fgcol_ec(fgshift, vc, info) attr_col_ec(fgshift, vc, info, 1)
-/* Font */
-#define REFCOUNT(fd) (((int *)(fd))[-1])
-#define FNTSIZE(fd)(((int *)(fd))[-2])
-#define FNTCHARCNT(fd) (((int *)(fd))[-3])
-#define FNTSUM(fd) (((int *)(fd))[-4])
-#define FONT_EXTRA_WORDS 4
-
/*
* Scroll Method
*/
diff --git a/drivers/video/fbdev/core/fbcon_rotate.c
b/drivers/video/fbdev/core/fbcon_rotate.c
index c0d445294aa7..ac72d4f85f7d 100644
--- a/drivers/video/fbdev/core/fbcon_rotate.c
+++ b/drivers/video/fbdev/core/fbcon_rotate.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include "fbcon.h"
#include "fbcon_rotate.h"
diff --git a/drivers/video/fbdev/core/tileblit.c
b/drivers/video/fbdev/core/tileblit.c
index 1dfaff0881fb..257e94feeeb6 100644
--- a/drivers/video/fbdev/core/tileblit.c
+++ b/drivers/video/fbdev/core/tileblit.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include "fbcon.h"
diff --git a/include/linux/font.h b/include/linux/font.h
index 51b91c8b69d5..40ed008d7dad 100644
--- a/include/linux/font.h
+++ b/include/linux/font.h
@@ -59,4 +59,12 @@ extern const struct font_desc *get_default_font(int xres,
int yres,
/* Max. length for the name of a predefined font */
#define MAX_FONT_NAME 32
+/* Extra word getters */
+#define REFCOUNT(fd) (((int *)(fd))[-1])
+#define FNTSIZE(fd)(((int *)(fd))[-2])
+#define FNTCHARCNT(fd) (((int *)(fd))[-3])
+#define FNTSUM(fd) (((int *)(fd))[-4])
+
+#define FONT_EXTRA_WORDS 4
+
#endif /* _VIDEO_FONT_H */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Hi all,
> >
> > syzbot has reported [1] a global out-of-bounds read issue in
> > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
> > font data buffers, declared in lib/fonts/font_*.c:
...
> > (drivers/video/fbdev/core/fbcon.c)
> > if (font->width <= 8) {
> > j = vc->vc_font.height;
> > + if (font->charcount * j > FNTSIZE(fontdata))
> > + return -EINVAL;
Can that still go wrong because the multiply wraps?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: return correct connection status after suspend/resume
return connection status base on hpd realtime state status
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 13 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 58 -
drivers/gpu/drm/msm/dp/dp_reg.h | 2 +
4 files changed, 39 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index b15b4ce4ba35..4f3679b7e262 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -572,6 +572,19 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
*dp_catalog)
dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
}
+u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+ u32 status = 0;
+
+ status = dp_read_aux(catalog, REG_DP_DP_HPD_INT_STATUS);
+ status &= DP_DP_HPD_STATE_STATUS_BITS_MASK;
+ status >>= DP_DP_HPD_STATE_STATUS_BITS_SHIFT;
+
+ return status;
+}
+
u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 4b7666f1fe6f..6d257dbebf29 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -97,6 +97,7 @@ void dp_catalog_ctrl_enable_irq(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_hpd_config_intr(struct dp_catalog *dp_catalog,
u32 intr_mask, bool en);
void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog);
+u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog);
u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_phy_reset(struct dp_catalog *dp_catalog);
int dp_catalog_ctrl_update_vx_px(struct dp_catalog *dp_catalog, u8 v_level,
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e175aa3fd3a9..1f16508d0387 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -114,8 +114,6 @@ struct dp_display_private {
struct dp_event event_list[DP_EVENT_Q_MAX];
spinlock_t event_lock;
- struct completion resume_comp;
-
struct dp_audio *audio;
};
@@ -508,9 +506,6 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
return 0;
}
- if (state == ST_SUSPENDED)
- tout = DP_TIMEOUT_NONE;
-
atomic_set(&dp->hpd_state, ST_CONNECT_PENDING);
hpd->hpd_high = 1;
@@ -798,8 +793,6 @@ static int dp_display_enable(struct dp_display_private *dp,
u32 data)
if (!rc)
dp_display->power_on = true;
- /* complete resume_comp regardless it is armed or not */
- complete(&dp->resume_comp);
return rc;
}
@@ -1151,9 +1144,6 @@ static int dp_display_probe(struct platform_device *pdev)
}
mutex_init(&dp->event_mutex);
-
- init_completion(&dp->resume_comp);
-
g_dp_display = &dp->dp_display;
/* Store DP audio handle inside DP display */
@@ -1189,6 +1179,26 @@ static int dp_display_remove(struct platform_device
*pdev)
static int dp_pm_resume(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dp_display_private *dp = platform_get_drvdata(pdev);
+ u32 status;
+
+ if (!dp) {
+ DRM_ERROR("DP driver bind failed. Invalid driver data\n");
+ return -EINVAL;
+ }
+
+ dp_display_host_init(dp);
+
+ dp_catalog_ctrl_hpd_config(dp->catalog);
+
+ status = dp_catalog_hpd_get_state_status(dp->catalog);
+
+ if (status)
+ dp->dp_display.is_connected = true;
+ else
+ dp->dp_display.is_connected = false;
+
return 0;
}
@@ -1202,6 +1212,9 @@ static int dp_pm_suspend(struct device *dev)
return -EINVAL;
}
+ if (dp->core_initialized == true)
+ dp_display_disable(dp, 0);
+
atomic_set(&dp->hpd_state, ST_SUSPENDED);
return 0;
@@ -1317,19 +1330,6 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
struct drm_device *dev,
return 0;
}
-static int dp_display_wait4resume_done(struct dp_display_private *dp)
-{
- int ret = 0;
-
- reinit_completion(&dp->resume_comp);
- if (!wait_for_completion_timeout(&dp->resume_comp,
- WAIT_FOR_RESUME_TIMEOUT_JIFFIES)) {
- DRM_ERROR("wait4resume_done timedout\n");
- ret = -ETIMEDOUT;
- }
- return ret;
-}
-
int msm_dp_display_enable(struct msm_dp *dp, struct drm_encoder *encoder)
{
int rc = 0;
@@ -1359,14 +1359,6 @@ int msm
[PATCH] drm/vc4: hdmi: Fix variable ret not used
drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_set_audio_infoframe’:
drivers/gpu/drm/vc4/vc4_hdmi.c:334:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index e8f99e2..5c3ddef 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -334,6 +334,10 @@ static void vc4_hdmi_set_audio_infoframe(struct
drm_encoder *encoder)
int ret;
ret = hdmi_audio_infoframe_init(&frame.audio);
+ if (ret < 0) {
+ DRM_ERROR("failed to setup audio infoframe");
+ return;
+ }
frame.audio.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
frame.audio.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > On Thu, 24 Sep 2020 08:57:52 +0200 > Thomas Gleixner wrote: > >> > Now as for migration disabled nesting, at least now we would have >> > groupings of this, and perhaps the theorists can handle that. I mean, >> > how is this much different that having a bunch of tasks blocked on a >> > mutex with the owner is pinned on a CPU? >> > >> > migrate_disable() is a BKL of pinning affinity. >> >> No. That's just wrong. preempt disable is a concurrency control, > > I think you totally misunderstood what I was saying. The above wasn't about > comparing preempt_disable to migrate_disable. It was comparing > migrate_disable to a chain of tasks blocked on mutexes where the top owner > has preempt_disable set. You still have a bunch of tasks that can't move to > other CPUs. What? The top owner does not prevent any task from moving. The tasks cannot move because they are blocked on the mutex, which means they are not runnable and non runnable tasks are not migrated at all. I really don't understand what you are trying to say. >> > If we only have local_lock() available (even on !RT), then it makes >> > the blocking in groups. At least this way you could grep for all the >> > different local_locks in the system and plug that into the algorithm >> > for WCS, just like one would with a bunch of mutexes. >> >> You cannot do that on RT at all where migrate disable is substituting >> preempt disable in spin and rw locks. The result would be the same as >> with a !RT kernel just with horribly bad performance. > > Note, the spin and rwlocks already have a lock associated with them. Why > would it be any different on RT? I wasn't suggesting adding another lock > inside a spinlock. Why would I recommend THAT? I wasn't recommending > blindly replacing migrate_disable() with local_lock(). I just meant expose > local_lock() but not migrate_disable(). We already exposed local_lock() to non RT and it's for places which do preempt_disable() or local_irq_disable() without having a lock associated. But both primitives are scope less and therefore behave like CPU local BKLs. What local_lock() provides in these cases is: - Making the protection scope clear by associating a named local lock which is coverred by lockdep. - It still maps to preempt_disable() or local_irq_disable() in !RT kernels - The scope and the named lock allows RT kernels to substitute with real (recursion aware) locking primitives which keep preemption and interupts enabled, but provide the fine grained protection for the scoped critical section. So how would you substitute migrate_disable() with a local_lock()? You can't. Again migrate_disable() is NOT a concurrency control and therefore it cannot be substituted by any concurrency control primitive. >> That means the stacking problem has to be solved anyway. >> >> So why on earth do you want to create yet another special duct tape case >> for kamp_local() which proliferates inconsistency instead of aiming for >> consistency accross all preemption models? > > The idea was to help with the scheduling issue. I don't see how mixing concepts and trying to duct tape a problem which is clearly in the realm of the scheduler, i.e. load balancing and placing algorithms, is helpful. Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Thu, Sep 24, 2020 at 06:45:16PM +0300, Dan Carpenter wrote: > Smatch has a tool to show where struct members are set. > > `~/smatch/smatch_data/db/smdb.py where console_font height` > > It's not perfect and this output comes from allmodconfig on yesterday's > linux-next. > > regards, > dan carpenter Wow, thank you for the really interesting information! > drivers/video/console/vgacon.c | vgacon_init| (struct > console_font)->height | 0-32 > drivers/video/console/vgacon.c | vgacon_adjust_height | (struct > console_font)->height | 1-32 > drivers/video/fbdev/core/fbcon.c | fbcon_startup | (struct > console_font)->height | 6,8,10-11,14,16,18,22,32 > drivers/video/fbdev/core/fbcon.c | fbcon_init | (struct > console_font)->height | 6,8,10-11,14,16,18,22,32 > drivers/video/fbdev/core/fbcon.c | fbcon_do_set_font | (struct > console_font)->height | 0-u32max > drivers/video/fbdev/core/fbcon.c | fbcon_set_def_font | (struct > console_font)->height | 6,8,10-11,14,16,18,22,32 > drivers/usb/misc/sisusbvga/sisusb_con.c | sisusbcon_init | > (struct console_font)->height | 0-u32max In looking at this one, c->vc_font.height = sisusb->current_font_height; `sisusb->current_font_height` is only set in sisusbcon_do_font_op(): sisusb->current_font_height = fh; and... > drivers/usb/misc/sisusbvga/sisusb_con.c | sisusbcon_do_font_op | > (struct console_font)->height | 1-32 ...sisusbcon_do_font_op() is called in four places, with an `fh` of either 16, `sisusb->font_backup_height`, or `font->height`. The latter two cases all come from sisusbcon_font_set(), whose dispatcher, con_font_set() gurantees that `font->height` is less than or equal to 32, as shown by Smatch here. > drivers/tty/vt/vt_ioctl.c | vt_k_ioctl | (struct > console_font)->height | ignore > drivers/tty/vt/vt_ioctl.c | vt_resizex | (struct > console_font)->height | 0-u32max > drivers/tty/vt/vt_ioctl.c | vt_ioctl | (struct > console_font)->height | ignore > drivers/tty/vt/vt_ioctl.c | vt_compat_ioctl| (struct > console_font)->height | ignore > drivers/tty/vt/vt.c| vc_allocate| (struct > console_font)->height | 0 > drivers/tty/vt/vt.c| vt_resize | (struct > console_font)->height | ignore > drivers/tty/vt/vt.c| do_con_write | (struct > console_font)->height | ignore > drivers/tty/vt/vt.c| con_unthrottle | (struct > console_font)->height | ignore > drivers/tty/vt/vt.c| con_flush_chars| (struct > console_font)->height | ignore > drivers/tty/vt/vt.c| con_shutdown | (struct > console_font)->height | ignore > drivers/tty/vt/vt.c| con_cleanup| (struct > console_font)->height | ignore > drivers/tty/vt/vt.c| con_init | (struct > console_font)->height | 0 > drivers/tty/vt/vt.c| con_font_set | (struct > console_font)->height | 1-32 > drivers/tty/vt/vt.c| con_font_default | (struct > console_font)->height | 0-u32max > drivers/tty/vt/selection.c | paste_selection| (struct > console_font)->height | ignore I will go through the list starting from these "0-u32max" cases. Thanks again! Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: commit_work scheduling
On 09/24/20 10:49, Daniel Vetter wrote: [...] > > > I also thought kernel threads can be distinguished from others, so > > > userspace shouldn't be able to sneak in and get elevated by accident. > > > > I guess maybe you could look at the parent? I still would like to > > think that we could come up with something a bit less shaking than > > matching thread names by regexp.. > > ps marks up kernel threads with [], so there is a way. But I haven't > looked at what it is exactly that tells kernel threads apart from others. > > But aside from that sounds like "match right kernel thread with regex and > set its scheduler class" is how this is currently done, if I'm > understanding what Tejun and Peter said correctly. > > Not pretty, but also *shrug* ... Isn't there a real danger that a sneaky application names its threads to match this regex and get a free promotion to RT without having the capability to do so? Cheers -- Qais Yousef ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/bridge: sii902x: Enable I/O and core VCC supplies if present
On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
voltage before the reset sequence is initiated. On most boards, this
assumption is true at boot-up, so initialization succeeds.
However, when we try to initialize the chip with incorrect supply
voltages, it will not respond to I2C requests. sii902x_probe() fails
with -ENXIO.
To resolve this, look for the "iovcc" and "cvcc12" regulators, and
make sure they are enabled before starting the reset sequence. If
these supplies are not available in devicetree, then they will default
to dummy-regulator. In that case everything will work like before.
This was observed on a STM32MP157C-DK2 booting in u-boot falcon mode.
On this board, the supplies would be set by the second stage
bootloader, which does not run in falcon mode.
Signed-off-by: Alexandru Gagniuc
---
drivers/gpu/drm/bridge/sii902x.c | 54
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 33fd33f953ec..a5558d83e4c5 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -168,6 +169,8 @@ struct sii902x {
struct drm_connector connector;
struct gpio_desc *reset_gpio;
struct i2c_mux_core *i2cmux;
+ struct regulator *iovcc;
+ struct regulator *cvcc12;
/*
* Mutex protects audio and video functions from interfering
* each other, by keeping their i2c command sequences atomic.
@@ -954,13 +957,13 @@ static const struct drm_bridge_timings
default_sii902x_timings = {
| DRM_BUS_FLAG_DE_HIGH,
};
+static int sii902x_init(struct sii902x *sii902x);
+
static int sii902x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct device *dev = &client->dev;
- unsigned int status = 0;
struct sii902x *sii902x;
- u8 chipid[4];
int ret;
ret = i2c_check_functionality(client->adapter,
@@ -989,6 +992,43 @@ static int sii902x_probe(struct i2c_client *client,
mutex_init(&sii902x->mutex);
+ sii902x->iovcc = devm_regulator_get(dev, "iovcc");
+ if (IS_ERR(sii902x->iovcc))
+ return PTR_ERR(sii902x->iovcc);
+
+ sii902x->cvcc12 = devm_regulator_get(dev, "cvcc12");
+ if (IS_ERR(sii902x->cvcc12))
+ return PTR_ERR(sii902x->cvcc12);
+
+ ret = regulator_enable(sii902x->iovcc);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable iovcc supply: %d\n", ret);
+ return ret;
+ }
+
+ ret = regulator_enable(sii902x->cvcc12);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable cvcc12 supply: %d\n", ret);
+ regulator_disable(sii902x->iovcc);
+ return PTR_ERR(sii902x->cvcc12);
+ }
+
+ ret = sii902x_init(sii902x);
+ if (ret < 0) {
+ regulator_disable(sii902x->cvcc12);
+ regulator_disable(sii902x->iovcc);
+ }
+
+ return ret;
+}
+
+static int sii902x_init(struct sii902x *sii902x)
+{
+ struct device *dev = &sii902x->i2c->dev;
+ unsigned int status = 0;
+ u8 chipid[4];
+ int ret;
+
sii902x_reset(sii902x);
ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
@@ -1012,11 +1052,11 @@ static int sii902x_probe(struct i2c_client *client,
regmap_read(sii902x->regmap, SII902X_INT_STATUS, &status);
regmap_write(sii902x->regmap, SII902X_INT_STATUS, status);
- if (client->irq > 0) {
+ if (sii902x->i2c->irq > 0) {
regmap_write(sii902x->regmap, SII902X_INT_ENABLE,
SII902X_HOTPLUG_EVENT);
- ret = devm_request_threaded_irq(dev, client->irq, NULL,
+ ret = devm_request_threaded_irq(dev, sii902x->i2c->irq, NULL,
sii902x_interrupt,
IRQF_ONESHOT, dev_name(dev),
sii902x);
@@ -1031,9 +1071,9 @@ static int sii902x_probe(struct i2c_client *client,
sii902x_audio_codec_init(sii902x, dev);
- i2c_set_clientdata(client, sii902x);
+ i2c_set_clientdata(sii902x->i2c, sii902x);
- sii902x->i2cmux = i2c_mux_alloc(client->adapter, dev,
+ sii902x->i2cmux = i2c_mux_alloc(sii902x->i2c->adapter, dev,
1, 0, I2C_MUX_GATE,
sii902x_i2c_bypass_select,
sii902x_i2c_bypass_deselect);
@@ -1051,6 +1091,8 @@ static int sii902x_remove(struct i2c_client *client)
i2c_mux_del_adapters(sii902x->i2cmux);
drm_bridge_remove(&sii902x->bridge);
+ regulator_disable(sii902x->cvcc12);
+ regulator_disable(si
[PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
Hi all,
syzbot has reported [1] a global out-of-bounds read issue in
fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
font data buffers, declared in lib/fonts/font_*.c:
(e.g. lib/fonts/font_8x8.c)
#define FONTDATAMAX 2048
static const unsigned char fontdata_8x8[FONTDATAMAX] = {
/* 0 0x00 '^@' */
0x00, /* */
0x00, /* */
0x00, /* */
0x00, /* */
0x00, /* */
0x00, /* */
0x00, /* */
0x00, /* */
[...]
In order to perform a reliable range check, fbcon_get_font() needs to know
`FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
do not keep that information in our font descriptor,
`struct console_font`:
(include/uapi/linux/kd.h)
struct console_font {
unsigned int width, height; /* font size */
unsigned int charcount;
unsigned char *data;/* font data with height fixed to 32 */
};
To make things worse, `struct console_font` is part of the UAPI, so we
cannot add a new field to keep track of `FONTDATAMAX`.
Fortunately, the framebuffer layer itself gives us a hint of how to
resolve this issue without changing UAPI. When allocating a buffer for a
user-provided font, fbcon_set_font() reserves four "extra words" at the
beginning of the buffer:
(drivers/video/fbdev/core/fbcon.c)
new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
[...]
new_data += FONT_EXTRA_WORDS * sizeof(int);
FNTSIZE(new_data) = size;
FNTCHARCNT(new_data) = charcount;
REFCOUNT(new_data) = 0; /* usage counter */
[...]
FNTSUM(new_data) = csum;
Later, to get the size of a data buffer, the framebuffer layer simply
calls FNTSIZE() on it:
(drivers/video/fbdev/core/fbcon.h)
/* Font */
#define REFCOUNT(fd)(((int *)(fd))[-1])
#define FNTSIZE(fd) (((int *)(fd))[-2])
#define FNTCHARCNT(fd) (((int *)(fd))[-3])
#define FNTSUM(fd) (((int *)(fd))[-4])
#define FONT_EXTRA_WORDS 4
Currently, this is only done for user-provided fonts. Let us do the same
thing for built-in fonts, prepend these "extra words" (including
`FONTDATAMAX`) to their data buffers, so that other subsystems, like the
framebuffer layer, can use these macros on all fonts, no matter built-in
or user-provided. As an example, this series fixes the syzbot issue in
fbcon_get_font():
(drivers/video/fbdev/core/fbcon.c)
if (font->width <= 8) {
j = vc->vc_font.height;
+ if (font->charcount * j > FNTSIZE(fontdata))
+ return -EINVAL;
[...]
Similarly, newport_con also use these macros. It only uses three of them:
(drivers/video/console/newport_con.c)
/* borrowed from fbcon.c */
#define REFCOUNT(fd)(((int *)(fd))[-1])
#define FNTSIZE(fd) (((int *)(fd))[-2])
#define FNTCHARCNT(fd) (((int *)(fd))[-3])
#define FONT_EXTRA_WORDS 3
To keep things simple, move all these macro definitions to ,
use four words instead of three, and initialize the fourth word in
newport_set_font() properly.
Many thanks to Greg Kroah-Hartman , who
reviewed and improved this series!
[1]: KASAN: global-out-of-bounds Read in fbcon_get_font
https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfd
Peilin Ye (3):
fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h
Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
fbcon: Fix global-out-of-bounds read in fbcon_get_font()
drivers/video/console/newport_con.c | 7 +--
drivers/video/fbdev/core/fbcon.c| 12
drivers/video/fbdev/core/fbcon.h| 7 ---
drivers/video/fbdev/core/fbcon_rotate.c | 1 +
drivers/video/fbdev/core/tileblit.c | 1 +
include/linux/font.h| 13 +
lib/fonts/font_10x18.c | 9 -
lib/fonts/font_6x10.c | 9 +
lib/fonts/font_6x11.c | 9 -
lib/fonts/font_7x14.c | 9 -
lib/fonts/font_8x16.c | 9 -
lib/fonts/font_8x8.c| 9 -
lib/fonts/font_acorn_8x8.c | 9 ++---
lib/fonts/font_mini_4x6.c | 8
lib/fonts/font_pearl_8x8.c | 9 -
lib/fonts/font_sun12x22.c | 9 -
lib/fonts/font_sun8x16.c| 7 ---
lib/fonts/font_ter16x32.c | 9 -
18 files changed, 79 insertions(+), 67 deletions(-)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/hisilicon: Deleted the drm_device declaration
drm_framebuffer.h contains drm/drm_device.h and struct drm_device is
already declared in this file, so there is no need to declare struct
drm_device in hibm_drm_drv.h.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 87d2aad..6a63502 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -22,8 +22,6 @@
#include
#include
-struct drm_device;
-
struct hibmc_connector {
struct drm_connector base;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/atomic: Pass the full state to CRTC atomic enable/disable
If the CRTC driver ever needs to access the full DRM state, it can't do so
at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state
will have cleared the pointer from the struct drm_crtc_state to the struct
drm_atomic_state before calling those hooks.
In order to allow that, let's pass the full DRM state to atomic_enable and
atomic_disable. The conversion was done using coccinelle, built tested on
all the drivers and actually tested on vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/arc/arcpgu_crtc.c| 4 ++--
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 8 ++--
drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++--
drivers/gpu/drm/arm/malidp_crtc.c| 6 --
drivers/gpu/drm/armada/armada_crtc.c | 8 ++--
drivers/gpu/drm/ast/ast_mode.c | 6 --
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4 ++--
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/gpu/drm/drm_simple_kms_helper.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 6 --
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 4 ++--
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 ++--
drivers/gpu/drm/imx/dcss/dcss-crtc.c | 8 ++--
drivers/gpu/drm/imx/ipuv3-crtc.c | 6 --
drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++--
drivers/gpu/drm/meson/meson_crtc.c | 8
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c| 4 ++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 4 ++--
drivers/gpu/drm/mxsfb/mxsfb_kms.c| 4 ++--
drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++--
drivers/gpu/drm/qxl/qxl_display.c| 4 ++--
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 --
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 --
drivers/gpu/drm/sti/sti_crtc.c | 4 ++--
drivers/gpu/drm/stm/ltdc.c | 4 ++--
drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 ++--
drivers/gpu/drm/tegra/dc.c | 8
drivers/gpu/drm/tidss/tidss_crtc.c | 6 --
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 ++--
drivers/gpu/drm/vboxvideo/vbox_mode.c| 4 ++--
drivers/gpu/drm/vc4/vc4_crtc.c | 8 ++--
drivers/gpu/drm/vc4/vc4_txp.c| 8 ++--
drivers/gpu/drm/virtio/virtgpu_display.c | 4 ++--
drivers/gpu/drm/vkms/vkms_crtc.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++--
drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 --
drivers/gpu/drm/zte/zx_vou.c | 4 ++--
include/drm/drm_modeset_helper_vtables.h | 13 ++---
43 files changed, 128 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index be7c29cec318..042d7b54a6de 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -116,7 +116,7 @@ static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc
*crtc)
}
static void arc_pgu_crtc_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -127,7 +127,7 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc
*crtc,
}
static void arc_pgu_crtc_atomic_disable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index f33418d6e1a0..a4bbf56a7fc1 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -273,8 +273,10 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
static void
komeda_crtc_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old)
+ struct drm_atomic_state *state)
{
+ struct drm_crtc_state *old = drm_atomic_get_old_crtc_state(state,
+ crtc);
pm_runtime_get_sync(crtc->dev->dev);
komeda_crtc_prepare(to_kcrtc(crtc));
drm_crtc_vblank_on(crtc);
@@ -319,8 +321,10 @@ komeda_crtc_flush_and_wait_for_flip_done(struct
komeda_crtc
[PATCH 3/3] fbcon: Fix global-out-of-bounds read in fbcon_get_font()
fbcon_get_font() is reading out-of-bounds. A malicious user may resize
`vc->vc_font.height` to a large value, causing fbcon_get_font() to
read out of `fontdata`.
fbcon_get_font() handles both built-in and user-provided fonts.
Fortunately, recently we have added FONT_EXTRA_WORDS support for built-in
fonts, so fix it by adding range checks using FNTSIZE().
This patch depends on patch "fbdev, newport_con: Move FONT_EXTRA_WORDS
macros into linux/font.h", and patch "Fonts: Support FONT_EXTRA_WORDS
macros for built-in fonts".
Cc: sta...@vger.kernel.org
Reported-and-tested-by: syzbot+29d4ed7f3bdedf2aa...@syzkaller.appspotmail.com
Link:
https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfd
Signed-off-by: Peilin Ye
---
drivers/video/fbdev/core/fbcon.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 66167830fefd..bda24c64e646 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2492,6 +2492,9 @@ static int fbcon_get_font(struct vc_data *vc, struct
console_font *font)
if (font->width <= 8) {
j = vc->vc_font.height;
+ if (font->charcount * j > FNTSIZE(fontdata))
+ return -EINVAL;
+
for (i = 0; i < font->charcount; i++) {
memcpy(data, fontdata, j);
memset(data + j, 0, 32 - j);
@@ -2500,6 +2503,9 @@ static int fbcon_get_font(struct vc_data *vc, struct
console_font *font)
}
} else if (font->width <= 16) {
j = vc->vc_font.height * 2;
+ if (font->charcount * j > FNTSIZE(fontdata))
+ return -EINVAL;
+
for (i = 0; i < font->charcount; i++) {
memcpy(data, fontdata, j);
memset(data + j, 0, 64 - j);
@@ -2507,6 +2513,9 @@ static int fbcon_get_font(struct vc_data *vc, struct
console_font *font)
fontdata += j;
}
} else if (font->width <= 24) {
+ if (font->charcount * (vc->vc_font.height * sizeof(u32)) >
FNTSIZE(fontdata))
+ return -EINVAL;
+
for (i = 0; i < font->charcount; i++) {
for (j = 0; j < vc->vc_font.height; j++) {
*data++ = fontdata[0];
@@ -2519,6 +2528,9 @@ static int fbcon_get_font(struct vc_data *vc, struct
console_font *font)
}
} else {
j = vc->vc_font.height * 4;
+ if (font->charcount * j > FNTSIZE(fontdata))
+ return -EINVAL;
+
for (i = 0; i < font->charcount; i++) {
memcpy(data, fontdata, j);
memset(data + j, 0, 128 - j);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/vc4: Pass the atomic state to encoder hooks
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 878718b8836e..17a4427bd899 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 232da0f50aa1..89e36da5043d 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -442,12 +442,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 03825596a308..7d2593398094 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
-static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder)
+static void vc4_hdmi
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Thu, Sep 24, 2020 at 04:09:37PM +0200, Greg Kroah-Hartman wrote: > On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote: > > Peilin Ye (3): > > fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h > > Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts > > fbcon: Fix global-out-of-bounds read in fbcon_get_font() > > > > drivers/video/console/newport_con.c | 7 +-- > > drivers/video/fbdev/core/fbcon.c| 12 > > drivers/video/fbdev/core/fbcon.h| 7 --- > > drivers/video/fbdev/core/fbcon_rotate.c | 1 + > > drivers/video/fbdev/core/tileblit.c | 1 + > > include/linux/font.h| 13 + > > lib/fonts/font_10x18.c | 9 - > > lib/fonts/font_6x10.c | 9 + > > lib/fonts/font_6x11.c | 9 - > > lib/fonts/font_7x14.c | 9 - > > lib/fonts/font_8x16.c | 9 - > > lib/fonts/font_8x8.c| 9 - > > lib/fonts/font_acorn_8x8.c | 9 ++--- > > lib/fonts/font_mini_4x6.c | 8 > > lib/fonts/font_pearl_8x8.c | 9 - > > lib/fonts/font_sun12x22.c | 9 - > > lib/fonts/font_sun8x16.c| 7 --- > > lib/fonts/font_ter16x32.c | 9 - > > 18 files changed, 79 insertions(+), 67 deletions(-) > > Gotta love going backwards in arrays :) > > Nice work, whole series is: > > Reviewed-by: Greg Kroah-Hartman Thank you for reviewing it! Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/vc4: hdmi: Create a custom connector state
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 7d2593398094..5e4ebb51a750 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,16 +170,39 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *conn_state =
kzalloc(sizeof(*conn_state), GFP_KERNEL);
+
+ if (connector->state)
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(connector->state);
+
+ __drm_atomic_helper_connector_reset(connector, &conn_state->base);
drm_atomic_helper_connector_tv_reset(connector);
}
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
+
+ return &new_state->base;
+}
+
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.detect = vc4_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 63c6f8bddf1d..d53d9fd88bfe 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -169,6 +169,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/vc4: hvs: Align the HVS atomic hooks to the new API
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
drivers/gpu/drm/vc4/vc4_hvs.c | 8 +---
drivers/gpu/drm/vc4/vc4_txp.c | 8 ++--
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 2e6fc2f28946..878718b8836e 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -503,8 +503,6 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
@@ -517,7 +515,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
*/
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
vc4_encoder->pre_crtc_configure(encoder);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 90b911fd2a7f..232da0f50aa1 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -915,8 +915,8 @@ extern struct platform_driver vc4_hvs_driver;
void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output);
int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output);
int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
-void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
-void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
+void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
+void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *state);
void vc4_hvs_dump_state(struct drm_device *dev);
void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 4d0a833366ce..22403ab2a430 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -391,11 +391,12 @@ static void vc4_hvs_update_dlist(struct drm_crtc *crtc)
}
void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
- struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
+ struct drm_crtc_state *new_crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
+ struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(new_crtc_state);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
bool oneshot = vc4_state->feed_txp;
@@ -404,9 +405,10 @@ void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
}
void vc4_hvs_atomic_disable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
+ struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(old_state);
unsigned int chan = vc4_state->assigned_channel;
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index c127bca0f246..8692b101797e 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -403,23 +403,19 @@ static int vc4_txp_atomic_check(struct drm_crtc *crtc,
static void vc4_txp_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
}
static void vc4_txp_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
/* Disable vblank irq handling
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
>
> On 22/09/2020 09:39, Leon Romanovsky wrote:
> > From: Maor Gottlieb
> >
> > Extend __sg_alloc_table_from_pages to support dynamic allocation of
> > SG table from pages. It should be used by drivers that can't supply
> > all the pages at one time.
> >
> > This function returns the last populated SGE in the table. Users should
> > pass it as an argument to the function from the second call and forward.
> > As before, nents will be equal to the number of populated SGEs (chunks).
>
> So it's appending and growing the "list", did I get that right? Sounds handy
> indeed. Some comments/questions below.
Yes, we (RDMA) use this function to chain contiguous pages.
>
> >
> > With this new extension, drivers can benefit the optimization of merging
> > contiguous pages without a need to allocate all pages in advance and
> > hold them in a large buffer.
> >
> > E.g. with the Infiniband driver that allocates a single page for hold
> > the
> > pages. For 1TB memory registration, the temporary buffer would consume
> > only
> > 4KB, instead of 2GB.
> >
> > Signed-off-by: Maor Gottlieb
> > Signed-off-by: Leon Romanovsky
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 12 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 +-
> > include/linux/scatterlist.h | 43 +++---
> > lib/scatterlist.c | 158 +++-
> > lib/sg_pool.c | 3 +-
> > tools/testing/scatterlist/main.c| 9 +-
> > 6 files changed, 163 insertions(+), 77 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > index 12b30075134a..f2eaed6aca3d 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> > @@ -403,6 +403,7 @@ __i915_gem_userptr_alloc_pages(struct
> > drm_i915_gem_object *obj,
> > unsigned int max_segment = i915_sg_segment_size();
> > struct sg_table *st;
> > unsigned int sg_page_sizes;
> > + struct scatterlist *sg;
> > int ret;
> >
> > st = kmalloc(sizeof(*st), GFP_KERNEL);
> > @@ -410,13 +411,12 @@ __i915_gem_userptr_alloc_pages(struct
> > drm_i915_gem_object *obj,
> > return ERR_PTR(-ENOMEM);
> >
> > alloc_table:
> > - ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
> > - 0, num_pages << PAGE_SHIFT,
> > - max_segment,
> > - GFP_KERNEL);
> > - if (ret) {
> > + sg = __sg_alloc_table_from_pages(st, pvec, num_pages, 0,
> > +num_pages << PAGE_SHIFT, max_segment,
> > +NULL, 0, GFP_KERNEL);
> > + if (IS_ERR(sg)) {
> > kfree(st);
> > - return ERR_PTR(ret);
> > + return ERR_CAST(sg);
> > }
> >
> > ret = i915_gem_gtt_prepare_pages(obj, st);
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > index ab524ab3b0b4..f22acd398b1f 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > @@ -419,6 +419,7 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
> > int ret = 0;
> > static size_t sgl_size;
> > static size_t sgt_size;
> > + struct scatterlist *sg;
> >
> > if (vmw_tt->mapped)
> > return 0;
> > @@ -441,13 +442,15 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
> > if (unlikely(ret != 0))
> > return ret;
> >
> > - ret = __sg_alloc_table_from_pages
> > - (&vmw_tt->sgt, vsgt->pages, vsgt->num_pages, 0,
> > -(unsigned long) vsgt->num_pages << PAGE_SHIFT,
> > -dma_get_max_seg_size(dev_priv->dev->dev),
> > -GFP_KERNEL);
> > - if (unlikely(ret != 0))
> > + sg = __sg_alloc_table_from_pages(&vmw_tt->sgt, vsgt->pages,
> > + vsgt->num_pages, 0,
> > + (unsigned long) vsgt->num_pages << PAGE_SHIFT,
> > + dma_get_max_seg_size(dev_priv->dev->dev),
> > + NULL, 0, GFP_KERNEL);
> > + if (IS_ERR(sg)) {
> > + ret = PTR_ERR(sg);
> > goto out_sg_alloc_fail;
> > + }
> >
> > if (vsgt->num_pages > vmw_tt->sgt.nents) {
> > uint64_t over_alloc =
> > diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> > index 45cf7b69d852..c24cc667b56b 100644
> > --- a/include/linux/scatterlist.h
> > +++ b/include/linux/scatterlist.h
> > @@ -165,6 +165,22 @@ static inline void sg_set_buf(struct scatterlist *sg,
> > const void *buf,
> > #define for_each_sgtable_dma_sg(sgt, sg, i) \
> >
Re: [PATCH] drm/hisilicon: Deleted the drm_device declaration
Hi
Am 25.09.20 um 09:02 schrieb Thomas Zimmermann:
> Hi,
>
> just a few nits.
>
> Am 25.09.20 um 08:49 schrieb Tian Tao:
>> drm_framebuffer.h contains drm/drm_device.h and struct drm_device is
>
> contains -> includes
>
>> already declared in this file, so there is no need to declare struct
>
> declared -> defined
Wait a second. drm_framebuffer.h actually declares struct drm_device,
but does not include . So the commit messag should say
something like
drm_framebuffer.h already declares struct drm_device, so there's no
need to declare it in hibm_drm_drv.h
>
>> drm_device in hibm_drm_drv.h.
>>
>> Signed-off-by: Tian Tao
>
> Acked-by: Thomas Zimmermann
>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 87d2aad..6a63502 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -22,8 +22,6 @@
>> #include
>> #include
>>
>> -struct drm_device;
>> -
>> struct hibmc_connector {
>> struct drm_connector base;
>>
>>
>
--
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
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 waltib...@protonmail.com changed: What|Removed |Added CC||waltib...@protonmail.com --- Comment #65 from waltib...@protonmail.com --- I'm getting the issue again on 5.8.9-arch2-1 - though compounding it is that suspending fails and it instantly tries to resume with a black screen. Can confirm that it was not present on 5.8.8-arch1-1 before it (that ran with many suspend/resume cycles for a week). Prime B350M-A R7 1700 Fury X (Fiji) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #66 from waltib...@protonmail.com --- Created attachment 292637 --> https://bugzilla.kernel.org/attachment.cgi?id=292637&action=edit dmesg 5.8.9-arch2-1 truncated dmesg logs of resume failures on 5.8.9-arch2-1 3 boot/suspend/resume/fail cycles occurred -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
Am 25.09.20 um 01:14 schrieb Dave Airlie: On Thu, 24 Sep 2020 at 22:42, Christian König wrote: Am 24.09.20 um 07:18 schrieb Dave Airlie: From: Dave Airlie All the accel moves do the same pattern here, provide a helper And exactly that pattern I want to get away from. Currently this is just refactoring out the helper code in each driver, but I see since it calls bo_mem_space we are probably moving a bit in the wrong direction. Exactly that's why I'm noting this. See what happens if we (for example) have a VRAM -> SYSTEM move is the following: 1. TTM allocates a new ttm_resource object in the SYSTEM domain. 2. We call the driver to move from VRAM to SYSTEM. 3. Driver finds that it can't do this and calls TTM to allocate GTT. 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to SYSTEM and call driver again. This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we should stop that immediately. My suggestion is that we rewrite how drivers call the ttm_bo_validate() function so that we can guarantee that this never happens. What do you think? I think that is likely the next step I'd like to take after this refactor, it's a lot bigger, and I'm not sure how it will look yet. Agree, yes. I have some ideas in mind for that, but not fully baked either. Do we envision the driver calling validate in a loop but when it can't find space it tells the driver and the driver does eviction and recalls validate? Not in a loop, but more like in a chain. My plan is something like this: Instead of having "normal" and "busy" placement we have a flag in the context if evictions are allowed or not. The call to ttm_bo_validate are then replaced with two calls, first without evictions and if that didn't worked one with evictions. Then the normal validate sequence should look like this: 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first with evictions=true. 2. If a BO should be in VRAM we then validate it to VRAM. If evictions are only allowed if the GEM flags say that GTT is not desired. For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special domains that will obviously look a bit different. Christian. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: add legacy support for using degamma for gamma
On Wed, 23 Sep 2020 14:57:23 +0300
Tomi Valkeinen wrote:
> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> be used to handle legacy gamma-set ioctl.
> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> CTM and DEGAMMA_LUT. This works fine on HW where we have either:
>
> degamma -> ctm -> gamma -> out
>
> or
>
> ctm -> gamma -> out
>
> However, if the HW has gamma table before ctm, the atomic property
> should be DEGAMMA_LUT, and thus we have:
>
> degamma -> ctm -> out
>
> This is fine for userspace which sets gamma table using the properties,
> as the userspace can check for the existence of gamma & degamma, but the
> legacy gamma-set ioctl does not work.
>
> This patch adds a new helper, drm_atomic_helper_legacy_degamma_set(),
> which can be used instead of drm_atomic_helper_legacy_gamma_set() when
> the DEGAMMA_LUT is the underlying property that needs to be set.
>
This sounds and looks right to me fwiw, so
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 81 ++---
> include/drm/drm_atomic_helper.h | 4 ++
> 2 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9e1ad493e689..5ba359114df6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3469,24 +3469,11 @@ int drm_atomic_helper_page_flip_target(struct
> drm_crtc *crtc,
> }
> EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
>
> -/**
> - * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction table
> - * @crtc: CRTC object
> - * @red: red correction table
> - * @green: green correction table
> - * @blue: green correction table
> - * @size: size of the tables
> - * @ctx: lock acquire context
> - *
> - * Implements support for legacy gamma correction table for drivers
> - * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> - * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
> for
> - * how the atomic color management and gamma tables work.
> - */
> -int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> -u16 *red, u16 *green, u16 *blue,
> -uint32_t size,
> -struct drm_modeset_acquire_ctx *ctx)
> +static int legacy_gamma_degamma_set(struct drm_crtc *crtc,
> + u16 *red, u16 *green, u16 *blue,
> + uint32_t size,
> + struct drm_modeset_acquire_ctx *ctx,
> + bool use_degamma)
> {
> struct drm_device *dev = crtc->dev;
> struct drm_atomic_state *state;
> @@ -3525,9 +3512,11 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> }
>
> /* Reset DEGAMMA_LUT and CTM properties. */
> - replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> + replaced = drm_property_replace_blob(&crtc_state->degamma_lut,
> + use_degamma ? blob : NULL);
> replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> - replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> + replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
> + use_degamma ? NULL : blob);
> crtc_state->color_mgmt_changed |= replaced;
>
> ret = drm_atomic_commit(state);
> @@ -3537,8 +3526,60 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> drm_property_blob_put(blob);
> return ret;
> }
> +
> +/**
> + * drm_atomic_helper_legacy_gamma_set - set the legacy gamma correction
> table using gamma_lut
> + * @crtc: CRTC object
> + * @red: red correction table
> + * @green: green correction table
> + * @blue: green correction table
> + * @size: size of the tables
> + * @ctx: lock acquire context
> + *
> + * Implements support for legacy gamma correction table for drivers
> + * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> + * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
> for
> + * how the atomic color management and gamma tables work.
> + *
> + * This function uses GAMMA_LUT property for the gamma table. This function
> + * can be used when the driver exposes either only GAMMA_LUT or both
> GAMMA_LUT
> + * and DEGAMMA_LUT.
> + */
> +int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> +u16 *red, u16 *green, u16 *blue,
> +uint32_t size,
> +struct drm_modeset_acquire_ctx *ctx)
> +{
> + return legacy_gamma_degamma_set(crtc, red, green, blue, size, ctx,
> false);
> +}
> EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
>
> +/**
> + * drm_atomic_helpe
Re: [PATCH 2/5] drm/omap: use degamma property for gamma table
On Wed, 23 Sep 2020 14:57:24 +0300
Tomi Valkeinen wrote:
> omapdrm supports gamma via GAMMA_LUT property. However, the HW we have
> is:
>
> gamma -> ctm -> out
>
> instead of what the model DRM framework uses:
>
> ctm -> gamma -> out
>
> As the following patches add CTM support for omapdrm, lets first fix the
> gamma.
>
> This patch changes the property from GAMMA_LUT to DEGAMMA_LUT, and uses
> drm_atomic_helper_legacy_degamma_set for gamma_set helper. Thus we will
> have:
>
> degamma -> ctm -> out
>
> and the legacy ioctl will continue working as before.
>
Makes sense to me:
Reviewed-by: Pekka Paalanen
Thanks,
pq
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 328a4a74f534..6116af920660 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -573,8 +573,8 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
> {
> struct drm_plane_state *pri_state;
>
> - if (state->color_mgmt_changed && state->gamma_lut) {
> - unsigned int length = state->gamma_lut->length /
> + if (state->color_mgmt_changed && state->degamma_lut) {
> + unsigned int length = state->degamma_lut->length /
> sizeof(struct drm_color_lut);
>
> if (length < 2)
> @@ -614,10 +614,10 @@ static void omap_crtc_atomic_flush(struct drm_crtc
> *crtc,
> struct drm_color_lut *lut = NULL;
> unsigned int length = 0;
>
> - if (crtc->state->gamma_lut) {
> + if (crtc->state->degamma_lut) {
> lut = (struct drm_color_lut *)
> - crtc->state->gamma_lut->data;
> - length = crtc->state->gamma_lut->length /
> + crtc->state->degamma_lut->data;
> + length = crtc->state->degamma_lut->length /
> sizeof(*lut);
> }
> priv->dispc_ops->mgr_set_gamma(priv->dispc, omap_crtc->channel,
> @@ -738,7 +738,7 @@ static const struct drm_crtc_funcs omap_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .destroy = omap_crtc_destroy,
> .page_flip = drm_atomic_helper_page_flip,
> - .gamma_set = drm_atomic_helper_legacy_gamma_set,
> + .gamma_set = drm_atomic_helper_legacy_degamma_set,
> .atomic_duplicate_state = omap_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> .atomic_set_property = omap_crtc_atomic_set_property,
> @@ -839,7 +839,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
> unsigned int gamma_lut_size = 256;
>
> - drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
> + drm_crtc_enable_color_mgmt(crtc, gamma_lut_size, false, 0);
> drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
> }
>
pgpE0fZzuj0Tf.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 9:39 AM Christian König wrote: > > Am 25.09.20 um 01:14 schrieb Dave Airlie: > > On Thu, 24 Sep 2020 at 22:42, Christian König > > wrote: > >> Am 24.09.20 um 07:18 schrieb Dave Airlie: > >>> From: Dave Airlie > >>> > >>> All the accel moves do the same pattern here, provide a helper > >> And exactly that pattern I want to get away from. > > Currently this is just refactoring out the helper code in each driver, but > > I see > > since it calls bo_mem_space we are probably moving a bit in the wrong > > direction. > > Exactly that's why I'm noting this. > > > > >> See what happens if we (for example) have a VRAM -> SYSTEM move is the > >> following: > >> > >> 1. TTM allocates a new ttm_resource object in the SYSTEM domain. > >> 2. We call the driver to move from VRAM to SYSTEM. > >> 3. Driver finds that it can't do this and calls TTM to allocate GTT. > >> 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to > >> SYSTEM and call driver again. > >> > >> This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we > >> should stop that immediately. > >> > >> My suggestion is that we rewrite how drivers call the ttm_bo_validate() > >> function so that we can guarantee that this never happens. > >> > >> What do you think? > > I think that is likely the next step I'd like to take after this > > refactor, it's a lot bigger, and I'm not sure how it will look yet. > > Agree, yes. I have some ideas in mind for that, but not fully baked either. > > > Do we envision the driver calling validate in a loop but when it can't > > find space it tells the driver and the driver does eviction and > > recalls validate? > > Not in a loop, but more like in a chain. > > My plan is something like this: > Instead of having "normal" and "busy" placement we have a flag in the > context if evictions are allowed or not. > The call to ttm_bo_validate are then replaced with two calls, first > without evictions and if that didn't worked one with evictions. > > Then the normal validate sequence should look like this: > 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first > with evictions=true. > 2. If a BO should be in VRAM we then validate it to VRAM. If evictions > are only allowed if the GEM flags say that GTT is not desired. That solves the trouble when you move a bo into vram as part of validate. But I'm not seeing how this solves the "need gtt mapping to move something out of vram" problem. Or should we instead move the entire eviction logic out from ttm into drivers, building it up from helpers? Then drivers which need gtt for moving stuff out of vram can do that right away. Also, this would allow us to implement very fancy eviction algorithms like all the nonsense we're doing in i915 for gtt handling on gen2/3 (but I really hope that never ever becomes a thing again in future gpus, so this is maybe more a what-if kind of thing). Not sure how that would look like, maybe a special validate function which takes a ttm_resource the driver already found (through evicting stuff or whatever) and then ttm just does the move and book-keeping and everything. And drivers would at first only call validate without allowing any eviction. Ofc anyone without special needs could use the standard eviction function that validate already has. -Daniel > For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special > domains that will obviously look a bit different. > > Christian. > > > > > Dave. > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote: > > On Fri, Sep 25, 2020 at 9:39 AM Christian König > wrote: > > > > Am 25.09.20 um 01:14 schrieb Dave Airlie: > > > On Thu, 24 Sep 2020 at 22:42, Christian König > > > wrote: > > >> Am 24.09.20 um 07:18 schrieb Dave Airlie: > > >>> From: Dave Airlie > > >>> > > >>> All the accel moves do the same pattern here, provide a helper > > >> And exactly that pattern I want to get away from. > > > Currently this is just refactoring out the helper code in each driver, > > > but I see > > > since it calls bo_mem_space we are probably moving a bit in the wrong > > > direction. > > > > Exactly that's why I'm noting this. > > > > > > > >> See what happens if we (for example) have a VRAM -> SYSTEM move is the > > >> following: > > >> > > >> 1. TTM allocates a new ttm_resource object in the SYSTEM domain. > > >> 2. We call the driver to move from VRAM to SYSTEM. > > >> 3. Driver finds that it can't do this and calls TTM to allocate GTT. > > >> 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to > > >> SYSTEM and call driver again. > > >> > > >> This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we > > >> should stop that immediately. > > >> > > >> My suggestion is that we rewrite how drivers call the ttm_bo_validate() > > >> function so that we can guarantee that this never happens. > > >> > > >> What do you think? > > > I think that is likely the next step I'd like to take after this > > > refactor, it's a lot bigger, and I'm not sure how it will look yet. > > > > Agree, yes. I have some ideas in mind for that, but not fully baked either. > > > > > Do we envision the driver calling validate in a loop but when it can't > > > find space it tells the driver and the driver does eviction and > > > recalls validate? > > > > Not in a loop, but more like in a chain. > > > > My plan is something like this: > > Instead of having "normal" and "busy" placement we have a flag in the > > context if evictions are allowed or not. > > The call to ttm_bo_validate are then replaced with two calls, first > > without evictions and if that didn't worked one with evictions. > > > > Then the normal validate sequence should look like this: > > 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first > > with evictions=true. > > 2. If a BO should be in VRAM we then validate it to VRAM. If evictions > > are only allowed if the GEM flags say that GTT is not desired. > > That solves the trouble when you move a bo into vram as part of > validate. But I'm not seeing how this solves the "need gtt mapping to > move something out of vram" problem. > > Or should we instead move the entire eviction logic out from ttm into > drivers, building it up from helpers? Then drivers which need gtt for > moving stuff out of vram can do that right away. Also, this would > allow us to implement very fancy eviction algorithms like all the > nonsense we're doing in i915 for gtt handling on gen2/3 (but I really > hope that never ever becomes a thing again in future gpus, so this is > maybe more a what-if kind of thing). Not sure how that would look > like, maybe a special validate function which takes a ttm_resource the > driver already found (through evicting stuff or whatever) and then ttm > just does the move and book-keeping and everything. And drivers would > at first only call validate without allowing any eviction. Ofc anyone > without special needs could use the standard eviction function that > validate already has. Spinning this a bit more, we could have different default eviction functions with this, e.g. so all the drivers that need gtt mapping for moving stuff around can share that code, but with specific&flat control flow instead of lots of ping-ping. And drivers that don't need gtt mapping (like i915, we just need dma_map_sg which we assume works always, or something from the ttm dma page pool, which really always works) can then use something simpler that's completely flat. -Daniel > > > For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special > > domains that will obviously look a bit different. > > > > Christian. > > > > > > > > Dave. > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- 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 0/3] drm: commit_work scheduling
On Thu, Sep 24, 2020 at 05:15:00PM +0100, Qais Yousef wrote: > On 09/24/20 10:49, Daniel Vetter wrote: > > [...] > > > > > I also thought kernel threads can be distinguished from others, so > > > > userspace shouldn't be able to sneak in and get elevated by accident. > > > > > > I guess maybe you could look at the parent? I still would like to > > > think that we could come up with something a bit less shaking than > > > matching thread names by regexp.. > > > > ps marks up kernel threads with [], so there is a way. But I haven't > > looked at what it is exactly that tells kernel threads apart from others. > > > > But aside from that sounds like "match right kernel thread with regex and > > set its scheduler class" is how this is currently done, if I'm > > understanding what Tejun and Peter said correctly. > > > > Not pretty, but also *shrug* ... > > Isn't there a real danger that a sneaky application names its threads to match > this regex and get a free promotion to RT without having the capability to do > so? A sneaky application can't fake being a kernel thread, at least that's what I thought. You need to check for that _and_ that the name matches. -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/atomic: document and enforce rules around "spurious" EBUSY
On Wed, 23 Sep 2020 17:18:52 +0200
Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
> ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
> of the additional commit inserted by the kernel without userspace's
> knowledge
>
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
>
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. Since this
> has been shipping for years already compositors need to deal no matter
> what, so as a first step just try to enforce this across drivers
> better with some checks.
>
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
>
> v3: Fix inverted WARN_ON (Pekka).
>
> v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> rules for drivers.
>
> v5: Make the WARNING more informative (Daniel)
>
> v6: Add unconditional debug output for compositor hackers to figure
> out what's going on when they get an EBUSY (Daniel)
... gmail workaround ...
> ---
> drivers/gpu/drm/drm_atomic.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58527f151984..f1a912e80846 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> * needed. It will also grab the relevant CRTC lock to make sure that the
> state
> * is consistent.
> *
> + * WARNING: Drivers may only add new CRTC states to a @state if
> + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
> + * not created by userspace through an IOCTL call.
> + *
> * Returns:
> *
> * Either the allocated state or the error code encoded into the pointer.
> When
> @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> struct drm_crtc_state *new_crtc_state;
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> + unsigned requested_crtc = 0;
> + unsigned affected_crtc = 0;
> int i, ret = 0;
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + requested_crtc |= drm_crtc_mask(crtc);
Is "old crtc state" the state that userspace is requesting as the new
state?
> +
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> if (ret) {
> @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
> }
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
And after driver check processing, the "old crtc state" has been
modified by the driver to add anything it will necessarily need like
other CRTCs?
What is "new state" then?
> +
> + /*
> + * For commits that allow modesets drivers can add other CRTCs to the
> + * atomic commit, e.g. when they need to reallocate global resources.
> + * This can cause spurious EBUSY, which robs compositors of a very
> + * effective sanity check for their drawing loop. Therefor only allow
> + * drivers to add unrelated CRTC states for modeset commits.
> + *
> + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> + * so compositors know what's going on.
> + */
> + if (affected_crtc != requested_crtc) {
> + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
> affected 0x%0x\n",
> + requested_crtc, affected_crtc);
> + WARN(!state->allow_modeset, "adding CRTC not allowed without
> modesets: requested 0x%x, affected 0x%0x\n",
> + requested_crtc, affected_crtc);
> + }
This hunk looks good to me.
Thanks,
pq
> +
> return 0;
> }
> EXPORT_SYMBOL(drm_atomic_check_only);
pgpUxN89mxQgH.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: debug output for EBUSY
On Wed, 23 Sep 2020 12:57:37 +0200
Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
>
These debug messages will be especially useful with the flight
recorder, but also without. :-)
...
> ---
> drivers/gpu/drm/drm_atomic.c| 4 ++--
> drivers/gpu/drm/drm_atomic_helper.c | 20 +---
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index e22669b64521..6864e520269d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1272,7 +1272,7 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> - for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> requested_crtc |= drm_crtc_mask(crtc);
>
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> @@ -1322,7 +1322,7 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
> }
>
> - for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> affected_crtc |= drm_crtc_mask(crtc);
Oops, these belong in the previous patch?
>
> /*
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e8ab7fd1..6b3bfabac26c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device
> *dev,
>* overridden by a previous synchronous update's state.
>*/
> if (old_plane_state->commit &&
> - !try_wait_for_completion(&old_plane_state->commit->hw_done))
> + !try_wait_for_completion(&old_plane_state->commit->hw_done)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
> preventing async commit\n",
> + plane->base.id, plane->name);
> return -EBUSY;
> + }
>
> return funcs->atomic_async_check(plane, new_plane_state);
> }
> @@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool
> nonblock)
>* commit with nonblocking ones. */
> if (!completed && nonblock) {
> spin_unlock(&crtc->commit_lock);
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
> previous commit\n",
> + crtc->base.id, crtc->name);
> +
> return -EBUSY;
> }
> } else if (i == 1) {
> @@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct
> drm_atomic_state *state,
> /* Userspace is not allowed to get ahead of the previous
>* commit with nonblocking ones. */
> if (nonblock && old_conn_state->commit &&
> -
> !try_wait_for_completion(&old_conn_state->commit->flip_done))
> +
> !try_wait_for_completion(&old_conn_state->commit->flip_done)) {
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
> previous commit\n",
> + conn->base.id, conn->name);
> +
> return -EBUSY;
> + }
>
> /* Always track connectors explicitly for e.g. link retraining.
> */
> commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
> old_conn_state->crtc);
> @@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct
> drm_atomic_state *state,
> /* Userspace is not allowed to get ahead of the previous
>* commit with nonblocking ones. */
> if (nonblock && old_plane_state->commit &&
> -
> !try_wait_for_completion(&old_plane_state->commit->flip_done))
> +
> !try_wait_for_completion(&old_plane_state->commit->flip_done)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
> commit\n",
> + plane->base.id, plane->name);
> +
> return -EBUSY;
> + }
>
> /* Always track planes explicitly for async pageflip support. */
> commit = crtc_or_fake_commit(state, new_plane_state->crtc ?:
> old_plane_state->crtc);
The new debug messages sound good to me.
Thanks,
pq
pgpU8O3LAlXxk.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Thu, Sep 24, 2020 at 04:09:37PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Hi all,
> >
> > syzbot has reported [1] a global out-of-bounds read issue in
> > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
> > font data buffers, declared in lib/fonts/font_*.c:
> >
> > (e.g. lib/fonts/font_8x8.c)
> > #define FONTDATAMAX 2048
> >
> > static const unsigned char fontdata_8x8[FONTDATAMAX] = {
> >
> > /* 0 0x00 '^@' */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > 0x00, /* */
> > [...]
> >
> > In order to perform a reliable range check, fbcon_get_font() needs to know
> > `FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
> > do not keep that information in our font descriptor,
> > `struct console_font`:
> >
> > (include/uapi/linux/kd.h)
> > struct console_font {
> > unsigned int width, height; /* font size */
> > unsigned int charcount;
> > unsigned char *data;/* font data with height fixed to 32 */
> > };
> >
> > To make things worse, `struct console_font` is part of the UAPI, so we
> > cannot add a new field to keep track of `FONTDATAMAX`.
> >
> > Fortunately, the framebuffer layer itself gives us a hint of how to
> > resolve this issue without changing UAPI. When allocating a buffer for a
> > user-provided font, fbcon_set_font() reserves four "extra words" at the
> > beginning of the buffer:
> >
> > (drivers/video/fbdev/core/fbcon.c)
> > new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
> > [...]
> > new_data += FONT_EXTRA_WORDS * sizeof(int);
> > FNTSIZE(new_data) = size;
> > FNTCHARCNT(new_data) = charcount;
> > REFCOUNT(new_data) = 0; /* usage counter */
> > [...]
> > FNTSUM(new_data) = csum;
> >
> > Later, to get the size of a data buffer, the framebuffer layer simply
> > calls FNTSIZE() on it:
> >
> > (drivers/video/fbdev/core/fbcon.h)
> > /* Font */
> > #define REFCOUNT(fd)(((int *)(fd))[-1])
> > #define FNTSIZE(fd) (((int *)(fd))[-2])
> > #define FNTCHARCNT(fd) (((int *)(fd))[-3])
> > #define FNTSUM(fd) (((int *)(fd))[-4])
> > #define FONT_EXTRA_WORDS 4
> >
> > Currently, this is only done for user-provided fonts. Let us do the same
> > thing for built-in fonts, prepend these "extra words" (including
> > `FONTDATAMAX`) to their data buffers, so that other subsystems, like the
> > framebuffer layer, can use these macros on all fonts, no matter built-in
> > or user-provided. As an example, this series fixes the syzbot issue in
> > fbcon_get_font():
> >
> > (drivers/video/fbdev/core/fbcon.c)
> > if (font->width <= 8) {
> > j = vc->vc_font.height;
> > + if (font->charcount * j > FNTSIZE(fontdata))
> > + return -EINVAL;
> > [...]
> >
> > Similarly, newport_con also use these macros. It only uses three of them:
> >
> > (drivers/video/console/newport_con.c)
> > /* borrowed from fbcon.c */
> > #define REFCOUNT(fd)(((int *)(fd))[-1])
> > #define FNTSIZE(fd) (((int *)(fd))[-2])
> > #define FNTCHARCNT(fd) (((int *)(fd))[-3])
> > #define FONT_EXTRA_WORDS 3
> >
> > To keep things simple, move all these macro definitions to ,
> > use four words instead of three, and initialize the fourth word in
> > newport_set_font() properly.
> >
> > Many thanks to Greg Kroah-Hartman , who
> > reviewed and improved this series!
> >
> > [1]: KASAN: global-out-of-bounds Read in fbcon_get_font
> >
> > https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfd
> >
> > Peilin Ye (3):
> > fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h
> > Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
> > fbcon: Fix global-out-of-bounds read in fbcon_get_font()
> >
> > drivers/video/console/newport_con.c | 7 +--
> > drivers/video/fbdev/core/fbcon.c| 12
> > drivers/video/fbdev/core/fbcon.h| 7 ---
> > drivers/video/fbdev/core/fbcon_rotate.c | 1 +
> > drivers/video/fbdev/core/tileblit.c | 1 +
> > include/linux/font.h| 13 +
> > lib/fonts/font_10x18.c | 9 -
> > lib/fonts/font_6x10.c | 9 +
> > lib/fonts/font_6x11.c | 9 -
> > lib/fonts/font_7x14.c | 9 -
> > lib/fonts/font_8x16.c | 9 -
> > lib/fonts/font_8x8.c| 9 -
> > lib/fonts/font_acorn_8x8.c | 9 ++---
> > lib/fonts/font_mini_4x6.c | 8
> > lib/fonts
Re: [PATCH v3 00/22] Convert all remaining drivers to GEM object functions
Hi Am 23.09.20 um 16:33 schrieb Christian König: > Feel free to add an Acked-by: Christian König > to all patches which I haven't explicitly reviewed. Done, thanks. > > I would say we should just push this to drm-misc-next now. It's merged now. Best regards Thomas > > Thanks for the nice cleanup, > Christian. > > Am 23.09.20 um 12:21 schrieb Thomas Zimmermann: >> The GEM and PRIME related callbacks in struct drm_driver are >> deprecated in >> favor of GEM object functions in struct drm_gem_object_funcs. This >> patchset >> converts the remaining drivers to object functions and removes most of >> the >> obsolete interfaces. >> >> Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and >> updates i.MX's dcss driver. The driver was missing from earlier versions >> and still needs review. >> >> Patches #1 to #6, #8 to #17 and #19 to #20 convert DRM drivers to GEM >> object >> functions, one by one. Each patch moves existing callbacks from struct >> drm_driver to an instance of struct drm_gem_object_funcs, and sets these >> funcs when the GEM object is initialized. The expection is >> .gem_prime_mmap. >> There are different ways of how drivers implement the callback, and >> moving >> it to GEM object functions requires a closer review for each. >> >> Patch #18 fixes virtgpu to use GEM object functions where possible. The >> driver recently introduced a function for one of the deprecated >> callbacks. >> >> Patches #7 and #20 convert i.MX's dcss and xlnx to CMA helper macros. >> There's >> no apparent reason why the drivers do the GEM setup on their's own. >> Using CMA >> helper macros adds GEM object functions implicitly. >> >> With most of the GEM and PRIME moved to GEM object functions, related >> code >> in struct drm_driver and in the DRM core/helpers is being removed by >> patch >> #22. >> >> Further testing is welcome. I tested the drivers for which I have HW >> available. These are gma500, i915, nouveau, radeon and vc4. The console, >> Weston and Xorg apparently work with the patches applied. >> >> v3: >> * restore default call to drm_gem_prime_export() in >> drm_gem_prime_handle_to_fd() >> * return -ENOSYS if get_sg_table is not set >> * drop all checks for obj->funcs >> * clean up TODO list and documentation >> v2: >> * moved code in amdgpu and radeon >> * made several functions static in various drivers >> * updated TODO-list item >> * fix virtgpu >> >> Thomas Zimmermann (22): >> drm/amdgpu: Introduce GEM object functions >> drm/armada: Introduce GEM object functions >> drm/etnaviv: Introduce GEM object functions >> drm/exynos: Introduce GEM object functions >> drm/gma500: Introduce GEM object functions >> drm/i915: Introduce GEM object functions >> drm/imx/dcss: Initialize DRM driver instance with CMA helper macro >> drm/mediatek: Introduce GEM object functions >> drm/msm: Introduce GEM object funcs >> drm/nouveau: Introduce GEM object functions >> drm/omapdrm: Introduce GEM object functions >> drm/pl111: Introduce GEM object functions >> drm/radeon: Introduce GEM object functions >> drm/rockchip: Convert to drm_gem_object_funcs >> drm/tegra: Introduce GEM object functions >> drm/vc4: Introduce GEM object functions >> drm/vgem: Introduce GEM object functions >> drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs >> drm/vkms: Introduce GEM object functions >> drm/xen: Introduce GEM object functions >> drm/xlnx: Initialize DRM driver instance with CMA helper macro >> drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver >> >> Documentation/gpu/drm-mm.rst | 4 +- >> Documentation/gpu/todo.rst | 9 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 -- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 23 +++-- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 5 -- >> drivers/gpu/drm/armada/armada_drv.c | 3 - >> drivers/gpu/drm/armada/armada_gem.c | 12 ++- >> drivers/gpu/drm/armada/armada_gem.h | 2 - >> drivers/gpu/drm/drm_gem.c | 53 >> drivers/gpu/drm/drm_gem_cma_helper.c | 8 +- >> drivers/gpu/drm/drm_prime.c | 14 +-- >> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 --- >> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - >> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 - >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --- >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 15 >> drivers/gpu/drm/gma500/framebuffer.c | 2 + >> drivers/gpu/drm/gma500/gem.c | 18 +++- >> drivers/gpu/drm/gma500/gem.h | 3 + >> drivers/gpu/drm/gma500/psb_drv.c | 9 -- >> drivers/gpu/drm/gma500/psb_drv.h | 2 - >> drivers/gpu/drm/i915/gem/i915_gem_object.c | 21 - >> drivers/gpu/drm/i915/ge
Re: [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Fri, Sep 25, 2020 at 11:24:46AM +0300, Pekka Paalanen wrote:
> On Wed, 23 Sep 2020 17:18:52 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> > ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > of the additional commit inserted by the kernel without userspace's
> > knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. Since this
> > has been shipping for years already compositors need to deal no matter
> > what, so as a first step just try to enforce this across drivers
> > better with some checks.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> > rules for drivers.
> >
> > v5: Make the WARNING more informative (Daniel)
> >
> > v6: Add unconditional debug output for compositor hackers to figure
> > out what's going on when they get an EBUSY (Daniel)
>
> ... gmail workaround ...
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 29 +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58527f151984..f1a912e80846 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> > * needed. It will also grab the relevant CRTC lock to make sure that the
> > state
> > * is consistent.
> > *
> > + * WARNING: Drivers may only add new CRTC states to a @state if
> > + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal
> > commit
> > + * not created by userspace through an IOCTL call.
> > + *
> > * Returns:
> > *
> > * Either the allocated state or the error code encoded into the pointer.
> > When
> > @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > struct drm_crtc_state *new_crtc_state;
> > struct drm_connector *conn;
> > struct drm_connector_state *conn_state;
> > + unsigned requested_crtc = 0;
> > + unsigned affected_crtc = 0;
> > int i, ret = 0;
> >
> > DRM_DEBUG_ATOMIC("checking %p\n", state);
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + requested_crtc |= drm_crtc_mask(crtc);
>
> Is "old crtc state" the state that userspace is requesting as the new
> state?
It's a dummy iterator variable we don't care about, all we really want is
to know which crtc are all part of the update. But everyone else also
wants the state.
I'll shuffle the patches so the hunk Ville requested is in the right
patch.
-Daniel
>
> > +
> > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > new_plane_state, i) {
> > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > if (ret) {
> > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > }
> > }
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + affected_crtc |= drm_crtc_mask(crtc);
>
> And after driver check processing, the "old crtc state" has been
> modified by the driver to add anything it will necessarily need like
> other CRTCs?
>
> What is "new state" then?
>
> > +
> > + /*
> > +* For commits that allow modesets drivers can add other CRTCs to the
> > +* atomic commit, e.g. when they need to reallocate global resources.
> > +* This can cause spurious EBUSY, which robs compositors of a very
> > +* effective sanity check for their drawing loop. Therefor only allow
> > +* drivers to add unrelated CRTC states for modeset commits.
> > +*
> > +* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> > +* so compositors know what's going on.
> > +*/
> > + if (affected_crtc != requested_crtc) {
> > + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
> > affected 0x%0x\n",
> > +requested_crtc, affected_crtc);
> > + WARN(!state->allow_modeset, "adding CRTC not allowed without
>
[PATCH 2/2] drm/atomic: debug output for EBUSY
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
v2: Move misplaced hunk to the right patch (Pekka)
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index e8ab7fd1..6b3bfabac26c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
* overridden by a previous synchronous update's state.
*/
if (old_plane_state->commit &&
- !try_wait_for_completion(&old_plane_state->commit->hw_done))
+ !try_wait_for_completion(&old_plane_state->commit->hw_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
preventing async commit\n",
+ plane->base.id, plane->name);
return -EBUSY;
+ }
return funcs->atomic_async_check(plane, new_plane_state);
}
@@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
* commit with nonblocking ones. */
if (!completed && nonblock) {
spin_unlock(&crtc->commit_lock);
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
previous commit\n",
+ crtc->base.id, crtc->name);
+
return -EBUSY;
}
} else if (i == 1) {
@@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_conn_state->commit &&
-
!try_wait_for_completion(&old_conn_state->commit->flip_done))
+
!try_wait_for_completion(&old_conn_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
previous commit\n",
+ conn->base.id, conn->name);
+
return -EBUSY;
+ }
/* Always track connectors explicitly for e.g. link retraining.
*/
commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc);
@@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_plane_state->commit &&
-
!try_wait_for_completion(&old_plane_state->commit->flip_done))
+
!try_wait_for_completion(&old_plane_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
commit\n",
+ plane->base.id, plane->name);
+
return -EBUSY;
+ }
/* Always track planes explicitly for async pageflip support. */
commit = crtc_or_fake_commit(state, new_plane_state->crtc ?:
old_plane_state->crtc);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.
v5: Make the WARNING more informative (Daniel)
v6: Add unconditional debug output for compositor hackers to figure
out what's going on when they get an EBUSY (Daniel)
v7: Fix up old/new_crtc_state confusion for real (Pekka/Ville)
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..aac9122f1da2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
* needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
+ * WARNING: Drivers may only add new CRTC states to a @state if
+ * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
+ * not created by userspace through an IOCTL call.
+ *
* Returns:
*
* Either the allocated state or the error code encoded into the pointer. When
@@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
*state)
struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
+ unsigned requested_crtc = 0;
+ unsigned affected_crtc = 0;
int i, ret = 0;
DRM_DEBUG_ATOMIC("checking %p\n", state);
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
+
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ /*
+* For commits that allow modesets drivers can add other CRTCs to the
+* atomic commit, e.g. when they need to reallocate global resources.
+* This can cause spurious EBUSY, which robs compositors of a very
+* effective sanity check for their drawing loop. Therefor only allow
+* drivers to add unrelated CRTC states for modeset commits.
+*
+* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
+* so compositors know what's going on.
+*/
+ if (affected_crtc != requested_crtc) {
+ DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ WARN(!state->allow_modeset, "adding CRTC not allowed without
modesets: requested 0x%x, affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/23] device-dax: Kill dax_kmem_res
On 24.09.20 23:50, Dan Williams wrote: > On Thu, Sep 24, 2020 at 2:42 PM David Hildenbrand wrote: >> >> >> >>> Am 24.09.2020 um 23:26 schrieb Dan Williams : >>> >>> [..] > I'm not suggesting to busy the whole "virtio" range, just the portion > that's about to be passed to add_memory_driver_managed(). I'm afraid I don't get your point. For virtio-mem: Before: 1. Create virtio0 container resource 2. (somewhen in the future) add_memory_driver_managed() - Create resource (System RAM (virtio_mem)), marking it busy/driver managed After: 1. Create virtio0 container resource 2. (somewhen in the future) Create resource (System RAM (virtio_mem)), marking it busy/driver managed 3. add_memory_driver_managed() Not helpful or simpler IMHO. >>> >>> The concern I'm trying to address is the theoretical race window and >>> layering violation in this sequence in the kmem driver: >>> >>> 1/ res = request_mem_region(...); >>> 2/ res->flags = IORESOURCE_MEM; >>> 3/ add_memory_driver_managed(); >>> >>> Between 2/ and 3/ something can race and think that it owns the >>> region. Do I think it will happen in practice, no, but it's still a >>> pattern that deserves come cleanup. >> >> I think in that unlikely event (rather impossible), >> add_memory_driver_managed() should fail, detecting a conflicting (busy) >> resource. Not sure what will happen next ( and did not double-check). > > add_memory_driver_managed() will fail, but the release_mem_region() in > kmem to unwind on the error path will do the wrong thing because that > other driver thinks it got ownership of the region. > I think if somebody would race and claim the region for itself (after we unchecked the BUSY flag), there would be another memory resource below our resource container (e.g., via __request_region()). So, interestingly, the current code will do a release_resource->__release_resource(old, true); which will remove whatever somebody added below the resource. If we were to do a remove_resource->__release_resource(old, false); we would only remove what we temporarily added, relocating anychildren (someone nasty added). But yeah, I don't think we have to worry about this case. >> But yeah, the way the BUSY bit is cleared here is wrong - simply overwriting >> other bits. And it would be even better if we could avoid manually messing >> with flags here. > > I'm ok to leave it alone for now (hasn't been and likely never will be > a problem in practice), but I think it was still worth grumbling Definitely, it gives us a better understanding. > about. I'll leave that part of kmem alone in the upcoming split of > dax_kmem_res removal. Yeah, stuff is more complicated than I would wished, so I guess it's better to leave it alone for now until we actually see issues with somebody else regarding *our* device-owned region (or we're able to come up with a cleanup that keeps all corner cases working for kmem and virtio-mem). -- Thanks, David / dhildenb ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Deleted the drm_device declaration
On Fri, Sep 25, 2020 at 04:51:38PM +0800, Tian Tao wrote: > drm_modeset_lock.h already declares struct drm_device, so there's no > need to declare it in vc4_drv.h > > Signed-off-by: Tian Tao Just an aside, when submitting patches please use scripts/get_maintainers.pl to generate the recipient list. Looking through past few patches from you it seems fairly arbitrary and often misses the actual maintainers for a given piece of code, which increases the odds the patch will get lost a lot. E.g. for this one I'm only like the 5th or so fallback person, and the main maintainer isn't on the recipient list. Cheeers, Daniel > --- > drivers/gpu/drm/vc4/vc4_drv.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h > index 8c8d96b..8717a1c 100644 > --- a/drivers/gpu/drm/vc4/vc4_drv.h > +++ b/drivers/gpu/drm/vc4/vc4_drv.h > @@ -19,7 +19,6 @@ > > #include "uapi/drm/vc4_drm.h" > > -struct drm_device; > struct drm_gem_object; > > /* Don't forget to update vc4_bo.c: bo_type_names[] when adding to > -- > 2.7.4 > -- 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 2/2] drm/atomic: debug output for EBUSY
On Fri, 25 Sep 2020 10:46:51 +0200 Daniel Vetter wrote: > Hopefully we'll have the drm crash recorder RSN, but meanwhile > compositors would like to know a bit better why they get an EBUSY. > > v2: Move misplaced hunk to the right patch (Pekka) Hi, both patches Acked-by: Pekka Paalanen Thanks, pq pgpZIDBA1GbbF.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
Am 25.09.20 um 10:18 schrieb Daniel Vetter: On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote: On Fri, Sep 25, 2020 at 9:39 AM Christian König wrote: Am 25.09.20 um 01:14 schrieb Dave Airlie: On Thu, 24 Sep 2020 at 22:42, Christian König wrote: Am 24.09.20 um 07:18 schrieb Dave Airlie: From: Dave Airlie All the accel moves do the same pattern here, provide a helper And exactly that pattern I want to get away from. Currently this is just refactoring out the helper code in each driver, but I see since it calls bo_mem_space we are probably moving a bit in the wrong direction. Exactly that's why I'm noting this. See what happens if we (for example) have a VRAM -> SYSTEM move is the following: 1. TTM allocates a new ttm_resource object in the SYSTEM domain. 2. We call the driver to move from VRAM to SYSTEM. 3. Driver finds that it can't do this and calls TTM to allocate GTT. 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to SYSTEM and call driver again. This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we should stop that immediately. My suggestion is that we rewrite how drivers call the ttm_bo_validate() function so that we can guarantee that this never happens. What do you think? I think that is likely the next step I'd like to take after this refactor, it's a lot bigger, and I'm not sure how it will look yet. Agree, yes. I have some ideas in mind for that, but not fully baked either. Do we envision the driver calling validate in a loop but when it can't find space it tells the driver and the driver does eviction and recalls validate? Not in a loop, but more like in a chain. My plan is something like this: Instead of having "normal" and "busy" placement we have a flag in the context if evictions are allowed or not. The call to ttm_bo_validate are then replaced with two calls, first without evictions and if that didn't worked one with evictions. Then the normal validate sequence should look like this: 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first with evictions=true. 2. If a BO should be in VRAM we then validate it to VRAM. If evictions are only allowed if the GEM flags say that GTT is not desired. That solves the trouble when you move a bo into vram as part of validate. But I'm not seeing how this solves the "need gtt mapping to move something out of vram" problem. Eviction is not a problem because the driver gets asked where to put an evicted BO and then TTM does all the moving. Or should we instead move the entire eviction logic out from ttm into drivers, building it up from helpers? I've been playing with that thought for a while as well, but then decided against it. The main problem I see is that we sometimes need to evict things from other drivers. E.g. when we overcommitted system memory and move things to swap for example. Then drivers which need gtt for moving stuff out of vram can do that right away. Also, this would allow us to implement very fancy eviction algorithms like all the nonsense we're doing in i915 for gtt handling on gen2/3 (but I really hope that never ever becomes a thing again in future gpus, so this is maybe more a what-if kind of thing). Not sure how that would look like, maybe a special validate function which takes a ttm_resource the driver already found (through evicting stuff or whatever) and then ttm just does the move and book-keeping and everything. And drivers would at first only call validate without allowing any eviction. Ofc anyone without special needs could use the standard eviction function that validate already has. Spinning this a bit more, we could have different default eviction functions with this, e.g. so all the drivers that need gtt mapping for moving stuff around can share that code, but with specific&flat control flow instead of lots of ping-ping. And drivers that don't need gtt mapping (like i915, we just need dma_map_sg which we assume works always, or something from the ttm dma page pool, which really always works) can then use something simpler that's completely flat. Ok you need to explain a bit more what exactly the problem with the GTT eviction is here :) Christian. -Daniel For special BOs, like amdgpus GDS, GWS and OA domain or VMWGFX special domains that will obviously look a bit different. Christian. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C66b5c2bfed8541cd986208d8612b8e1d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637366187002213152&sdata=OPdXMe2rG1Uy%2BZD%2BjYKHfkLc9xVAQ1AL23QbEu3drnE%3D&reserved=0 -- Daniel Vetter Software Engineer, Intel Corporation https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C66b5c2b
Re: [PATCH 3/4] drm/etnaviv: add total hi bandwidth perfcounter
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> These two perf counters represent the total read and write
> GPU bandwidth in terms of 64bits.
>
> The used sequence was taken from Vivante kernel driver.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 35 ++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> index 782732e6ce72..b37459f022d7 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> @@ -69,6 +69,29 @@ static u32 pipe_perf_reg_read(struct etnaviv_gpu *gpu,
> return value;
> }
>
> +static u32 pipe_reg_read(struct etnaviv_gpu *gpu,
> + const struct etnaviv_pm_domain *domain,
> + const struct etnaviv_pm_signal *signal)
> +{
> + u32 clock = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
> + u32 value = 0;
> + unsigned i;
> +
> + for (i = 0; i < gpu->identity.pixel_pipes; i++) {
> + clock &= ~(VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE__MASK);
> + clock |= VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE(i);
> + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock);
> + value += gpu_read(gpu, signal->data);
> + }
> +
> + /* switch back to pixel pipe 0 to prevent GPU hang */
> + clock &= ~(VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE__MASK);
> + clock |= VIVS_HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE(0);
> + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock);
> +
> + return value;
> +}
> +
> static u32 hi_total_cycle_read(struct etnaviv_gpu *gpu,
> const struct etnaviv_pm_domain *domain,
> const struct etnaviv_pm_signal *signal)
> @@ -102,8 +125,18 @@ static const struct etnaviv_pm_domain doms_3d[] = {
> .name = "HI",
> .profile_read = VIVS_MC_PROFILE_HI_READ,
> .profile_config = VIVS_MC_PROFILE_CONFIG2,
> - .nr_signals = 5,
> + .nr_signals = 7,
I've tripped across this part. It's something I don't particularly
like, as this value has a risk of getting inconsistent with the actual
array. Maybe we could split out signal array from this initialization,
so we could then use the ARRAY_SIZE macro to initialize this value?
But that's not really related to this patch and can be done in a
follow-up cleanup.
Regards,
Lucas
> .signal = (const struct etnaviv_pm_signal[]) {
> + {
> + "TOTAL_READ_BYTES8",
> + VIVS_HI_PROFILE_READ_BYTES8,
> + &pipe_reg_read,
> + },
> + {
> + "TOTAL_WRITE_BYTES8",
> + VIVS_HI_PROFILE_WRITE_BYTES8,
> + &pipe_reg_read,
> + },
> {
> "TOTAL_CYCLES",
> 0,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/etnaviv: add total hi bandwidth perf counters
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote: > This little patch set adds support for the total bandwidth used by HI. The > basic hi bandwidth read-out is quite simple but I needed to add some little > clean-ups to make it nice looking. > > Christian Gmeiner (4): > drm/etnaviv: rename pipe_reg_read(..) > drm/etnaviv: call perf_reg_read(..) > drm/etnaviv: add total hi bandwidth perfcounter > drm/etnaviv: add pipe_select(..) helper > > drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 78 --- > 1 file changed, 55 insertions(+), 23 deletions(-) Thanks, I've applied the whole series to my etnaviv/next branch. regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: Drop local dma_parms
On Do, 2020-09-03 at 21:40 +0100, Robin Murphy wrote:
> Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
> for platform devices"), struct platform_device already provides a
> dma_parms structure, so we can save allocating another one.
>
> Signed-off-by: Robin Murphy
Thanks, applied to etnaviv/next.
Regards,
Lucas
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
> 2 files changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index a9a3afaef9a1..79b3bcd9f444 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -535,7 +535,6 @@ static int etnaviv_bind(struct device *dev)
> }
> drm->dev_private = priv;
>
> - dev->dma_parms = &priv->dma_parms;
> dma_set_max_seg_size(dev, SZ_2G);
>
> mutex_init(&priv->gem_lock);
> @@ -585,8 +584,6 @@ static void etnaviv_unbind(struct device *dev)
>
> component_unbind_all(dev, drm);
>
> - dev->dma_parms = NULL;
> -
> etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
>
> drm->dev_private = NULL;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 4d8dc9236e5f..7db607817c0c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -33,7 +33,6 @@ struct etnaviv_file_private {
>
> struct etnaviv_drm_private {
> int num_gpus;
> - struct device_dma_parameters dma_parms;
> struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
> gfp_t shm_gfp_mask;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: dsi: Use dev_ based logging
Standardize on the dev_ based logging and drop the include of drm_print.h.
Remove useless dsi_color_from_mipi function.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 87 ++-
1 file changed, 45 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 164f79ef6269..93fa8bfd3127 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -76,6 +76,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
+ struct device *dev;
struct clk *pllref_clk;
struct dw_mipi_dsi *dsi;
u32 hw_version;
@@ -110,23 +111,6 @@ static inline void dsi_update_bits(struct dw_mipi_dsi_stm
*dsi, u32 reg,
dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
}
-static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
-{
- switch (fmt) {
- case MIPI_DSI_FMT_RGB888:
- return DSI_RGB888;
- case MIPI_DSI_FMT_RGB666:
- return DSI_RGB666_CONF2;
- case MIPI_DSI_FMT_RGB666_PACKED:
- return DSI_RGB666_CONF1;
- case MIPI_DSI_FMT_RGB565:
- return DSI_RGB565_CONF1;
- default:
- DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
- }
- return DSI_RGB888;
-}
-
static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int odf)
{
int divisor = idf * odf;
@@ -205,14 +189,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
/* Enable the DSI PLL & wait for its lock */
dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
SLEEP_US, TIMEOUT_US);
if (ret)
- DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
+ dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
return 0;
}
@@ -221,7 +205,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Enable the DSI wrapper */
dsi_set(dsi, DSI_WCR, WCR_DSIEN);
@@ -231,7 +215,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
{
struct dw_mipi_dsi_stm *dsi = priv_data;
- DRM_DEBUG_DRIVER("\n");
+ dev_dbg(dsi->dev, "\n");
/* Disable the DSI wrapper */
dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
@@ -244,6 +228,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
{
struct dw_mipi_dsi_stm *dsi = priv_data;
unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+ enum mipi_dsi_pixel_format fmt;
int ret, bpp;
u32 val;
@@ -267,11 +252,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
if (pll_out_khz > dsi->lane_max_kbps) {
pll_out_khz = dsi->lane_max_kbps;
- DRM_WARN("Warning max phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning max phy mbps is used\n");
}
if (pll_out_khz < dsi->lane_min_kbps) {
pll_out_khz = dsi->lane_min_kbps;
- DRM_WARN("Warning min phy mbps is used\n");
+ dev_warn(dsi->dev, "Warning min phy mbps is used\n");
}
/* Compute best pll parameters */
@@ -281,7 +266,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
&idf, &ndiv, &odf);
if (ret)
- DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+ dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
params\n");
/* Get the adjusted pll out value */
pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
@@ -297,14 +282,31 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
/* Select video mode by resetting DSIM bit */
dsi_clear(dsi, DSI_WCFGR, WCFGR_DSIM);
+ switch (format) {
+ case MIPI_DSI_FMT_RGB888:
+ fmt = DSI_RGB888;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ fmt = DSI_RGB666_CONF2;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ fmt = DSI_RGB666_CONF1;
+ break;
+ case MIPI_DSI_FMT_RGB565:
+ fmt = DSI_RGB565_CONF1;
+ break;
+ default:
+ fmt = DSI_RGB888;
+
Re: [PATCH 0/3] fbdev: stop using compat_alloc_user_space
On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote: > > Hi Daniel/Arnd. > > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote: > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote: > > > The fbdev code uses compat_alloc_user_space in a few of its > > > compat_ioctl handlers, which tends to be a bit more complicated > > > and error-prone than calling the underlying handlers directly, > > > so I would like to remove it completely. > > > > > > This modifies two such functions in fbdev, and removes another > > > one that is completely unused. > > > > > > Arnd > > > > > > Arnd Bergmann (3): > > > fbdev: simplify fb_getput_cmap() > > > fbdev: sbuslib: remove unused FBIOSCURSOR32 helper > > > fbdev: sbuslib: remove compat_alloc_user_space usage > > > > Looks all good, but we're also kinda looking for a new volunteer for > > handling fbdev patches ... drm-misc commit rights, still not interested? > > Hi Daniel - I read the above as an a-b. And Arnd did not take the bait > it seems. Ah right, I meant to reply but then forgot about it. I don't really want commit access, thanks for the offer. > Hi Arnd. checkpatch complained about some whitespace, which I fixed > while applying. > Will push to drm-misc-next tomorrow unless I hear anything else. Great, thanks! Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
Hi
Am 23.09.20 um 16:27 schrieb Christian König:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
>> The new type struct dma_buf_map represents a mapping of dma-buf memory
>> into kernel space. It contains a flag, is_iomem, that signals users to
>> access the mapped memory with I/O operations instead of regular loads
>> and stores.
>>
>> It was assumed that DMA buffer memory can be accessed with regular load
>> and store operations. Some architectures, such as sparc64, require the
>> use of I/O operations to access dma-map buffers that are located in I/O
>> memory. Providing struct dma_buf_map allows drivers to implement this.
>> This was specifically a problem when refreshing the graphics framebuffer
>> on such systems. [1]
>>
>> As the first step, struct dma_buf stores an instance of struct
>> dma_buf_map
>> internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
>> converted. Finally, affected drivers can be fixed.
>>
>> [1]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200725191012.GA434957%40ravnborg.org%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C54486b9682654f3950b808d85fbcb1d3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637364611338153209&sdata=%2BZm7t8OcgkIxnY%2FdZSLhSbKC7t1y4VW5lINFKwCQv3A%3D&reserved=0
>>
>
> Only two nit picks below, apart from that Reviewed-by: Christian König
>
>
>>
>> Signed-off-by: Thomas Zimmermann
>> Acked-by: Sumit Semwal
>> ---
>> Documentation/driver-api/dma-buf.rst | 3 +
>> drivers/dma-buf/dma-buf.c | 14 ++---
>> include/linux/dma-buf-map.h | 87
>> include/linux/dma-buf.h | 3 +-
>> 4 files changed, 99 insertions(+), 8 deletions(-)
>> create mode 100644 include/linux/dma-buf-map.h
>>
>> diff --git a/Documentation/driver-api/dma-buf.rst
>> b/Documentation/driver-api/dma-buf.rst
>> index 13ea0cc0a3fa..3244c600a9a1 100644
>> --- a/Documentation/driver-api/dma-buf.rst
>> +++ b/Documentation/driver-api/dma-buf.rst
>> @@ -115,6 +115,9 @@ Kernel Functions and Structures Reference
>> .. kernel-doc:: include/linux/dma-buf.h
>> :internal:
>> +.. kernel-doc:: include/linux/dma-buf-map.h
>> + :internal:
>> +
>> Reservation Objects
>> ---
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 58564d82a3a2..5e849ca241a0 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
>> mutex_lock(&dmabuf->lock);
>> if (dmabuf->vmapping_counter) {
>> dmabuf->vmapping_counter++;
>> - BUG_ON(!dmabuf->vmap_ptr);
>> - ptr = dmabuf->vmap_ptr;
>> + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> + ptr = dmabuf->vmap_ptr.vaddr;
>> goto out_unlock;
>> }
>> - BUG_ON(dmabuf->vmap_ptr);
>> + BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>> ptr = dmabuf->ops->vmap(dmabuf);
>> if (WARN_ON_ONCE(IS_ERR(ptr)))
>> @@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
>> if (!ptr)
>> goto out_unlock;
>> - dmabuf->vmap_ptr = ptr;
>> + dmabuf->vmap_ptr.vaddr = ptr;
>> dmabuf->vmapping_counter = 1;
>> out_unlock:
>> @@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>> void *vaddr)
>> if (WARN_ON(!dmabuf))
>> return;
>> - BUG_ON(!dmabuf->vmap_ptr);
>> + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>> BUG_ON(dmabuf->vmapping_counter == 0);
>> - BUG_ON(dmabuf->vmap_ptr != vaddr);
>> + BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
>> mutex_lock(&dmabuf->lock);
>> if (--dmabuf->vmapping_counter == 0) {
>> if (dmabuf->ops->vunmap)
>> dmabuf->ops->vunmap(dmabuf, vaddr);
>> - dmabuf->vmap_ptr = NULL;
>> + dma_buf_map_clear(&dmabuf->vmap_ptr);
>> }
>> mutex_unlock(&dmabuf->lock);
>> }
>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
>> new file mode 100644
>> index ..d4b1bb3cc4b0
>> --- /dev/null
>> +++ b/include/linux/dma-buf-map.h
>> @@ -0,0 +1,87 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Pointer to dma-buf-mapped memory, plus helpers.
>> + */
>> +
>> +#ifndef __DMA_BUF_MAP_H__
>> +#define __DMA_BUF_MAP_H__
>> +
>> +#include
>> +
>> +/**
>> + * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
>> + * @vaddr_iomem: The buffer's address if in I/O memory
>> + * @vaddr: The buffer's address if in system memory
>> + * @is_iomem: True if the dma-buf memory is located in I/O
>> + * memory, or false otherwise.
>> + *
>> + * Calling dma-buf's vmap operation returns a pointer to the buffer.
>> + * Depending on the location of the buffer, users may have to access it
>> + * with I/O operations or memory load/store operations. struct
>> dma_buf_map
>> + * stores the buffer add
Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning
On 24/09/2020 14:48, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote: >> On x64 we get: >> >> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: >> conversion from 'long unsigned int' to 'unsigned int' changes value from >> '18446744073709551613' to '4294967293' [-Woverflow] >> >> The registers are 32 bit, so fix by casting to u32. > > I wonder if we need a BIT32 macro... This is a common issue, it would be > nice to handle it in the macros that define register fields. That's probably a good idea. I think #define BIT32(nr) (1u << (nr)) should work correct on all archs. Although I'm not quite sure if nr should be cast to u32, but in my tests a u64 nr doesn't cause type promotion to u64. Anyway, I'd like to merge this fix as it is to get rid of the warning for the merge window. 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: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers that can't supply
all the pages at one time.
This function returns the last populated SGE in the table. Users should
pass it as an argument to the function from the second call and forward.
As before, nents will be equal to the number of populated SGEs (chunks).
So it's appending and growing the "list", did I get that right? Sounds handy
indeed. Some comments/questions below.
Yes, we (RDMA) use this function to chain contiguous pages.
I will eveluate if i915 could start using it. We have some loops which
build page by page and coalesce.
[snip]
if (unlikely(ret))
diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
--- a/tools/testing/scatterlist/main.c
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++, i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(&st, pages, test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(&st, pages, test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very welcomed. Since
the testing framework is already there, even if it bit-rotted a bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how the end
table looks like given the initial state and some different page patterns
added to it. And both crossing and not crossing into sg chaining scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
We will add proper test in next kernel cycle.
Patch seems to be adding a requirement that all callers of
(__)sg_alloc_table_from_pages pass in zeroed struct sg_table, which
wasn't the case so far.
Have you audited all the callers and/or fixed them? There seems to be
quite a few. Gut feel says problem would probably be better solved in
lib/scatterlist.c and not by making all the callers memset. Should be
possible if you make sure you only read st->nents if prev was passed in?
I've fixed the unit test and with this change the existing tests do
pass. But without zeroing it does fail on the very first, single page,
test scenario.
You can pull the unit test hacks from
git://people.freedesktop.org/~tursulin/drm-intel sgtest.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/vc4: crtc: Rework a bit the CRTC state code
On Fri, 25 Sep 2020 at 12:38, Maxime Ripard wrote: > > Hi Dave, > > On Wed, Sep 23, 2020 at 03:59:04PM +0100, Dave Stevenson wrote: > > Hi Maxime > > > > On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote: > > > > > > The current CRTC state reset hook in vc4 allocates a vc4_crtc_state > > > structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state > > > embeds drm_crtc_state as its first member, and therefore can be safely > > > casted. > > > > s/casted/cast > > > > > However, this is pretty fragile especially since there's no check for this > > > in place, and we're going to need to access vc4_crtc_state member at reset > > > so this looks like a good occasion to make it more robust. > > > > > > Signed-off-by: Maxime Ripard > > > Tested-by: Dave Stevenson > > > > Based on the issue I perceived with the previous patch, I'm happy. I > > haven't thought about how the framework handles losing the state, but > > that's not the driver's problem. > > > > There is still an implicit assumption that drm_crtc_state is the first > > member from the implementation of to_vc4_crtc_state in vc4_drv.h. To > > make it even more robust that could be a container_of instead. I > > haven't checked for any other places that make the assumption though. > > Good catch, I'll send another patch to fix it > > > Reviewed-by: Dave Stevenson > > Does it apply to the second patch as well? No. I got another interrupt before I'd refreshed my memory over what the second patch was doing and responding to it. I'll do that now (I don't think it changed much from v1) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
and store operations. Some architectures, such as sparc64, require the
use of I/O operations to access dma-map buffers that are located in I/O
memory. Providing struct dma_buf_map allows drivers to implement this.
This was specifically a problem when refreshing the graphics framebuffer
on such systems. [1]
As the first step, struct dma_buf stores an instance of struct dma_buf_map
internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
converted. Finally, affected drivers can be fixed.
v3:
* moved documentation into separate patch
* test for NULL pointers with !
[1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
Acked-by: Sumit Semwal
---
drivers/dma-buf/dma-buf.c | 14 +++
include/linux/dma-buf-map.h | 82 +
include/linux/dma-buf.h | 3 +-
3 files changed, 91 insertions(+), 8 deletions(-)
create mode 100644 include/linux/dma-buf-map.h
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 58564d82a3a2..5e849ca241a0 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
- BUG_ON(!dmabuf->vmap_ptr);
- ptr = dmabuf->vmap_ptr;
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+ ptr = dmabuf->vmap_ptr.vaddr;
goto out_unlock;
}
- BUG_ON(dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
ptr = dmabuf->ops->vmap(dmabuf);
if (WARN_ON_ONCE(IS_ERR(ptr)))
@@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
if (!ptr)
goto out_unlock;
- dmabuf->vmap_ptr = ptr;
+ dmabuf->vmap_ptr.vaddr = ptr;
dmabuf->vmapping_counter = 1;
out_unlock:
@@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(dmabuf->vmap_ptr != vaddr);
+ BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, vaddr);
- dmabuf->vmap_ptr = NULL;
+ dma_buf_map_clear(&dmabuf->vmap_ptr);
}
mutex_unlock(&dmabuf->lock);
}
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
new file mode 100644
index ..00143c88feb6
--- /dev/null
+++ b/include/linux/dma-buf-map.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Pointer to dma-buf-mapped memory, plus helpers.
+ */
+
+#ifndef __DMA_BUF_MAP_H__
+#define __DMA_BUF_MAP_H__
+
+#include
+
+/**
+ * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
+ * @vaddr_iomem: The buffer's address if in I/O memory
+ * @vaddr: The buffer's address if in system memory
+ * @is_iomem: True if the dma-buf memory is located in I/O
+ * memory, or false otherwise.
+ */
+struct dma_buf_map {
+ union {
+ void __iomem *vaddr_iomem;
+ void *vaddr;
+ };
+ bool is_iomem;
+};
+
+/* API transition helper */
+static inline bool dma_buf_map_is_vaddr(const struct dma_buf_map *map, const
void *vaddr)
+{
+ return !map->is_iomem && (map->vaddr == vaddr);
+}
+
+/**
+ * dma_buf_map_is_null - Tests for a dma-buf mapping to be NULL
+ * @map: The dma-buf mapping structure
+ *
+ * Depending on the state of struct dma_buf_map.is_iomem, tests if the
+ * mapping is NULL.
+ *
+ * Returns:
+ * True if the mapping is NULL, or false otherwise.
+ */
+static inline bool dma_buf_map_is_null(const struct dma_buf_map *map)
+{
+ if (map->is_iomem)
+ return !map->vaddr_iomem;
+ return !map->vaddr;
+}
+
+/**
+ * dma_buf_map_is_set - Tests is the dma-buf mapping has been set
+ * @map: The dma-buf mapping structure
+ *
+ * Depending on the state of struct dma_buf_map.is_iomem, tests if the
+ * mapping has been set.
+ *
+ * Returns:
+ * True if the mapping is been set, or false otherwise.
+ */
+static inline bool dma_buf_map_is_set(const struct dma_buf_map *map)
+{
+ return !dma_buf_map_is_null(map);
+}
+
+/**
+ * dma_buf_map_clear - Cle
[PATCH v3 2/4] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v3:
* update fastrpc driver (kernel test robot)
v2:
* always clear map parameter in dma_buf_vmap() (Daniel)
* include dma-buf-heaps and i915 selftests (kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
Acked-by: Christian König
Acked-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 28 +++
drivers/dma-buf/heaps/heap-helpers.c | 8 --
drivers/gpu/drm/drm_gem_cma_helper.c | 13 +
drivers/gpu/drm/drm_gem_shmem_helper.c| 14 ++
drivers/gpu/drm/drm_prime.c | 9 --
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 11 ++--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 12 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 10 +--
drivers/gpu/drm/tegra/gem.c | 18
.../common/videobuf2/videobuf2-dma-contig.c | 14 +++---
.../media/common/videobuf2/videobuf2-dma-sg.c | 16 +++
.../common/videobuf2/videobuf2-vmalloc.c | 15 +++---
drivers/misc/fastrpc.c| 6 ++--
include/drm/drm_prime.h | 3 +-
include/linux/dma-buf-map.h | 13 +
include/linux/dma-buf.h | 6 ++--
17 files changed, 143 insertions(+), 61 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5e849ca241a0..61bd24d21b38 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1186,46 +1186,50 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* dma_buf_vmap - Create virtual mapping for the buffer object into kernel
* address space. Same restrictions as for vmap and friends apply.
* @dmabuf:[in]buffer to vmap
+ * @map: [out] returns the vmap pointer
*
* This call may fail due to lack of virtual mapping address space.
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these interfaces.
*
- * Returns NULL on error.
+ * Returns 0 on success, or a negative errno code otherwise.
*/
-void *dma_buf_vmap(struct dma_buf *dmabuf)
+int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
- void *ptr;
+ struct dma_buf_map ptr;
+ int ret = 0;
+
+ dma_buf_map_clear(map);
if (WARN_ON(!dmabuf))
- return NULL;
+ return -EINVAL;
if (!dmabuf->ops->vmap)
- return NULL;
+ return -EINVAL;
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
- ptr = dmabuf->vmap_ptr.vaddr;
+ *map = dmabuf->vmap_ptr;
goto out_unlock;
}
BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
- ptr = dmabuf->ops->vmap(dmabuf);
- if (WARN_ON_ONCE(IS_ERR(ptr)))
- ptr = NULL;
- if (!ptr)
+ ret = dmabuf->ops->vmap(dmabuf, &ptr);
+ if (WARN_ON_ONCE(ret))
goto out_unlock;
- dmabuf->vmap_ptr.vaddr = ptr;
+ dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
+ *map = dmabuf->vmap_ptr;
+
out_unlock:
mutex_unlock(&dmabuf->lock);
- return ptr;
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index d0696cf937af..aeb9e100f339 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -235,7 +235,7 @@ static int dma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
return 0;
}
-static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
+static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
void *vaddr;
@@ -244,7 +244,11 @@ static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
vaddr = dma_heap_buffer_vmap_get(buffer);
mutex_unlock(&buffer->lock);
- return vaddr;
+ if (!vaddr)
+ return -ENOMEM;
+ dma_buf_map_set_vaddr(map, vaddr);
+
+ return 0;
}
static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
diff --git a/drivers/gpu/drm/drm_gem_c
[PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Dma-buf provides vmap() and vunmap() for retriving and releasing mappings of dma-buf memory in kernel address space. The functions operate with plain addresses and the assumption is that the memory can be accessed with load and store operations. This is not the case on some architectures (e.g., sparc64) where I/O memory can only be accessed with dedicated instructions. This patchset introduces struct dma_buf_map, which contains the address of a buffer and a flag that tells whether system- or I/O-memory instructions are required. Some background: updating the DRM framebuffer console on sparc64 makes the kernel panic. This is because the framebuffer memory cannot be accessed with system-memory instructions. We currently employ a workaround in DRM to address this specific problem. [1] To resolve the problem, we'd like to address it at the most common point, which is the dma-buf framework. The dma-buf mapping ideally knows if I/O instructions are required and exports this information to it's users. The new structure struct dma_buf_map stores the buffer address and a flag that signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) can then access the memory accordingly. This patchset only introduces struct dma_buf_map, and updates struct dma_buf and it's interfaces. Further patches can update dma-buf users. For example, there's a prototype patchset for DRM that fixes the framebuffer problem. [2] Further work: TTM, one of DRM's memory managers, already exports an is_iomem flag of its own. It could later be switched over to exporting struct dma_buf_map, thus simplifying some code. Several DRM drivers expect their fbdev console to operate on I/O memory. These could possibly be switched over to the generic fbdev emulation, as soon as the generic code uses struct dma_buf_map. v3: * update fastrpc driver (kernel test robot) * expand documentation (Daniel) * move documentation into separate patch v2: * always clear map parameter in dma_buf_vmap() (Daniel) * include dma-buf-heaps and i915 selftests (kernel test robot) * initialize cma_obj before using it in drm_gem_cma_free_object() (kernel test robot) [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ [2] https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ Thomas Zimmermann (4): dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces dma-buf: Document struct dma_buf_map Documentation/driver-api/dma-buf.rst | 9 + drivers/dma-buf/dma-buf.c | 42 ++-- drivers/dma-buf/heaps/heap-helpers.c | 10 +- drivers/gpu/drm/drm_gem_cma_helper.c | 20 +- drivers/gpu/drm/drm_gem_shmem_helper.c| 17 +- drivers/gpu/drm/drm_prime.c | 15 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 14 +- drivers/gpu/drm/tegra/gem.c | 23 ++- .../common/videobuf2/videobuf2-dma-contig.c | 17 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 19 +- .../common/videobuf2/videobuf2-vmalloc.c | 21 +- drivers/misc/fastrpc.c| 6 +- include/drm/drm_prime.h | 5 +- include/linux/dma-buf-map.h | 193 ++ include/linux/dma-buf.h | 11 +- 18 files changed, 372 insertions(+), 94 deletions(-) create mode 100644 include/linux/dma-buf-map.h -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v2:
* include dma-buf-heaps and i915 selftests (kernel test robot)
* initialize cma_obj before using it in drm_gem_cma_free_object()
(kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
Acked-by: Christian König
Acked-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 8 ++---
drivers/dma-buf/heaps/heap-helpers.c | 2 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 9 +++---
drivers/gpu/drm/drm_gem_shmem_helper.c| 3 +-
drivers/gpu/drm/drm_prime.c | 6 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 +--
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +-
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 4 +--
drivers/gpu/drm/tegra/gem.c | 5 +--
.../common/videobuf2/videobuf2-dma-contig.c | 3 +-
.../media/common/videobuf2/videobuf2-dma-sg.c | 3 +-
.../common/videobuf2/videobuf2-vmalloc.c | 6 ++--
include/drm/drm_prime.h | 2 +-
include/linux/dma-buf-map.h | 32 +--
include/linux/dma-buf.h | 4 +--
16 files changed, 66 insertions(+), 34 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 61bd24d21b38..a6ba4d598f0e 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1236,21 +1236,21 @@ EXPORT_SYMBOL_GPL(dma_buf_vmap);
/**
* dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
* @dmabuf:[in]buffer to vunmap
- * @vaddr: [in]vmap to vunmap
+ * @map: [in]vmap pointer to vunmap
*/
-void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
if (WARN_ON(!dmabuf))
return;
BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
+ BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
- dmabuf->ops->vunmap(dmabuf, vaddr);
+ dmabuf->ops->vunmap(dmabuf, map);
dma_buf_map_clear(&dmabuf->vmap_ptr);
}
mutex_unlock(&dmabuf->lock);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index aeb9e100f339..fcf4ce3e2cbb 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -251,7 +251,7 @@ static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf,
struct dma_buf_map *map
return 0;
}
-static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 19670b05ead5..2165633c9b9e 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -175,13 +175,12 @@ drm_gem_cma_create_with_handle(struct drm_file *file_priv,
*/
void drm_gem_cma_free_object(struct drm_gem_object *gem_obj)
{
- struct drm_gem_cma_object *cma_obj;
-
- cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(cma_obj->vaddr);
if (gem_obj->import_attach) {
if (cma_obj->vaddr)
- dma_buf_vunmap(gem_obj->import_attach->dmabuf,
cma_obj->vaddr);
+ dma_buf_vunmap(gem_obj->import_attach->dmabuf, &map);
drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
} else if (cma_obj->vaddr) {
dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
@@ -628,7 +627,7 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*dev,
obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj)) {
- dma_buf_vunmap(attach->dmabuf, map.vaddr);
+ dma_buf_vunmap(attach->dmabuf, &map);
return obj;
}
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6328cfbb828e..fb11df7aced5 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -337,6 +337,7 @@ EXPO
[PATCH v3 4/4] dma-buf: Document struct dma_buf_map
This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included. v3: * update documentation in a separate patch * expand docs (Daniel) * carry-over acks from patch 1 Signed-off-by: Thomas Zimmermann Reviewed-by: Christian König Reviewed-by: Daniel Vetter Acked-by: Sumit Semwal --- Documentation/driver-api/dma-buf.rst | 9 include/linux/dma-buf-map.h | 72 2 files changed, 81 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 13ea0cc0a3fa..6dbcc4714b0b 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -115,6 +115,15 @@ Kernel Functions and Structures Reference .. kernel-doc:: include/linux/dma-buf.h :internal: +Buffer Mapping Helpers +~~ + +.. kernel-doc:: include/linux/dma-buf-map.h + :doc: overview + +.. kernel-doc:: include/linux/dma-buf-map.h + :internal: + Reservation Objects --- diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h index c173a4abf4ba..fd1aba545fdf 100644 --- a/include/linux/dma-buf-map.h +++ b/include/linux/dma-buf-map.h @@ -8,6 +8,78 @@ #include +/** + * DOC: overview + * + * Calling dma-buf's vmap operation returns a pointer to the buffer's memory. + * Depending on the location of the buffer, users may have to access it with + * I/O operations or memory load/store operations. For example, copying to + * system memory could be done with memcpy(), copying to I/O memory would be + * done with memcpy_toio(). + * + * .. code-block:: c + * + * void *vaddr = ...; // pointer to system memory + * memcpy(vaddr, src, len); + * + * void *vaddr_iomem = ...; // pointer to I/O memory + * memcpy_toio(vaddr, _iomem, src, len); + * + * When using dma-buf's vmap operation, the returned pointer is encoded as + * :c:type:`struct dma_buf_map `. + * :c:type:`struct dma_buf_map ` stores the buffer's address in + * system or I/O memory and a flag that signals the required method of + * accessing the buffer. Use the returned instance and the helper functions + * to access the buffer's memory in the correct way. + * + * Open-coding access to :c:type:`struct dma_buf_map ` is + * considered bad style. Rather then accessing its fields directly, use one + * of the provided helper functions, or implement your own. For example, + * instances of :c:type:`struct dma_buf_map ` can be initialized + * statically with DMA_BUF_MAP_INIT_VADDR(), or at runtime with + * dma_buf_map_set_vaddr(). These helpers will set an address in system memory. + * + * .. code-block:: c + * + * struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(0xdeadbeaf); + * + * dma_buf_map_set_vaddr(&map. 0xdeadbeaf); + * + * Test if a mapping is valid with either dma_buf_map_is_set() or + * dma_buf_map_is_null(). + * + * .. code-block:: c + * + * if (dma_buf_map_is_set(&map) != dma_buf_map_is_null(&map)) + * // always true + * + * Instances of :c:type:`struct dma_buf_map ` can be compared + * for equality with dma_buf_map_is_equal(). Mappings the point to different + * memory spaces, system or I/O, are never equal. That's even true if both + * spaces are located in the same address space, both mappings contain the + * same address value, or both mappings refer to NULL. + * + * .. code-block:: c + * + * struct dma_buf_map sys_map; // refers to system memory + * struct dma_buf_map io_map; // refers to I/O memory + * + * if (dma_buf_map_is_equal(&sys_map, &io_map)) + * // always false + * + * Instances of struct dma_buf_map do not have to be cleaned up, but + * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings + * always refer to system memory. + * + * The type :c:type:`struct dma_buf_map ` and its helpers are + * actually independent from the dma-buf infrastructure. When sharing buffers + * among devices, drivers have to know the location of the memory to access + * the buffers in a safe way. :c:type:`struct dma_buf_map ` + * solves this problem for dma-buf and its users. If other drivers or + * sub-systems require similar functionality, the type could be generalized + * and moved to a more prominent header file. + */ + /** * struct dma_buf_map - Pointer to vmap'ed dma-buf memory. * @vaddr_iomem: The buffer's address if in I/O memory -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning
On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote: > On 24/09/2020 14:48, Laurent Pinchart wrote: > > Hi Tomi, > > > > Thank you for the patch. > > > > On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote: > >> On x64 we get: > >> > >> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: > >> conversion from 'long unsigned int' to 'unsigned int' changes value from > >> '18446744073709551613' to '4294967293' [-Woverflow] > >> > >> The registers are 32 bit, so fix by casting to u32. > > > > I wonder if we need a BIT32 macro... This is a common issue, it would be > > nice to handle it in the macros that define register fields. > > That's probably a good idea. I think > > #define BIT32(nr) (1u << (nr)) > > should work correct on all archs. Although I'm not quite sure if nr should be > cast to u32, but in my > tests a u64 nr doesn't cause type promotion to u64. I don't think we need to support nr values larger than 2^32-1 ;-) > Anyway, I'd like to merge this fix as it is to get rid of the warning for the > merge window. Sounds good to me. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: dsi: Use dev_ based logging
On Fri, 2020-09-25 at 12:22 +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
> Remove useless dsi_color_from_mipi function.
[]
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
[]
> - DRM_DEBUG_DRIVER("pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
> - pll_in_khz, pll_out_khz, *lane_mbps);
> + dev_dbg(dsi->dev, "pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
> pll_in_khz, pll_out_khz,
> + *lane_mbps);
The line wrapping change here is pretty pointless and IMO
makes the code harder to read.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/vc4: crtc: Keep the previously assigned HVS FIFO
Hi Maxime
Sorry for the delay.
On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
>
> The HVS FIFOs are currently assigned each time we have an atomic_check
> for all the enabled CRTCs.
>
> However, if we are running multiple outputs in parallel and we happen to
> disable the first (by index) CRTC, we end up changing the assigned FIFO
> of the second CRTC without disabling and reenabling the pixelvalve which
> ends up in a stall and eventually a VBLANK timeout.
>
> In order to fix this, we can create a special value for our assigned
> channel to mark it as disabled, and if our CRTC already had an assigned
> channel in its previous state, we keep on using it.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
> Tested-by: Dave Stevenson
Reviewed-by: Dave Stevenson
I retested too and had triple output (HDMI-0, HDMI-1, and DPI) working
happily! Switching around resolutions on the HDMI outputs was working
fine. DPI was an Adafruit Kippah and 800x480 LCD, so no options on
resolution.
We may finally have this muxing nailed.
Dave
> ---
>
> Changes from v1:
> - Split away the crtc state reset refactoring
> - Fixed the checkpatch warnings
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 1 +
> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
> drivers/gpu/drm/vc4/vc4_kms.c | 22 --
> 3 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 7ef20adedee5..482219fb4db2 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -863,6 +863,7 @@ void vc4_crtc_reset(struct drm_crtc *crtc)
> return;
> }
>
> + vc4_crtc_state->assigned_channel = VC4_HVS_CHANNEL_DISABLED;
> __drm_atomic_helper_crtc_reset(crtc, &vc4_crtc_state->base);
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 8c8d96b6289f..90b911fd2a7f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -532,6 +532,8 @@ struct vc4_crtc_state {
> } margins;
> };
>
> +#define VC4_HVS_CHANNEL_DISABLED ((unsigned int)-1)
> +
> static inline struct vc4_crtc_state *
> to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
> {
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 01fa60844695..149825ff5df8 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -616,7 +616,7 @@ static int
> vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> {
> unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct drm_crtc *crtc;
> int i, ret;
>
> @@ -629,6 +629,8 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> * modified.
> */
> list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + struct drm_crtc_state *crtc_state;
> +
> if (!crtc->state->enable)
> continue;
>
> @@ -637,15 +639,23 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> return PTR_ERR(crtc_state);
> }
>
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - struct vc4_crtc_state *vc4_crtc_state =
> - to_vc4_crtc_state(crtc_state);
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> + struct vc4_crtc_state *new_vc4_crtc_state =
> + to_vc4_crtc_state(new_crtc_state);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> unsigned int matching_channels;
>
> - if (!crtc_state->enable)
> + if (old_crtc_state->enable && !new_crtc_state->enable)
> + new_vc4_crtc_state->assigned_channel =
> VC4_HVS_CHANNEL_DISABLED;
> +
> + if (!new_crtc_state->enable)
> continue;
>
> + if (new_vc4_crtc_state->assigned_channel !=
> VC4_HVS_CHANNEL_DISABLED) {
> + unassigned_channels &=
> ~BIT(new_vc4_crtc_state->assigned_channel);
> + continue;
> + }
> +
> /*
> * The problem we have to solve here is that we have
> * up to 7 encoders, connected to up to 6 CRTCs.
> @@ -674,7 +684,7 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> if (matching_channels) {
> unsigned int channel = ffs(matching_channels) - 1;
>
> - vc4_crtc_state->assigned_channel = channel;
> + new_vc4_crtc_state->assigned_channel = channel;
> una
Re: [PATCH] drm: bridge: cdns-mhdp8546: fix compile warning
On Fri, Sep 25, 2020 at 03:05:52PM +0300, Tomi Valkeinen wrote: > On 25/09/2020 15:00, Laurent Pinchart wrote: > > On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote: > >> On 24/09/2020 14:48, Laurent Pinchart wrote: > >>> Hi Tomi, > >>> > >>> Thank you for the patch. > >>> > >>> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote: > On x64 we get: > > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: > conversion from 'long unsigned int' to 'unsigned int' changes value from > '18446744073709551613' to '4294967293' [-Woverflow] > > The registers are 32 bit, so fix by casting to u32. > >>> > >>> I wonder if we need a BIT32 macro... This is a common issue, it would be > >>> nice to handle it in the macros that define register fields. > >> > >> That's probably a good idea. I think > >> > >> #define BIT32(nr) (1u << (nr)) > >> > >> should work correct on all archs. Although I'm not quite sure if nr should > >> be cast to u32, but in my > >> tests a u64 nr doesn't cause type promotion to u64. > > > > I don't think we need to support nr values larger than 2^32-1 ;-) > > That's true, but we might have: > > u64 nr = 1; > BIT32(nr) > > Afaics, we don't need to cast nr to u32, but maybe that's still the safe > thing to do. > > >> Anyway, I'd like to merge this fix as it is to get rid of the warning for > >> the merge window. > > > > Sounds good to me. > > Was that a reviewed-by? =) Acked-by: Laurent Pinchart -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 0/7] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 The details are mentioned in DP to HDMI2.1 PCON Enum/Config improvement slide decks: https://groups.vesa.org/wg/DP/document/folder/1316 This RFC series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. Ankit Nautiyal (3): drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link status and link recovery drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 338 ++ drivers/gpu/drm/drm_edid.c| 50 +++ drivers/gpu/drm/i915/display/intel_ddi.c | 2 + .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/display/intel_dp.c | 251 - drivers/gpu/drm/i915/display/intel_dp.h | 2 + include/drm/drm_connector.h | 6 + include/drm/drm_dp_helper.h | 97 + include/drm/drm_edid.h| 30 ++ 9 files changed, 779 insertions(+), 3 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 4/7] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 6 +
drivers/gpu/drm/i915/display/intel_dp.c | 202 ++
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 210 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..9a295a43b189 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1264,6 +1264,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1312,6 +1317,7 @@ struct intel_dp {
unsigned long last_backlight_off;
ktime_t panel_power_off_time;
+ struct intel_dp_pcon_frl frl;
struct notifier_block edp_notifier;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf1e9cf1c0f3..3a8e69e5bbfb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2869,6 +2869,9 @@ static void intel_dp_prepare(struct intel_encoder
*encoder,
intel_dp->DP |= DP_PIPE_SEL_CHV(crtc->pipe);
else
intel_dp->DP |= DP_PIPE_SEL(crtc->pipe);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
}
@@ -3705,6 +3708,9 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3799,6 +3805,202 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_get_max_rate_gbps(struct intel_dp *intel_dp)
+{
+ int max_link_clock, max_lanes, max_rate_khz, max_rate_gbps;
+
+ max_link_clock = intel_dp_max_link_rate(intel_dp);
+ max_lanes = intel_dp_max_lane_count(intel_dp);
+ max_rate_khz = intel_dp_max_data_rate(max_link_clock, max_lanes);
+ max_rate_gbps = 8 * DIV_ROUND_UP(max_rate_khz, 100);
+
+ return max_rate_gbps;
+}
+
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+ int max_frl_mask = 0;
+
+ switch (max_frl) {
+ case 48:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_48GBPS;
+ break;
+ case 40:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_40GBPS;
+ break;
+ case 32:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_32GBPS;
+ break;
+ case 24:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_24GBPS;
+ break;
+ case 18:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_18GBPS;
+ break;
+ case 9:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_9GBPS;
+ break;
+ default:
+ max_frl_mask = 0;
+ }
+
+ return max_frl_mask;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lane);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE true
+#define PCON_CONCURRENT_MODE true
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl, max_pcon_frl, max_sink_frl, max_rate_gbps, max_frl_edid,
ret;
+ u8 max_frl_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_rate_gbps = intel_dp_get_max_rate_gbps(intel_dp);
+ drm_dbg(&i915->drm, "Source max rate = %d Gbps\n", max_rat
[RFC 1/7] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b27a0e2169c8..3b6371f36676 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10(1 << 0)
+#define DRM_EDID_DSC_12(1 << 1)
+#define DRM_EDID_DSC_16(1 << 2)
+#define DRM_EDID_DSC_ALL (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE 0xf
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 5/7] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 4d06178cd76c..cf8a8e2a64f7 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3389,6 +3389,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, if (!is_mst) intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + intel_dp_check_frl_training(intel_dp); + intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); /* * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 3a8e69e5bbfb..b6e53e4f06ee 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4129,6 +4129,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp); intel_dp_stop_link_train(intel_dp); @@ -6050,6 +6051,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, intel_crtc_pch_transcoder(crtc), false); } + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp); intel_dp_stop_link_train(intel_dp); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 6/7] drm/dp_helper: Add support for link status and link recovery
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC interrupt mechanism. While source can always read final HDMI
sink’s status using I2C over AUX, it’s easier and faster to read
the PCON’s already read HDMI sink’s status registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 33 +
include/drm/drm_dp_helper.h | 16
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 36302d4924f4..aac282bc5dfc 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2671,3 +2671,36 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lane; i++)
+ {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i ,
&buf) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+
+ switch(error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 58a6600e5698..7b143a2ae5ff 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -1985,4 +2000,5 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux, struct
drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 3/7] drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 305
include/drm/drm_dp_helper.h | 81 +
2 files changed, 386 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 478dd51f738d..36302d4924f4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2366,3 +2366,308 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS.
+ **/
+int drm_dp_get_pcon_max_frl_bw(struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * else returns negative error code.
+ **/
+int drm_dp_get_hdmi_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, &buf);
+ if (ret < 0)
+ return ret;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, &buf);
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * max_frl_mask: mask for selecting the bandwidths supported by source,
+ * to be tried by Pcon f/w.
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, &buf);
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GBPS;
+ break;
+ case 18:
+ buf |= DP_PCON_ENABLE_MAX_BW_18GBPS;
+ break;
+ case 24:
+ buf |= DP_PCON_ENABLE_MAX_BW_24GBPS;
+ break;
+ case 32:
[RFC 7/7] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
is off; reinitiate frl link training to recover.
Also, HDMI FRL link error count range for each individual FRL
active lane is indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b6e53e4f06ee..0de4c72e66c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5893,6 +5893,29 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+
+ is_active = drm_dp_pcon_hdmi_link_active(&intel_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, &buf) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ intel_dp_check_frl_training(intel_dp);
+ drm_dp_pcon_hdmi_frl_link_error_count(&intel_dp->aux,
&intel_dp->attached_connector->base);
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6121,7 +6144,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6145,6 +6168,23 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(&i915->drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 ||
!val)
+ return;
+
+ drm_dp_dpcd_writeb(&intel_dp->aux, DP_LINK_SERVICE_IRQ_VECTOR_ESI0,
val);
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6184,7 +6224,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(&intel_dp->aux);
@@ -6594,7 +6635,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 2/7] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 50 +
include/drm/drm_connector.h | 6 +
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 631125b46e04..d468ac91abb6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4849,6 +4849,51 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static void drm_parse_hdmi_21_additional_fields(struct drm_connector
*connector,
+ const u8 *db)
+{
+ /* hf_vsdb 7:14 support needs to be added */
+
+u8 max_frl_rate_per_lane;
+struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+max_frl_rate_per_lane = (db[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+
+switch(max_frl_rate_per_lane) {
+case 0:
+ hdmi->max_lane = 0;
+ hdmi->max_frl_rate_per_lane = 0;
+ break;
+case 1:
+ hdmi->max_lane = 3;
+ hdmi->max_frl_rate_per_lane = 3;
+ break;
+case 2:
+ hdmi->max_lane = 3;
+ hdmi->max_frl_rate_per_lane = 6;
+ break;
+case 3:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 6;
+ break;
+case 4:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 8;
+ break;
+case 5:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 10;
+ break;
+case 6:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 12;
+ break;
+default:
+ DRM_DEBUG_KMS("max frl rate per lane 0x%x, reserved\n",
max_frl_rate_per_lane);
+ break;
+}
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4902,6 +4947,11 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ drm_parse_hdmi_21_additional_fields(connector, hf_vsdb);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 928136556174..aa6ae9c17ca4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lane: supported by sink */
+ u8 max_lane;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 12:58, Jason Gunthorpe wrote: On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote: On 25/09/2020 08:13, Leon Romanovsky wrote: On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote: On 22/09/2020 09:39, Leon Romanovsky wrote: From: Maor Gottlieb Extend __sg_alloc_table_from_pages to support dynamic allocation of SG table from pages. It should be used by drivers that can't supply all the pages at one time. This function returns the last populated SGE in the table. Users should pass it as an argument to the function from the second call and forward. As before, nents will be equal to the number of populated SGEs (chunks). So it's appending and growing the "list", did I get that right? Sounds handy indeed. Some comments/questions below. Yes, we (RDMA) use this function to chain contiguous pages. I will eveluate if i915 could start using it. We have some loops which build page by page and coalesce. Christoph H doesn't like it, but if there are enough cases we should really have a pin_user_pages_to_sg() rather than open code this all over the place. With THP the chance of getting a coalescing SG is much higher, and everything is more efficient with larger SGEs. Right, I was actually referring to i915 sites where we build sg tables out of shmem and plain kernel pages. In those areas we have some open coded coalescing loops (see for instance our shmem_get_pages). Plus a local "trim" to discard the unused entries, since we allocate pessimistically not knowing how coalescing will pan out. This kind of core function which appends pages could replace some of that. Maybe it would be slightly less efficient but I will pencil in to at least evaluate it. Otherwise I do agree that coalescing is a win and in the past I have measured savings in a few MiB range just for struct scatterlist storage. Regards, Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(&st, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(&st, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a bit,
but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how
the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
Do you want to take some of the commits from
git://people.freedesktop.org/~tursulin/drm-intel sgtest? It would be
fine by me. I can clean up the commit messages if you want.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest&id=79102f4d795c4769431fc44a6cf7ed5c5b1b5214
- this one undoes the bit rot and makes the test just work on the
current kernel.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest&id=b09bfe80486c4d93ee1d8ae17d5b46397b1c6ee1
- this one you probably should squash in your patch. Minus the zeroing
of struct sg_stable since that would hide the issue.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest&id=97f5df37e612f798ced90541eece13e2ef639181
- final commit is optional but I guess handy for debugging.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index d6eeefab3d018b..6550c0bc824ea2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj,
void *ptr)
{
if (is_vmalloc_addr(ptr))
vunmap(ptr);
- else
- kunmap(kmap_to_page(ptr));
}
struct sg_table *
@@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* forever.
*
* So if the page is beyond the 32b boundary, make an explicit
-* vmap. On 64b, this check will be optimised away as we can
-* directly kmap any page on the system.
+* vmap.
*/
if (!PageHighMem(page))
- return kmap(page);
+ return page_address(page);
}
mem = stack;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag if
actually required). Switch to use vmap, and use vfree to free both the
vmalloc mapping and the page array, as well as dropping the references
to each page.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++
1 file changed, 18 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..f011ea42487e11 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
return file;
}
-static size_t shmem_npte(struct file *file)
-{
- return file->f_mapping->host->i_size >> PAGE_SHIFT;
-}
-
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
- unsigned long pfn;
-
- vunmap(ptr);
-
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (!WARN_ON(IS_ERR(page))) {
- put_page(page);
- put_page(page);
- }
- }
-}
-
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
- struct vm_struct *area;
- unsigned long pfn;
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
+ struct page **pages;
+ size_t n_pages, i;
+ void *vaddr;
- area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
+ n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
return NULL;
- }
- ptes = mem;
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (IS_ERR(page))
+ for (i = 0; i < n_pages; i++) {
+ pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+ GFP_KERNEL);
+ if (IS_ERR(pages[i]))
goto err_page;
-
- **ptes++ = mk_pte(page, PAGE_KERNEL);
}
- if (mem != stack)
- kvfree(mem);
-
+ vaddr = vmap(pages, n_pages, VM_MAP_PUT_PAGES, PAGE_KERNEL);
+ if (!vaddr)
+ goto err_page;
mapping_set_unevictable(file->f_mapping);
- return area->addr;
-
+ return vaddr;
err_page:
- if (mem != stack)
- kvfree(mem);
-
- __shmem_unpin_map(file, area->addr, pfn);
+ while (--i >= 0)
+ put_page(pages[i]);
+ kvfree(pages);
return NULL;
}
void shmem_unpin_map(struct file *file, void *ptr)
{
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr, shmem_npte(file));
+ vfree(ptr);
}
static int __shmem_rw(struct file *file, loff_t off,
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++
2 files changed, 59 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
select CRC32
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
+ select VMAP_PFN
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..b519417667eb4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
return err;
}
-static inline pte_t iomap_pte(resource_size_t base,
- dma_addr_t offset,
- pgprot_t prot)
-{
- return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
/* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+ enum i915_map_type type)
{
- unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
- struct sg_table *sgt = obj->mm.pages;
- pte_t *stack[32], **mem;
- struct vm_struct *area;
+ unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+ struct page *stack[32], **pages = stack, *page;
+ struct sgt_iter iter;
pgprot_t pgprot;
+ void *vaddr;
- if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
- return NULL;
-
- if (GEM_WARN_ON(type == I915_MAP_WC &&
- !static_cpu_has(X86_FEATURE_PAT)))
- return NULL;
-
- /* A single page can always be kmapped */
- if (n_pte == 1 && type == I915_MAP_WB) {
- struct page *page = sg_page(sgt->sgl);
-
+ switch (type) {
+ default:
+ MISSING_CASE(type);
+ fallthrough;/* to use PAGE_KERNEL anyway */
+ case I915_MAP_WB:
/*
* On 32b, highmem using a finite set of indirect PTE (i.e.
* vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* So if the page is beyond the 32b boundary, make an explicit
* vmap.
*/
- if (!PageHighMem(page))
- return page_address(page);
- }
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- /* Too big for stack -- allocate temporary array instead */
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
-
- area = alloc_vm_area(obj->base.size, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
- return NULL;
- }
-
- switch (type) {
- default:
- MISSING_CASE(type);
- fallthrough;/* to use PAGE_KERNEL anyway */
- case I915_MAP_WB:
+ if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+ return page_address(sg_page(obj->mm.pages->sgl));
pgprot = PAGE_KERNEL;
break;
case I915_MAP_WC:
@@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
break;
}
- if (i915_gem_object_has_struct_page(obj)) {
- struct sgt_iter iter;
- struct page *page;
- pte_t **ptes = mem;
+ if (n_pages > ARRAY_SIZE(stack)) {
+ /* Too big for stack -- allocate temporary array instead */
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
+ return NULL;
+ }
- for_each_sgt_page(page, iter, sgt)
- **ptes++
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 11:34 AM Christian König wrote: > > Am 25.09.20 um 10:18 schrieb Daniel Vetter: > > On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote: > >> On Fri, Sep 25, 2020 at 9:39 AM Christian König > >> wrote: > >>> Am 25.09.20 um 01:14 schrieb Dave Airlie: > On Thu, 24 Sep 2020 at 22:42, Christian König > wrote: > > Am 24.09.20 um 07:18 schrieb Dave Airlie: > >> From: Dave Airlie > >> > >> All the accel moves do the same pattern here, provide a helper > > And exactly that pattern I want to get away from. > Currently this is just refactoring out the helper code in each driver, > but I see > since it calls bo_mem_space we are probably moving a bit in the wrong > direction. > >>> Exactly that's why I'm noting this. > >>> > > See what happens if we (for example) have a VRAM -> SYSTEM move is the > > following: > > > > 1. TTM allocates a new ttm_resource object in the SYSTEM domain. > > 2. We call the driver to move from VRAM to SYSTEM. > > 3. Driver finds that it can't do this and calls TTM to allocate GTT. > > 4. Since we are maybe out of GTT TTM evicts a different BO from GTT to > > SYSTEM and call driver again. > > > > This is a horrible ping/pong between driver/TTM/driver/TTM/driver and we > > should stop that immediately. > > > > My suggestion is that we rewrite how drivers call the ttm_bo_validate() > > function so that we can guarantee that this never happens. > > > > What do you think? > I think that is likely the next step I'd like to take after this > refactor, it's a lot bigger, and I'm not sure how it will look yet. > >>> Agree, yes. I have some ideas in mind for that, but not fully baked > >>> either. > >>> > Do we envision the driver calling validate in a loop but when it can't > find space it tells the driver and the driver does eviction and > recalls validate? > >>> Not in a loop, but more like in a chain. > >>> > >>> My plan is something like this: > >>> Instead of having "normal" and "busy" placement we have a flag in the > >>> context if evictions are allowed or not. > >>> The call to ttm_bo_validate are then replaced with two calls, first > >>> without evictions and if that didn't worked one with evictions. > >>> > >>> Then the normal validate sequence should look like this: > >>> 1. If a BO is in the SYSTEM (or SWAP domain) we validate it to GTT first > >>> with evictions=true. > >>> 2. If a BO should be in VRAM we then validate it to VRAM. If evictions > >>> are only allowed if the GEM flags say that GTT is not desired. > >> That solves the trouble when you move a bo into vram as part of > >> validate. But I'm not seeing how this solves the "need gtt mapping to > >> move something out of vram" problem. > > Eviction is not a problem because the driver gets asked where to put an > evicted BO and then TTM does all the moving. Hm I guess then I don't quite get where you see the ping-pong happening, I thought that only happens for evicting stuff. But hey not much actual working experience with ttm over here, I'm just reading :-) I thought the issue is that ttm wants to evict from $something to SYSTEM, and to do that the driver first needs to set a GTT mapping for the SYSTEM ttm_resource allocation, so that it can use the blitter/sdma engine or whatever to move the data over. But for swap-in/validation I'm confused how you can end up with the "wrong" placement, that feels like a driver bug. How exactly can you get into a situation with validation where ttm gives you SYSTEM, but not GTT and the driver has to fix that up? I'm not really following I think, I guess there's something obvious I'm missing. > >> Or should we instead move the entire eviction logic out from ttm into > >> drivers, building it up from helpers? > > I've been playing with that thought for a while as well, but then > decided against it. > > The main problem I see is that we sometimes need to evict things from > other drivers. > > E.g. when we overcommitted system memory and move things to swap for > example. Hm yeah ttm has that limit to avoid stepping into the shrinker, directly calling into another driver to keep within the limit while ignoring that there's other memory users and caches out there still feels wrong, it's kinda a parallel world vs shrinker callbacks. And there's nothing stopping you from doing the SYSTEM->SWAP movement from a shrinker callback with the locking rules we've established around dma_resv (just needs to be a trylock). So feels a bit backwards if we design ttm eviction around this part of it ... > >> Then drivers which need gtt for > >> moving stuff out of vram can do that right away. Also, this would > >> allow us to implement very fancy eviction algorithms like all the > >> nonsense we're doing in i915 for gtt handling on gen2/3 (but I really > >> hope that never ever becomes a thing again in future gpus, so this is > >> maybe
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Fri, Sep 25, 2020 at 06:13:00AM -0400, Peilin Ye wrote:
> Hi all!
>
> On Fri, Sep 25, 2020 at 08:46:04AM +0200, Jiri Slaby wrote:
> > > In order to perform a reliable range check, fbcon_get_font() needs to know
> > > `FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
> > > do not keep that information in our font descriptor,
> > > `struct console_font`:
> > >
> > > (include/uapi/linux/kd.h)
> > > struct console_font {
> > > unsigned int width, height; /* font size */
> > > unsigned int charcount;
> > > unsigned char *data;/* font data with height fixed to 32 */
> > > };
> > >
> > > To make things worse, `struct console_font` is part of the UAPI, so we
> > > cannot add a new field to keep track of `FONTDATAMAX`.
> >
> > Hi,
> >
> > but you still can define struct kernel_console_font containing struct
> > console_font and the 4 more members you need in the kernel. See below.
> >
> > > Fortunately, the framebuffer layer itself gives us a hint of how to
> > > resolve this issue without changing UAPI. When allocating a buffer for a
> > > user-provided font, fbcon_set_font() reserves four "extra words" at the
> > > beginning of the buffer:
> > >
> > > (drivers/video/fbdev/core/fbcon.c)
> > > new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
> >
> > I might be missing something (like coffee in the morning), but why don't
> > you just:
> > 1) declare struct font_data as
> > {
> > unsigned sum, char_count, size, refcnt;
> > const unsigned char data[];
> > }
> >
> > Or maybe "struct console_font font" instead of "const unsigned char
> > data[]", if need be.
> >
> > 2) allocate by:
> > kmalloc(struct_size(struct font_data, data, size));
> >
> > 3) use container_of wherever needed
> >
> > That is you name the data on negative indexes using struct as you
> > already have to define one.
> >
> > Then you don't need the ugly macros with negative indexes. And you can
> > pass this structure down e.g. to fbcon_do_set_font, avoiding potential
> > mistakes in accessing data[-1] and similar.
>
> Sorry that I didn't mention it in the cover letter, but yes, I've tried
> this - a new `kernel_console_font` would be much cleaner than negative
> array indexing.
>
> The reason I ended up giving it up was, frankly speaking, these macros
> are being used at about 30 places, and I am not familiar enough with the
> framebuffer and newport_con code, so I wasn't confident how to clean
> them up and plug in `kernel_console_font` properly...
>
> Another reason was that, functions like fbcon_get_font() handle both user
> fonts and built-in fonts, so I wanted a single solution for both of
> them. I think we can't really introduce `kernel_console_font` while
> keeping these macros, that would make the error handling logics etc.
> very messy.
>
> I'm not very sure what to do now. Should I give it another try cleaning
> up all the macros?
>
> And thank you for reviewing this!
I think the only way to make this work is that we have one place which
takes in the userspace uapi struct, and then converts it once into a
kernel_console_font. With all the error checking.
Then all internal code deals in terms of kernel_console_font, with
properly typed and named struct members and helper functions and
everything. And we might need a gradual conversion for this, so that first
we can convert over invidual console drivers, then subsystems, until at
the end we've pushed the conversion from uapi array to kernel_console_font
all the way to the ioctl entry points.
But that's indeed a huge pile of work, and fair warning: fbcon is
semi-orphaned, so by doing this you'll pretty much volunteer for
maintainership :-)
But I'd be very happy to help get this done and throw some maintainership
credentials at you in the proces ...
Cheers, 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 1/6] drm/atomic: Pass the full state to CRTC atomic enable/disable
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to shawnguo/for-next drm-intel/for-linux-next linus/master
anholt/for-next v5.9-rc6 next-20200925]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-vc4-hdmi-Support-the-10-12-bit-output/20200925-151211
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/1ceb933c2a3dd89451b7563e66097d05e1df8d2e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Maxime-Ripard/drm-vc4-hdmi-Support-the-10-12-bit-output/20200925-151211
git checkout 1ceb933c2a3dd89451b7563e66097d05e1df8d2e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/imx/dcss/dcss-crtc.c: In function 'dcss_crtc_atomic_enable':
>> drivers/gpu/drm/imx/dcss/dcss-crtc.c:82:42: error: implicit declaration of
>> function 'drm_atomic_get_old_crtc_state'
>> [-Werror=implicit-function-declaration]
82 | struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
|
^
>> drivers/gpu/drm/imx/dcss/dcss-crtc.c:82:42: warning: initialization of
>> 'struct drm_crtc_state *' from 'int' makes pointer from integer without a
>> cast [-Wint-conversion]
drivers/gpu/drm/imx/dcss/dcss-crtc.c: In function 'dcss_crtc_atomic_disable':
drivers/gpu/drm/imx/dcss/dcss-crtc.c:118:42: warning: initialization of
'struct drm_crtc_state *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
118 | struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
|
^
cc1: some warnings being treated as errors
vim +/drm_atomic_get_old_crtc_state +82 drivers/gpu/drm/imx/dcss/dcss-crtc.c
78
79 static void dcss_crtc_atomic_enable(struct drm_crtc *crtc,
80 struct drm_atomic_state *state)
81 {
> 82 struct drm_crtc_state *old_crtc_state =
drm_atomic_get_old_crtc_state(state,
83
crtc);
84 struct dcss_crtc *dcss_crtc = container_of(crtc, struct
dcss_crtc,
85 base);
86 struct dcss_dev *dcss = dcss_crtc->base.dev->dev_private;
87 struct drm_display_mode *mode = &crtc->state->adjusted_mode;
88 struct drm_display_mode *old_mode =
&old_crtc_state->adjusted_mode;
89 struct videomode vm;
90
91 drm_display_mode_to_videomode(mode, &vm);
92
93 pm_runtime_get_sync(dcss->dev);
94
95 vm.pixelclock = mode->crtc_clock * 1000;
96
97 dcss_ss_subsam_set(dcss->ss);
98 dcss_dtg_css_set(dcss->dtg);
99
100 if (!drm_mode_equal(mode, old_mode) || !old_crtc_state->active)
{
101 dcss_dtg_sync_set(dcss->dtg, &vm);
102 dcss_ss_sync_set(dcss->ss, &vm,
103 mode->flags & DRM_MODE_FLAG_PHSYNC,
104 mode->flags & DRM_MODE_FLAG_PVSYNC);
105 }
106
107 dcss_enable_dtg_and_ss(dcss);
108
109 dcss_ctxld_enable(dcss->ctxld);
110
111 /* Allow CTXLD kick interrupt to be disabled when VBLANK is
disabled. */
112 dcss_crtc->disable_ctxld_kick_irq = true;
113 }
114
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
Am 25.09.20 um 15:17 schrieb Daniel Vetter: [SNIP] Eviction is not a problem because the driver gets asked where to put an evicted BO and then TTM does all the moving. Hm I guess then I don't quite get where you see the ping-pong happening, I thought that only happens for evicting stuff. No, eviction is the nice case. One step after another. E.g. from VRAM to GTT, then from GTT to SYSTEM and then eventually swapped out. But hey not much actual working experience with ttm over here, I'm just reading :-) I thought the issue is that ttm wants to evict from $something to SYSTEM, and to do that the driver first needs to set a GTT mapping for the SYSTEM ttm_resource allocation, so that it can use the blitter/sdma engine or whatever to move the data over. But for swap-in/validation I'm confused how you can end up with the "wrong" placement, that feels like a driver bug. The problem happens in the other direction and always directly triggered by the driver. How exactly can you get into a situation with validation where ttm gives you SYSTEM, but not GTT and the driver has to fix that up? I'm not really following I think, I guess there's something obvious I'm missing. For example a buffer which was evicted to SYSTEM needs to be moved back directly to VRAM. Or we want to evacuate all buffers from VRAM to SYSTEM because of hibernation. etc Or should we instead move the entire eviction logic out from ttm into drivers, building it up from helpers? I've been playing with that thought for a while as well, but then decided against it. The main problem I see is that we sometimes need to evict things from other drivers. E.g. when we overcommitted system memory and move things to swap for example. Hm yeah ttm has that limit to avoid stepping into the shrinker, directly calling into another driver to keep within the limit while ignoring that there's other memory users and caches out there still feels wrong, it's kinda a parallel world vs shrinker callbacks. And there's nothing stopping you from doing the SYSTEM->SWAP movement from a shrinker callback with the locking rules we've established around dma_resv (just needs to be a trylock). So feels a bit backwards if we design ttm eviction around this part of it ... Ok, that's a good point. Need to think about that a bit more then. Then drivers which need gtt for moving stuff out of vram can do that right away. Also, this would allow us to implement very fancy eviction algorithms like all the nonsense we're doing in i915 for gtt handling on gen2/3 (but I really hope that never ever becomes a thing again in future gpus, so this is maybe more a what-if kind of thing). Not sure how that would look like, maybe a special validate function which takes a ttm_resource the driver already found (through evicting stuff or whatever) and then ttm just does the move and book-keeping and everything. And drivers would at first only call validate without allowing any eviction. Ofc anyone without special needs could use the standard eviction function that validate already has. Spinning this a bit more, we could have different default eviction functions with this, e.g. so all the drivers that need gtt mapping for moving stuff around can share that code, but with specific&flat control flow instead of lots of ping-ping. And drivers that don't need gtt mapping (like i915, we just need dma_map_sg which we assume works always, or something from the ttm dma page pool, which really always works) can then use something simpler that's completely flat. Ok you need to explain a bit more what exactly the problem with the GTT eviction is here :) So the full set of limitations are - range limits - power-of-two alignement of start - some other (smaller) power of two alignment for size (lol) - "color", i.e. different caching modes needs at least one page of empty space in-between Stuffing all that into a generic eviction logic is imo silly. On top of that we have the eviction collector where we scan the entire thing until we've built up a sufficiently big hole, then evict just these buffers. If we don't do this then pretty much any big buffer with constraints results in the entire GTT getting evicted. Again something that's only worth it if you have ridiculous placement constraints like these old intel chips. gen2/3 in i915.ko is maybe a bit extreme, but having the driver in control of the eviction code feels like a much better design than ttm inflicting a one-size-fits-all on everyone. Ofc with defaults and building blocks and all that. Yeah, that makes a lot of sense. Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 14:39, Maor Gottlieb wrote:
On 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(&st, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(&st, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a
bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of
how the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty
confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
Do you want to take some of the commits from
git://people.freedesktop.org/~tursulin/drm-intel sgtest? It would be
fine by me. I can clean up the commit messages if you want.
I will very appreciate it. Thanks
I've pushed a branch with tidied commit messages and a bit re-ordered to
the same location. You can pull and include in your series:
tools/testing/scatterlist: Rejuvenate bit-rotten test
tools/testing/scatterlist: Show errors in human readable form
And "test fixes for sg append" you can squash (minus the sg_table
zeroing) into your patch.
If this plan does not work for you, I can send two of my patches to lkml
independently. What ever you prefer.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 37/45] drm/ttm: add a helper to allocate a temp tt for copies.
On Fri, Sep 25, 2020 at 3:40 PM Christian König wrote: > > Am 25.09.20 um 15:17 schrieb Daniel Vetter: > > [SNIP] > >> Eviction is not a problem because the driver gets asked where to put an > >> evicted BO and then TTM does all the moving. > > Hm I guess then I don't quite get where you see the ping-pong > > happening, I thought that only happens for evicting stuff. > > No, eviction is the nice case. One step after another. > > E.g. from VRAM to GTT, then from GTT to SYSTEM and then eventually > swapped out. > > > But hey not much actual working experience with ttm over here, I'm just > > reading > > :-) I thought the issue is that ttm wants to evict from $something to > > SYSTEM, and to do that the driver first needs to set a GTT mapping for > > the SYSTEM ttm_resource allocation, so that it can use the > > blitter/sdma engine or whatever to move the data over. But for > > swap-in/validation I'm confused how you can end up with the "wrong" > > placement, that feels like a driver bug. > > The problem happens in the other direction and always directly triggered > by the driver. > > > How exactly can you get into a situation with validation where ttm > > gives you SYSTEM, but not GTT and the driver has to fix that up? I'm > > not really following I think, I guess there's something obvious I'm > > missing. > > For example a buffer which was evicted to SYSTEM needs to be moved back > directly to VRAM. > > Or we want to evacuate all buffers from VRAM to SYSTEM because of > hibernation. > > etc Ok, I think I get it. Eviction always goes one step only in the chain (but maybe multiple times as part of an overall eu validate for all the buffers). But swap in can go the entire length in one go. So yeah demidlayering eviction isn't quite the right thing here, since it's not the problem. -Daniel > > Or should we instead move the entire eviction logic out from ttm into > drivers, building it up from helpers? > >> I've been playing with that thought for a while as well, but then > >> decided against it. > >> > >> The main problem I see is that we sometimes need to evict things from > >> other drivers. > >> > >> E.g. when we overcommitted system memory and move things to swap for > >> example. > > Hm yeah ttm has that limit to avoid stepping into the shrinker, > > directly calling into another driver to keep within the limit while > > ignoring that there's other memory users and caches out there still > > feels wrong, it's kinda a parallel world vs shrinker callbacks. And > > there's nothing stopping you from doing the SYSTEM->SWAP movement from > > a shrinker callback with the locking rules we've established around > > dma_resv (just needs to be a trylock). > > > > So feels a bit backwards if we design ttm eviction around this part of it > > ... > > Ok, that's a good point. Need to think about that a bit more then. > > Then drivers which need gtt for > moving stuff out of vram can do that right away. Also, this would > allow us to implement very fancy eviction algorithms like all the > nonsense we're doing in i915 for gtt handling on gen2/3 (but I really > hope that never ever becomes a thing again in future gpus, so this is > maybe more a what-if kind of thing). Not sure how that would look > like, maybe a special validate function which takes a ttm_resource the > driver already found (through evicting stuff or whatever) and then ttm > just does the move and book-keeping and everything. And drivers would > at first only call validate without allowing any eviction. Ofc anyone > without special needs could use the standard eviction function that > validate already has. > >>> Spinning this a bit more, we could have different default eviction > >>> functions with this, e.g. so all the drivers that need gtt mapping for > >>> moving stuff around can share that code, but with specific&flat > >>> control flow instead of lots of ping-ping. And drivers that don't need > >>> gtt mapping (like i915, we just need dma_map_sg which we assume works > >>> always, or something from the ttm dma page pool, which really always > >>> works) can then use something simpler that's completely flat. > >> Ok you need to explain a bit more what exactly the problem with the GTT > >> eviction is here :) > > So the full set of limitations are > > - range limits > > - power-of-two alignement of start > > - some other (smaller) power of two alignment for size (lol) > > - "color", i.e. different caching modes needs at least one page of > > empty space in-between > > > > Stuffing all that into a generic eviction logic is imo silly. On top > > of that we have the eviction collector where we scan the entire thing > > until we've built up a sufficiently big hole, then evict just these > > buffers. If we don't do this then pretty much any big buffer with > > constraints results in the entire GTT getting evicted. Again something > > that's only worth it if you have ridiculous plac
Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++
> 2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
> select CRC32
> select SND_HDA_I915 if SND_HDA_CORE
> select CEC_CORE if CEC_NOTIFIER
> + select VMAP_PFN
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
> drm_i915_gem_object *obj)
> return err;
> }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> - dma_addr_t offset,
> - pgprot_t prot)
> -{
> - return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
> /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> + enum i915_map_type type)
> {
> - unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> - struct sg_table *sgt = obj->mm.pages;
> - pte_t *stack[32], **mem;
> - struct vm_struct *area;
> + unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> + struct page *stack[32], **pages = stack, *page;
> + struct sgt_iter iter;
> pgprot_t pgprot;
> + void *vaddr;
>
> - if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> - return NULL;
> -
> - if (GEM_WARN_ON(type == I915_MAP_WC &&
> - !static_cpu_has(X86_FEATURE_PAT)))
> - return NULL;
> -
> - /* A single page can always be kmapped */
> - if (n_pte == 1 && type == I915_MAP_WB) {
> - struct page *page = sg_page(sgt->sgl);
> -
> + switch (type) {
> + default:
> + MISSING_CASE(type);
> + fallthrough;/* to use PAGE_KERNEL anyway */
> + case I915_MAP_WB:
> /*
> * On 32b, highmem using a finite set of indirect PTE (i.e.
> * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
> drm_i915_gem_object *obj,
> * So if the page is beyond the 32b boundary, make an explicit
> * vmap.
> */
> - if (!PageHighMem(page))
> - return page_address(page);
> - }
> -
> - mem = stack;
> - if (n_pte > ARRAY_SIZE(stack)) {
> - /* Too big for stack -- allocate temporary array instead */
> - mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> - if (!mem)
> - return NULL;
> - }
> -
> - area = alloc_vm_area(obj->base.size, mem);
> - if (!area) {
> - if (mem != stack)
> - kvfree(mem);
> - return NULL;
> - }
> -
> - switch (type) {
> - default:
> - MISSING_CASE(type);
> - fallthrough;/* to use PAGE_KERNEL anyway */
> - case I915_MAP_WB:
> + if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> + return page_address(sg_page(obj->mm.pages->sgl));
> pgprot = PAGE_KERNEL;
> break;
> case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct
> drm_i915_gem_object *obj,
> break;
> }
>
> - if (i915_gem_object_has_struct_page(obj)) {
> - struct sgt_iter iter;
> - struct page *page;
> - pte_t **ptes = mem;
> + if (n_pages > ARRAY_SIZE(stack)) {
> + /* Too big for stack -- allocate tempora
[PATCH] drm/panel: rm68200: fix mode to 50fps
Compute new timings to get a framerate of 50fps with a pixel clock
@54Mhz.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
index 2b9e48b0a491..412c0dbcb2b6 100644
--- a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
+++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
@@ -82,15 +82,15 @@ struct rm68200 {
};
static const struct drm_display_mode default_mode = {
- .clock = 52582,
+ .clock = 54000,
.hdisplay = 720,
- .hsync_start = 720 + 38,
- .hsync_end = 720 + 38 + 8,
- .htotal = 720 + 38 + 8 + 38,
+ .hsync_start = 720 + 48,
+ .hsync_end = 720 + 48 + 9,
+ .htotal = 720 + 48 + 9 + 48,
.vdisplay = 1280,
.vsync_start = 1280 + 12,
- .vsync_end = 1280 + 12 + 4,
- .vtotal = 1280 + 12 + 4 + 12,
+ .vsync_end = 1280 + 12 + 5,
+ .vtotal = 1280 + 12 + 5 + 12,
.flags = 0,
.width_mm = 68,
.height_mm = 122,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
CONFIG_AMDGPU triggers full rebuild
Hi, whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole kernel. I guess it auto-selects some architecture-specific feature. That full rebuild might be avoidable if I could enable that feature permanently. Any ideas what this could be and how to avoid the full rebuilt? Best regards Thomas -- 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 0/3] fbdev: stop using compat_alloc_user_space
On Fri, Sep 25, 2020 at 01:31:51PM +0200, Arnd Bergmann wrote: > On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote: > > > > Hi Daniel/Arnd. > > > > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote: > > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote: > > > > The fbdev code uses compat_alloc_user_space in a few of its > > > > compat_ioctl handlers, which tends to be a bit more complicated > > > > and error-prone than calling the underlying handlers directly, > > > > so I would like to remove it completely. > > > > > > > > This modifies two such functions in fbdev, and removes another > > > > one that is completely unused. > > > > > > > > Arnd > > > > > > > > Arnd Bergmann (3): > > > > fbdev: simplify fb_getput_cmap() > > > > fbdev: sbuslib: remove unused FBIOSCURSOR32 helper > > > > fbdev: sbuslib: remove compat_alloc_user_space usage > > > > > > Looks all good, but we're also kinda looking for a new volunteer for > > > handling fbdev patches ... drm-misc commit rights, still not interested? > > > > Hi Daniel - I read the above as an a-b. And Arnd did not take the bait > > it seems. > > Ah right, I meant to reply but then forgot about it. > > I don't really want commit access, thanks for the offer. > > > Hi Arnd. checkpatch complained about some whitespace, which I fixed > > while applying. > > Will push to drm-misc-next tomorrow unless I hear anything else. > > Great, thanks! Pushed now. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: dsi: Use dev_ based logging
Hi Yannick.
On Fri, Sep 25, 2020 at 12:22:33PM +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
The patchs filas to drop the include mentioned here.
> Remove useless dsi_color_from_mipi function.
IMO the dsi_color_from_mipi() was nice, and inlining the helper
is no gain for readability.
Sam
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 87 ++-
> 1 file changed, 45 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 164f79ef6269..93fa8bfd3127 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -76,6 +76,7 @@ enum dsi_color {
>
> struct dw_mipi_dsi_stm {
> void __iomem *base;
> + struct device *dev;
> struct clk *pllref_clk;
> struct dw_mipi_dsi *dsi;
> u32 hw_version;
> @@ -110,23 +111,6 @@ static inline void dsi_update_bits(struct
> dw_mipi_dsi_stm *dsi, u32 reg,
> dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
> }
>
> -static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
> -{
> - switch (fmt) {
> - case MIPI_DSI_FMT_RGB888:
> - return DSI_RGB888;
> - case MIPI_DSI_FMT_RGB666:
> - return DSI_RGB666_CONF2;
> - case MIPI_DSI_FMT_RGB666_PACKED:
> - return DSI_RGB666_CONF1;
> - case MIPI_DSI_FMT_RGB565:
> - return DSI_RGB565_CONF1;
> - default:
> - DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
> - }
> - return DSI_RGB888;
> -}
> -
> static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int odf)
> {
> int divisor = idf * odf;
> @@ -205,14 +189,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
>SLEEP_US, TIMEOUT_US);
> if (ret)
> - DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
> + dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
>
> /* Enable the DSI PLL & wait for its lock */
> dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
>SLEEP_US, TIMEOUT_US);
> if (ret)
> - DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
> + dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
>
> return 0;
> }
> @@ -221,7 +205,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
>
> - DRM_DEBUG_DRIVER("\n");
> + dev_dbg(dsi->dev, "\n");
>
> /* Enable the DSI wrapper */
> dsi_set(dsi, DSI_WCR, WCR_DSIEN);
> @@ -231,7 +215,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
>
> - DRM_DEBUG_DRIVER("\n");
> + dev_dbg(dsi->dev, "\n");
>
> /* Disable the DSI wrapper */
> dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
> @@ -244,6 +228,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
> unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
> + enum mipi_dsi_pixel_format fmt;
> int ret, bpp;
> u32 val;
>
> @@ -267,11 +252,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
>
> if (pll_out_khz > dsi->lane_max_kbps) {
> pll_out_khz = dsi->lane_max_kbps;
> - DRM_WARN("Warning max phy mbps is used\n");
> + dev_warn(dsi->dev, "Warning max phy mbps is used\n");
> }
> if (pll_out_khz < dsi->lane_min_kbps) {
> pll_out_khz = dsi->lane_min_kbps;
> - DRM_WARN("Warning min phy mbps is used\n");
> + dev_warn(dsi->dev, "Warning min phy mbps is used\n");
> }
>
> /* Compute best pll parameters */
> @@ -281,7 +266,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
> ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
>&idf, &ndiv, &odf);
> if (ret)
> - DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
> + dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
> params\n");
>
> /* Get the adjusted pll out value */
> pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
> @@ -297,14 +282,31 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
> /* Select video mode by resetting DSIM bit */
> dsi_clear(dsi, DSI_WCFGR, WCFGR_DSIM);
>
> + switch (format) {
> + case MIPI_DSI_FMT_RGB888:
> + fmt = DSI_RGB888;
> + break;
> + case MIPI_D
Re: [PATCH 1/9] drm/format-helper: Pass destination pitch to drm_fb_memcpy_dstclip()
Hi
Am 29.06.20 um 10:40 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:03PM +0200, Thomas Zimmermann wrote:
>> The memcpy's destination buffer might have a different pitch than the
>> source. Support different pitches as function argument.
>>
>> Signed-off-by: Thomas Zimmermann
>
> Reviewed-by: Daniel Vetter
>
> But I do have questions ... why did we allocate a source drm_framebuffer
> with mismatching pitch? That sounds backwards, especially for simplekms.
There's userspace that allocates framebuffers in tiles of 64x64 pixels.
I think I've seen this with Gnome. So if you have a 800x600 display
mode, the allocated framebuffer has a scanline pitch of 832 pixels and
the final 32 pixels are ignored.
In regular drivers, we can handle this with the VGA offset register [1]
or some equivalent. That's obviously not an option with simplekms, so
the different pitch is required.
Best regards
Thomas
[1]
https://web.stanford.edu/class/cs140/projects/pintos/specs/freevga/vga/crtcreg.htm#13
>
> Would be good to add the reasons why we need this to the commit message,
> I'm sure I'll discover it later on eventually.
> -Daniel
>
>> ---
>> drivers/gpu/drm/drm_format_helper.c| 9 +
>> drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
>> drivers/gpu/drm/tiny/cirrus.c | 2 +-
>> include/drm/drm_format_helper.h| 2 +-
>> 4 files changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_format_helper.c
>> b/drivers/gpu/drm/drm_format_helper.c
>> index c043ca364c86..8d5a683afea7 100644
>> --- a/drivers/gpu/drm/drm_format_helper.c
>> +++ b/drivers/gpu/drm/drm_format_helper.c
>> @@ -52,6 +52,7 @@ EXPORT_SYMBOL(drm_fb_memcpy);
>> /**
>> * drm_fb_memcpy_dstclip - Copy clip buffer
>> * @dst: Destination buffer (iomem)
>> + * @dst_pitch: Number of bytes between two consecutive scanlines within dst
>> * @vaddr: Source buffer
>> * @fb: DRM framebuffer
>> * @clip: Clip rectangle area to copy
>> @@ -59,12 +60,12 @@ EXPORT_SYMBOL(drm_fb_memcpy);
>> * This function applies clipping on dst, i.e. the destination is a
>> * full (iomem) framebuffer but only the clip rect content is copied over.
>> */
>> -void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
>> - struct drm_framebuffer *fb,
>> +void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch,
>> + void *vaddr, struct drm_framebuffer *fb,
>> struct drm_rect *clip)
>> {
>> unsigned int cpp = fb->format->cpp[0];
>> -unsigned int offset = clip_offset(clip, fb->pitches[0], cpp);
>> +unsigned int offset = clip_offset(clip, dst_pitch, cpp);
>> size_t len = (clip->x2 - clip->x1) * cpp;
>> unsigned int y, lines = clip->y2 - clip->y1;
>>
>> @@ -73,7 +74,7 @@ void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
>> for (y = 0; y < lines; y++) {
>> memcpy_toio(dst, vaddr, len);
>> vaddr += fb->pitches[0];
>> -dst += fb->pitches[0];
>> +dst += dst_pitch;
>> }
>> }
>> EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
>> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> index f16bd278ab7e..7d4f3a62d885 100644
>> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
>> @@ -1586,7 +1586,7 @@ mgag200_handle_damage(struct mga_device *mdev, struct
>> drm_framebuffer *fb,
>> if (drm_WARN_ON(dev, !vmap))
>> return; /* BUG: SHMEM BO should always be vmapped */
>>
>> -drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
>> +drm_fb_memcpy_dstclip(mdev->vram, fb->pitches[0], vmap, fb, clip);
>>
>> drm_gem_shmem_vunmap(fb->obj[0], vmap);
>>
>> diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
>> index 744a8e337e41..2dd9e5e31e3d 100644
>> --- a/drivers/gpu/drm/tiny/cirrus.c
>> +++ b/drivers/gpu/drm/tiny/cirrus.c
>> @@ -327,7 +327,7 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer
>> *fb,
>> goto out_dev_exit;
>>
>> if (cirrus->cpp == fb->format->cpp[0])
>> -drm_fb_memcpy_dstclip(cirrus->vram,
>> +drm_fb_memcpy_dstclip(cirrus->vram, fb->pitches[0],
>>vmap, fb, rect);
>>
>> else if (fb->format->cpp[0] == 4 && cirrus->cpp == 2)
>> diff --git a/include/drm/drm_format_helper.h
>> b/include/drm/drm_format_helper.h
>> index 5f9e37032468..2b5036a5fbe7 100644
>> --- a/include/drm/drm_format_helper.h
>> +++ b/include/drm/drm_format_helper.h
>> @@ -11,7 +11,7 @@ struct drm_rect;
>>
>> void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
>> struct drm_rect *clip);
>> -void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
>> +void drm_fb_memcpy_dstclip(void __iomem *dst, unsigned int dst_pitch, void
>> *vaddr,
>> struct drm_framebuffer *fb,
>> struc
Re: CONFIG_AMDGPU triggers full rebuild
Maybe MMU notifiers? But honestly I don't know for sure. Christian. Am 25.09.20 um 16:29 schrieb Thomas Zimmermann: Hi, whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole kernel. I guess it auto-selects some architecture-specific feature. That full rebuild might be avoidable if I could enable that feature permanently. Any ideas what this could be and how to avoid the full rebuilt? Best regards Thomas ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/radeon: stop using TTMs fault callback
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 22 +++
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 29 ++
3 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 689426dd8480..8c285eb118f9 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -775,7 +775,7 @@ void radeon_bo_move_notify(struct ttm_buffer_object *bo,
radeon_update_memory_usage(rbo, new_mem->mem_type, 1);
}
-int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct ttm_operation_ctx ctx = { false, false };
struct radeon_device *rdev;
@@ -798,7 +798,7 @@ int radeon_bo_fault_reserve_notify(struct ttm_buffer_object
*bo)
/* Can't move a pinned BO to visible VRAM */
if (rbo->tbo.pin_count > 0)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
/* hurrah the memory is not visible ! */
radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_VRAM);
@@ -812,16 +812,20 @@ int radeon_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
r = ttm_bo_validate(bo, &rbo->placement, &ctx);
if (unlikely(r == -ENOMEM)) {
radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_GTT);
- return ttm_bo_validate(bo, &rbo->placement, &ctx);
- } else if (unlikely(r != 0)) {
- return r;
+ r = ttm_bo_validate(bo, &rbo->placement, &ctx);
+ } else if (likely(!r)) {
+ offset = bo->mem.start << PAGE_SHIFT;
+ /* this should never happen */
+ if ((offset + size) > rdev->mc.visible_vram_size)
+ return VM_FAULT_SIGBUS;
}
- offset = bo->mem.start << PAGE_SHIFT;
- /* this should never happen */
- if ((offset + size) > rdev->mc.visible_vram_size)
- return -EINVAL;
+ if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(r))
+ return VM_FAULT_SIGBUS;
+ ttm_bo_move_to_lru_tail_unlocked(bo);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 27cfb64057fe..d606e9a935e3 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -163,7 +163,7 @@ extern int radeon_bo_check_tiling(struct radeon_bo *bo,
bool has_moved,
extern void radeon_bo_move_notify(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *new_mem);
-extern int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
+extern vm_fault_t radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
extern int radeon_bo_get_surface_reg(struct radeon_bo *bo);
extern void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
bool shared);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index df5cedb2b632..63e38b05a5bc 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -803,7 +803,6 @@ static struct ttm_bo_driver radeon_bo_driver = {
.move = &radeon_bo_move,
.verify_access = &radeon_verify_access,
.move_notify = &radeon_bo_move_notify,
- .fault_reserve_notify = &radeon_bo_fault_reserve_notify,
.io_mem_reserve = &radeon_ttm_io_mem_reserve,
};
@@ -904,17 +903,29 @@ void radeon_ttm_set_active_vram_size(struct radeon_device
*rdev, u64 size)
static vm_fault_t radeon_ttm_fault(struct vm_fault *vmf)
{
- struct ttm_buffer_object *bo;
- struct radeon_device *rdev;
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
vm_fault_t ret;
- bo = (struct ttm_buffer_object *)vmf->vma->vm_private_data;
- if (bo == NULL)
- return VM_FAULT_NOPAGE;
-
- rdev = radeon_get_rdev(bo->bdev);
down_read(&rdev->pm.mclk_lock);
- ret = ttm_bo_vm_fault(vmf);
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ goto unlock_mclk;
+
+ ret = radeon_bo_fault_reserve_notify(bo);
+ if (ret)
+ goto unlock_resv;
+
+ ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ goto unlock_mclk;
+
+unlock_resv:
+ dma_resv_unlock(bo->base.resv);
+
+unlock_mclk:
[PATCH 1/5] drm/ttm: move SG flag check into ttm_bo_vm_reserve
Just check earlier if a BO can be page faulted in the first place.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 98a006fc30a5..991ef132e108 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -157,6 +157,15 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
return VM_FAULT_NOPAGE;
}
+ /*
+* Refuse to fault imported pages. This should be handled
+* (if at all) by redirecting mmap to the exporter.
+*/
+ if (bo->ttm && (bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ dma_resv_unlock(bo->base.resv);
+ return VM_FAULT_SIGBUS;
+ }
+
return 0;
}
EXPORT_SYMBOL(ttm_bo_vm_reserve);
@@ -281,13 +290,6 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
vm_fault_t ret = VM_FAULT_NOPAGE;
unsigned long address = vmf->address;
- /*
-* Refuse to fault imported pages. This should be handled
-* (if at all) by redirecting mmap to the exporter.
-*/
- if (bo->ttm && (bo->ttm->page_flags & TTM_PAGE_FLAG_SG))
- return VM_FAULT_SIGBUS;
-
if (bdev->driver->fault_reserve_notify) {
struct dma_fence *moving = dma_fence_get(bo->moving);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/amdgpu: stop using TTMs fault callback
Implement the fault handler ourself using the provided TTM functions.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 40 +++---
3 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 63e9c5793c30..80bc7177cd45 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1341,19 +1341,14 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object
*bo)
* Returns:
* 0 for success or a negative error code on failure.
*/
-int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct ttm_operation_ctx ctx = { false, false };
- struct amdgpu_bo *abo;
+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
unsigned long offset, size;
int r;
- if (!amdgpu_bo_is_amdgpu_bo(bo))
- return 0;
-
- abo = ttm_to_amdgpu_bo(bo);
-
/* Remember that this BO was accessed by the CPU */
abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
@@ -1367,7 +1362,7 @@ int amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
/* Can't move a pinned BO to visible VRAM */
if (abo->tbo.pin_count > 0)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
/* hurrah the memory is not visible ! */
atomic64_inc(&adev->num_vram_cpu_page_faults);
@@ -1379,15 +1374,18 @@ int amdgpu_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
abo->placement.busy_placement = &abo->placements[1];
r = ttm_bo_validate(bo, &abo->placement, &ctx);
- if (unlikely(r != 0))
- return r;
+ if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(r))
+ return VM_FAULT_SIGBUS;
offset = bo->mem.start << PAGE_SHIFT;
/* this should never happen */
if (bo->mem.mem_type == TTM_PL_VRAM &&
(offset + size) > adev->gmc.visible_vram_size)
- return -EINVAL;
+ return VM_FAULT_SIGBUS;
+ ttm_bo_move_to_lru_tail_unlocked(bo);
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index e91750e43448..132e5f955180 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -284,7 +284,7 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *new_mem);
void amdgpu_bo_release_notify(struct ttm_buffer_object *bo);
-int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
+vm_fault_t amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence *fence,
bool shared);
int amdgpu_bo_sync_wait_resv(struct amdgpu_device *adev, struct dma_resv *resv,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d3bd2fd448be..399961035ae6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1708,7 +1708,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.verify_access = &amdgpu_verify_access,
.move_notify = &amdgpu_bo_move_notify,
.release_notify = &amdgpu_bo_release_notify,
- .fault_reserve_notify = &amdgpu_bo_fault_reserve_notify,
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
.access_memory = &amdgpu_ttm_access_memory,
@@ -2088,15 +2087,48 @@ void amdgpu_ttm_set_buffer_funcs_status(struct
amdgpu_device *adev, bool enable)
adev->mman.buffer_funcs_enabled = enable;
}
+static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
+{
+ struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
+ vm_fault_t ret;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_bo_fault_reserve_notify(bo);
+ if (ret)
+ goto unlock;
+
+ ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+ TTM_BO_VM_NUM_PREFAULT, 1);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ return ret;
+
+unlock:
+ dma_resv_unlock(bo->base.resv);
+ return ret;
+}
+
+static struct vm_operations_struct amdgpu_ttm_vm_ops = {
+ .fault = amdgpu_ttm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_close,
+ .access = ttm_bo_vm_access
+};
+
int amdgpu_mmap(s
[PATCH 5/5] drm/ttm: remove fault callback
Another one bites the dust.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 --
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 991ef132e108..87ee8f0ca08e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -290,28 +290,6 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
vm_fault_t ret = VM_FAULT_NOPAGE;
unsigned long address = vmf->address;
- if (bdev->driver->fault_reserve_notify) {
- struct dma_fence *moving = dma_fence_get(bo->moving);
-
- err = bdev->driver->fault_reserve_notify(bo);
- switch (err) {
- case 0:
- break;
- case -EBUSY:
- case -ERESTARTSYS:
- dma_fence_put(moving);
- return VM_FAULT_NOPAGE;
- default:
- dma_fence_put(moving);
- return VM_FAULT_SIGBUS;
- }
-
- if (bo->moving != moving) {
- ttm_bo_move_to_lru_tail_unlocked(bo);
- }
- dma_fence_put(moving);
- }
-
/*
* Wait for buffer data in transit, due to a pipelined
* move.
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 864afa8f6f18..9897a16c0a9d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -190,9 +190,6 @@ struct ttm_bo_driver {
void (*move_notify)(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *new_mem);
- /* notify the driver we are taking a fault on this BO
-* and have reserved it */
- int (*fault_reserve_notify)(struct ttm_buffer_object *bo);
/**
* notify the driver that we're about to swap out this bo
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/nouveau: stop using TTMs fault callback
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 50 ++-
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++---
3 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8d51cfca07c8..1d4b16c0e353 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1226,8 +1226,7 @@ nouveau_ttm_io_mem_free(struct ttm_bo_device *bdev,
struct ttm_resource *reg)
mutex_unlock(&drm->ttm.io_reserve_mutex);
}
-static int
-nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
+vm_fault_t nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
{
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct nouveau_bo *nvbo = nouveau_bo(bo);
@@ -1243,34 +1242,38 @@ nouveau_ttm_fault_reserve_notify(struct
ttm_buffer_object *bo)
!nvbo->kind)
return 0;
- if (bo->mem.mem_type == TTM_PL_SYSTEM) {
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_GART,
-0);
+ if (bo->mem.mem_type != TTM_PL_SYSTEM)
+ return 0;
+
+ nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_GART, 0);
+
+ } else {
+ /* make sure bo is in mappable vram */
+ if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
+ bo->mem.start + bo->mem.num_pages < mappable)
+ return 0;
- ret = nouveau_bo_validate(nvbo, false, false);
- if (ret)
- return ret;
+ for (i = 0; i < nvbo->placement.num_placement; ++i) {
+ nvbo->placements[i].fpfn = 0;
+ nvbo->placements[i].lpfn = mappable;
}
- return 0;
- }
- /* make sure bo is in mappable vram */
- if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
- bo->mem.start + bo->mem.num_pages < mappable)
- return 0;
+ for (i = 0; i < nvbo->placement.num_busy_placement; ++i) {
+ nvbo->busy_placements[i].fpfn = 0;
+ nvbo->busy_placements[i].lpfn = mappable;
+ }
- for (i = 0; i < nvbo->placement.num_placement; ++i) {
- nvbo->placements[i].fpfn = 0;
- nvbo->placements[i].lpfn = mappable;
+ nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_VRAM, 0);
}
- for (i = 0; i < nvbo->placement.num_busy_placement; ++i) {
- nvbo->busy_placements[i].fpfn = 0;
- nvbo->busy_placements[i].lpfn = mappable;
- }
+ ret = nouveau_bo_validate(nvbo, false, false);
+ if (unlikely(ret == -EBUSY || ret == -ERESTARTSYS))
+ return VM_FAULT_NOPAGE;
+ else if (unlikely(ret))
+ return VM_FAULT_SIGBUS;
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_VRAM, 0);
- return nouveau_bo_validate(nvbo, false, false);
+ ttm_bo_move_to_lru_tail_unlocked(bo);
+ return 0;
}
static int
@@ -1381,7 +1384,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
.move_notify = nouveau_bo_move_ntfy,
.move = nouveau_bo_move,
.verify_access = nouveau_bo_verify_access,
- .fault_reserve_notify = &nouveau_ttm_fault_reserve_notify,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index ff68ded8d590..641ef6298a0e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -89,6 +89,7 @@ void nouveau_bo_placement_set(struct nouveau_bo *, u32 type,
u32 busy);
void nouveau_bo_wr16(struct nouveau_bo *, unsigned index, u16 val);
u32 nouveau_bo_rd32(struct nouveau_bo *, unsigned index);
void nouveau_bo_wr32(struct nouveau_bo *, unsigned index, u32 val);
+vm_fault_t nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo);
void nouveau_bo_fence(struct nouveau_bo *, struct nouveau_fence *, bool
exclusive);
int nouveau_bo_validate(struct nouveau_bo *, bool interruptible,
bool no_wait_gpu);
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 427341753441..edf3bb89a47f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -134,17 +134,19 @@ static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
if (ret)
return ret;
- nouveau_bo_del_io_reserve_lru(bo);
+ ret = nouveau_ttm_f
Re: [PATCH 3/9] drm: Add simplekms driver
Hi Daniel
Am 29.06.20 um 11:06 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:05PM +0200, Thomas Zimmermann wrote:
>> The simplekms driver is a DRM driver for simplefb framebuffers as
>> provided by the kernel's boot code. This driver enables basic
>> graphical output on many different graphics devices that are provided
>> by the platform (e.g., EFI, VESA, embedded framebuffers).
>>
>> With the kernel's simplefb infrastructure, the kernel receives a
>> pre-configured framebuffer from the system (i.e., firmware, boot
>> loader). It creates a platform device to which simplekms attaches.
>> The system's framebuffer consists of a memory range, size and format.
>> Based on these values, simplekms creates a DRM devices. No actual
>> modesetting is possible.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> MAINTAINERS | 6 +
>> drivers/gpu/drm/tiny/Kconfig | 16 +
>> drivers/gpu/drm/tiny/Makefile| 1 +
>> drivers/gpu/drm/tiny/simplekms.c | 495 +++
>> 4 files changed, 518 insertions(+)
>> create mode 100644 drivers/gpu/drm/tiny/simplekms.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index f17d99164a77..ac517dc8d05d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -5505,6 +5505,12 @@ S:Orphan / Obsolete
>> F: drivers/gpu/drm/savage/
>> F: include/uapi/drm/savage_drm.h
>>
>> +DRM DRIVER FOR SIMPLE FRAMEBUFFERS
>> +M: Thomas Zimmermann
>> +S: Maintained
>> +T: git git://anongit.freedesktop.org/drm/drm-misc
>> +F: drivers/gpu/drm/tiny/simplekms.c
>> +
>> DRM DRIVER FOR SIS VIDEO CARDS
>> S: Orphan / Obsolete
>> F: drivers/gpu/drm/sis/
>> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
>> index 2b6414f0fa75..50dbde8bdcb2 100644
>> --- a/drivers/gpu/drm/tiny/Kconfig
>> +++ b/drivers/gpu/drm/tiny/Kconfig
>> @@ -28,6 +28,22 @@ config DRM_GM12U320
>> This is a KMS driver for projectors which use the GM12U320 chipset
>> for video transfer over USB2/3, such as the Acer C120 mini projector.
>>
>> +config DRM_SIMPLEKMS
>> +tristate "Simple framebuffer driver"
>> +depends on DRM
>> +select DRM_GEM_SHMEM_HELPER
>> +select DRM_KMS_HELPER
>> +help
>> + DRM driver for simple platform-provided framebuffers.
>> +
>> + This driver assumes that the display hardware has been initialized
>> + by the firmware or bootloader before the kernel boots. Scanout
>> + buffer, size, and display format must be provided via device tree,
>> + UEFI, VESA, etc.
>> +
>> + On x86 and compatible, you should also select CONFIG_X86_SYSFB to
>> + use UEFI and VESA framebuffers.
>> +
>> config TINYDRM_HX8357D
>> tristate "DRM support for HX8357D display panels"
>> depends on DRM && SPI
>> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
>> index 6ae4e9e5a35f..e83fbbfa7344 100644
>> --- a/drivers/gpu/drm/tiny/Makefile
>> +++ b/drivers/gpu/drm/tiny/Makefile
>> @@ -2,6 +2,7 @@
>>
>> obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
>> obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
>> +obj-$(CONFIG_DRM_SIMPLEKMS) += simplekms.o
>> obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
>> obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
>> obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
>> diff --git a/drivers/gpu/drm/tiny/simplekms.c
>> b/drivers/gpu/drm/tiny/simplekms.c
>> new file mode 100644
>> index ..dc7cf3983945
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tiny/simplekms.c
>> @@ -0,0 +1,495 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRIVER_NAME "simplekms"
>> +#define DRIVER_DESC "DRM driver for simple-framebuffer platform devices"
>> +#define DRIVER_DATE "20200625"
>> +#define DRIVER_MAJOR1
>> +#define DRIVER_MINOR0
>> +
>> +/*
>> + * Assume a monitor resolution of 96 dpi to
>> + * get a somewhat reasonable screen size.
>> + */
>> +#define RES_MM(d) \
>> +(((d) * 254ul) / (96ul * 10ul))
>> +
>> +#define SIMPLEKMS_MODE(hd, vd) \
>> +DRM_SIMPLE_MODE(hd, vd, RES_MM(hd), RES_MM(vd))
>> +
>> +/*
>> + * Helpers for simplefb
>> + */
>> +
>> +static int
>> +simplefb_get_validated_int(struct drm_device *dev, const char *name,
>> + uint32_t value)
>> +{
>> +if (value > INT_MAX) {
>> +drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
>> +name, value);
>> +return -EINVAL;
>> +}
>> +return (int)value;
>> +}
>> +
>> +static int
>> +simplefb_get_validated_int0(struct drm_device *dev, const char *name,
>> +uint32_t value)
>> +{
>> +if (!value) {
>> +drm_err(dev, "simplefb: invalid framebuffer %s of %u\n",
>> +
Re: CONFIG_AMDGPU triggers full rebuild
Hi Christian Am 25.09.20 um 16:54 schrieb Christian König: > Maybe MMU notifiers? But honestly I don't know for sure. I checked. In my current config MMU_NOTIFIERS is y and DRM_AMDGPU is n. So it shouldn't have triggered the rebuilds, I guess. Anyway, thanks for trying to help. Best regards Thomas > > Christian. > > Am 25.09.20 um 16:29 schrieb Thomas Zimmermann: >> Hi, >> >> whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole >> kernel. I guess it auto-selects some architecture-specific feature. That >> full rebuild might be avoidable if I could enable that feature permanently. >> >> Any ideas what this could be and how to avoid the full rebuilt? >> >> Best regards >> Thomas >> >> >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > -- 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][next] drm/i915: Fix inconsistent IS_ERR and PTR_ERR
Hi all,
Friendly ping: who can take this?
Thanks
--
Gustavo
On 9/10/20 05:21, Gustavo A. R. Silva wrote:
> Fix inconsistent IS_ERR and PTR_ERR in i915_gem_object_copy_blt().
>
> The proper pointer to be passed as argument to PTR_ERR() is vma[1].
>
> This bug was detected with the help of Coccinelle.
>
> Fixes: 6b05030496f7 ("drm/i915: Convert i915_gem_object/client_blt.c to use
> ww locking as well, v2.")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> index d93eb36160c9..aee7ad3cc3c6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> @@ -364,7 +364,7 @@ int i915_gem_object_copy_blt(struct drm_i915_gem_object
> *src,
>
> vma[1] = i915_vma_instance(dst, vm, NULL);
> if (IS_ERR(vma[1]))
> - return PTR_ERR(vma);
> + return PTR_ERR(vma[1]);
>
> i915_gem_ww_ctx_init(&ww, true);
> intel_engine_pm_get(ce->engine);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
