Re: [PATCH] drm/i915: check to see if the FPU is available before using it
On Sat, Mar 28, 2020 at 1:59 AM Chris Wilson wrote: > > Quoting Jason A. Donenfeld (2020-03-28 00:04:22) > > It's not safe to just grab the FPU willy nilly without first checking to > > see if it's available. This patch adds the usual call to may_use_simd() > > and falls back to boring memcpy if it's not available. > > These instructions do not use the fpu, nor are these registers aliased > over the fpu stack. This description and the may_use_simd() do not > look like they express the right granularity as to which simd state are > included Most of the time when discussing vector instructions in the kernel with x86, "FPU" is used to denote the whole shebang, because of similar XSAVE semantics and requirements with actual floating point instructions and SIMD instructions. So when I say "grab the FPU", I'm really referring to the act of messing with any registers that aren't saved and restored by default during context switch and need the explicit marking for XSAVE to come in -- the kernel_fpu_begin/end calls that you already have. With regards to the granularity here, you are in fact touching xmm registers. That means you need kernel_fpu_begin/end, which you correctly have. However, it also means that before using those, you should check to see if that's okay by using the may_use_simd() instruction. Now you may claim that at the moment may_use_simd()-->irq_fpu_usable()-->(!in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle()) always holds true, and you're a keen follower of the (recently changed) kernel fpu x86 semantics in case those conditions change, and that your driver is so strictly written that you know exactly the context this fancy memcpy will run in, always, and you'll never deviate from it, and therefore it's okay to depart from the rules and omit the check and safe fallback code. But c'mon - i915 is complex, and mixed context bugs abound, and the rules for using those registers might in fact change without you noticing. So why not apply this to have a safe fallback for when the numerous assumptions no longer hold? (If you're extra worried I suppose you could make it a `if (WARN_ON(!may_use_simd()))` instead or something, but that seems like a bit much.) > Look at caller, return the error and let them decide if they can avoid > the read from WC, which quite often they can. And no, this is not done > from interrupt context, we would be crucified if we did. Ahh, now, reading this comment here I realize maybe I've misunderstood you. Do you mean to say that checking for may_use_simd() is a thing that you'd like to do after all, but you don't like it falling back to slow memcpy. Instead, you'd like for the code to return an error value, and then caller can just optionally skip the memcpy under some complicated driver circumstances? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 4/4] backlight: qcom-wled: Add support for WLED5 peripheral that is present on PM8150L PMICs
From: Subbaraman Narayanamurthy
PM8150L WLED supports the following:
- Two modulators and each sink can use any of the modulator
- Multiple CABC selection options from which one can be selected/enabled
- Multiple brightness width selection (12 bits to 15 bits)
Signed-off-by: Subbaraman Narayanamurthy
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 443 +++-
1 file changed, 442 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index a6ddaa9..3a57011 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -19,12 +19,15 @@
#define WLED_DEFAULT_BRIGHTNESS2048
#define WLED_SOFT_START_DLY_US 1
#define WLED3_SINK_REG_BRIGHT_MAX 0xFFF
+#define WLED5_SINK_REG_BRIGHT_MAX_12B 0xFFF
+#define WLED5_SINK_REG_BRIGHT_MAX_15B 0x7FFF
/* WLED3/WLED4 control registers */
#define WLED3_CTRL_REG_FAULT_STATUS0x08
#define WLED3_CTRL_REG_ILIM_FAULT_BIT BIT(0)
#define WLED3_CTRL_REG_OVP_FAULT_BIT BIT(1)
#define WLED4_CTRL_REG_SC_FAULT_BIT BIT(2)
+#define WLED5_CTRL_REG_OVP_PRE_ALARM_BIT BIT(4)
#define WLED3_CTRL_REG_INT_RT_STS 0x10
#define WLED3_CTRL_REG_OVP_FAULT_STATUS BIT(1)
@@ -40,6 +43,7 @@
#define WLED3_CTRL_REG_OVP 0x4d
#define WLED3_CTRL_REG_OVP_MASK GENMASK(1, 0)
+#define WLED5_CTRL_REG_OVP_MASK GENMASK(3, 0)
#define WLED3_CTRL_REG_ILIMIT 0x4e
#define WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)
@@ -101,6 +105,44 @@
#define WLED4_SINK_REG_BRIGHT(n) (0x57 + (n * 0x10))
+/* WLED5 specific control registers */
+#define WLED5_CTRL_REG_OVP_INT_CTL 0x5f
+#define WLED5_CTRL_REG_OVP_INT_TIMER_MASK GENMASK(2, 0)
+
+/* WLED5 specific sink registers */
+#define WLED5_SINK_REG_MOD_A_EN0x50
+#define WLED5_SINK_REG_MOD_B_EN0x60
+#define WLED5_SINK_REG_MOD_EN_MASKBIT(7)
+
+#define WLED5_SINK_REG_MOD_A_SRC_SEL 0x51
+#define WLED5_SINK_REG_MOD_B_SRC_SEL 0x61
+#define WLED5_SINK_REG_MOD_SRC_SEL_HIGH 0
+#define WLED5_SINK_REG_MOD_SRC_SEL_EXT0x03
+#define WLED5_SINK_REG_MOD_SRC_SEL_MASK GENMASK(1, 0)
+
+#define WLED5_SINK_REG_MOD_A_BRIGHTNESS_WIDTH_SEL 0x52
+#define WLED5_SINK_REG_MOD_B_BRIGHTNESS_WIDTH_SEL 0x62
+#define WLED5_SINK_REG_BRIGHTNESS_WIDTH_12B 0
+#define WLED5_SINK_REG_BRIGHTNESS_WIDTH_15B 1
+
+#define WLED5_SINK_REG_MOD_A_BRIGHTNESS_LSB0x53
+#define WLED5_SINK_REG_MOD_A_BRIGHTNESS_MSB0x54
+#define WLED5_SINK_REG_MOD_B_BRIGHTNESS_LSB0x63
+#define WLED5_SINK_REG_MOD_B_BRIGHTNESS_MSB0x64
+
+#define WLED5_SINK_REG_MOD_SYNC_BIT0x65
+#define WLED5_SINK_REG_SYNC_MOD_A_BIT BIT(0)
+#define WLED5_SINK_REG_SYNC_MOD_B_BIT BIT(1)
+#define WLED5_SINK_REG_SYNC_MASK GENMASK(1, 0)
+
+/* WLED5 specific per-'string' registers below */
+#define WLED5_SINK_REG_STR_FULL_SCALE_CURR(n) (0x72 + (n * 0x10))
+
+#define WLED5_SINK_REG_STR_SRC_SEL(n) (0x73 + (n * 0x10))
+#define WLED5_SINK_REG_SRC_SEL_MOD_A 0
+#define WLED5_SINK_REG_SRC_SEL_MOD_B 1
+#define WLED5_SINK_REG_SRC_SEL_MASK GENMASK(1, 0)
+
struct wled_var_cfg {
const u32 *values;
u32 (*fn)(u32);
@@ -125,6 +167,8 @@ struct wled_config {
u32 num_strings;
u32 string_i_limit;
u32 enabled_strings[WLED_MAX_STRINGS];
+ u32 mod_sel;
+ u32 cabc_sel;
bool cs_out_en;
bool ext_gen;
bool cabc;
@@ -150,6 +194,7 @@ struct wled {
u32 version;
bool disabled_by_short;
bool has_short_detect;
+ bool cabc_disabled;
int short_irq;
int ovp_irq;
@@ -184,6 +229,27 @@ struct wled {
bool (*wled_auto_detection_required)(struct wled *wled);
};
+enum wled5_mod_sel {
+ MOD_A,
+ MOD_B,
+ MOD_MAX,
+};
+
+static const u8 wled5_brightness_reg[MOD_MAX] = {
+ [MOD_A] = WLED5_SINK_REG_MOD_A_BRIGHTNESS_LSB,
+ [MOD_B] = WLED5_SINK_REG_MOD_B_BRIGHTNESS_LSB,
+};
+
+static const u8 wled5_src_sel_reg[MOD_MAX] = {
+ [MOD_A] = WLED5_SINK_REG_MOD_A_SRC_SEL,
+ [MOD_B] = WLED5_SINK_REG_MOD_B_SRC_SEL,
+};
+
+static const u8 wled5_brt_wid_sel_reg[MOD_MAX] = {
+ [MOD_A] = WLED5_SINK_REG_MOD_A_BRIGHTNESS_WIDTH_SEL,
+ [MOD_B] = WLED5_SINK_REG_MOD_B_BRIGHTNE
[PATCH V5 0/4] Add support for WLED5
Currently, WLED driver supports only WLED4 peripherals that is present on pmi8998 and pm660L. This patch series converts the existing WLED4 bindings from .txt to .yaml format and adds the support for WLED5 peripheral that is present on PM8150L. PM8150L WLED supports the following. - Two modulators and each sink can use any of the modulator - Multiple CABC selection options - Multiple brightness width selection (12 bits to 15 bits) Changes from V1: - Rebased on top of the below commit. backlight: qcom-wled: Fix unsigned comparison to zero Changes from V2: - Addressed Bjorn's comments by splitting the WLED4 changes in a seperate patch. - Added WLED5 auto calibration support Changes from V3: - Addressed comments from Daniel Thompson and Rob Herring - Seperated the WLED5 bindings from the driver changes - Squashed wled5 auto string detection and wled5 basic changes to avoid the NULL callback function pointer issue. Changes from V4: - Addressed the yaml formatting comments from Rob Herring. - Addressed the comments from Daniel Thompson on the below patch "backlight: qcom-wled: Add callback functions" Kiran Gunda (3): backlight: qcom-wled: convert the wled bindings to .yaml format backlight: qcom-wled: Add callback functions backlight: qcom-wled: Add WLED5 bindings Subbaraman Narayanamurthy (1): backlight: qcom-wled: Add support for WLED5 peripheral that is present on PM8150L PMICs .../bindings/leds/backlight/qcom-wled.txt | 154 - .../bindings/leds/backlight/qcom-wled.yaml | 255 drivers/video/backlight/qcom-wled.c| 659 ++--- 3 files changed, 841 insertions(+), 227 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 3/4] backlight: qcom-wled: Add WLED5 bindings
Add WLED5 specific bindings. Signed-off-by: Kiran Gunda Signed-off-by: Subbaraman Narayanamurthy --- .../bindings/leds/backlight/qcom-wled.yaml | 60 -- 1 file changed, 57 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index 770e780..5714631 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -21,6 +21,7 @@ properties: - qcom,pm8941-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm8150l-wled reg: maxItems: 1 @@ -28,12 +29,13 @@ properties: default-brightness: description: brightness value on boot. -minimum: 0 -maximum: 4095 -default: 2048 label: true + max-brightness: +description: + Maximum brightness level. + qcom,cs-out: description: enable current sink output. @@ -130,6 +132,31 @@ properties: This feature is not supported for WLED3. type: boolean + qcom,modulator-sel: +description: + Selects the modulator used for brightness modulation. + Allowed values are, + 0 - Modulator A + 1 - Modulator B + This property is applicable only to WLED5 peripheral. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 0, 1 ] + - default: 0 + + qcom,cabc-sel: +description: + Selects the CABC pin signal used for brightness modulation. + Allowed values are, + 0 - CABC disabled + 1 - CABC 1 + 2 - CABC 2 + 3 - External signal (e.g. LPG) is used for dimming + This property is applicable only to WLED5 peripheral. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 0, 1, 2, 3 ] + allOf: - if: properties: @@ -179,6 +206,33 @@ allOf: - const: ovp - const: short + - if: + properties: +compatible: + contains: +enum: + - qcom,pm8150l-wled + +then: + properties: +default-brightness: + minimum: 0 + maximum: 32767 + +max-brightness: + minimum: 0 + maximum: 32767 + +else: + properties: +default-brightness: +minimum: 0 +maximum: 4095 + +max-brightness: + minimum: 0 + maximum: 4095 + required: - compatible - reg -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 2/4] backlight: qcom-wled: Add callback functions
Add wled_cabc_config, wled_sync_toggle, wled_ovp_fault_status
and wled_ovp_delay and wled_auto_detection_required callback
functions to prepare the driver for adding WLED5 support.
Signed-off-by: Kiran Gunda
Signed-off-by: Subbaraman Narayanamurthy
---
drivers/video/backlight/qcom-wled.c | 216
1 file changed, 144 insertions(+), 72 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 3d276b3..a6ddaa9 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -147,6 +147,7 @@ struct wled {
u32 max_brightness;
u32 short_count;
u32 auto_detect_count;
+ u32 version;
bool disabled_by_short;
bool has_short_detect;
int short_irq;
@@ -154,7 +155,33 @@ struct wled {
struct wled_config cfg;
struct delayed_work ovp_work;
+
+ /* Configures the brightness. Applicable for wled3, wled4 and wled5 */
int (*wled_set_brightness)(struct wled *wled, u16 brightness);
+
+ /* Configures the cabc register. Applicable for wled4 and wled5 */
+ int (*wled_cabc_config)(struct wled *wled, bool enable);
+
+ /*
+* Toggles the sync bit for the brightness update to take place.
+* Applicable for WLED3, WLED4 and WLED5.
+*/
+ int (*wled_sync_toggle)(struct wled *wled);
+
+ /* Determines OVP fault status. Applicable for WLED4 and WLED5 */
+ int (*wled_ovp_fault_status)(struct wled *wled, bool *fault_set);
+
+ /*
+* Time to wait before checking the OVP status after wled module enable.
+* Applicable for WLED4 and WLED5.
+*/
+ int (*wled_ovp_delay)(struct wled *wled);
+
+ /*
+* Determines if the auto string detection is required.
+* Applicable for WLED4 and WLED5
+*/
+ bool (*wled_auto_detection_required)(struct wled *wled);
};
static int wled3_set_brightness(struct wled *wled, u16 brightness)
@@ -237,7 +264,7 @@ static int wled_module_enable(struct wled *wled, int val)
return 0;
}
-static int wled_sync_toggle(struct wled *wled)
+static int wled3_sync_toggle(struct wled *wled)
{
int rc;
unsigned int mask = GENMASK(wled->max_string_count - 1, 0);
@@ -255,6 +282,46 @@ static int wled_sync_toggle(struct wled *wled)
return rc;
}
+static int wled4_ovp_fault_status(struct wled *wled, bool *fault_set)
+{
+ int rc;
+ u32 int_rt_sts, fault_sts;
+
+ *fault_set = false;
+ rc = regmap_read(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS,
+ &int_rt_sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to read INT_RT_STS rc=%d\n", rc);
+ return rc;
+ }
+
+ rc = regmap_read(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_FAULT_STATUS,
+ &fault_sts);
+ if (rc < 0) {
+ dev_err(wled->dev, "Failed to read FAULT_STATUS rc=%d\n", rc);
+ return rc;
+ }
+
+ if (int_rt_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
+ *fault_set = true;
+
+ if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT)
+ *fault_set = true;
+
+ if (*fault_set)
+ dev_dbg(wled->dev, "WLED OVP fault detected, int_rt_sts=0x%x
fault_sts=0x%x\n",
+ int_rt_sts, fault_sts);
+
+ return rc;
+}
+
+static int wled4_ovp_delay(struct wled *wled)
+{
+ return WLED_SOFT_START_DLY_US;
+}
+
static int wled_update_status(struct backlight_device *bl)
{
struct wled *wled = bl_get_data(bl);
@@ -275,7 +342,7 @@ static int wled_update_status(struct backlight_device *bl)
goto unlock_mutex;
}
- rc = wled_sync_toggle(wled);
+ rc = wled->wled_sync_toggle(wled);
if (rc < 0) {
dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
goto unlock_mutex;
@@ -298,6 +365,25 @@ static int wled_update_status(struct backlight_device *bl)
return rc;
}
+static int wled4_cabc_config(struct wled *wled, bool enable)
+{
+ int i, j, rc;
+ u8 val;
+
+ for (i = 0; i < wled->cfg.num_strings; i++) {
+ j = wled->cfg.enabled_strings[i];
+
+ val = enable ? WLED4_SINK_REG_STR_CABC_MASK : 0;
+ rc = regmap_update_bits(wled->regmap, wled->sink_addr +
+ WLED4_SINK_REG_STR_CABC(j),
+ WLED4_SINK_REG_STR_CABC_MASK, val);
+ if (rc < 0)
+ return rc;
+ }
+
+ return 0;
+}
+
#define WLED_SHORT_DLY_MS 20
#define WLED_SHORT_CNT_MAX 5
#define WLED_SHORT_RESET_CNT_DLY_USUSEC_PER_SEC
@@ -345,9 +431,10 @@ static irqret
[RESEND] drm: bridge: adv7511: Fix low refresh rate register for ADV7533/5
For ADV7533 and ADV7535 low refresh rate is selected using
bits [3:2] of 0x4a main register.
So depending on ADV model write 0xfb or 0x4a register.
Fixes: 9c8af882bf12: ("drm: Add adv7511 encoder driver")
Signed-off-by: Bogdan Togorean
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 87b58c1acff4..2a8fd2b27f0d 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -756,8 +756,13 @@ static void adv7511_mode_set(struct adv7511 *adv7511,
else
low_refresh_rate = ADV7511_LOW_REFRESH_RATE_NONE;
- regmap_update_bits(adv7511->regmap, 0xfb,
- 0x6, low_refresh_rate << 1);
+ if (adv7511->type == ADV7511)
+ regmap_update_bits(adv7511->regmap, 0xfb,
+ 0x6, low_refresh_rate << 1);
+ else
+ regmap_update_bits(adv7511->regmap, 0x4a,
+ 0xc, low_refresh_rate << 2);
+
regmap_update_bits(adv7511->regmap, 0x17,
0x60, (vsync_polarity << 6) | (hsync_polarity << 5));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 1/2] drm: bridge: adv7511: Enable SPDIF DAI
ADV7511 support I2S or SPDIF as audio input interfaces. This commit
enable support for SPDIF.
Signed-off-by: Bogdan Togorean
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
index a428185be2c1..1e9b128d229b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -119,6 +119,9 @@ int adv7511_hdmi_hw_params(struct device *dev, void *data,
audio_source = ADV7511_AUDIO_SOURCE_I2S;
i2s_format = ADV7511_I2S_FORMAT_LEFT_J;
break;
+ case HDMI_SPDIF:
+ audio_source = ADV7511_AUDIO_SOURCE_SPDIF;
+ break;
default:
return -EINVAL;
}
@@ -175,11 +178,21 @@ static int audio_startup(struct device *dev, void *data)
/* use Audio infoframe updated info */
regmap_update_bits(adv7511->regmap, ADV7511_REG_GC(1),
BIT(5), 0);
+ /* enable SPDIF receiver */
+ if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF)
+ regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG,
+ BIT(7), BIT(7));
+
return 0;
}
static void audio_shutdown(struct device *dev, void *data)
{
+ struct adv7511 *adv7511 = dev_get_drvdata(dev);
+
+ if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF)
+ regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG,
+ BIT(7), 0);
}
static int adv7511_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
@@ -213,6 +226,7 @@ static const struct hdmi_codec_pdata codec_data = {
.ops = &adv7511_codec_ops,
.max_i2s_channels = 2,
.i2s = 1,
+ .spdif = 1,
};
int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Force DPCD backlight mode for HP CML 2020 system
There's another Samsung OLED panel needs to use DPCD aux interface to
control backlight.
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c6fbe6e6bc9d..d0cfee3b7a65 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1299,6 +1299,8 @@ static const struct edid_quirk edid_quirk_list[] = {
* only supports DPCD backlight controls
*/
{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
+ /* HP CML 2020 system */
+ { MFG(0x4c, 0x83), PROD_ID(0x45, 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
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/44] drm/device: Deprecate dev_private harder
On Fri, Apr 03, 2020 at 03:57:47PM +0200, Daniel Vetter wrote:
> We've had lots of conversions to embeddeding, but didn't stop using
> ->dev_private. Which defeats the point of this.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
> ---
> include/drm/drm_device.h | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index d39132b477dd..a55874db9dd4 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -88,9 +88,12 @@ struct drm_device {
> /**
>* @dev_private:
>*
> - * DRM driver private data. Instead of using this pointer it is
> - * recommended that drivers use drm_dev_init() and embed struct
> - * &drm_device in their larger per-device structure.
> + * DRM driver private data. This is deprecated and should be left set to
> + * NULL.
> + *
> + * Instead of using this pointer it is recommended that drivers use
> + * drm_dev_init() and embed struct &drm_device in their larger
> + * per-device structure.
>*/
> void *dev_private;
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/44] drm/vboxvideo: drop DRM_MTRR_WC #define
On Fri, Apr 03, 2020 at 03:57:50PM +0200, Daniel Vetter wrote:
> Doesn't apply to upstream kernels since a rather long time.
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/vboxvideo/vbox_ttm.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> index 976423d0c3cc..f5a06675da43 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> @@ -24,25 +24,13 @@ int vbox_mm_init(struct vbox_private *vbox)
> return ret;
> }
>
> -#ifdef DRM_MTRR_WC
> - vbox->fb_mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 0),
> - pci_resource_len(dev->pdev, 0),
> - DRM_MTRR_WC);
> -#else
> vbox->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
>pci_resource_len(dev->pdev, 0));
> -#endif
> return 0;
> }
>
> void vbox_mm_fini(struct vbox_private *vbox)
> {
> -#ifdef DRM_MTRR_WC
> - drm_mtrr_del(vbox->fb_mtrr,
> - pci_resource_start(vbox->ddev.pdev, 0),
> - pci_resource_len(vbox->ddev.pdev, 0), DRM_MTRR_WC);
> -#else
> arch_phys_wc_del(vbox->fb_mtrr);
> -#endif
> drm_vram_helper_release_mm(&vbox->ddev);
> }
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Bad rss-counter state from drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
Excerpts from Thomas Hellström (VMware)'s message of April 7, 2020 7:26 am: > On 4/7/20 2:38 AM, Alex Xu (Hello71) wrote: >> Excerpts from Thomas Hellström (VMware)'s message of April 6, 2020 5:04 pm: >>> Hi, >>> >>> On 4/6/20 9:51 PM, Alex Xu (Hello71) wrote: Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to start filling dmesg, and then closing programs causes more BUGs and hangs, and then everything grinds to a halt (can't start more programs, can't even reboot through systemd). Using master and reverting that branch up to that point fixes the problem. I'm using a Ryzen 1600 and AMD Radeon RX 480 on an ASRock B450 Pro4 board with IOMMU enabled. >>> If you could try the attached patch, that'd be great! >>> >>> Thanks, >>> >>> Thomas >>> >> Yeah, that works too. Kernel config sent off-list. >> >> Regards, >> Alex. > > Thanks. Do you want me to add your > > Reported-by: and Tested-by: To this patch? > > /Thomas > > Sure. Shouldn't we fix it properly though? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/44] drm/vboxvideo: Stop using drm_device->dev_private
On Fri, Apr 03, 2020 at 03:57:52PM +0200, Daniel Vetter wrote:
> We use the baseclass pattern here, so lets to the proper (and more
> typesafe) upcasting.
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
Acked-by: Sam Ravnborg
As for naming discussed in other mail I had gone for
to_vbox() - as we name the variable assinged vbox whereever we use it.
But no strong feeling as long as we get away from dev_private
and are consistent.
Sam
> ---
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 -
> drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 +
> drivers/gpu/drm/vboxvideo/vbox_irq.c | 2 +-
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 10 +-
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> index be0600b22cf5..d34cddd809fd 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -52,7 +52,6 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> return PTR_ERR(vbox);
>
> vbox->ddev.pdev = pdev;
> - vbox->ddev.dev_private = vbox;
> pci_set_drvdata(pdev, vbox);
> mutex_init(&vbox->hw_mutex);
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
> b/drivers/gpu/drm/vboxvideo/vbox_drv.h
> index 87421903816c..ac7c2effc46f 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
> @@ -127,6 +127,7 @@ struct vbox_encoder {
> #define to_vbox_crtc(x) container_of(x, struct vbox_crtc, base)
> #define to_vbox_connector(x) container_of(x, struct vbox_connector, base)
> #define to_vbox_encoder(x) container_of(x, struct vbox_encoder, base)
> +#define to_vbox_dev(x) container_of(x, struct vbox_private, ddev)
>
> bool vbox_check_supported(u16 id);
> int vbox_hw_init(struct vbox_private *vbox);
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_irq.c
> b/drivers/gpu/drm/vboxvideo/vbox_irq.c
> index 16a1e29f5292..631657fa554f 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_irq.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_irq.c
> @@ -34,7 +34,7 @@ void vbox_report_hotplug(struct vbox_private *vbox)
> irqreturn_t vbox_irq_handler(int irq, void *arg)
> {
> struct drm_device *dev = (struct drm_device *)arg;
> - struct vbox_private *vbox = (struct vbox_private *)dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(dev);
> u32 host_flags = vbox_get_flags(vbox);
>
> if (!(host_flags & HGSMIHOSTFLAGS_IRQ))
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> index 0883a435e62b..d9a5af62af89 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> @@ -36,7 +36,7 @@ static void vbox_do_modeset(struct drm_crtc *crtc)
> u16 flags;
> s32 x_offset, y_offset;
>
> - vbox = crtc->dev->dev_private;
> + vbox = to_vbox_dev(crtc->dev);
> width = vbox_crtc->width ? vbox_crtc->width : 640;
> height = vbox_crtc->height ? vbox_crtc->height : 480;
> bpp = fb ? fb->format->cpp[0] * 8 : 32;
> @@ -77,7 +77,7 @@ static void vbox_do_modeset(struct drm_crtc *crtc)
> static int vbox_set_view(struct drm_crtc *crtc)
> {
> struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
> - struct vbox_private *vbox = crtc->dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(crtc->dev);
> struct vbva_infoview *p;
>
> /*
> @@ -174,7 +174,7 @@ static void vbox_crtc_set_base_and_mode(struct drm_crtc
> *crtc,
> int x, int y)
> {
> struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
> - struct vbox_private *vbox = crtc->dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(crtc->dev);
> struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
> bool needs_modeset = drm_atomic_crtc_needs_modeset(crtc->state);
>
> @@ -272,7 +272,7 @@ static void vbox_primary_atomic_update(struct drm_plane
> *plane,
> {
> struct drm_crtc *crtc = plane->state->crtc;
> struct drm_framebuffer *fb = plane->state->fb;
> - struct vbox_private *vbox = fb->dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(fb->dev);
> struct drm_mode_rect *clips;
> uint32_t num_clips, i;
>
> @@ -704,7 +704,7 @@ static int vbox_get_modes(struct drm_connector *connector)
> int preferred_width, preferred_height;
>
> vbox_connector = to_vbox_connector(connector);
> - vbox = connector->dev->dev_private;
> + vbox = to_vbox_dev(connector->dev);
>
> hgsmi_report_flags_location(vbox->guest_pool, GUEST_HEAP_OFFSET(vbox) +
> HOST_FLAGS_OFFSET);
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
__
Re: [PATCH 09/44] drm/vboxvidoe: use managed pci functions
On Fri, Apr 03, 2020 at 03:57:53PM +0200, Daniel Vetter wrote:
> Allows us to drop the cleanup code on the floor.
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
With this change we avoid calling pci_disable_device()
twise in case vbox_mm_init() fails.
Once in vbox_hw_fini() and once in the error path.
Which is just a small extra bonus.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++
> drivers/gpu/drm/vboxvideo/vbox_main.c | 7 +--
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> index d34cddd809fd..c80695c2f6c0 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -55,13 +55,13 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> pci_set_drvdata(pdev, vbox);
> mutex_init(&vbox->hw_mutex);
>
> - ret = pci_enable_device(pdev);
> + ret = pcim_enable_device(pdev);
> if (ret)
> return ret;
>
> ret = vbox_hw_init(vbox);
> if (ret)
> - goto err_pci_disable;
> + return ret;
>
> ret = vbox_mm_init(vbox);
> if (ret)
> @@ -93,8 +93,6 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> vbox_mm_fini(vbox);
> err_hw_fini:
> vbox_hw_fini(vbox);
> -err_pci_disable:
> - pci_disable_device(pdev);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
> b/drivers/gpu/drm/vboxvideo/vbox_main.c
> index 9dcab115a261..1336ab9795fc 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_main.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
> @@ -71,8 +71,6 @@ static void vbox_accel_fini(struct vbox_private *vbox)
>
> for (i = 0; i < vbox->num_crtcs; ++i)
> vbva_disable(&vbox->vbva_info[i], vbox->guest_pool, i);
> -
> - pci_iounmap(vbox->ddev.pdev, vbox->vbva_buffers);
> }
>
> /* Do we support the 4.3 plus mode hint reporting interface? */
> @@ -125,7 +123,7 @@ int vbox_hw_init(struct vbox_private *vbox)
> /* Create guest-heap mem-pool use 2^4 = 16 byte chunks */
> vbox->guest_pool = gen_pool_create(4, -1);
> if (!vbox->guest_pool)
> - goto err_unmap_guest_heap;
> + return -ENOMEM;
>
> ret = gen_pool_add_virt(vbox->guest_pool,
> (unsigned long)vbox->guest_heap,
> @@ -168,8 +166,6 @@ int vbox_hw_init(struct vbox_private *vbox)
>
> err_destroy_guest_pool:
> gen_pool_destroy(vbox->guest_pool);
> -err_unmap_guest_heap:
> - pci_iounmap(vbox->ddev.pdev, vbox->guest_heap);
> return ret;
> }
>
> @@ -177,5 +173,4 @@ void vbox_hw_fini(struct vbox_private *vbox)
> {
> vbox_accel_fini(vbox);
> gen_pool_destroy(vbox->guest_pool);
> - pci_iounmap(vbox->ddev.pdev, vbox->guest_heap);
> }
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible 13t-aw100
On Tue, 07 Apr 2020, Kai-Heng Feng wrote:
>> On Mar 27, 2020, at 19:03, Kai-Heng Feng wrote:
>>
>> Hi,
>>
>>> On Mar 23, 2020, at 13:35, Kai-Heng Feng
>>> wrote:
>>>
>>> There's another OLED panel needs to use DPCD aux interface to control
>>> backlight.
>>>
>>> BugLink: https://bugs.launchpad.net/bugs/1860303
>>> Signed-off-by: Kai-Heng Feng
>>
>> Would it be possible to review this?
>> I'd like to send a similar quirk for a new panel, and I want to avoid
>> causing any merge conflict.
>
> Another gentle ping...
Can't really review, but if you say that's needed...
Acked-by: Jani Nikula
>
>>
>> Kai-Heng
>>
>>> ---
>>> drivers/gpu/drm/drm_dp_helper.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>>> b/drivers/gpu/drm/drm_dp_helper.c
>>> index 8ba4531e808d..a0d4314663de 100644
>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>> @@ -1301,6 +1301,8 @@ static const struct edid_quirk edid_quirk_list[] = {
>>> * only supports DPCD backlight controls
>>> */
>>> { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
>>> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
>>> + /* HP Spectre x360 Convertible 13t-aw100 */
>>> + { MFG(0x4c, 0x83), PROD_ID(0x42, 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
>>> --
>>> 2.17.1
>>>
>>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Force DPCD backlight mode for HP CML 2020 system
On Tue, 07 Apr 2020, Kai-Heng Feng wrote:
> There's another Samsung OLED panel needs to use DPCD aux interface to
> control backlight.
Acked-by: Jani Nikula
>
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index c6fbe6e6bc9d..d0cfee3b7a65 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1299,6 +1299,8 @@ static const struct edid_quirk edid_quirk_list[] = {
>* only supports DPCD backlight controls
>*/
> { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
> BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> + /* HP CML 2020 system */
> + { MFG(0x4c, 0x83), PROD_ID(0x45, 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
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/44] drm/vboxvideo: Use devm_gen_pool_create
On Fri, Apr 03, 2020 at 03:57:54PM +0200, Daniel Vetter wrote:
> Aside from deleting all the cleanup code we're now also setting a name
> for the pool
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
Nice cleanup.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/vboxvideo/vbox_main.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
> b/drivers/gpu/drm/vboxvideo/vbox_main.c
> index 1336ab9795fc..d68d9bad7674 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_main.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
> @@ -121,7 +121,8 @@ int vbox_hw_init(struct vbox_private *vbox)
> return -ENOMEM;
>
> /* Create guest-heap mem-pool use 2^4 = 16 byte chunks */
> - vbox->guest_pool = gen_pool_create(4, -1);
> + vbox->guest_pool = devm_gen_pool_create(vbox->ddev.dev, 4, -1,
> + "vboxvideo-accel");
> if (!vbox->guest_pool)
> return -ENOMEM;
>
> @@ -130,12 +131,12 @@ int vbox_hw_init(struct vbox_private *vbox)
> GUEST_HEAP_OFFSET(vbox),
> GUEST_HEAP_USABLE_SIZE, -1);
> if (ret)
> - goto err_destroy_guest_pool;
> + return ret;
>
> ret = hgsmi_test_query_conf(vbox->guest_pool);
> if (ret) {
> DRM_ERROR("vboxvideo: hgsmi_test_query_conf failed\n");
> - goto err_destroy_guest_pool;
> + return ret;
> }
>
> /* Reduce available VRAM size to reflect the guest heap. */
> @@ -147,30 +148,23 @@ int vbox_hw_init(struct vbox_private *vbox)
>
> if (!have_hgsmi_mode_hints(vbox)) {
> ret = -ENOTSUPP;
> - goto err_destroy_guest_pool;
> + return ret;
> }
>
> vbox->last_mode_hints = devm_kcalloc(vbox->ddev.dev, vbox->num_crtcs,
>sizeof(struct vbva_modehint),
>GFP_KERNEL);
> - if (!vbox->last_mode_hints) {
> - ret = -ENOMEM;
> - goto err_destroy_guest_pool;
> - }
> + if (!vbox->last_mode_hints)
> + return -ENOMEM;
>
> ret = vbox_accel_init(vbox);
> if (ret)
> - goto err_destroy_guest_pool;
> + return ret;
>
> return 0;
> -
> -err_destroy_guest_pool:
> - gen_pool_destroy(vbox->guest_pool);
> - return ret;
> }
>
> void vbox_hw_fini(struct vbox_private *vbox)
> {
> vbox_accel_fini(vbox);
> - gen_pool_destroy(vbox->guest_pool);
> }
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/44] drm/v3d: Delete v3d_dev->pdev
Hi Daniel.
On Fri, Apr 03, 2020 at 03:57:58PM +0200, Daniel Vetter wrote:
> We already have it in v3d_dev->drm.dev with zero additional pointer
> chasing. Personally I don't like duplicated pointers like this
> because:
> - reviewers need to check whether the pointer is for the same or
> different objects if there's multiple
> - compilers have an easier time too
>
> To avoid having to pull in some big headers I implemented the casting
> function as a macro instead of a static inline.
Hmm...
> Typechecking thanks to
> container_of still assured.
>
> But also a bit a bikeshed, so feel free to ignore.
>
> Signed-off-by: Daniel Vetter
> Cc: Eric Anholt
This and patch 13 has same subject - confusing.
Sam
> ---
> drivers/gpu/drm/v3d/v3d_drv.c | 3 +--
> drivers/gpu/drm/v3d/v3d_drv.h | 3 ++-
> drivers/gpu/drm/v3d/v3d_irq.c | 8 +---
> 3 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> index 37cb880f2826..82a7dfdd14c2 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -235,7 +235,7 @@ static int
> map_regs(struct v3d_dev *v3d, void __iomem **regs, const char *name)
> {
> struct resource *res =
> - platform_get_resource_byname(v3d->pdev, IORESOURCE_MEM, name);
> + platform_get_resource_byname(v3d_to_pdev(v3d), IORESOURCE_MEM,
> name);
>
> *regs = devm_ioremap_resource(v3d->drm.dev, res);
> return PTR_ERR_OR_ZERO(*regs);
> @@ -255,7 +255,6 @@ static int v3d_platform_drm_probe(struct platform_device
> *pdev)
> if (IS_ERR(v3d))
> return PTR_ERR(v3d);
>
> - v3d->pdev = pdev;
> drm = &v3d->drm;
>
> platform_set_drvdata(pdev, drm);
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> index 4d2d1f2fe1af..935f23b524b2 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -46,7 +46,6 @@ struct v3d_dev {
> int ver;
> bool single_irq_line;
>
> - struct platform_device *pdev;
> void __iomem *hub_regs;
> void __iomem *core_regs[3];
> void __iomem *bridge_regs;
> @@ -128,6 +127,8 @@ v3d_has_csd(struct v3d_dev *v3d)
> return v3d->ver >= 41;
> }
>
> +#define v3d_to_pdev(v3d) to_platform_device(v3d->drm.dev)
> +
> /* The per-fd struct, which tracks the MMU mappings. */
> struct v3d_file_priv {
> struct v3d_dev *v3d;
> diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
> index f4ce6d057c90..51b65263c657 100644
> --- a/drivers/gpu/drm/v3d/v3d_irq.c
> +++ b/drivers/gpu/drm/v3d/v3d_irq.c
> @@ -217,7 +217,7 @@ v3d_irq_init(struct v3d_dev *v3d)
> V3D_CORE_WRITE(core, V3D_CTL_INT_CLR, V3D_CORE_IRQS);
> V3D_WRITE(V3D_HUB_INT_CLR, V3D_HUB_IRQS);
>
> - irq1 = platform_get_irq(v3d->pdev, 1);
> + irq1 = platform_get_irq(v3d_to_pdev(v3d), 1);
> if (irq1 == -EPROBE_DEFER)
> return irq1;
> if (irq1 > 0) {
> @@ -226,7 +226,8 @@ v3d_irq_init(struct v3d_dev *v3d)
> "v3d_core0", v3d);
> if (ret)
> goto fail;
> - ret = devm_request_irq(v3d->drm.dev,
> platform_get_irq(v3d->pdev, 0),
> + ret = devm_request_irq(v3d->drm.dev,
> +platform_get_irq(v3d_to_pdev(v3d), 0),
> v3d_hub_irq, IRQF_SHARED,
> "v3d_hub", v3d);
> if (ret)
> @@ -234,7 +235,8 @@ v3d_irq_init(struct v3d_dev *v3d)
> } else {
> v3d->single_irq_line = true;
>
> - ret = devm_request_irq(v3d->drm.dev,
> platform_get_irq(v3d->pdev, 0),
> + ret = devm_request_irq(v3d->drm.dev,
> +platform_get_irq(v3d_to_pdev(v3d), 0),
> v3d_irq, IRQF_SHARED,
> "v3d", v3d);
> if (ret)
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/44] drm/udl: don't set drm_device->dev_private
On Fri, Apr 03, 2020 at 03:58:00PM +0200, Daniel Vetter wrote:
> We're mostly there already, just a handful of places that didn't use
> the to_udl container_of cast. To make sure no new appear, don't set
> ->dev_private.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Emil Velikov
> Cc: Thomas Zimmermann
> Cc: Daniel Vetter
> Cc: Alexios Zavras
> Cc: Laurent Pinchart
> Cc: Thomas Gleixner
> Cc: "José Roberto de Souza"
> Cc: Sam Ravnborg
> Cc: Gerd Hoffmann
> Cc: Allison Randal
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/udl/udl_connector.c | 4 ++--
> drivers/gpu/drm/udl/udl_drv.c | 1 -
> drivers/gpu/drm/udl/udl_modeset.c | 6 +++---
> 3 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_connector.c
> b/drivers/gpu/drm/udl/udl_connector.c
> index 0afdfb0d1fe1..cdc1c42e1669 100644
> --- a/drivers/gpu/drm/udl/udl_connector.c
> +++ b/drivers/gpu/drm/udl/udl_connector.c
> @@ -59,7 +59,7 @@ static int udl_get_modes(struct drm_connector *connector)
> static enum drm_mode_status udl_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> {
> - struct udl_device *udl = connector->dev->dev_private;
> + struct udl_device *udl = to_udl(connector->dev);
> if (!udl->sku_pixel_limit)
> return 0;
>
> @@ -72,7 +72,7 @@ static enum drm_mode_status udl_mode_valid(struct
> drm_connector *connector,
> static enum drm_connector_status
> udl_detect(struct drm_connector *connector, bool force)
> {
> - struct udl_device *udl = connector->dev->dev_private;
> + struct udl_device *udl = to_udl(connector->dev);
> struct udl_drm_connector *udl_connector =
> container_of(connector,
> struct udl_drm_connector,
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 4ba5149fdd57..126545428895 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -63,7 +63,6 @@ static struct udl_device *udl_driver_create(struct
> usb_interface *interface)
> return udl;
>
> udl->udev = udev;
> - udl->drm.dev_private = udl;
>
> r = udl_init(udl);
> if (r)
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index 8cad01f3d163..99518a826435 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -215,7 +215,7 @@ static char *udl_dummy_render(char *wrptr)
> static int udl_crtc_write_mode_to_hw(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> - struct udl_device *udl = dev->dev_private;
> + struct udl_device *udl = to_udl(dev);
> struct urb *urb;
> char *buf;
> int retval;
> @@ -369,7 +369,7 @@ udl_simple_display_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> struct drm_crtc *crtc = &pipe->crtc;
> struct drm_device *dev = crtc->dev;
> struct drm_framebuffer *fb = plane_state->fb;
> - struct udl_device *udl = dev->dev_private;
> + struct udl_device *udl = to_udl(dev);
> struct drm_display_mode *mode = &crtc_state->mode;
> char *buf;
> char *wrptr;
> @@ -464,7 +464,7 @@ static const struct drm_mode_config_funcs udl_mode_funcs
> = {
> int udl_modeset_init(struct drm_device *dev)
> {
> size_t format_count = ARRAY_SIZE(udl_simple_display_pipe_formats);
> - struct udl_device *udl = dev->dev_private;
> + struct udl_device *udl = to_udl(dev);
> struct drm_connector *connector;
> int ret;
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] amdgpu: remove load and unload callbacks (v3)
Hi Alex Am 07.02.20 um 20:50 schrieb Alex Deucher: > These are deprecated and the drm will soon start warning when drivers still > use them. It was a long and twisty road, but seems to work. Are you going to convert radeon as well? It's the only remaining KMS driver that uses load. Best regards Thomas > > v2: Add additional patch (13/15) which should fix the crash reported by > Thomas Zimmermann. > v3: Fix dp aux registration harder, add missing kconfig guard > > Alex Deucher (15): > drm/amdgpu: rename amdgpu_debugfs_preempt_cleanup > drm/amdgpu/ttm: move debugfs init into core amdgpu debugfs > drm/amdgpu/pm: move debugfs init into core amdgpu debugfs > drm/amdgpu/sa: move debugfs init into core amdgpu debugfs > drm/amdgpu/fence: move debugfs init into core amdgpu debugfs > drm/amdgpu/gem: move debugfs init into core amdgpu debugfs > drm/amdgpu/regs: move debugfs init into core amdgpu debugfs > drm/amdgpu/firmware: move debugfs init into core amdgpu debugfs > drm/amdgpu: don't call drm_connector_register for non-MST ports > drm/amdgpu/display: move debugfs init into core amdgpu debugfs (v2) > drm/amd/display: move dpcd debugfs members setup > drm/amdgpu/display: add a late register connector callback > drm/amdgpu/display: split dp connector registration (v2) > drm/amdgpu/ring: move debugfs init into core amdgpu debugfs > drm/amdgpu: drop legacy drm load and unload callbacks > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 17 - > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 69 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 17 - > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3 - > drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 7 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 9 +-- > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h| 2 + > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 15 +--- > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 4 ++ > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 +--- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 + > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 +-- > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 1 - > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++ > .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 + > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 13 ++-- > 19 files changed, 140 insertions(+), 89 deletions(-) > -- 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 27/44] drm/tidss: Use devm_drm_dev_alloc
On Fri, Apr 03, 2020 at 03:58:11PM +0200, Daniel Vetter wrote:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/tidss/tidss_drv.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
> b/drivers/gpu/drm/tidss/tidss_drv.c
> index ad449d104306..7d4465d58be8 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.c
> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> @@ -135,20 +135,13 @@ static int tidss_probe(struct platform_device *pdev)
>
> dev_dbg(dev, "%s\n", __func__);
>
> - /* Can't use devm_* since drm_device's lifetime may exceed dev's */
> - tidss = kzalloc(sizeof(*tidss), GFP_KERNEL);
> - if (!tidss)
> - return -ENOMEM;
> + tidss = devm_drm_dev_alloc(&pdev->dev, &tidss_driver,
> +struct tidss_device, ddev);
> + if (IS_ERR(tidss))
> + return PTR_ERR(tidss);
>
> ddev = &tidss->ddev;
>
> - ret = devm_drm_dev_init(&pdev->dev, ddev, &tidss_driver);
> - if (ret) {
> - kfree(ddev);
> - return ret;
> - }
> - drmm_add_final_kfree(ddev, tidss);
> -
> tidss->dev = dev;
> tidss->feat = of_device_get_match_data(dev);
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/44] drm/tidss: Don't use drm_device->dev_private
On Fri, Apr 03, 2020 at 03:58:12PM +0200, Daniel Vetter wrote:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/tidss/tidss_crtc.c | 16
> drivers/gpu/drm/tidss/tidss_drv.c | 2 --
> drivers/gpu/drm/tidss/tidss_drv.h | 2 ++
> drivers/gpu/drm/tidss/tidss_irq.c | 12 ++--
> drivers/gpu/drm/tidss/tidss_kms.c | 2 +-
> drivers/gpu/drm/tidss/tidss_plane.c | 6 +++---
> 6 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c
> b/drivers/gpu/drm/tidss/tidss_crtc.c
> index d4ce9bab8c7e..2396262c09e4 100644
> --- a/drivers/gpu/drm/tidss/tidss_crtc.c
> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
> @@ -24,7 +24,7 @@
> static void tidss_crtc_finish_page_flip(struct tidss_crtc *tcrtc)
> {
> struct drm_device *ddev = tcrtc->crtc.dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
> struct drm_pending_vblank_event *event;
> unsigned long flags;
> bool busy;
> @@ -88,7 +88,7 @@ static int tidss_crtc_atomic_check(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> struct drm_device *ddev = crtc->dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
> struct dispc_device *dispc = tidss->dispc;
> struct tidss_crtc *tcrtc = to_tidss_crtc(crtc);
> u32 hw_videoport = tcrtc->hw_videoport;
> @@ -165,7 +165,7 @@ static void tidss_crtc_atomic_flush(struct drm_crtc *crtc,
> {
> struct tidss_crtc *tcrtc = to_tidss_crtc(crtc);
> struct drm_device *ddev = crtc->dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
> unsigned long flags;
>
> dev_dbg(ddev->dev,
> @@ -216,7 +216,7 @@ static void tidss_crtc_atomic_enable(struct drm_crtc
> *crtc,
> {
> struct tidss_crtc *tcrtc = to_tidss_crtc(crtc);
> struct drm_device *ddev = crtc->dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
> const struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> unsigned long flags;
> int r;
> @@ -259,7 +259,7 @@ static void tidss_crtc_atomic_disable(struct drm_crtc
> *crtc,
> {
> struct tidss_crtc *tcrtc = to_tidss_crtc(crtc);
> struct drm_device *ddev = crtc->dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
> unsigned long flags;
>
> dev_dbg(ddev->dev, "%s, event %p\n", __func__, crtc->state->event);
> @@ -295,7 +295,7 @@ enum drm_mode_status tidss_crtc_mode_valid(struct
> drm_crtc *crtc,
> {
> struct tidss_crtc *tcrtc = to_tidss_crtc(crtc);
> struct drm_device *ddev = crtc->dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
>
> return dispc_vp_mode_valid(tidss->dispc, tcrtc->hw_videoport, mode);
> }
> @@ -314,7 +314,7 @@ static const struct drm_crtc_helper_funcs
> tidss_crtc_helper_funcs = {
> static int tidss_crtc_enable_vblank(struct drm_crtc *crtc)
> {
> struct drm_device *ddev = crtc->dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
>
> dev_dbg(ddev->dev, "%s\n", __func__);
>
> @@ -328,7 +328,7 @@ static int tidss_crtc_enable_vblank(struct drm_crtc *crtc)
> static void tidss_crtc_disable_vblank(struct drm_crtc *crtc)
> {
> struct drm_device *ddev = crtc->dev;
> - struct tidss_device *tidss = ddev->dev_private;
> + struct tidss_device *tidss = to_tidss(ddev);
>
> dev_dbg(ddev->dev, "%s\n", __func__);
>
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
> b/drivers/gpu/drm/tidss/tidss_drv.c
> index 7d4465d58be8..99edc66ebdef 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.c
> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> @@ -147,8 +147,6 @@ static int tidss_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, tidss);
>
> - ddev->dev_private = tidss;
> -
> ret = dispc_init(tidss);
> if (ret) {
> dev_err(dev, "failed to initialize dispc: %d\n", ret);
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.h
> b/drivers/gpu/drm/tidss/tidss_drv.h
> index e2aa6436ad18..b23cd95c8d78 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.h
> +++ b/drivers/gpu/drm/tidss/tidss_drv.h
> @@ -33,6 +33,8 @@ struct tidss_device {
> struct drm_atomic_state *saved_state;
> };
>
> +#define to_tidss(__dev) container_of(__dev, struct tidss_device, ddev)
> +
> int tidss_runtime_get(struct tidss_device *tidss);
> void tidss_runtime_put(struct tidss_device *tidss);
>
> diff --git a/drivers
Re: [PATCH 29/44] drm/tidss: Delete tidss->saved_state
On Fri, Apr 03, 2020 at 03:58:13PM +0200, Daniel Vetter wrote:
> Not used anymore since the switch to suspend/resume helpers.
>
> Signed-off-by: Daniel Vetter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
Good spot.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/tidss/tidss_drv.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.h
> b/drivers/gpu/drm/tidss/tidss_drv.h
> index b23cd95c8d78..3b0a3d87b7c4 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.h
> +++ b/drivers/gpu/drm/tidss/tidss_drv.h
> @@ -29,8 +29,6 @@ struct tidss_device {
>
> spinlock_t wait_lock; /* protects the irq masks */
> dispc_irq_t irq_mask; /* enabled irqs in addition to wait_list */
> -
> - struct drm_atomic_state *saved_state;
> };
>
> #define to_tidss(__dev) container_of(__dev, struct tidss_device, ddev)
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Set up generic fbdev after registering device
Hi Jani Am 07.04.20 um 09:24 schrieb Jani Nikula: > On Tue, 07 Apr 2020, Thomas Zimmermann wrote: >> Hi Sam >> >> Am 06.04.20 um 22:00 schrieb Sam Ravnborg: >>> Hi Thomas. >>> >>> On Mon, Apr 06, 2020 at 03:43:55PM +0200, Thomas Zimmermann wrote: Generic fbdev emulation is a DRM client. If possible, it should behave like userspace clients. Therefore it should not run before the driver registered the new DRM device. If the setup function fails, the driver should not report an error. >>> >>> Thanks for taking the time to refactor all the relevant drivers. >>> >>> I have received some push-back in the past when suggesting this, >>> but cannot remember from who. >>> Let's see what review comments you get. >>> >>> As the rule is that the fbdev setup shall be setup after registering >>> the DRM device - it would be nice to have this included in the >>> documentation of drm_fbdev_generic_setup >>> >>> Could you try to to update the documentation to cover this? >> >> Good idea. I'll add this to patchset's next iteration. > > How about something like: > > drm_WARN_ON(dev, !dev->registered); > > (Not sure if that needs to be !dev->driver->load && !dev->registered). I added such a warning to the patch. Only radeon uses load(), but it has its own fbdev code. So the original test should be fine. Best regards Thomas > > This can be a follow-up patch later too. > > BR, > Jani. > > >> >> Best regards >> Thomas >> >>> >>> I will get back to the patches later this week. >>> >>> Sam >>> This is a follow-up patchset to the discussion at [1]. I went through all calls to drm_fbdev_generic_setup(), moved them to the final operation of their driver's probe function, and removed the return value. Built-tested on x86-64, aarch64 and arm. [1] https://lore.kernel.org/dri-devel/20200403135828.2542770-1-daniel.vet...@ffwll.ch/T/#m216b5b37aeeb7b28d55ad73b7a702b3d1d7bf867 Thomas Zimmermann (10): drm/ast: Set up fbdev after registering device; remove error checks drm/hibmc: Remove error check from fbdev setup drm/kirin: Set up fbdev after fully registering device drm/ingenic: Remove error check from fbdev setup drm/mediathek: Remove error check from fbdev setup drm/mgag200: Set up fbdev after registering device; remove error checks drm/tilcdc: Set up fbdev after fully registering device drm/udl: Remove error check from fbdev setup drm/vboxvideo: Set up fbdev after registering device; remove error checks drm/fb-helper: Remove return value from drm_fbdev_generic_setup() drivers/gpu/drm/ast/ast_drv.c | 3 +++ drivers/gpu/drm/ast/ast_main.c | 5 - drivers/gpu/drm/drm_fb_helper.c| 18 -- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c| 6 +- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c| 4 ++-- drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +--- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +--- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++ drivers/gpu/drm/mgag200/mgag200_main.c | 4 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 3 +-- drivers/gpu/drm/udl/udl_drv.c | 6 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++ include/drm/drm_fb_helper.h| 5 +++-- 13 files changed, 25 insertions(+), 45 deletions(-) -- 2.26.0 > -- 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 32/44] drm/mcde: Use devm_drm_dev_alloc
On Fri, Apr 03, 2020 at 03:58:16PM +0200, Daniel Vetter wrote:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: Linus Walleij
Acked-by: Sam Ravnborg
But one comment below.
> ---
> drivers/gpu/drm/mcde/mcde_drv.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
> index 88cc6b4a7a64..bdb525e3c5d7 100644
> --- a/drivers/gpu/drm/mcde/mcde_drv.c
> +++ b/drivers/gpu/drm/mcde/mcde_drv.c
> @@ -307,24 +307,16 @@ static int mcde_probe(struct platform_device *pdev)
> int ret;
> int i;
>
> - mcde = kzalloc(sizeof(*mcde), GFP_KERNEL);
> - if (!mcde)
> - return -ENOMEM;
> - mcde->dev = dev;
> -
> - ret = devm_drm_dev_init(dev, &mcde->drm, &mcde_drm_driver);
> - if (ret) {
> - kfree(mcde);
> - return ret;
> - }
> + mcde = devm_drm_dev_alloc(dev, &mcde_drm_driver, struct mcde, drm);
> + if (IS_ERR(mcde))
> + return PTR_ERR(mcde);
> drm = &mcde->drm;
> drm->dev_private = mcde;
> - drmm_add_final_kfree(drm, mcde);
> + mcde->dev = dev;
> platform_set_drvdata(pdev, drm);
>
> /* Enable continuous updates: this is what Linux' framebuffer expects */
> mcde->oneshot_mode = false;
> - drm->dev_private = mcde;
It is assinged twice - but this change really belongs in next patch.
>
> /* First obtain and turn on the main power */
> mcde->epod = devm_regulator_get(dev, "epod");
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 33/44] drm/mcde: Don't use drm_device->dev_private
On Fri, Apr 03, 2020 at 03:58:17PM +0200, Daniel Vetter wrote:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Linus Walleij
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/mcde/mcde_display.c | 10 +-
> drivers/gpu/drm/mcde/mcde_drm.h | 2 ++
> drivers/gpu/drm/mcde/mcde_drv.c | 5 ++---
> drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
> 4 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_display.c
> b/drivers/gpu/drm/mcde/mcde_display.c
> index e59907e68854..04e1d38d41f7 100644
> --- a/drivers/gpu/drm/mcde/mcde_display.c
> +++ b/drivers/gpu/drm/mcde/mcde_display.c
> @@ -948,7 +948,7 @@ static void mcde_display_disable(struct
> drm_simple_display_pipe *pipe)
> {
> struct drm_crtc *crtc = &pipe->crtc;
> struct drm_device *drm = crtc->dev;
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
> struct drm_pending_vblank_event *event;
>
> drm_crtc_vblank_off(crtc);
> @@ -1020,7 +1020,7 @@ static void mcde_display_update(struct
> drm_simple_display_pipe *pipe,
> {
> struct drm_crtc *crtc = &pipe->crtc;
> struct drm_device *drm = crtc->dev;
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
> struct drm_pending_vblank_event *event = crtc->state->event;
> struct drm_plane *plane = &pipe->plane;
> struct drm_plane_state *pstate = plane->state;
> @@ -1078,7 +1078,7 @@ static int mcde_display_enable_vblank(struct
> drm_simple_display_pipe *pipe)
> {
> struct drm_crtc *crtc = &pipe->crtc;
> struct drm_device *drm = crtc->dev;
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
> u32 val;
>
> /* Enable all VBLANK IRQs */
> @@ -1097,7 +1097,7 @@ static void mcde_display_disable_vblank(struct
> drm_simple_display_pipe *pipe)
> {
> struct drm_crtc *crtc = &pipe->crtc;
> struct drm_device *drm = crtc->dev;
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
>
> /* Disable all VBLANK IRQs */
> writel(0, mcde->regs + MCDE_IMSCPP);
> @@ -1117,7 +1117,7 @@ static struct drm_simple_display_pipe_funcs
> mcde_display_funcs = {
>
> int mcde_display_init(struct drm_device *drm)
> {
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
> int ret;
> static const u32 formats[] = {
> DRM_FORMAT_ARGB,
> diff --git a/drivers/gpu/drm/mcde/mcde_drm.h b/drivers/gpu/drm/mcde/mcde_drm.h
> index 80edd6628979..679c2c4e6d9d 100644
> --- a/drivers/gpu/drm/mcde/mcde_drm.h
> +++ b/drivers/gpu/drm/mcde/mcde_drm.h
> @@ -34,6 +34,8 @@ struct mcde {
> struct regulator *vana;
> };
>
> +#define to_mcde(dev) container_of(dev, struct mcde, drm)
> +
> bool mcde_dsi_irq(struct mipi_dsi_device *mdsi);
> void mcde_dsi_te_request(struct mipi_dsi_device *mdsi);
> extern struct platform_driver mcde_dsi_driver;
> diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
> index bdb525e3c5d7..84f3e2dbd77b 100644
> --- a/drivers/gpu/drm/mcde/mcde_drv.c
> +++ b/drivers/gpu/drm/mcde/mcde_drv.c
> @@ -164,7 +164,7 @@ static irqreturn_t mcde_irq(int irq, void *data)
> static int mcde_modeset_init(struct drm_device *drm)
> {
> struct drm_mode_config *mode_config;
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
> int ret;
>
> if (!mcde->bridge) {
> @@ -311,7 +311,6 @@ static int mcde_probe(struct platform_device *pdev)
> if (IS_ERR(mcde))
> return PTR_ERR(mcde);
> drm = &mcde->drm;
> - drm->dev_private = mcde;
> mcde->dev = dev;
> platform_set_drvdata(pdev, drm);
>
> @@ -486,7 +485,7 @@ static int mcde_probe(struct platform_device *pdev)
> static int mcde_remove(struct platform_device *pdev)
> {
> struct drm_device *drm = platform_get_drvdata(pdev);
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
>
> component_master_del(&pdev->dev, &mcde_drm_comp_ops);
> clk_disable_unprepare(mcde->mcde_clk);
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index 7af5ebb0c436..1baa2324cdb9 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -1020,7 +1020,7 @@ static int mcde_dsi_bind(struct device *dev, struct
> device *master,
>void *data)
> {
> struct drm_device *drm = data;
> - struct mcde *mcde = drm->dev_private;
> + struct mcde *mcde = to_mcde(drm);
> struct mcde_dsi *d = dev_get_drvdata(dev);
> struct device_node *child;
> struct drm_panel *panel = NULL;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedeskto
Re: [PATCH 34/44] drm/ingenic: Use devm_drm_dev_alloc
On Fri, Apr 03, 2020 at 03:58:18PM +0200, Daniel Vetter wrote:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: Paul Cercueil
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm.c | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
> b/drivers/gpu/drm/ingenic/ingenic-drm.c
> index a9bc6623b488..bb62d8e93985 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
> @@ -614,9 +614,10 @@ static int ingenic_drm_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> - priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> - if (!priv)
> - return -ENOMEM;
> + priv = devm_drm_dev_alloc(dev, &ingenic_drm_driver_data,
> + struct ingenic_drm, drm);
> + if (IS_ERR(priv))
> + return PTR_ERR(priv);
>
> priv->soc_info = soc_info;
> priv->dev = dev;
> @@ -625,13 +626,6 @@ static int ingenic_drm_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, priv);
>
> - ret = devm_drm_dev_init(dev, drm, &ingenic_drm_driver_data);
> - if (ret) {
> - kfree(priv);
> - return ret;
> - }
> - drmm_add_final_kfree(drm, priv);
> -
> ret = drmm_mode_config_init(drm);
> if (ret)
> return ret;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 35/44] drm/ingenic: Don't set drm_device->dev_private
On Fri, Apr 03, 2020 at 03:58:19PM +0200, Daniel Vetter wrote: > Entirely not used, just copypasta. > > Signed-off-by: Daniel Vetter > Cc: Paul Cercueil Acked-by: Sam Ravnborg > --- > drivers/gpu/drm/ingenic/ingenic-drm.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c > b/drivers/gpu/drm/ingenic/ingenic-drm.c > index bb62d8e93985..3386270cb8a3 100644 > --- a/drivers/gpu/drm/ingenic/ingenic-drm.c > +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c > @@ -622,7 +622,6 @@ static int ingenic_drm_probe(struct platform_device *pdev) > priv->soc_info = soc_info; > priv->dev = dev; > drm = &priv->drm; > - drm->dev_private = priv; > > platform_set_drvdata(pdev, priv); > > -- > 2.25.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 39/44] drm/cirrus: Use devm_drm_dev_alloc
On Fri, Apr 03, 2020 at 03:58:23PM +0200, Daniel Vetter wrote:
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: "Noralf Trønnes"
> Cc: Rob Herring
> Cc: Thomas Zimmermann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: Emil Velikov
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index a36269717c3b..4b65637147ba 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -567,18 +567,13 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> return ret;
>
> ret = -ENOMEM;
> - cirrus = kzalloc(sizeof(*cirrus), GFP_KERNEL);
> - if (cirrus == NULL)
> - return ret;
> + cirrus = devm_drm_dev_alloc(&pdev->dev, &cirrus_driver,
> + struct cirrus_device, dev);
> + if (IS_ERR(cirrus))
> + return PTR_ERR(cirrus);
>
> dev = &cirrus->dev;
> - ret = devm_drm_dev_init(&pdev->dev, dev, &cirrus_driver);
> - if (ret) {
> - kfree(cirrus);
> - return ret;
> - }
> dev->dev_private = cirrus;
> - drmm_add_final_kfree(dev, cirrus);
>
> cirrus->vram = devm_ioremap(&pdev->dev, pci_resource_start(pdev, 0),
> pci_resource_len(pdev, 0));
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 40/44] drm/cirrus: Don't use drm_device->dev_private
On Fri, Apr 03, 2020 at 03:58:24PM +0200, Daniel Vetter wrote:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc: Thomas Zimmermann
> Cc: virtualizat...@lists.linux-foundation.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index 4b65637147ba..744a8e337e41 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -59,6 +59,8 @@ struct cirrus_device {
> void __iomem *mmio;
> };
>
> +#define to_cirrus(_dev) container_of(_dev, struct cirrus_device, dev)
> +
> /* -- */
> /*
> * The meat of this driver. The core passes us a mode and we have to program
> @@ -311,7 +313,7 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
> static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> {
> - struct cirrus_device *cirrus = fb->dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(fb->dev);
> void *vmap;
> int idx, ret;
>
> @@ -436,7 +438,7 @@ static void cirrus_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> struct drm_crtc_state *crtc_state,
> struct drm_plane_state *plane_state)
> {
> - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
>
> cirrus_mode_set(cirrus, &crtc_state->mode, plane_state->fb);
> cirrus_fb_blit_fullscreen(plane_state->fb);
> @@ -445,7 +447,7 @@ static void cirrus_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> static void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *old_state)
> {
> - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
> struct drm_plane_state *state = pipe->plane.state;
> struct drm_crtc *crtc = &pipe->crtc;
> struct drm_rect rect;
> @@ -573,7 +575,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> return PTR_ERR(cirrus);
>
> dev = &cirrus->dev;
> - dev->dev_private = cirrus;
>
> cirrus->vram = devm_ioremap(&pdev->dev, pci_resource_start(pdev, 0),
> pci_resource_len(pdev, 0));
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 40/44] drm/cirrus: Don't use drm_device->dev_private
Hi Thomas.
On Mon, Apr 06, 2020 at 01:58:54PM +0200, Thomas Zimmermann wrote:
>
>
> Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> > Upcasting using a container_of macro is more typesafe, faster and
> > easier for the compiler to optimize.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: Daniel Vetter
> > Cc: "Noralf Trønnes"
> > Cc: Sam Ravnborg
> > Cc: Eric Anholt
> > Cc: Thomas Zimmermann
> > Cc: virtualizat...@lists.linux-foundation.org
> > ---
> > drivers/gpu/drm/cirrus/cirrus.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/cirrus/cirrus.c
> > b/drivers/gpu/drm/cirrus/cirrus.c
> > index 4b65637147ba..744a8e337e41 100644
> > --- a/drivers/gpu/drm/cirrus/cirrus.c
> > +++ b/drivers/gpu/drm/cirrus/cirrus.c
> > @@ -59,6 +59,8 @@ struct cirrus_device {
> > void __iomem *mmio;
> > };
> >
> > +#define to_cirrus(_dev) container_of(_dev, struct cirrus_device, dev)
> > +
>
> Maybe to_cirrus_device() ? I had the same comment for vbox and I think
> it applies to all patches.
The variable name is consistently using the name "cirrus" - so my
personal preference is to_cirrus().
Also IMO struct cirrus_device is misnamed. It is more than a device.
Sam
>
> Best regards
> Thomas
>
> > /* -- */
> > /*
> > * The meat of this driver. The core passes us a mode and we have to
> > program
> > @@ -311,7 +313,7 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
> > static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
> >struct drm_rect *rect)
> > {
> > - struct cirrus_device *cirrus = fb->dev->dev_private;
> > + struct cirrus_device *cirrus = to_cirrus(fb->dev);
> > void *vmap;
> > int idx, ret;
> >
> > @@ -436,7 +438,7 @@ static void cirrus_pipe_enable(struct
> > drm_simple_display_pipe *pipe,
> >struct drm_crtc_state *crtc_state,
> >struct drm_plane_state *plane_state)
> > {
> > - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> > + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
> >
> > cirrus_mode_set(cirrus, &crtc_state->mode, plane_state->fb);
> > cirrus_fb_blit_fullscreen(plane_state->fb);
> > @@ -445,7 +447,7 @@ static void cirrus_pipe_enable(struct
> > drm_simple_display_pipe *pipe,
> > static void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
> >struct drm_plane_state *old_state)
> > {
> > - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> > + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
> > struct drm_plane_state *state = pipe->plane.state;
> > struct drm_crtc *crtc = &pipe->crtc;
> > struct drm_rect rect;
> > @@ -573,7 +575,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> > return PTR_ERR(cirrus);
> >
> > dev = &cirrus->dev;
> > - dev->dev_private = cirrus;
> >
> > cirrus->vram = devm_ioremap(&pdev->dev, pci_resource_start(pdev, 0),
> > pci_resource_len(pdev, 0));
> >
>
> --
> 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
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/44] devm_drm_dev_alloc, no more drmm_add_final_kfree
Hi Daniel. Made specific reply to several patches. This bunch: > drm/st7735r: Use devm_drm_dev_alloc > drm/st7586: Use devm_drm_dev_alloc > drm/repaper: Use devm_drm_dev_alloc > drm/mi0283qt: Use devm_drm_dev_alloc > drm/ili9486: Use devm_drm_dev_alloc > drm/ili9341: Use devm_drm_dev_alloc > drm/ili9225: Use devm_drm_dev_alloc > drm/hx8357d: Use devm_drm_dev_alloc > drm/gm12u320: Use devm_drm_dev_alloc > drm/gm12u320: Don't use drm_device->dev_private are all: Acked-by: Sam Ravnborg I will take a look at patch 44 later today. I steered away from the vgem, i915 stuff on purpose. I leave that to more competent persons. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/10] drm/tilcdc: Set up fbdev after fully registering device
Generic fbdev support is a DRM client. Set it up after fully registering the new DRM device. Signed-off-by: Thomas Zimmermann Acked-by: Jyri Sarha Reviewed-by: Noralf Trønnes Acked-by: Gerd Hoffmann --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 78c1877d13a83..a5e9ee4c7fbf4 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -390,10 +390,9 @@ static int tilcdc_init(struct drm_driver *ddrv, struct device *dev) ret = drm_dev_register(ddev, 0); if (ret) goto init_failed; + priv->is_registered = true; drm_fbdev_generic_setup(ddev, bpp); - - priv->is_registered = true; return 0; init_failed: -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] drm/mediatek: Remove error check from fbdev setup
Remove the error check from the fbdev setup function. The function
will print a warning.
v2:
* fix subject line
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2eaa9080d2505..ce570283b55f7 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -347,9 +347,7 @@ static int mtk_drm_bind(struct device *dev)
if (ret < 0)
goto err_deinit;
- ret = drm_fbdev_generic_setup(drm, 32);
- if (ret)
- DRM_ERROR("Failed to initialize fbdev: %d\n", ret);
+ drm_fbdev_generic_setup(drm, 32);
return 0;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/10] Set up generic fbdev after registering device
Generic fbdev emulation is a DRM client. If possible, it should behave like userspace clients. Therefore it should not run before the driver registered the new DRM device. If the setup function fails, the driver should not report an error. This is a follow-up patchset to the discussion at [1]. I went through all calls to drm_fbdev_generic_setup(), moved them to the final operation of their driver's probe function, and removed the return value. Built on x86-64, aarch64 and arm. Tested with mgag200. v2: * warn in drm_fbdev_generic_setup() if device is unregistered (Jani) * document the new behavior (Sam) * fix mediatek subject (Noralf) * keep kirin patch for now, even though the patched code will probably be removed Thomas Zimmermann (10): drm/ast: Set up fbdev after registering device; remove error checks drm/hibmc: Remove error check from fbdev setup drm/kirin: Set up fbdev after fully registering device drm/ingenic: Remove error check from fbdev setup drm/mediatek: Remove error check from fbdev setup drm/mgag200: Set up fbdev after registering device; remove error checks drm/tilcdc: Set up fbdev after fully registering device drm/udl: Remove error check from fbdev setup drm/vboxvideo: Set up fbdev after registering device; remove error checks drm/fb-helper: Remove return value from drm_fbdev_generic_setup() drivers/gpu/drm/ast/ast_drv.c | 3 +++ drivers/gpu/drm/ast/ast_main.c| 5 drivers/gpu/drm/drm_fb_helper.c | 25 ++- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 + .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 +-- drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +-- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 4 +-- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++ drivers/gpu/drm/mgag200/mgag200_main.c| 4 --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +-- drivers/gpu/drm/udl/udl_drv.c | 6 + drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++--- include/drm/drm_fb_helper.h | 5 ++-- 13 files changed, 30 insertions(+), 47 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/10] drm/fb-helper: Remove return value from drm_fbdev_generic_setup()
Generic fbdev emulation is a DRM client. Drivers should invoke the
setup function, but not depend on its success. Hence remove the return
value.
v2:
* warn if fbdev device has not been registered yet
* document the new behavior
* convert the existing warning to the new dev_ interface
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Reviewed-by: Noralf Trønnes
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_fb_helper.c | 25 +
include/drm/drm_fb_helper.h | 5 +++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 165c8dab50797..97f5e43837486 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2169,7 +2169,9 @@ static const struct drm_client_funcs
drm_fbdev_client_funcs = {
* @dev->mode_config.preferred_depth is used if this is zero.
*
* This function sets up generic fbdev emulation for drivers that supports
- * dumb buffers with a virtual address and that can be mmap'ed.
+ * dumb buffers with a virtual address and that can be mmap'ed. It's supposed
+ * to run after the DRM driver registered the new DRM device with
+ * drm_dev_register().
*
* Restore, hotplug events and teardown are all taken care of. Drivers that do
* suspend/resume need to call drm_fb_helper_set_suspend_unlocked() themselves.
@@ -2186,29 +2188,30 @@ static const struct drm_client_funcs
drm_fbdev_client_funcs = {
* Setup will be retried on the next hotplug event.
*
* The fbdev is destroyed by drm_dev_unregister().
- *
- * Returns:
- * Zero on success or negative error code on failure.
*/
-int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
+void drm_fbdev_generic_setup(struct drm_device *dev,
+unsigned int preferred_bpp)
{
struct drm_fb_helper *fb_helper;
int ret;
- WARN(dev->fb_helper, "fb_helper is already set!\n");
+ drm_WARN(dev, !dev->registered, "Device has not been registered.\n");
+ drm_WARN(dev, dev->fb_helper, "fb_helper is already set!\n");
if (!drm_fbdev_emulation)
- return 0;
+ return;
fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
- if (!fb_helper)
- return -ENOMEM;
+ if (!fb_helper) {
+ drm_err(dev, "Failed to allocate fb_helper\n");
+ return;
+ }
ret = drm_client_init(dev, &fb_helper->client, "fbdev",
&drm_fbdev_client_funcs);
if (ret) {
kfree(fb_helper);
drm_err(dev, "Failed to register client: %d\n", ret);
- return ret;
+ return;
}
if (!preferred_bpp)
@@ -,8 +2225,6 @@ int drm_fbdev_generic_setup(struct drm_device *dev,
unsigned int preferred_bpp)
drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
drm_client_register(&fb_helper->client);
-
- return 0;
}
EXPORT_SYMBOL(drm_fbdev_generic_setup);
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 208dbf87afa3e..fb037be83997d 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -269,7 +269,8 @@ int drm_fb_helper_debug_leave(struct fb_info *info);
void drm_fb_helper_lastclose(struct drm_device *dev);
void drm_fb_helper_output_poll_changed(struct drm_device *dev);
-int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int
preferred_bpp);
+void drm_fbdev_generic_setup(struct drm_device *dev,
+unsigned int preferred_bpp);
#else
static inline void drm_fb_helper_prepare(struct drm_device *dev,
struct drm_fb_helper *helper,
@@ -443,7 +444,7 @@ static inline void drm_fb_helper_output_poll_changed(struct
drm_device *dev)
{
}
-static inline int
+static inline void
drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
{
return 0;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/10] drm/ingenic: Remove error check from fbdev setup
Remove the error check from the fbdev setup function. The function will print a warning. Signed-off-by: Thomas Zimmermann Reviewed-by: Paul Cercueil Reviewed-by: Noralf Trønnes Acked-by: Gerd Hoffmann --- drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-drm.c index 7f3f869f57b3f..d938f2b1a96f1 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c @@ -783,9 +783,7 @@ static int ingenic_drm_probe(struct platform_device *pdev) goto err_devclk_disable; } - ret = drm_fbdev_generic_setup(drm, 32); - if (ret) - dev_warn(dev, "Unable to start fbdev emulation: %i", ret); + drm_fbdev_generic_setup(drm, 32); return 0; -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/10] drm/ast: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering the new DRM device. Remove the error checks as the driver's probe function should not depend on a DRM client's state. Signed-off-by: Thomas Zimmermann Reviewed-by: Noralf Trønnes Acked-by: Gerd Hoffmann --- drivers/gpu/drm/ast/ast_drv.c | 3 +++ drivers/gpu/drm/ast/ast_main.c | 5 - 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 30aa73a5d9b72..b7ba22dddcad9 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -32,6 +32,7 @@ #include #include +#include #include #include @@ -111,6 +112,8 @@ static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto err_ast_driver_unload; + drm_fbdev_generic_setup(dev, 32); + return 0; err_ast_driver_unload: diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c index 18a0a4ce00f6e..e5398e3dabe70 100644 --- a/drivers/gpu/drm/ast/ast_main.c +++ b/drivers/gpu/drm/ast/ast_main.c @@ -30,7 +30,6 @@ #include #include -#include #include #include #include @@ -512,10 +511,6 @@ int ast_driver_load(struct drm_device *dev, unsigned long flags) drm_mode_config_reset(dev); - ret = drm_fbdev_generic_setup(dev, 32); - if (ret) - goto out_free; - return 0; out_free: kfree(ast); -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/10] drm/kirin: Set up fbdev after fully registering device
Generic fbdev support is a DRM client. Set it up after fully registering
the new DRM device.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index d3145ae877d74..981858cc8d2b5 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -277,8 +277,6 @@ static int kirin_drm_bind(struct device *dev)
if (ret)
goto err_kms_cleanup;
- drm_fbdev_generic_setup(drm_dev, 32);
-
/* connectors should be registered after drm device register */
if (driver_data->register_connects) {
ret = kirin_drm_connectors_register(drm_dev);
@@ -286,6 +284,8 @@ static int kirin_drm_bind(struct device *dev)
goto err_drm_dev_unregister;
}
+ drm_fbdev_generic_setup(drm_dev, 32);
+
return 0;
err_drm_dev_unregister:
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/10] drm/hibmc: Remove error check from fbdev setup
Generic fbdev support is a DRM client. Remove the error check as the
driver's probe function should not depend on a DRM client's state.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 79a180ae4509f..a6fd0c29e5b89 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -307,11 +307,7 @@ static int hibmc_load(struct drm_device *dev)
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);
- ret = drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
- if (ret) {
- DRM_ERROR("failed to initialize fbdev: %d\n", ret);
- goto err;
- }
+ drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
return 0;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/10] drm/mgag200: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering the new DRM device. Remove the error checks as the driver's probe function should not depend on a DRM client's state. Signed-off-by: Thomas Zimmermann Reviewed-by: Noralf Trønnes Acked-by: Gerd Hoffmann --- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++ drivers/gpu/drm/mgag200/mgag200_main.c | 4 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index 7a5bad2f57d70..3298b7ef18b03 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c @@ -77,6 +77,8 @@ static int mga_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto err_mgag200_driver_unload; + drm_fbdev_generic_setup(dev, 0); + return 0; err_mgag200_driver_unload: diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c b/drivers/gpu/drm/mgag200/mgag200_main.c index e278b6a547bde..b680cf47cbb94 100644 --- a/drivers/gpu/drm/mgag200/mgag200_main.c +++ b/drivers/gpu/drm/mgag200/mgag200_main.c @@ -181,10 +181,6 @@ int mgag200_driver_load(struct drm_device *dev, unsigned long flags) dev_warn(&dev->pdev->dev, "Could not initialize cursors. Not doing hardware cursors.\n"); - r = drm_fbdev_generic_setup(mdev->dev, 0); - if (r) - goto err_modeset; - return 0; err_modeset: -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/10] drm/vboxvideo: Set up fbdev after registering device; remove error checks
Generic fbdev support is a DRM client. Set it up after registering the new DRM device. Remove the error checks as the driver's probe function should not depend on a DRM client's state. Signed-off-by: Thomas Zimmermann Reviewed-by: Noralf Trønnes Acked-by: Gerd Hoffmann --- drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c b/drivers/gpu/drm/vboxvideo/vbox_drv.c index d685ec197fa05..282348e071fe3 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c @@ -82,14 +82,12 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto err_mode_fini; - ret = drm_fbdev_generic_setup(&vbox->ddev, 32); - if (ret) - goto err_irq_fini; - ret = drm_dev_register(&vbox->ddev, 0); if (ret) goto err_irq_fini; + drm_fbdev_generic_setup(&vbox->ddev, 32); + return 0; err_irq_fini: -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/10] drm/udl: Remove error check from fbdev setup
Remove the error check from the fbdev setup function. The driver's
probe function should not depend on a DRM client's state.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/udl/udl_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 1ce2d865c36dc..9cc6d075cb402 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -97,14 +97,10 @@ static int udl_usb_probe(struct usb_interface *interface,
DRM_INFO("Initialized udl on minor %d\n", udl->drm.primary->index);
- r = drm_fbdev_generic_setup(&udl->drm, 0);
- if (r)
- goto err_drm_dev_unregister;
+ drm_fbdev_generic_setup(&udl->drm, 0);
return 0;
-err_drm_dev_unregister:
- drm_dev_unregister(&udl->drm);
err_free:
drm_dev_put(&udl->drm);
return r;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
etnaviv: command buffer outside valid memory window
Hello, I'm trying to get etnaviv on an i.MX6Q (2 GB DDR RAM) device running with kernel 5.6.2 but it is failing to setup the GPU with the following error: [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 256 MiB at 0x7f40 [0.00] On node 0 totalpages: 524288 [0.00] Normal zone: 4608 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 524288 pages, LIFO batch:63 ... [0.00] Memory: 1803240K/2097152K available (6144K kernel code, 247K rwdata, 2284K rodata, 1024K init, 375K bss, 31768K reserved, 262144K cma-reserved, 0K highmem) ... [0.529924] etnaviv etnaviv: bound 13.gpu (ops gpu_ops) [0.530153] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) [0.530408] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) [0.530427] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108 [0.530748] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 [0.530833] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 [0.530853] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 ... [5.374046] etnaviv etnaviv: command buffer outside valid memory window [5.389451] etnaviv etnaviv: command buffer outside valid memory window [5.406062] etnaviv etnaviv: command buffer outside valid memory window [5.421381] etnaviv etnaviv: command buffer outside valid memory window I have a similar setup with a i.MX6DL (1GB DDR RAM) and this works w/o an error. I found this patch https://lkml.org/lkml/2019/6/19/809 which describes a similar issue. Is there something I'm missing or I have misconfigured? Any hint would be highly appreciated. Thx, Hannes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 36/44] drm/komeda: use devm_drm_dev_alloc
On Fri, Apr 03, 2020 at 09:58:20PM +0800, Daniel Vetter wrote:
> Komeda uses the component framework, which does open/close a new
> devres group around all the bind callbacks. Which means we can use
> devm_ functions for managing the drm_device cleanup, with leaking
> stuff in case of deferred probes or other reasons to unbind
> components, or the component_master.
>
> Also note that this fixes a double-free in the probe unroll code, bot
> drm_dev_put and kfree(kms) result in the kms allocation getting freed.
>
> Aside: komeda_bind could be cleaned up a lot, devm_kfree is a bit
> redundant. Plus I'm not clear on why there's suballocations for
> mdrv->mdev and mdrv->kms. Plus I'm not sure the lifetimes are correct
> with all that devm_kzalloc usage ... That structure layout is also the
> reason why komeda still uses drm_device->dev_private and can't easily
> be replaced with a proper container_of upcasting. I'm pretty sure that
> there's endless amounts of hotunplug/hotremove bugs in there with all
> the unprotected dereferencing of drm_device->dev_private.
Hi Daniel:
Thank you for the patch.
Reviewed-by: James Qian Wang
For why komeda has two devices komeda_dev and komeda_kms_dev.
That because komeda treats drm_crtc/plane as virtual, which pick the real
komeda resources to satify the user's requirement. In the initial driver
design we want to clear the difference of these two class structures
so we defined two devices:
- komeda_dev:
managing the real komeda device and resources.
- komeda_kms_dev
the virtual device managing the drm related stuff like
komeda_crtc/plane.
And yes, even for that we don't need two sub-allocations, we are planing
to move the komeda_dev into the komeda_kms_dev or just merge two devices
together.
Thanks
James
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 16dfd5cdb66c..6b85d5f4caa8 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -261,18 +261,16 @@ static void komeda_kms_mode_config_init(struct
> komeda_kms_dev *kms,
>
> struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
> {
> - struct komeda_kms_dev *kms = kzalloc(sizeof(*kms), GFP_KERNEL);
> + struct komeda_kms_dev *kms;
> struct drm_device *drm;
> int err;
>
> - if (!kms)
> - return ERR_PTR(-ENOMEM);
> + kms = devm_drm_dev_alloc(mdev->dev, &komeda_kms_driver,
> + struct komeda_kms_dev, base);
> + if (IS_ERR(kms))
> + return kms;
>
> drm = &kms->base;
> - err = drm_dev_init(drm, &komeda_kms_driver, mdev->dev);
> - if (err)
> - goto free_kms;
> - drmm_add_final_kfree(drm, kms);
>
> drm->dev_private = mdev;
>
> @@ -329,9 +327,6 @@ struct komeda_kms_dev *komeda_kms_attach(struct
> komeda_dev *mdev)
> drm_mode_config_cleanup(drm);
> komeda_kms_cleanup_private_objs(kms);
> drm->dev_private = NULL;
> - drm_dev_put(drm);
> -free_kms:
> - kfree(kms);
> return ERR_PTR(err);
> }
>
> @@ -348,5 +343,4 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
> drm_mode_config_cleanup(drm);
> komeda_kms_cleanup_private_objs(kms);
> drm->dev_private = NULL;
> - drm_dev_put(drm);
> }
> --
> 2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] drm/fb-helper: Remove return value from drm_fbdev_generic_setup()
Hi Thomas.
You missed my ack on the first 9 patches:
https://lore.kernel.org/dri-devel/20200407101354.ga12...@ravnborg.org/
Not that it matters as others have acked/reviewed them.
On Wed, Apr 08, 2020 at 10:26:41AM +0200, Thomas Zimmermann wrote:
> Generic fbdev emulation is a DRM client. Drivers should invoke the
> setup function, but not depend on its success. Hence remove the return
> value.
>
> v2:
> * warn if fbdev device has not been registered yet
> * document the new behavior
> * convert the existing warning to the new dev_ interface
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Noralf Trønnes
> Acked-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/drm_fb_helper.c | 25 +
> include/drm/drm_fb_helper.h | 5 +++--
> 2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 165c8dab50797..97f5e43837486 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2169,7 +2169,9 @@ static const struct drm_client_funcs
> drm_fbdev_client_funcs = {
> * @dev->mode_config.preferred_depth is used if this is zero.
> *
> * This function sets up generic fbdev emulation for drivers that supports
> - * dumb buffers with a virtual address and that can be mmap'ed.
> + * dumb buffers with a virtual address and that can be mmap'ed. It's supposed
> + * to run after the DRM driver registered the new DRM device with
> + * drm_dev_register().
OR maybe be more explicit - something like:
drm_fbdev_generic_setup() shall be called after the DRM is registered
with drm_dev_register().
Either way is fine.
Sam
> *
> * Restore, hotplug events and teardown are all taken care of. Drivers that
> do
> * suspend/resume need to call drm_fb_helper_set_suspend_unlocked()
> themselves.
> @@ -2186,29 +2188,30 @@ static const struct drm_client_funcs
> drm_fbdev_client_funcs = {
> * Setup will be retried on the next hotplug event.
> *
> * The fbdev is destroyed by drm_dev_unregister().
> - *
> - * Returns:
> - * Zero on success or negative error code on failure.
> */
> -int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int
> preferred_bpp)
> +void drm_fbdev_generic_setup(struct drm_device *dev,
> + unsigned int preferred_bpp)
> {
> struct drm_fb_helper *fb_helper;
> int ret;
>
> - WARN(dev->fb_helper, "fb_helper is already set!\n");
> + drm_WARN(dev, !dev->registered, "Device has not been registered.\n");
> + drm_WARN(dev, dev->fb_helper, "fb_helper is already set!\n");
>
> if (!drm_fbdev_emulation)
> - return 0;
> + return;
>
> fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
> - if (!fb_helper)
> - return -ENOMEM;
> + if (!fb_helper) {
> + drm_err(dev, "Failed to allocate fb_helper\n");
> + return;
> + }
>
> ret = drm_client_init(dev, &fb_helper->client, "fbdev",
> &drm_fbdev_client_funcs);
> if (ret) {
> kfree(fb_helper);
> drm_err(dev, "Failed to register client: %d\n", ret);
> - return ret;
> + return;
> }
>
> if (!preferred_bpp)
> @@ -,8 +2225,6 @@ int drm_fbdev_generic_setup(struct drm_device *dev,
> unsigned int preferred_bpp)
> drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
>
> drm_client_register(&fb_helper->client);
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_fbdev_generic_setup);
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 208dbf87afa3e..fb037be83997d 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -269,7 +269,8 @@ int drm_fb_helper_debug_leave(struct fb_info *info);
> void drm_fb_helper_lastclose(struct drm_device *dev);
> void drm_fb_helper_output_poll_changed(struct drm_device *dev);
>
> -int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int
> preferred_bpp);
> +void drm_fbdev_generic_setup(struct drm_device *dev,
> + unsigned int preferred_bpp);
> #else
> static inline void drm_fb_helper_prepare(struct drm_device *dev,
> struct drm_fb_helper *helper,
> @@ -443,7 +444,7 @@ static inline void
> drm_fb_helper_output_poll_changed(struct drm_device *dev)
> {
> }
>
> -static inline int
> +static inline void
> drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
> {
> return 0;
> --
> 2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] dt-bindings: display: panel: Add binding document for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is a 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
Sam said he had applied this to drm-misc-next already,
but I can't see it so far, so included for completenes.
.../display/panel/leadtek,ltk050h3146w.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
new file mode 100644
index ..a372bdc5bde1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel
+
+maintainers:
+ - Heiko Stuebner
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - leadtek,ltk050h3146w
+ - leadtek,ltk050h3146w-a2
+ reg: true
+ backlight: true
+ reset-gpios: true
+ iovcc-supply:
+ description: regulator that supplies the iovcc voltage
+ vci-supply:
+ description: regulator that supplies the vci voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - iovcc-supply
+ - vci-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "leadtek,ltk050h3146w";
+reg = <0>;
+backlight = <&backlight>;
+iovcc-supply = <&vcc_1v8>;
+vci-supply = <&vcc3v3_lcd>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/panel: add panel driver for Leadtek LTK050H3146W
From: Heiko Stuebner
The LTK050H3146W is 5.0" 720x1280 DSI display. There are two variants
with essentially the same name, LTK050H3146W and LTK050H3146W-A2.
They differ in their init sequence and mode details.
changes in v2:
- add display variants
changes in v3:
- fixed indentation and artifacts found by Sam
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk050h3146w.c| 691 ++
3 files changed, 703 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..d56258b9fcaf 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -137,6 +137,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_LEADTEK_LTK050H3146W
+ tristate "Leadtek LTK050H3146W panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Leadtek LTK050H3146W
+ TFT-LCD modules. The panel has a 720x1280 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_LEADTEK_LTK500HD1829
tristate "Leadtek LTK500HD1829 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..2335a1e32ae0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
new file mode 100644
index ..5a7a31c8513e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct ltk050h3146w_cmd {
+ char cmd;
+ char data;
+};
+
+struct ltk050h3146w;
+struct ltk050h3146w_desc {
+ const struct drm_display_mode *mode;
+ int (*init)(struct ltk050h3146w *ctx);
+};
+
+struct ltk050h3146w {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator *vci;
+ struct regulator *iovcc;
+ const struct ltk050h3146w_desc *panel_desc;
+ bool prepared;
+};
+
+static const struct ltk050h3146w_cmd page1_cmds[] = {
+ { 0x22, 0x0A }, /* BGR SS GS */
+ { 0x31, 0x00 }, /* column inversion */
+ { 0x53, 0xA2 }, /* VCOM1 */
+ { 0x55, 0xA2 }, /* VCOM2 */
+ { 0x50, 0x81 }, /* VREG1OUT=5V */
+ { 0x51, 0x85 }, /* VREG2OUT=-5V */
+ { 0x62, 0x0D }, /* EQT Time setting */
+/*
+ * The vendor init selected page 1 here _again_
+ * Is this supposed to be page 2?
+ */
+ { 0xA0, 0x00 },
+ { 0xA1, 0x1A },
+ { 0xA2, 0x28 },
+ { 0xA3, 0x13 },
+ { 0xA4, 0x16 },
+ { 0xA5, 0x29 },
+ { 0xA6, 0x1D },
+ { 0xA7, 0x1E },
+ { 0xA8, 0x84 },
+ { 0xA9, 0x1C },
+ { 0xAA, 0x28 },
+ { 0xAB, 0x75 },
+ { 0xAC, 0x1A },
+ { 0xAD, 0x19 },
+ { 0xAE, 0x4D },
+ { 0xAF, 0x22 },
+ { 0xB0, 0x28 },
+ { 0xB1, 0x54 },
+ { 0xB2, 0x66 },
+ { 0xB3, 0x39 },
+ { 0xC0, 0x00 },
+ { 0xC1, 0x1A },
+ { 0xC2, 0x28 },
+ { 0xC3, 0x13 },
+ { 0xC4, 0x16 },
+ { 0xC5, 0x29 },
+ { 0xC6, 0x1D },
+ { 0xC7, 0x1E },
+ { 0xC8, 0x84 },
+ { 0xC9, 0x1C },
+ { 0xCA, 0x28 },
+ { 0xCB, 0x75 },
+ { 0xCC, 0x1A },
+ { 0xCD, 0x19 },
+ { 0xCE, 0x4D },
+ { 0xCF, 0x22 },
+ { 0xD0, 0x28 },
+ { 0xD1, 0x54 },
+ { 0xD2, 0x66 },
+ { 0xD3, 0x39 },
+};
+
+static const struct ltk050h3146w_cmd page3_cmds[] = {
+ { 0x01, 0x00 },
+ { 0x02, 0x00 },
+ { 0x03, 0x73 },
+ { 0x04, 0x00 },
+ { 0x05, 0x00 },
+ { 0x06, 0x0a },
+ { 0x07, 0x00 },
+ { 0x08,
Re: [PATCH v3 2/2] drm/panel: add panel driver for Leadtek LTK050H3146W
Goodmorning Heiko
On Wed, Apr 08, 2020 at 10:53:17AM +0200, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> The LTK050H3146W is 5.0" 720x1280 DSI display. There are two variants
> with essentially the same name, LTK050H3146W and LTK050H3146W-A2.
>
> They differ in their init sequence and mode details.
>
> changes in v2:
> - add display variants
> changes in v3:
> - fixed indentation and artifacts found by Sam
>
> Signed-off-by: Heiko Stuebner
That was quick - thanks.
Applied - and now I also have pushed the patches out.
Sam
> ---
> drivers/gpu/drm/panel/Kconfig | 11 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../drm/panel/panel-leadtek-ltk050h3146w.c| 691 ++
> 3 files changed, 703 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index a1723c1b5fbf..d56258b9fcaf 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -137,6 +137,17 @@ config DRM_PANEL_KINGDISPLAY_KD097D04
> 24 bit RGB per pixel. It provides a MIPI DSI interface to
> the host and has a built-in LED backlight.
>
> +config DRM_PANEL_LEADTEK_LTK050H3146W
> + tristate "Leadtek LTK050H3146W panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for Leadtek LTK050H3146W
> + TFT-LCD modules. The panel has a 720x1280 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
> config DRM_PANEL_LEADTEK_LTK500HD1829
> tristate "Leadtek LTK500HD1829 panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 96a883cd6630..2335a1e32ae0 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
> panel-ilitek-ili9881c.o
> obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
> obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
> obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
> +obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
> obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
> obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
> b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
> new file mode 100644
> index ..5a7a31c8513e
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c
> @@ -0,0 +1,691 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct ltk050h3146w_cmd {
> + char cmd;
> + char data;
> +};
> +
> +struct ltk050h3146w;
> +struct ltk050h3146w_desc {
> + const struct drm_display_mode *mode;
> + int (*init)(struct ltk050h3146w *ctx);
> +};
> +
> +struct ltk050h3146w {
> + struct device *dev;
> + struct drm_panel panel;
> + struct gpio_desc *reset_gpio;
> + struct regulator *vci;
> + struct regulator *iovcc;
> + const struct ltk050h3146w_desc *panel_desc;
> + bool prepared;
> +};
> +
> +static const struct ltk050h3146w_cmd page1_cmds[] = {
> + { 0x22, 0x0A }, /* BGR SS GS */
> + { 0x31, 0x00 }, /* column inversion */
> + { 0x53, 0xA2 }, /* VCOM1 */
> + { 0x55, 0xA2 }, /* VCOM2 */
> + { 0x50, 0x81 }, /* VREG1OUT=5V */
> + { 0x51, 0x85 }, /* VREG2OUT=-5V */
> + { 0x62, 0x0D }, /* EQT Time setting */
> +/*
> + * The vendor init selected page 1 here _again_
> + * Is this supposed to be page 2?
> + */
> + { 0xA0, 0x00 },
> + { 0xA1, 0x1A },
> + { 0xA2, 0x28 },
> + { 0xA3, 0x13 },
> + { 0xA4, 0x16 },
> + { 0xA5, 0x29 },
> + { 0xA6, 0x1D },
> + { 0xA7, 0x1E },
> + { 0xA8, 0x84 },
> + { 0xA9, 0x1C },
> + { 0xAA, 0x28 },
> + { 0xAB, 0x75 },
> + { 0xAC, 0x1A },
> + { 0xAD, 0x19 },
> + { 0xAE, 0x4D },
> + { 0xAF, 0x22 },
> + { 0xB0, 0x28 },
> + { 0xB1, 0x54 },
> + { 0xB2, 0x66 },
> + { 0xB3, 0x39 },
> + { 0xC0, 0x00 },
> + { 0xC1, 0x1A },
> + { 0xC2, 0x28 },
> + { 0xC3, 0x13 },
> + { 0xC4, 0x16 },
> + { 0xC5, 0x29 },
> + { 0xC6, 0x1D },
> + { 0xC7, 0x1E },
> + { 0xC8, 0x84 },
> + { 0xC9, 0x1C },
> + { 0xCA, 0x28 },
> + { 0xCB, 0x75 },
> + { 0xCC, 0x1A },
> + { 0xCD, 0x19 },
> + { 0xCE, 0x4D },
> + { 0xCF,
Re: [PATCH 36/44] drm/komeda: use devm_drm_dev_alloc
On Wed, Apr 8, 2020 at 10:41 AM james qian wang (Arm Technology China)
wrote:
>
> On Fri, Apr 03, 2020 at 09:58:20PM +0800, Daniel Vetter wrote:
> > Komeda uses the component framework, which does open/close a new
> > devres group around all the bind callbacks. Which means we can use
> > devm_ functions for managing the drm_device cleanup, with leaking
> > stuff in case of deferred probes or other reasons to unbind
> > components, or the component_master.
> >
> > Also note that this fixes a double-free in the probe unroll code, bot
> > drm_dev_put and kfree(kms) result in the kms allocation getting freed.
> >
> > Aside: komeda_bind could be cleaned up a lot, devm_kfree is a bit
> > redundant. Plus I'm not clear on why there's suballocations for
> > mdrv->mdev and mdrv->kms. Plus I'm not sure the lifetimes are correct
> > with all that devm_kzalloc usage ... That structure layout is also the
> > reason why komeda still uses drm_device->dev_private and can't easily
> > be replaced with a proper container_of upcasting. I'm pretty sure that
> > there's endless amounts of hotunplug/hotremove bugs in there with all
> > the unprotected dereferencing of drm_device->dev_private.
>
> Hi Daniel:
>
> Thank you for the patch.
>
> Reviewed-by: James Qian Wang
>
> For why komeda has two devices komeda_dev and komeda_kms_dev.
> That because komeda treats drm_crtc/plane as virtual, which pick the real
> komeda resources to satify the user's requirement. In the initial driver
> design we want to clear the difference of these two class structures
> so we defined two devices:
>
> - komeda_dev:
> managing the real komeda device and resources.
>
> - komeda_kms_dev
> the virtual device managing the drm related stuff like
> komeda_crtc/plane.
>
> And yes, even for that we don't need two sub-allocations, we are planing
> to move the komeda_dev into the komeda_kms_dev or just merge two devices
> together.
Yeah I think the logical split makes a lot of sense, e.g. amdgpu has a
similar split between the drm front-end structures, and the DC
back-end stuff that deals with the hardware. Same as other drivers.
The issue I think I'm seeing with komeda is all the pointer chasing
(not a problem, just a bit of indirection that's not strictly needed),
and that when you unload the back-end disappears right away, while the
front-end might still be used by userspace. And then all the pointers
you have lead to oopses.
I admit that for built-in hw hotunplug isn't really a major use-case.
But we do have some usb drivers nowadays in drm, so I'm trying to
clean this all up a bit and make sure that as many drivers as possible
have clean&correct code in this area.
Anyway if you're already planning to look into this then awesome!
Cheers, Daniel
> Thanks
> James
>
> > Signed-off-by: Daniel Vetter
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > Cc: Mihail Atanassov
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 16 +---
> > 1 file changed, 5 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index 16dfd5cdb66c..6b85d5f4caa8 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > @@ -261,18 +261,16 @@ static void komeda_kms_mode_config_init(struct
> > komeda_kms_dev *kms,
> >
> > struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
> > {
> > - struct komeda_kms_dev *kms = kzalloc(sizeof(*kms), GFP_KERNEL);
> > + struct komeda_kms_dev *kms;
> > struct drm_device *drm;
> > int err;
> >
> > - if (!kms)
> > - return ERR_PTR(-ENOMEM);
> > + kms = devm_drm_dev_alloc(mdev->dev, &komeda_kms_driver,
> > + struct komeda_kms_dev, base);
> > + if (IS_ERR(kms))
> > + return kms;
> >
> > drm = &kms->base;
> > - err = drm_dev_init(drm, &komeda_kms_driver, mdev->dev);
> > - if (err)
> > - goto free_kms;
> > - drmm_add_final_kfree(drm, kms);
> >
> > drm->dev_private = mdev;
> >
> > @@ -329,9 +327,6 @@ struct komeda_kms_dev *komeda_kms_attach(struct
> > komeda_dev *mdev)
> > drm_mode_config_cleanup(drm);
> > komeda_kms_cleanup_private_objs(kms);
> > drm->dev_private = NULL;
> > - drm_dev_put(drm);
> > -free_kms:
> > - kfree(kms);
> > return ERR_PTR(err);
> > }
> >
> > @@ -348,5 +343,4 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
> > drm_mode_config_cleanup(drm);
> > komeda_kms_cleanup_private_objs(kms);
> > drm->dev_private = NULL;
> > - drm_dev_put(drm);
> > }
> > --
> > 2.25.1
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/10] drm/fb-helper: Remove return value from drm_fbdev_generic_setup()
Hi Sam
Am 08.04.20 um 10:50 schrieb Sam Ravnborg:
> Hi Thomas.
>
> You missed my ack on the first 9 patches:
> https://lore.kernel.org/dri-devel/20200407101354.ga12...@ravnborg.org/
> Not that it matters as others have acked/reviewed them.
This got lost. I'll add you acks. Thanks for taking another look at the
patches.
>
> On Wed, Apr 08, 2020 at 10:26:41AM +0200, Thomas Zimmermann wrote:
>> Generic fbdev emulation is a DRM client. Drivers should invoke the
>> setup function, but not depend on its success. Hence remove the return
>> value.
>>
>> v2:
>> * warn if fbdev device has not been registered yet
>> * document the new behavior
>> * convert the existing warning to the new dev_ interface
>>
>> Signed-off-by: Thomas Zimmermann
>> Reviewed-by: Sam Ravnborg
>> Reviewed-by: Noralf Trønnes
>> Acked-by: Gerd Hoffmann
>> ---
>> drivers/gpu/drm/drm_fb_helper.c | 25 +
>> include/drm/drm_fb_helper.h | 5 +++--
>> 2 files changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 165c8dab50797..97f5e43837486 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -2169,7 +2169,9 @@ static const struct drm_client_funcs
>> drm_fbdev_client_funcs = {
>> * @dev->mode_config.preferred_depth is used if this is
>> zero.
>> *
>> * This function sets up generic fbdev emulation for drivers that supports
>> - * dumb buffers with a virtual address and that can be mmap'ed.
>> + * dumb buffers with a virtual address and that can be mmap'ed. It's
>> supposed
>> + * to run after the DRM driver registered the new DRM device with
>> + * drm_dev_register().
> OR maybe be more explicit - something like:
> drm_fbdev_generic_setup() shall be called after the DRM is registered
> with drm_dev_register().
I think this one is even better.
Best regards
Thomas
>
> Either way is fine.
>
> Sam
>
>> *
>> * Restore, hotplug events and teardown are all taken care of. Drivers that
>> do
>> * suspend/resume need to call drm_fb_helper_set_suspend_unlocked()
>> themselves.
>> @@ -2186,29 +2188,30 @@ static const struct drm_client_funcs
>> drm_fbdev_client_funcs = {
>> * Setup will be retried on the next hotplug event.
>> *
>> * The fbdev is destroyed by drm_dev_unregister().
>> - *
>> - * Returns:
>> - * Zero on success or negative error code on failure.
>> */
>> -int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int
>> preferred_bpp)
>> +void drm_fbdev_generic_setup(struct drm_device *dev,
>> + unsigned int preferred_bpp)
>> {
>> struct drm_fb_helper *fb_helper;
>> int ret;
>>
>> -WARN(dev->fb_helper, "fb_helper is already set!\n");
>> +drm_WARN(dev, !dev->registered, "Device has not been registered.\n");
>> +drm_WARN(dev, dev->fb_helper, "fb_helper is already set!\n");
>>
>> if (!drm_fbdev_emulation)
>> -return 0;
>> +return;
>>
>> fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
>> -if (!fb_helper)
>> -return -ENOMEM;
>> +if (!fb_helper) {
>> +drm_err(dev, "Failed to allocate fb_helper\n");
>> +return;
>> +}
>>
>> ret = drm_client_init(dev, &fb_helper->client, "fbdev",
>> &drm_fbdev_client_funcs);
>> if (ret) {
>> kfree(fb_helper);
>> drm_err(dev, "Failed to register client: %d\n", ret);
>> -return ret;
>> +return;
>> }
>>
>> if (!preferred_bpp)
>> @@ -,8 +2225,6 @@ int drm_fbdev_generic_setup(struct drm_device *dev,
>> unsigned int preferred_bpp)
>> drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
>>
>> drm_client_register(&fb_helper->client);
>> -
>> -return 0;
>> }
>> EXPORT_SYMBOL(drm_fbdev_generic_setup);
>>
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index 208dbf87afa3e..fb037be83997d 100644
>> --- a/include/drm/drm_fb_helper.h
>> +++ b/include/drm/drm_fb_helper.h
>> @@ -269,7 +269,8 @@ int drm_fb_helper_debug_leave(struct fb_info *info);
>> void drm_fb_helper_lastclose(struct drm_device *dev);
>> void drm_fb_helper_output_poll_changed(struct drm_device *dev);
>>
>> -int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int
>> preferred_bpp);
>> +void drm_fbdev_generic_setup(struct drm_device *dev,
>> + unsigned int preferred_bpp);
>> #else
>> static inline void drm_fb_helper_prepare(struct drm_device *dev,
>> struct drm_fb_helper *helper,
>> @@ -443,7 +444,7 @@ static inline void
>> drm_fb_helper_output_poll_changed(struct drm_device *dev)
>> {
>> }
>>
>> -static inline int
>> +static inline void
>> drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
>> {
>> return 0;
>> --
>> 2.26.0
--
Thomas Zimmermann
Graphics D
Re: [Intel-gfx] [PATCH v2 13/17] drm/i915: Stop using mode->private_flags
On Tue, 07 Apr 2020, Ville Syrjälä wrote: > On Tue, Apr 07, 2020 at 09:38:47AM +0200, Daniel Vetter wrote: >> On Fri, Apr 03, 2020 at 11:40:04PM +0300, Ville Syrjala wrote: >> > From: Ville Syrjälä >> > >> > Replace the use of mode->private_flags with a truly private bitmaks >> > in our own crtc state. We also need a copy in the crtc itself so the >> > vblank code can get at it. We already have scanline_offset in there >> > for a similar reason, as well as the vblank->hwmode which is assigned >> > via drm_calc_timestamping_constants(). Fortunately we now have a >> > nice place for doing the crtc_state->crtc copy in >> > intel_crtc_update_active_timings() which gets called both for >> > modesets and init/resume readout. >> > >> > The one slightly iffy spot is the INHERITED flag which we want to >> > preserve until userspace/fb_helper does the first proper commit after >> > actually calling .detecti() on the connectors. Otherwise we don't have >> > the full sink capabilities (audio,infoframes,etc.) when .compute_config() >> > gets called and thus we will fail to enable those features when the >> > first userspace commit happens. The only internal commit we do prior to >> > that should be from intel_initial_commit() and there we can simply >> > preserve the INHERITED flag from the readout. >> > >> > CC: Sam Ravnborg >> > Cc: Daniel Vetter >> > Cc: Emil Velikov >> > Signed-off-by: Ville Syrjälä >> > --- >> > drivers/gpu/drm/i915/display/icl_dsi.c| 13 -- >> > drivers/gpu/drm/i915/display/intel_atomic.c | 1 + >> > drivers/gpu/drm/i915/display/intel_display.c | 24 +-- >> > .../drm/i915/display/intel_display_types.h| 9 ++- >> > drivers/gpu/drm/i915/display/intel_tv.c | 4 ++-- >> > drivers/gpu/drm/i915/display/vlv_dsi.c| 6 ++--- >> > drivers/gpu/drm/i915/i915_irq.c | 4 ++-- >> > 7 files changed, 37 insertions(+), 24 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c >> > b/drivers/gpu/drm/i915/display/icl_dsi.c >> > index 99a25c0bb08f..4d6788ef2e5e 100644 >> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c >> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c >> > @@ -1469,8 +1469,7 @@ static void gen11_dsi_get_config(struct >> > intel_encoder *encoder, >> >pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc); >> > >> >if (gen11_dsi_is_periodic_cmd_mode(intel_dsi)) >> > - pipe_config->hw.adjusted_mode.private_flags |= >> > - I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE; >> > + pipe_config->mode_flags |= I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE; >> > } >> > >> > static int gen11_dsi_dsc_compute_config(struct intel_encoder *encoder, >> > @@ -1555,10 +1554,6 @@ static int gen11_dsi_compute_config(struct >> > intel_encoder *encoder, >> > >> >pipe_config->port_clock = afe_clk(encoder, pipe_config) / 5; >> > >> > - /* We would not operate in periodic command mode */ >> > - pipe_config->hw.adjusted_mode.private_flags &= >> > - ~I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE; >> > - >> >> Since you delete this here, but not above (and then you could also detel >> gen11_dsi_is_periodic_cmd_mode I think): It's dead code, maybe prep patch >> to just garbage collect I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE? > > I think this flag is still WIP. It was added very recently so I'm > assuming there is some plan for it (not that I like adding half > baked dead stuff like this). So we may want to wait a bit to see > where it's going. The reason I deleted this specific statement is > that we zero the crtc state before .compute_config() so this one > would remain dead code even if the flag starts to get used for > something. It's part of a series that's halfway merged. BR, Jani. > >> >> I think the proper replacement is the mode flag stuff below, this is just >> interim stuff that fell through the review. >> >> With that prep patch to get rid of these 2 hunks above: >> >> Reviewed-by: Daniel Vetter >> >> Also surplus Acked-by: Daniel Vetter on the patch >> to delete I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE in case I miss the new >> version. >> -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH RESEND 1/7] drm/dsc: use rc_model_size from DSC config for PPS
> -Original Message- > From: Jani Nikula > Sent: Friday, March 27, 2020 6:12 PM > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: Nikula, Jani ; Alex Deucher > ; Harry Wentland ; Navare, > Manasi D ; Kulkarni, Vandita > > Subject: [PATCH RESEND 1/7] drm/dsc: use rc_model_size from DSC config for > PPS > > The PPS is supposed to reflect the DSC config instead of hard coding the > rc_model_size. Make it so. > > Currently all users of drm_dsc_pps_payload_pack() hard code the size to > 8192 also in the DSC config, so this change should have no impact, other than > allowing the drivers to use other sizes as needed. > > Cc: Alex Deucher > Cc: Harry Wentland > Cc: Manasi Navare > Cc: Vandita Kulkarni > Signed-off-by: Jani Nikula Looks good to me. Reviewed-by: Vandita Kulkarni > --- > drivers/gpu/drm/drm_dsc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c index > 4a475d9696ff..09afbc01ea94 100644 > --- a/drivers/gpu/drm/drm_dsc.c > +++ b/drivers/gpu/drm/drm_dsc.c > @@ -186,8 +186,7 @@ void drm_dsc_pps_payload_pack(struct > drm_dsc_picture_parameter_set *pps_payload, > pps_payload->flatness_max_qp = dsc_cfg->flatness_max_qp; > > /* PPS 38, 39 */ > - pps_payload->rc_model_size = > - cpu_to_be16(DSC_RC_MODEL_SIZE_CONST); > + pps_payload->rc_model_size = cpu_to_be16(dsc_cfg->rc_model_size); > > /* PPS 40 */ > pps_payload->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST; > -- > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH RESEND 2/7] drm/dsc: add helper for calculating rc buffer size from DPCD
> -Original Message-
> From: Jani Nikula
> Sent: Friday, March 27, 2020 6:12 PM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Nikula, Jani ; Alex Deucher
> ; Harry Wentland ; Navare,
> Manasi D ; Kulkarni, Vandita
>
> Subject: [PATCH RESEND 2/7] drm/dsc: add helper for calculating rc buffer size
> from DPCD
>
> Add a helper for calculating the rc buffer size from the DCPD offsets
> DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE.
>
> Cc: Alex Deucher
> Cc: Harry Wentland
> Cc: Manasi Navare
> Cc: Vandita Kulkarni
> Signed-off-by: Jani Nikula
Looks good to me.
Reviewed-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/drm_dsc.c | 27 +++
> include/drm/drm_dsc.h | 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c index
> 09afbc01ea94..ff602f7ec65b 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -49,6 +49,33 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
> *pps_header) } EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
>
> +/**
> + * drm_dsc_dp_rc_buffer_size - get rc buffer size in bytes
> + * @rc_buffer_block_size: block size code, according to DPCD offset 62h
> + * @rc_buffer_size: number of blocks - 1, according to DPCD offset 63h
> + *
> + * return:
> + * buffer size in bytes, or 0 on invalid input */ int
> +drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size) {
> + int size = 1024 * (rc_buffer_size + 1);
> +
> + switch (rc_buffer_block_size) {
> + case DP_DSC_RC_BUF_BLK_SIZE_1:
> + return 1 * size;
> + case DP_DSC_RC_BUF_BLK_SIZE_4:
> + return 4 * size;
> + case DP_DSC_RC_BUF_BLK_SIZE_16:
> + return 16 * size;
> + case DP_DSC_RC_BUF_BLK_SIZE_64:
> + return 64 * size;
> + default:
> + return 0;
> + }
> +}
> +EXPORT_SYMBOL(drm_dsc_dp_rc_buffer_size);
> +
> /**
> * drm_dsc_pps_payload_pack() - Populates the DSC PPS
> *
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h index
> 887954cbfc60..537a68330840 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -602,6 +602,7 @@ struct drm_dsc_pps_infoframe { } __packed;
>
> void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
> +int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8
> +rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set
> *pps_sdp,
> const struct drm_dsc_config *dsc_cfg); int
> drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm: Introduce plane and CRTC scaling filter properties
On Tue, Apr 07, 2020 at 08:28:02PM +0300, Ville Syrjälä wrote:
> On Tue, Mar 31, 2020 at 12:08:53AM +0530, Pankaj Bharadiya wrote:
> > Introduce per-plane and per-CRTC scaling filter properties to allow
> > userspace to select the driver's default scaling filter or
> > Nearest-neighbor(NN) filter for upscaling operations on CRTC and
> > plane.
> >
> > Drivers can set up this property for a plane by calling
> > drm_plane_create_scaling_filter() and for a CRTC by calling
> > drm_crtc_create_scaling_filter().
> >
> > NN filter works by filling in the missing color values in the upscaled
> > image with that of the coordinate-mapped nearest source pixel value.
> >
> > NN filter for integer multiple scaling can be particularly useful for
> > for pixel art games that rely on sharp, blocky images to deliver their
> > distinctive look.
> >
> > changes since v2:
> > * Create per-plane and per-CRTC scaling filter property (Ville)
> > changes since v1:
> > * None
> > changes since RFC:
> > * Add separate properties for plane and CRTC (Ville)
> >
> > Signed-off-by: Pankaj Bharadiya
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 8
> > drivers/gpu/drm/drm_crtc.c| 78 +++
> > drivers/gpu/drm/drm_plane.c | 78 +++
> > include/drm/drm_crtc.h| 16 +++
> > include/drm/drm_plane.h | 21 +
> > 5 files changed, 201 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a1e5e262bae2..ac7dabbf0bcf 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> > *crtc,
> > return -EFAULT;
> >
> > set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> > + } else if (property == crtc->scaling_filter_property) {
> > + state->scaling_filter = val;
> > } else if (crtc->funcs->atomic_set_property) {
> > return crtc->funcs->atomic_set_property(crtc, state, property,
> > val);
> > } else {
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > + else if (property == crtc->scaling_filter_property)
>
> Random side observation: Why do we have two different styles to naming
> these things (prop_foo vs. foo_property)? Would be nice to unify this
> one way or the other.
Need to handle this separately.
All per-plane props follow foo_property convention and we have mixed
conventions for properties in struct drm_mode_config with majority being
foo_property.
>
> > + *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property,
> > val);
> > else
> > @@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > sizeof(struct drm_rect),
> > &replaced);
> > return ret;
> > + } else if (property == plane->scaling_filter_property) {
> > + state->scaling_filter = val;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > } else if (property == config->prop_fb_damage_clips) {
> > *val = (state->fb_damage_clips) ?
> > state->fb_damage_clips->base.id : 0;
> > + } else if (property == plane->scaling_filter_property) {
> > + *val = state->scaling_filter;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state,
> > property, val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 4936e1080e41..95502c88966b 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -748,3 +748,81 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object
> > *obj,
> >
> > return ret;
> > }
> > +
> > +/**
> > + * DOC: CRTC scaling filter property
> > + *
> > + * SCALING_FILTER:
> > + *
> > + * Indicates scaling filter to be used for CRTC scaler
> > + *
> > + * The value of this property can be one of the following:
> > + * Default:
> > + * Driver's default scaling filter
> > + * Nearest Neighbor:
> > + * Nearest Neighbor scaling filter
> > + *
> > + * Drivers can set up this property for a CRTC by calling
> > + * drm_crtc_create_scaling_filter_property
> > + */
> > +
> > +/**
> > + * drm_crtc_create_scaling_filter_property - create a new scaling filter
> > + * property
> > + *
RE: [PATCH RESEND 4/7] drm/i915/dsc: configure hardware using specified rc_model_size
> -Original Message-
> From: Jani Nikula
> Sent: Friday, March 27, 2020 6:12 PM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Nikula, Jani ; Navare, Manasi D
> ; Kulkarni, Vandita
> Subject: [PATCH RESEND 4/7] drm/i915/dsc: configure hardware using
> specified rc_model_size
>
> The rc_model_size is specified in the DSC config, and the hardware
> programming should respect that instead of hard coding a value of 8192.
>
> Regardless, the rc_model_size in DSC config is currently hard coded to the
> same value, so this should have no impact, other than allowing the use of
> other
> sizes as needed.
>
> Cc: Manasi Navare
> Cc: Vandita Kulkarni
> Signed-off-by: Jani Nikula
Looks good to me.
Reviewed-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 95ad87d4ccb3..1f74b0174b1a 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -740,7 +740,7 @@ static void intel_dsc_pps_configure(struct
> intel_encoder *encoder,
>
> /* Populate PICTURE_PARAMETER_SET_9 registers */
> pps_val = 0;
> - pps_val |= DSC_RC_MODEL_SIZE(DSC_RC_MODEL_SIZE_CONST) |
> + pps_val |= DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
> DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST);
> drm_info(&dev_priv->drm, "PPS9 = 0x%08x\n", pps_val);
> if (!is_pipe_dsc(crtc_state)) {
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH RESEND 6/7] drm/i915/bios: fill in DSC rc_model_size from VBT
> -Original Message- > From: Jani Nikula > Sent: Friday, March 27, 2020 6:12 PM > To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: Nikula, Jani ; Navare, Manasi D > ; Kulkarni, Vandita > Subject: [PATCH RESEND 6/7] drm/i915/bios: fill in DSC rc_model_size from > VBT > > The VBT fields match the DPCD data, so use the same helper. > > Cc: Manasi Navare > Cc: Vandita Kulkarni > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_bios.c | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c > b/drivers/gpu/drm/i915/display/intel_bios.c > index 839124647202..a4ea0e6c3286 100644 > --- a/drivers/gpu/drm/i915/display/intel_bios.c > +++ b/drivers/gpu/drm/i915/display/intel_bios.c > @@ -2494,16 +2494,11 @@ static void fill_dsc(struct intel_crtc_state > *crtc_state, > crtc_state->dsc.slice_count); > > /* > - * FIXME: Use VBT rc_buffer_block_size and rc_buffer_size for the > - * implementation specific physical rate buffer size. Currently we use > - * the required rate buffer model size calculated in > - * drm_dsc_compute_rc_parameters() according to VESA DSC Annex E. > - * >* The VBT rc_buffer_block_size and rc_buffer_size definitions > - * correspond to DP 1.4 DPCD offsets 0x62 and 0x63. The DP DSC > - * implementation should also use the DPCD (or perhaps VBT for eDP) > - * provided value for the buffer size. > + * correspond to DP 1.4 DPCD offsets 0x62 and 0x63. >*/ > + vdsc_cfg->rc_model_size = drm_dsc_dp_rc_buffer_size(dsc- > >rc_buffer_block_size, > + dsc- > >rc_buffer_size); Do we need to handle the invalid case here? Regards Vandita > > /* FIXME: DSI spec says bpc + 1 for this one */ > vdsc_cfg->line_buf_depth = VBT_DSC_LINE_BUFFER_DEPTH(dsc- > >line_buffer_depth); > -- > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: NT39016: Add support for 50 Hz refresh rate
Hi Paul.
On Wed, Apr 08, 2020 at 11:58:30AM +0200, Paul Cercueil wrote:
> By changing the pixel clock and the length of the back porch, it is
> possible to obtain a perfect 50 Hz refresh rate.
>
> Signed-off-by: Paul Cercueil
Lower case in $subject.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/panel-novatek-nt39016.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> index f1286cf6528b..05cae8d62d56 100644
> --- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> +++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> @@ -325,7 +325,7 @@ static int nt39016_remove(struct spi_device *spi)
> }
>
> static const struct drm_display_mode kd035g6_display_modes[] = {
> - {
> + { /* 60 Hz */
> .clock = 6000,
> .hdisplay = 320,
> .hsync_start = 320 + 10,
> @@ -338,6 +338,19 @@ static const struct drm_display_mode
> kd035g6_display_modes[] = {
> .vrefresh = 60,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> },
> + { /* 50 Hz */
> + .clock = 5400,
> + .hdisplay = 320,
> + .hsync_start = 320 + 42,
> + .hsync_end = 320 + 42 + 50,
> + .htotal = 320 + 42 + 50 + 20,
> + .vdisplay = 240,
> + .vsync_start = 240 + 5,
> + .vsync_end = 240 + 5 + 1,
> + .vtotal = 240 + 5 + 1 + 4,
> + .vrefresh = 50,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> + },
> };
>
> static const struct nt39016_panel_info kd035g6_info = {
> --
> 2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panel: NT39016: Add support for multiple modes
Hi Paul.
On Wed, Apr 08, 2020 at 11:58:29AM +0200, Paul Cercueil wrote:
> Add support for multiple drm_display_mode entries. This will allow to
> add a 50 Hz mode later.
>
> Signed-off-by: Paul Cercueil
Patch looks good.
Could we please use lower case in the $subject?
Acked-by: Sam Ravnborg
I asume you will apply yourself.
Sam
> ---
> drivers/gpu/drm/panel/panel-novatek-nt39016.c | 33 +--
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> index a470810f7dbe..f1286cf6528b 100644
> --- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> +++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> @@ -49,7 +49,8 @@ enum nt39016_regs {
> #define NT39016_SYSTEM_STANDBY BIT(1)
>
> struct nt39016_panel_info {
> - struct drm_display_mode display_mode;
> + const struct drm_display_mode *display_modes;
> + unsigned int num_modes;
> u16 width_mm, height_mm;
> u32 bus_format, bus_flags;
> };
> @@ -212,15 +213,22 @@ static int nt39016_get_modes(struct drm_panel
> *drm_panel,
> struct nt39016 *panel = to_nt39016(drm_panel);
> const struct nt39016_panel_info *panel_info = panel->panel_info;
> struct drm_display_mode *mode;
> + unsigned int i;
>
> - mode = drm_mode_duplicate(connector->dev, &panel_info->display_mode);
> - if (!mode)
> - return -ENOMEM;
> + for (i = 0; i < panel_info->num_modes; i++) {
> + mode = drm_mode_duplicate(connector->dev,
> + &panel_info->display_modes[i]);
> + if (!mode)
> + return -ENOMEM;
> +
> + drm_mode_set_name(mode);
>
> - drm_mode_set_name(mode);
> + mode->type = DRM_MODE_TYPE_DRIVER;
> + if (panel_info->num_modes == 1)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
>
> - mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> - drm_mode_probed_add(connector, mode);
> + drm_mode_probed_add(connector, mode);
> + }
>
> connector->display_info.bpc = 8;
> connector->display_info.width_mm = panel_info->width_mm;
> @@ -230,7 +238,7 @@ static int nt39016_get_modes(struct drm_panel *drm_panel,
>&panel_info->bus_format, 1);
> connector->display_info.bus_flags = panel_info->bus_flags;
>
> - return 1;
> + return panel_info->num_modes;
> }
>
> static const struct drm_panel_funcs nt39016_funcs = {
> @@ -316,8 +324,8 @@ static int nt39016_remove(struct spi_device *spi)
> return 0;
> }
>
> -static const struct nt39016_panel_info kd035g6_info = {
> - .display_mode = {
> +static const struct drm_display_mode kd035g6_display_modes[] = {
> + {
> .clock = 6000,
> .hdisplay = 320,
> .hsync_start = 320 + 10,
> @@ -330,6 +338,11 @@ static const struct nt39016_panel_info kd035g6_info = {
> .vrefresh = 60,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> },
> +};
> +
> +static const struct nt39016_panel_info kd035g6_info = {
> + .display_modes = kd035g6_display_modes,
> + .num_modes = ARRAY_SIZE(kd035g6_display_modes),
> .width_mm = 71,
> .height_mm = 53,
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> --
> 2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: mb862xx: remove set but not used variable 'mdr'
Hi Jason.
On Fri, Apr 03, 2020 at 10:25:53AM +0800, Jason Yan wrote:
> Fix the following gcc warning:
>
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c:187:6: warning: variable
> ‘mdr’ set but not used [-Wunused-but-set-variable]
> int mdr;
> ^~~
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Thanks, committed to drm-misc-next.
The fix will show up durign the next merge window.
Sam
> ---
> drivers/video/fbdev/mb862xx/mb862xxfb_accel.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
> b/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
> index 42569264801f..d40b806461ca 100644
> --- a/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
> +++ b/drivers/video/fbdev/mb862xx/mb862xxfb_accel.c
> @@ -184,7 +184,6 @@ static void mb86290fb_imageblit16(u32 *cmd, u16 step, u16
> dx, u16 dy,
> static void mb86290fb_imageblit(struct fb_info *info,
> const struct fb_image *image)
> {
> - int mdr;
> u32 *cmd = NULL;
> void (*cmdfn) (u32 *, u16, u16, u16, u16, u16, u32, u32,
> const struct fb_image *, struct fb_info *) = NULL;
> @@ -196,7 +195,6 @@ static void mb86290fb_imageblit(struct fb_info *info,
> u16 dx = image->dx, dy = image->dy;
> int x2, y2, vxres, vyres;
>
> - mdr = (GDC_ROP_COPY << 9);
> x2 = image->dx + image->width;
> y2 = image->dy + image->height;
> vxres = info->var.xres_virtual;
> --
> 2.17.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: matroxfb: remove dead code and set but not used variable
Hi Jason.
On Fri, Apr 03, 2020 at 10:16:09AM +0800, Jason Yan wrote:
> Fix the following gcc warning:
>
> drivers/video/fbdev/matrox/g450_pll.c:336:15: warning: variable
> ‘pixel_vco’ set but not used [-Wunused-but-set-variable]
> unsigned int pixel_vco;
>^
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Thanks, committed and pushed to drm-misc-next.
The fix will show up in upstream kernel at the next
merge window.
Sam
> ---
> drivers/video/fbdev/matrox/g450_pll.c | 22 --
> 1 file changed, 22 deletions(-)
>
> diff --git a/drivers/video/fbdev/matrox/g450_pll.c
> b/drivers/video/fbdev/matrox/g450_pll.c
> index c15f8a57498e..ff8e321a22ce 100644
> --- a/drivers/video/fbdev/matrox/g450_pll.c
> +++ b/drivers/video/fbdev/matrox/g450_pll.c
> @@ -333,11 +333,9 @@ static int __g450_setclk(struct matrox_fb_info *minfo,
> unsigned int fout,
>unsigned int *deltaarray)
> {
> unsigned int mnpcount;
> - unsigned int pixel_vco;
> const struct matrox_pll_limits* pi;
> struct matrox_pll_cache* ci;
>
> - pixel_vco = 0;
> switch (pll) {
> case M_PIXEL_PLL_A:
> case M_PIXEL_PLL_B:
> @@ -420,7 +418,6 @@ static int __g450_setclk(struct matrox_fb_info *minfo,
> unsigned int fout,
>
> mnp = matroxfb_DAC_in(minfo, M1064_XPIXPLLCM)
> << 16;
> mnp |= matroxfb_DAC_in(minfo, M1064_XPIXPLLCN)
> << 8;
> - pixel_vco = g450_mnp2vco(minfo, mnp);
> matroxfb_DAC_unlock_irqrestore(flags);
> }
> pi = &minfo->limits.video;
> @@ -441,25 +438,6 @@ static int __g450_setclk(struct matrox_fb_info *minfo,
> unsigned int fout,
> unsigned int delta;
>
> vco = g450_mnp2vco(minfo, mnp);
> -#if 0
> - if (pll == M_VIDEO_PLL) {
> - unsigned int big, small;
> -
> - if (vco < pixel_vco) {
> - small = vco;
> - big = pixel_vco;
> - } else {
> - small = pixel_vco;
> - big = vco;
> - }
> - while (big > small) {
> - big >>= 1;
> - }
> - if (big == small) {
> - continue;
> - }
> - }
> -#endif
> delta = pll_freq_delta(fout, g450_vco2f(mnp, vco));
> for (idx = mnpcount; idx > 0; idx--) {
> /* == is important; due to nextpll algorithm we
> get
> --
> 2.17.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vram-helpers: Merge code into a single file
Hi Thomas.
On Tue, Mar 31, 2020 at 10:12:38AM +0200, Thomas Zimmermann wrote:
> Most of the documentation was in an otherwise empty file, which was
> probably just left from a previous clean-up effort. So move code and
> documentation into a single file.
>
> Signed-off-by: Thomas Zimmermann
Nice clean-up
Acked-by: Sam Ravnborg
> ---
> Documentation/gpu/drm-mm.rst | 9 ---
> drivers/gpu/drm/Makefile | 3 +-
> drivers/gpu/drm/drm_gem_vram_helper.c| 95 ++--
> drivers/gpu/drm/drm_vram_helper_common.c | 94 ---
> 4 files changed, 91 insertions(+), 110 deletions(-)
> delete mode 100644 drivers/gpu/drm/drm_vram_helper_common.c
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index c77b326012606..1839762044be1 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -373,15 +373,6 @@ GEM CMA Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
> :export:
>
> -VRAM Helper Function Reference
> -==
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_vram_helper_common.c
> - :doc: overview
> -
> -.. kernel-doc:: include/drm/drm_gem_vram_helper.h
> - :internal:
> -
> GEM VRAM Helper Functions Reference
> ---
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 183c600483073..f34d08c834851 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -33,8 +33,7 @@ drm-$(CONFIG_PCI) += drm_pci.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>
> -drm_vram_helper-y := drm_gem_vram_helper.o \
> - drm_vram_helper_common.o
> +drm_vram_helper-y := drm_gem_vram_helper.o
> obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
>
> drm_ttm_helper-y := drm_gem_ttm_helper.o
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index d4e4f80d3a6c1..d70e335f7ee3e 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1,5 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
>
> +#include
> +
> #include
> #include
> #include
> @@ -19,13 +21,93 @@ static const struct drm_gem_object_funcs
> drm_gem_vram_object_funcs;
> /**
> * DOC: overview
> *
> - * This library provides a GEM buffer object that is backed by video RAM
> - * (VRAM). It can be used for framebuffer devices with dedicated memory.
> + * This library provides &struct drm_gem_vram_object (GEM VRAM), a GEM
> + * buffer object that is backed by video RAM (VRAM). It can be used for
> + * framebuffer devices with dedicated memory.
> *
> * The data structure &struct drm_vram_mm and its helpers implement a memory
> - * manager for simple framebuffer devices with dedicated video memory. Buffer
> - * objects are either placed in video RAM or evicted to system memory. The
> rsp.
> - * buffer object is provided by &struct drm_gem_vram_object.
> + * manager for simple framebuffer devices with dedicated video memory. GEM
> + * VRAM buffer objects are either placed in the video memory or remain
> evicted
> + * to system memory.
> + *
> + * With the GEM interface userspace applications create, manage and destroy
> + * graphics buffers, such as an on-screen framebuffer. GEM does not provide
> + * an implementation of these interfaces. It's up to the DRM driver to
> + * provide an implementation that suits the hardware. If the hardware device
> + * contains dedicated video memory, the DRM driver can use the VRAM helper
> + * library. Each active buffer object is stored in video RAM. Active
> + * buffer are used for drawing the current frame, typically something like
> + * the frame's scanout buffer or the cursor image. If there's no more space
> + * left in VRAM, inactive GEM objects can be moved to system memory.
> + *
> + * The easiest way to use the VRAM helper library is to call
> + * drm_vram_helper_alloc_mm(). The function allocates and initializes an
> + * instance of &struct drm_vram_mm in &struct drm_device.vram_mm . Use
> + * &DRM_GEM_VRAM_DRIVER to initialize &struct drm_driver and
> + * &DRM_VRAM_MM_FILE_OPERATIONS to initialize &struct file_operations;
> + * as illustrated below.
> + *
> + * .. code-block:: c
> + *
> + * struct file_operations fops ={
> + * .owner = THIS_MODULE,
> + * DRM_VRAM_MM_FILE_OPERATION
> + * };
> + * struct drm_driver drv = {
> + * .driver_feature = DRM_ ... ,
> + * .fops = &fops,
> + * DRM_GEM_VRAM_DRIVER
> + * };
> + *
> + * int init_drm_driver()
> + * {
> + * struct drm_device *dev;
> + * uint64_t vram_base;
> + * unsigned long vram_size;
> + * int ret;
> + *
> + * // setup device, vram base and size
> + * // ...
> + *
> + * ret = drm_vram
Re: [PATCH 1/2] drm/panel: NT39016: Add support for multiple modes
On Wed, Apr 08, 2020 at 12:12:26PM +0200, Paul Cercueil wrote:
> Hi Sam,
>
>
> Le mer. 8 avril 2020 à 12:04, Sam Ravnborg a écrit :
> > Hi Paul.
> >
> > On Wed, Apr 08, 2020 at 11:58:29AM +0200, Paul Cercueil wrote:
> > > Add support for multiple drm_display_mode entries. This will allow
> > > to
> > > add a 50 Hz mode later.
> > >
> > > Signed-off-by: Paul Cercueil
> > Patch looks good.
> >
> > Could we please use lower case in the $subject?
>
> You mean 's/Add/add/' or the panel name as well?
The panel name. We are not consistent if we start sentences in $subject
with lower or upper case - so Add and add are both fine.
But the panel name is (almost) always with lower case.
Sam
>
> -Paul
>
> > Acked-by: Sam Ravnborg
> >
> > I asume you will apply yourself.
> >
> > Sam
> >
> > > ---
> > > drivers/gpu/drm/panel/panel-novatek-nt39016.c | 33
> > > +--
> > > 1 file changed, 23 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> > > b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> > > index a470810f7dbe..f1286cf6528b 100644
> > > --- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> > > +++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
> > > @@ -49,7 +49,8 @@ enum nt39016_regs {
> > > #define NT39016_SYSTEM_STANDBY BIT(1)
> > >
> > > struct nt39016_panel_info {
> > > -struct drm_display_mode display_mode;
> > > +const struct drm_display_mode *display_modes;
> > > +unsigned int num_modes;
> > > u16 width_mm, height_mm;
> > > u32 bus_format, bus_flags;
> > > };
> > > @@ -212,15 +213,22 @@ static int nt39016_get_modes(struct drm_panel
> > > *drm_panel,
> > > struct nt39016 *panel = to_nt39016(drm_panel);
> > > const struct nt39016_panel_info *panel_info = panel->panel_info;
> > > struct drm_display_mode *mode;
> > > +unsigned int i;
> > >
> > > -mode = drm_mode_duplicate(connector->dev,
> > > &panel_info->display_mode);
> > > -if (!mode)
> > > -return -ENOMEM;
> > > +for (i = 0; i < panel_info->num_modes; i++) {
> > > +mode = drm_mode_duplicate(connector->dev,
> > > +
> > > &panel_info->display_modes[i]);
> > > +if (!mode)
> > > +return -ENOMEM;
> > > +
> > > +drm_mode_set_name(mode);
> > >
> > > -drm_mode_set_name(mode);
> > > +mode->type = DRM_MODE_TYPE_DRIVER;
> > > +if (panel_info->num_modes == 1)
> > > +mode->type |= DRM_MODE_TYPE_PREFERRED;
> > >
> > > -mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > > -drm_mode_probed_add(connector, mode);
> > > +drm_mode_probed_add(connector, mode);
> > > +}
> > >
> > > connector->display_info.bpc = 8;
> > > connector->display_info.width_mm = panel_info->width_mm;
> > > @@ -230,7 +238,7 @@ static int nt39016_get_modes(struct drm_panel
> > > *drm_panel,
> > >&panel_info->bus_format, 1);
> > > connector->display_info.bus_flags = panel_info->bus_flags;
> > >
> > > -return 1;
> > > +return panel_info->num_modes;
> > > }
> > >
> > > static const struct drm_panel_funcs nt39016_funcs = {
> > > @@ -316,8 +324,8 @@ static int nt39016_remove(struct spi_device
> > > *spi)
> > > return 0;
> > > }
> > >
> > > -static const struct nt39016_panel_info kd035g6_info = {
> > > -.display_mode = {
> > > +static const struct drm_display_mode kd035g6_display_modes[] = {
> > > +{
> > > .clock = 6000,
> > > .hdisplay = 320,
> > > .hsync_start = 320 + 10,
> > > @@ -330,6 +338,11 @@ static const struct nt39016_panel_info
> > > kd035g6_info = {
> > > .vrefresh = 60,
> > > .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> > > },
> > > +};
> > > +
> > > +static const struct nt39016_panel_info kd035g6_info = {
> > > +.display_modes = kd035g6_display_modes,
> > > +.num_modes = ARRAY_SIZE(kd035g6_display_modes),
> > > .width_mm = 71,
> > > .height_mm = 53,
> > > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > > --
> > > 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 4/6] dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML
Hi Maxime,
On Tue, Apr 07, 2020 at 09:12:51AM +0200, Maxime Ripard wrote:
> On Mon, Apr 06, 2020 at 08:50:28PM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 06, 2020 at 07:09:15PM +0200, Maxime Ripard wrote:
> > > On Mon, Apr 06, 2020 at 02:19:27PM +0300, Laurent Pinchart wrote:
> > > > On Mon, Apr 06, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> > > > > On Mon, Apr 06, 2020 at 02:39:33AM +0300, Laurent Pinchart wrote:
> > > > > > Convert the Rockchip HDMI TX text binding to YAML.
> > > > > >
> > > > > > Signed-off-by: Laurent Pinchart
> > > > > >
> > > > > > ---
> > > > > > .../display/rockchip/dw_hdmi-rockchip.txt | 74
> > > > > > .../display/rockchip/rockchip,dw-hdmi.yaml| 178
> > > > > > ++
> > > > > > 2 files changed, 178 insertions(+), 74 deletions(-)
> > > > > > delete mode 100644
> > > > > > Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > create mode 100644
> > > > > > Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > >
> > > > > > b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > deleted file mode 100644
> > > > > > index 3d32ce137e7f..
> > > > > > ---
> > > > > > a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> > > > > > +++ /dev/null
> > > > > > @@ -1,74 +0,0 @@
> > > > > > -Rockchip DWC HDMI TX Encoder
> > > > > > -
> > > > > > -
> > > > > > -The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX
> > > > > > controller IP
> > > > > > -with a companion PHY IP.
> > > > > > -
> > > > > > -These DT bindings follow the Synopsys DWC HDMI TX bindings defined
> > > > > > in
> > > > > > -Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with
> > > > > > the
> > > > > > -following device-specific properties.
> > > > > > -
> > > > > > -
> > > > > > -Required properties:
> > > > > > -
> > > > > > -- compatible: should be one of the following:
> > > > > > - "rockchip,rk3228-dw-hdmi"
> > > > > > - "rockchip,rk3288-dw-hdmi"
> > > > > > - "rockchip,rk3328-dw-hdmi"
> > > > > > - "rockchip,rk3399-dw-hdmi"
> > > > > > -- reg: See dw_hdmi.txt.
> > > > > > -- reg-io-width: See dw_hdmi.txt. Shall be 4.
> > > > > > -- interrupts: HDMI interrupt number
> > > > > > -- clocks: See dw_hdmi.txt.
> > > > > > -- clock-names: Shall contain "iahb" and "isfr" as defined in
> > > > > > dw_hdmi.txt.
> > > > > > -- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port
> > > > > > numbered 0
> > > > > > - corresponding to the video input of the controller. The port
> > > > > > shall have two
> > > > > > - endpoints, numbered 0 and 1, connected respectively to the vopb
> > > > > > and vopl.
> > > > > > -- rockchip,grf: Shall reference the GRF to mux vopl/vopb.
> > > > > > -
> > > > > > -Optional properties
> > > > > > -
> > > > > > -- ddc-i2c-bus: The HDMI DDC bus can be connected to either a
> > > > > > system I2C master
> > > > > > - or the functionally-reduced I2C master contained in the DWC
> > > > > > HDMI. When
> > > > > > - connected to a system I2C master this property contains a
> > > > > > phandle to that
> > > > > > - I2C master controller.
> > > > > > -- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
> > > > > > -- clock-names: May contain "cec" as defined in dw_hdmi.txt.
> > > > > > -- clock-names: May contain "grf", power for grf io.
> > > > > > -- clock-names: May contain "vpll", external clock for some hdmi
> > > > > > phy.
> > > > > > -- phys: from general PHY binding: the phandle for the PHY device.
> > > > > > -- phy-names: Should be "hdmi" if phys references an external phy.
> > > > > > -
> > > > > > -Optional pinctrl entry:
> > > > > > -- If you have both a "unwedge" and "default" pinctrl entry, dw_hdmi
> > > > > > - will switch to the unwedge pinctrl state for 10ms if it ever
> > > > > > gets an
> > > > > > - i2c timeout. It's intended that this unwedge pinctrl entry will
> > > > > > - cause the SDA line to be driven low to work around a hardware
> > > > > > - errata.
> > > > > > -
> > > > > > -Example:
> > > > > > -
> > > > > > -hdmi: hdmi@ff98 {
> > > > > > - compatible = "rockchip,rk3288-dw-hdmi";
> > > > > > - reg = <0xff98 0x2>;
> > > > > > - reg-io-width = <4>;
> > > > > > - ddc-i2c-bus = <&i2c5>;
> > > > > > - rockchip,grf = <&grf>;
> > > > > > - interrupts = ;
> > > > > > - clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
> > > > > > - clock-names = "iahb", "isfr";
> > > > > > - ports {
> > > > > > - hdmi_in: port {
> > > > > > - #address-cells = <1>;
> > > > > > - #size-cells = <0>;
> > > > > > - hdmi_in_vopb: endpoint@0 {
> > > > > > - reg =
[PATCH] drm/ttm: Temporarily disable the huge_fault() callback
From: "Thomas Hellstrom (VMware)"
With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are
errors like:
BUG: non-zero pgtables_bytes on freeing mm
and:
BUG: Bad rss-counter state
with TTM transparent huge-pages.
Until we've figured out what other TTM drivers do differently compared to
vmwgfx, disable the huge_fault() callback, eliminating transhuge
page-table entries.
Cc: Christian König
Signed-off-by: Thomas Hellstrom (VMware)
Reported-by: Alex Xu (Hello71)
Tested-by: Alex Xu (Hello71)
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 63 -
1 file changed, 63 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 6ee3b96f0d13..0ad30b112982 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -442,66 +442,6 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
}
EXPORT_SYMBOL(ttm_bo_vm_fault);
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-/**
- * ttm_pgprot_is_wrprotecting - Is a page protection value write-protecting?
- * @prot: The page protection value
- *
- * Return: true if @prot is write-protecting. false otherwise.
- */
-static bool ttm_pgprot_is_wrprotecting(pgprot_t prot)
-{
- /*
-* This is meant to say "pgprot_wrprotect(prot) == prot" in a generic
-* way. Unfortunately there is no generic pgprot_wrprotect.
-*/
- return pte_val(pte_wrprotect(__pte(pgprot_val(prot ==
- pgprot_val(prot);
-}
-
-static vm_fault_t ttm_bo_vm_huge_fault(struct vm_fault *vmf,
- enum page_entry_size pe_size)
-{
- struct vm_area_struct *vma = vmf->vma;
- pgprot_t prot;
- struct ttm_buffer_object *bo = vma->vm_private_data;
- vm_fault_t ret;
- pgoff_t fault_page_size = 0;
- bool write = vmf->flags & FAULT_FLAG_WRITE;
-
- switch (pe_size) {
- case PE_SIZE_PMD:
- fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
- break;
-#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
- case PE_SIZE_PUD:
- fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
- break;
-#endif
- default:
- WARN_ON_ONCE(1);
- return VM_FAULT_FALLBACK;
- }
-
- /* Fallback on write dirty-tracking or COW */
- if (write && ttm_pgprot_is_wrprotecting(vma->vm_page_prot))
- return VM_FAULT_FALLBACK;
-
- ret = ttm_bo_vm_reserve(bo, vmf);
- if (ret)
- return ret;
-
- prot = vm_get_page_prot(vma->vm_flags);
- ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
- if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
- return ret;
-
- dma_resv_unlock(bo->base.resv);
-
- return ret;
-}
-#endif
-
void ttm_bo_vm_open(struct vm_area_struct *vma)
{
struct ttm_buffer_object *bo = vma->vm_private_data;
@@ -604,9 +544,6 @@ static const struct vm_operations_struct ttm_bo_vm_ops = {
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
.access = ttm_bo_vm_access,
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- .huge_fault = ttm_bo_vm_huge_fault,
-#endif
};
static struct ttm_buffer_object *ttm_bo_vm_lookup(struct ttm_bo_device *bdev,
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Temporarily disable the huge_fault() callback
Hi, Christian, On 4/8/20 1:53 PM, Thomas Hellström (VMware) wrote: From: "Thomas Hellstrom (VMware)" With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are errors like: BUG: non-zero pgtables_bytes on freeing mm and: BUG: Bad rss-counter state with TTM transparent huge-pages. Until we've figured out what other TTM drivers do differently compared to vmwgfx, disable the huge_fault() callback, eliminating transhuge page-table entries. Cc: Christian König Signed-off-by: Thomas Hellstrom (VMware) Reported-by: Alex Xu (Hello71) Tested-by: Alex Xu (Hello71) --- Without being able to test and track this down on amdgpu there's little more than this I can do at the moment. Hopefully I'll be able to test on nouveau/ttm after getting back from vacation to see if I can reproduce. It looks like some part of the kernel mistakes a huge page-table entry for a page directory, and that would be a path that is not hit with vmwgfx. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] gpu/drm: ingenic: Switch emulated fbdev to 16bpp
On Wed, Feb 26, 2020 at 01:30:40AM -0300, Paul Cercueil wrote: > The fbdev emulation is only ever used on Ingenic SoCs to run old SDL1 > based games at 16bpp (rgb565). Recent applications generally talk to > DRM directly, and can request their favourite pixel format; so we can > make everybody happy by switching the emulated fbdev to 16bpp. > > v2: No change > > Signed-off-by: Paul Cercueil > --- > drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c > b/drivers/gpu/drm/ingenic/ingenic-drm.c > index 5493a80d7d2f..3f8cc98d41fe 100644 > --- a/drivers/gpu/drm/ingenic/ingenic-drm.c > +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c > @@ -807,7 +807,7 @@ static int ingenic_drm_probe(struct platform_device *pdev) > goto err_devclk_disable; > } > > - ret = drm_fbdev_generic_setup(drm, 32); > + ret = drm_fbdev_generic_setup(drm, 16); This will conflict with Thomas' work to remove the error code, so might need a rebase. Now for the patch itself your supposed to set drm_device->mode_config.preferred_bpp and leave this here as 0. That way userspace can also know what's the best option. Maybe in the future we could auto-compute the preferred_bpp from just taking the first format of the first primary plane, but atm not there. With the above change: Reviewed-by: Daniel Vetter > if (ret) > dev_warn(dev, "Unable to start fbdev emulation: %i", ret); > > -- > 2.25.0 > -- 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 v2 3/3] gpu/drm: ingenic: Add option to mmap GEM buffers cached
On Wed, Feb 26, 2020 at 01:30:41AM -0300, Paul Cercueil wrote:
> Ingenic SoCs are most notably used in cheap chinese handheld gaming
> consoles. There, the games and applications generally render in software
> directly in the emulated framebuffer using SDL1.
>
> Since the emulated framebuffer is mapped as write-combine by default,
> these applications start to run really slow as soon as alpha-blending is
> used.
>
> Add a 'cached_gem_buffers' option to the ingenic-drm driver to mmap the
> GEM buffers as fully cached to address this issue.
>
> v2: Use standard noncoherent DMA APIs
>
> Signed-off-by: Paul Cercueil
Dumb buffers don't have any cache flushing controls, so without a ->dirty
callback I'm not sure how this exactly works. I think you need a pile more
here.
Also there's a prefere_shadow bit that you're supposed to set in this
case, and which userspace is supposed to obey.
Also kinda surprised that fbdev userspace is this bad, since generally all
of fbdev is wc. Traditionally at least.
-Daniel
> ---
> drivers/gpu/drm/ingenic/ingenic-drm.c | 35 +--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
> b/drivers/gpu/drm/ingenic/ingenic-drm.c
> index 3f8cc98d41fe..e51ac8d62d27 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
> @@ -6,6 +6,8 @@
>
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -30,6 +32,11 @@
> #include
> #include
>
> +static bool ingenic_drm_cached_gem_buf;
> +module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, bool,
> 0400);
> +MODULE_PARM_DESC(cached_gem_buffers,
> + "Enable fully cached GEM buffers [default=false]");
> +
> #define JZ_REG_LCD_CFG 0x00
> #define JZ_REG_LCD_VSYNC 0x04
> #define JZ_REG_LCD_HSYNC 0x08
> @@ -379,15 +386,23 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> struct drm_plane_state *state = plane->state;
> unsigned int width, height, cpp;
> dma_addr_t addr;
> + uint32_t len;
>
> if (state && state->fb) {
> addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
> +
> width = state->src_w >> 16;
> height = state->src_h >> 16;
> cpp = state->fb->format->cpp[plane->index];
> + len = width * height * cpp;
> +
> + if (ingenic_drm_cached_gem_buf) {
> + dma_cache_sync(priv->dev, phys_to_virt(addr),
> +len, DMA_TO_DEVICE);
> + }
>
> priv->dma_hwdesc->addr = addr;
> - priv->dma_hwdesc->cmd = width * height * cpp / 4;
> + priv->dma_hwdesc->cmd = len / 4;
> priv->dma_hwdesc->cmd |= JZ_LCD_CMD_EOF_IRQ;
> }
> }
> @@ -532,6 +547,22 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
> *crtc)
>
> DEFINE_DRM_GEM_CMA_FOPS(ingenic_drm_fops);
>
> +static int ingenic_drm_gem_mmap(struct drm_gem_object *obj,
> + struct vm_area_struct *vma)
> +{
> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
> + struct ingenic_drm *priv = drm_device_get_priv(obj->dev);
> + unsigned long attrs = DMA_ATTR_NON_CONSISTENT;
> +
> + if (!ingenic_drm_cached_gem_buf)
> + return drm_gem_cma_prime_mmap(obj, vma);
> +
> + vma->vm_page_prot = dma_pgprot(priv->dev, vma->vm_page_prot, attrs);
> +
> + return dma_mmap_attrs(priv->dev, vma, cma_obj->vaddr, cma_obj->paddr,
> + vma->vm_end - vma->vm_start, attrs);
> +}
> +
> static struct drm_driver ingenic_drm_driver_data = {
> .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
> .name = "ingenic-drm",
> @@ -553,7 +584,7 @@ static struct drm_driver ingenic_drm_driver_data = {
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
> .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + .gem_prime_mmap = ingenic_drm_gem_mmap,
>
> .irq_handler= ingenic_drm_irq_handler,
> .release= ingenic_drm_release,
> --
> 2.25.0
>
--
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 02/44] drm: Add devm_drm_dev_alloc macro
On Wed, Apr 08, 2020 at 08:57:14AM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> Finally managed to dive into this..
>
> Maybe I need more coffee, it is still morning here.
> But alas this patch triggered a few comments.
>
> Sam
>
> On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> > The kerneldoc is only added for this new function. Existing kerneldoc
> > and examples will be udated at the very end, since once all drivers
> > are converted over to devm_drm_dev_alloc we can unexport a lot of
> > interim functions and make the documentation for driver authors a lot
> > cleaner and less confusing. There will be only one true way to
> > initialize a drm_device at the end of this, which is going to be
> > devm_drm_dev_alloc.
>
> This changelog entry does a poor job describing what the purpose of this
> change is.
> Try to read it outside context.
Something like:
Add a new macro helper to combine the usual init sequence in drivers,
consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree
triplet. This allows us to remove the rather unsightly
drmm_add_final_kfree from all currently merged drivers.
This good enough, as an intro paragraph?
>
>
> >
> > Cc: Paul Kocialkowski
> > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 23 +++
> > include/drm/drm_drv.h | 33 +
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 1bb4f636b83c..9e60b784b3ac 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -739,6 +739,29 @@ int devm_drm_dev_init(struct device *parent,
> > }
> > EXPORT_SYMBOL(devm_drm_dev_init);
> >
> > +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver
> > *driver,
> > + size_t size, size_t offset)
> > +{
> > + void *container;
> > + struct drm_device *drm;
> > + int ret;
> > +
> > + container = kzalloc(size, GFP_KERNEL);
> > + if (!container)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + drm = container + offset;
> > + ret = devm_drm_dev_init(parent, drm, driver);
> > + if (ret) {
> > + kfree(container);
> > + return ERR_PTR(ret);
> > + }
> > + drmm_add_final_kfree(drm, container);
> > +
> > + return container;
> > +}
> > +EXPORT_SYMBOL(__devm_drm_dev_alloc);
> > +
> > /**
> > * drm_dev_alloc - Allocate new DRM device
> > * @driver: DRM driver to allocate device for
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index e7c6ea261ed1..26776be5a21e 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -626,6 +626,39 @@ int devm_drm_dev_init(struct device *parent,
> > struct drm_device *dev,
> > struct drm_driver *driver);
> >
> > +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver
> > *driver,
> > + size_t size, size_t offset);
> > +
> > +/**
> > + * devm_drm_dev_alloc - Resource managed allocation of a &drm_device
> > instance
> > + * @parent: Parent device object
> > + * @driver: DRM driver
> > + * @type: the type of the struct which contains struct &drm_device
> > + * @member: the name of the &drm_device within @type.
> I am confused about the naming here.
> devm_ implies we allocate something with a lifetime equal that of a
> driver. So when the driver are gone what we allocate is also gone.
> Like everythign else devm_ prefixed.
>
> But the lifetime of a drm_device is until the last userspace reference
> is gone (final drm_dev_put() is called).
The kerneldoc for this is largely copied from the existing
devm_drm_dev_init. And yes the lifetime is bound to the device, we do the
drm_dev_put() when that disappears. Now other users of drm_device might
still hold references and delay cleanup, but "cleanup is done as a devres
action" is very much what devm_ signifies.
"
> > + *
> > + * This allocates and initialize a new DRM device. No device registration
> > is done.
> > + * Call drm_dev_register() to advertice the device to user space and
> > register it
> > + * with other core subsystems. This should be done last in the device
> s/This/Calling drm_dev_register()/ will make this sentence a bit more
> explicit.
>
> > + * initialization sequence to make sure userspace can't access an
> > inconsistent
> > + * state.
> > + *
> > + * The initial ref-count of the object is 1. Use drm_dev_get() and
> > + * drm_dev_put() to take and drop further ref-counts.
> > + *
> > + * It is recommended that drivers embed &struct drm_device into their own
> > device
> > + * structure.
> > + *
> > + * Note that this manages the lifetime of the resulting &drm_device
> > + * automatically using devres.
> Hmm, no this is managed by drmres???
Yup, the next sentence explains how. And note that we're already using
this in the form of devm_drm_dev_init. So not clear what
Re: [PATCH 14/44] drm/v3d: Delete v3d_dev->pdev
On Wed, Apr 08, 2020 at 09:27:01AM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Fri, Apr 03, 2020 at 03:57:58PM +0200, Daniel Vetter wrote:
> > We already have it in v3d_dev->drm.dev with zero additional pointer
> > chasing. Personally I don't like duplicated pointers like this
> > because:
> > - reviewers need to check whether the pointer is for the same or
> > different objects if there's multiple
> > - compilers have an easier time too
> >
> > To avoid having to pull in some big headers I implemented the casting
> > function as a macro instead of a static inline.
> Hmm...
>
> > Typechecking thanks to
> > container_of still assured.
> >
> > But also a bit a bikeshed, so feel free to ignore.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Eric Anholt
>
> This and patch 13 has same subject - confusing.
dev != pdev
But yeah I agree it's a nice trick I'm pulling here :-)
Cheers, Daniel
>
> Sam
>
> > ---
> > drivers/gpu/drm/v3d/v3d_drv.c | 3 +--
> > drivers/gpu/drm/v3d/v3d_drv.h | 3 ++-
> > drivers/gpu/drm/v3d/v3d_irq.c | 8 +---
> > 3 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> > index 37cb880f2826..82a7dfdd14c2 100644
> > --- a/drivers/gpu/drm/v3d/v3d_drv.c
> > +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> > @@ -235,7 +235,7 @@ static int
> > map_regs(struct v3d_dev *v3d, void __iomem **regs, const char *name)
> > {
> > struct resource *res =
> > - platform_get_resource_byname(v3d->pdev, IORESOURCE_MEM, name);
> > + platform_get_resource_byname(v3d_to_pdev(v3d), IORESOURCE_MEM,
> > name);
> >
> > *regs = devm_ioremap_resource(v3d->drm.dev, res);
> > return PTR_ERR_OR_ZERO(*regs);
> > @@ -255,7 +255,6 @@ static int v3d_platform_drm_probe(struct
> > platform_device *pdev)
> > if (IS_ERR(v3d))
> > return PTR_ERR(v3d);
> >
> > - v3d->pdev = pdev;
> > drm = &v3d->drm;
> >
> > platform_set_drvdata(pdev, drm);
> > diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> > index 4d2d1f2fe1af..935f23b524b2 100644
> > --- a/drivers/gpu/drm/v3d/v3d_drv.h
> > +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> > @@ -46,7 +46,6 @@ struct v3d_dev {
> > int ver;
> > bool single_irq_line;
> >
> > - struct platform_device *pdev;
> > void __iomem *hub_regs;
> > void __iomem *core_regs[3];
> > void __iomem *bridge_regs;
> > @@ -128,6 +127,8 @@ v3d_has_csd(struct v3d_dev *v3d)
> > return v3d->ver >= 41;
> > }
> >
> > +#define v3d_to_pdev(v3d) to_platform_device(v3d->drm.dev)
> > +
> > /* The per-fd struct, which tracks the MMU mappings. */
> > struct v3d_file_priv {
> > struct v3d_dev *v3d;
> > diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
> > index f4ce6d057c90..51b65263c657 100644
> > --- a/drivers/gpu/drm/v3d/v3d_irq.c
> > +++ b/drivers/gpu/drm/v3d/v3d_irq.c
> > @@ -217,7 +217,7 @@ v3d_irq_init(struct v3d_dev *v3d)
> > V3D_CORE_WRITE(core, V3D_CTL_INT_CLR, V3D_CORE_IRQS);
> > V3D_WRITE(V3D_HUB_INT_CLR, V3D_HUB_IRQS);
> >
> > - irq1 = platform_get_irq(v3d->pdev, 1);
> > + irq1 = platform_get_irq(v3d_to_pdev(v3d), 1);
> > if (irq1 == -EPROBE_DEFER)
> > return irq1;
> > if (irq1 > 0) {
> > @@ -226,7 +226,8 @@ v3d_irq_init(struct v3d_dev *v3d)
> >"v3d_core0", v3d);
> > if (ret)
> > goto fail;
> > - ret = devm_request_irq(v3d->drm.dev,
> > platform_get_irq(v3d->pdev, 0),
> > + ret = devm_request_irq(v3d->drm.dev,
> > + platform_get_irq(v3d_to_pdev(v3d), 0),
> >v3d_hub_irq, IRQF_SHARED,
> >"v3d_hub", v3d);
> > if (ret)
> > @@ -234,7 +235,8 @@ v3d_irq_init(struct v3d_dev *v3d)
> > } else {
> > v3d->single_irq_line = true;
> >
> > - ret = devm_request_irq(v3d->drm.dev,
> > platform_get_irq(v3d->pdev, 0),
> > + ret = devm_request_irq(v3d->drm.dev,
> > + platform_get_irq(v3d_to_pdev(v3d), 0),
> >v3d_irq, IRQF_SHARED,
> >"v3d", v3d);
> > if (ret)
> > --
> > 2.25.1
> >
> > ___
> > 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 00/44] devm_drm_dev_alloc, no more drmm_add_final_kfree
On Wed, Apr 08, 2020 at 10:08:17AM +0200, Sam Ravnborg wrote: > Hi Daniel. > > Made specific reply to several patches. > > This bunch: > > drm/st7735r: Use devm_drm_dev_alloc > > drm/st7586: Use devm_drm_dev_alloc > > drm/repaper: Use devm_drm_dev_alloc > > drm/mi0283qt: Use devm_drm_dev_alloc > > drm/ili9486: Use devm_drm_dev_alloc > > drm/ili9341: Use devm_drm_dev_alloc > > drm/ili9225: Use devm_drm_dev_alloc > > drm/hx8357d: Use devm_drm_dev_alloc > > drm/gm12u320: Use devm_drm_dev_alloc > > drm/gm12u320: Don't use drm_device->dev_private > > are all: > Acked-by: Sam Ravnborg > > I will take a look at patch 44 later today. > I steered away from the vgem, i915 stuff on purpose. > I leave that to more competent persons. Yeah I think next round I'll leave out the vkms, vgem and i915-selftest, since that's a bigger discussion. But hopefully I can land the devm_drm_dev_alloc and many of the more basic conversions in here soonish. Thanks a lot for looking through this all. -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/ttm: Temporarily disable the huge_fault() callback
Am 08.04.20 um 14:01 schrieb Thomas Hellström (VMware): Hi, Christian, On 4/8/20 1:53 PM, Thomas Hellström (VMware) wrote: From: "Thomas Hellstrom (VMware)" With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are errors like: BUG: non-zero pgtables_bytes on freeing mm and: BUG: Bad rss-counter state with TTM transparent huge-pages. Until we've figured out what other TTM drivers do differently compared to vmwgfx, disable the huge_fault() callback, eliminating transhuge page-table entries. Cc: Christian König Signed-off-by: Thomas Hellstrom (VMware) Reported-by: Alex Xu (Hello71) Tested-by: Alex Xu (Hello71) Acked-by: Christian König --- Without being able to test and track this down on amdgpu there's little more than this I can do at the moment. Hopefully I'll be able to test on nouveau/ttm after getting back from vacation to see if I can reproduce. It looks like some part of the kernel mistakes a huge page-table entry for a page directory, and that would be a path that is not hit with vmwgfx. Well that looks like an ugly one and I don't know enough about the page table handling to hunt this down either. BTW: Have you seen the coverity warning about "WARN_ON_ONCE(ret = VM_FAULT_FALLBACK);"? Regards, Christian. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 17/28] mm: remove the prot argument from vm_map_ram
On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote: > This is always GFP_KERNEL - for long term mappings with other properties > vmap should be used. PAGE_KERNEL != GFP_KERNEL :-) > - return vm_map_ram(mock->pages, mock->npages, 0, PAGE_KERNEL); > + return vm_map_ram(mock->pages, mock->npages, 0); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> If this code was broken for non-coherent caches a crude powerpc hack
> isn't going to help anyone else. Remove the hack as it is the last
> user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
Well Ben added this to make stuff work on ppc, ofc the home grown dma
layer in drm from back then isn't going to work in other places. I guess
should have at least an ack from him, in case anyone still cares about
this on ppc. Adding Ben to cc.
-Daniel
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/drm_scatter.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
> index ca520028b2cb..f4e6184d1877 100644
> --- a/drivers/gpu/drm/drm_scatter.c
> +++ b/drivers/gpu/drm/drm_scatter.c
> @@ -43,15 +43,6 @@
>
> #define DEBUG_SCATTER 0
>
> -static inline void *drm_vmalloc_dma(unsigned long size)
> -{
> -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> - return __vmalloc(size, GFP_KERNEL, pgprot_noncached_wc(PAGE_KERNEL));
> -#else
> - return vmalloc_32(size);
> -#endif
> -}
> -
> static void drm_sg_cleanup(struct drm_sg_mem * entry)
> {
> struct page *page;
> @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, void
> *data,
> return -ENOMEM;
> }
>
> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> if (!entry->virtual) {
> kfree(entry->busaddr);
> kfree(entry->pagelist);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: decruft the vmalloc API
On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote: > Hi all, > > Peter noticed that with some dumb luck you can toast the kernel address > space with exported vmalloc symbols. > > I used this as an opportunity to decruft the vmalloc.c API and make it > much more systematic. This also removes any chance to create vmalloc > mappings outside the designated areas or using executable permissions > from modules. Besides that it removes more than 300 lines of code. > Looks great, thanks for doing this! Acked-by: Peter Zijlstra (Intel) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] topic/phy-compliance
Hey, Here's a pull request to pull in the DP PHY Compliance series. It's based on top of drm/drm-next, and contains all patches for core, amd and i915. :) Cheers, Maarten topic/phy-compliance-2020-04-08: Topic pull request for topic/phy-compliance: - Standardize DP_PHY_TEST_PATTERN name. - Add support for setting/getting test pattern from sink. - Implement DP PHY compliance to i915. The following changes since commit 12ab316ced2c5f32ced0e6300a054db644b5444a: Merge tag 'amd-drm-next-5.7-2020-04-01' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-08 09:34:27 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/topic/phy-compliance-2020-04-08 for you to fetch changes up to 8cdf727119289db3a98835662eb28e1c5ad835f1: drm/i915/dp: Program vswing, pre-emphasis, test-pattern (2020-04-08 14:41:09 +0200) Topic pull request for topic/phy-compliance: - Standardize DP_PHY_TEST_PATTERN name. - Add support for setting/getting test pattern from sink. - Implement DP PHY compliance to i915. Animesh Manna (7): drm/amd/display: Align macro name as per DP spec drm/dp: get/set phy compliance pattern drm/i915/dp: Made intel_dp_adjust_train() non-static drm/i915/dp: Preparation for DP phy compliance auto test drm/i915/dp: Add debugfs entry for DP phy compliance drm/i915/dp: Register definition for DP compliance register drm/i915/dp: Program vswing, pre-emphasis, test-pattern drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c| 94 +++ .../gpu/drm/i915/display/intel_display_debugfs.c | 12 +- drivers/gpu/drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_dp.c| 171 + drivers/gpu/drm/i915/display/intel_dp.h| 1 + .../gpu/drm/i915/display/intel_dp_link_training.c | 9 +- .../gpu/drm/i915/display/intel_dp_link_training.h | 4 + drivers/gpu/drm/i915/i915_reg.h| 18 +++ include/drm/drm_dp_helper.h| 33 +++- 10 files changed, 337 insertions(+), 8 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman wrote: > Benjamin Herrenschmidt writes: > > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: > >> Benjamin Herrenschmidt writes: > > IBM still put 40x cores inside POWER chips no ? > > Oh yeah that's true. I guess most folks don't know that, or that they > run RHEL on them. Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels. Also, if that's the only 405 based product that is still relevant with a 5.7+ kernel, it may be useful to know at which point they move to a 476 core and stop updating kernels on the old ones. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/28] staging: android: ion: use vmap instead of vm_map_ram
On Wed, Apr 08, 2020 at 01:59:00PM +0200, Christoph Hellwig wrote: > vm_map_ram can keep mappings around after the vm_unmap_ram. Using that > with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues. > > Signed-off-by: Christoph Hellwig Acked-by: Greg Kroah-Hartman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm: Introduce plane and CRTC scaling filter properties
On Wed, Apr 08, 2020 at 03:17:27PM +0530, Bharadiya,Pankaj wrote:
> On Tue, Apr 07, 2020 at 08:28:02PM +0300, Ville Syrjälä wrote:
> > On Tue, Mar 31, 2020 at 12:08:53AM +0530, Pankaj Bharadiya wrote:
> > > Introduce per-plane and per-CRTC scaling filter properties to allow
> > > userspace to select the driver's default scaling filter or
> > > Nearest-neighbor(NN) filter for upscaling operations on CRTC and
> > > plane.
> > >
> > > Drivers can set up this property for a plane by calling
> > > drm_plane_create_scaling_filter() and for a CRTC by calling
> > > drm_crtc_create_scaling_filter().
> > >
> > > NN filter works by filling in the missing color values in the upscaled
> > > image with that of the coordinate-mapped nearest source pixel value.
> > >
> > > NN filter for integer multiple scaling can be particularly useful for
> > > for pixel art games that rely on sharp, blocky images to deliver their
> > > distinctive look.
> > >
> > > changes since v2:
> > > * Create per-plane and per-CRTC scaling filter property (Ville)
> > > changes since v1:
> > > * None
> > > changes since RFC:
> > > * Add separate properties for plane and CRTC (Ville)
> > >
> > > Signed-off-by: Pankaj Bharadiya
> > > ---
> > > drivers/gpu/drm/drm_atomic_uapi.c | 8
> > > drivers/gpu/drm/drm_crtc.c| 78 +++
> > > drivers/gpu/drm/drm_plane.c | 78 +++
> > > include/drm/drm_crtc.h| 16 +++
> > > include/drm/drm_plane.h | 21 +
> > > 5 files changed, 201 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > index a1e5e262bae2..ac7dabbf0bcf 100644
> > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > @@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct
> > > drm_crtc *crtc,
> > > return -EFAULT;
> > >
> > > set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> > > + } else if (property == crtc->scaling_filter_property) {
> > > + state->scaling_filter = val;
> > > } else if (crtc->funcs->atomic_set_property) {
> > > return crtc->funcs->atomic_set_property(crtc, state, property,
> > > val);
> > > } else {
> > > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > > else if (property == config->prop_out_fence_ptr)
> > > *val = 0;
> > > + else if (property == crtc->scaling_filter_property)
> >
> > Random side observation: Why do we have two different styles to naming
> > these things (prop_foo vs. foo_property)? Would be nice to unify this
> > one way or the other.
>
> Need to handle this separately.
>
> All per-plane props follow foo_property convention and we have mixed
> conventions for properties in struct drm_mode_config with majority being
> foo_property.
>
> >
> > > + *val = state->scaling_filter;
> > > else if (crtc->funcs->atomic_get_property)
> > > return crtc->funcs->atomic_get_property(crtc, state, property,
> > > val);
> > > else
> > > @@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct
> > > drm_plane *plane,
> > > sizeof(struct drm_rect),
> > > &replaced);
> > > return ret;
> > > + } else if (property == plane->scaling_filter_property) {
> > > + state->scaling_filter = val;
> > > } else if (plane->funcs->atomic_set_property) {
> > > return plane->funcs->atomic_set_property(plane, state,
> > > property, val);
> > > @@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > > } else if (property == config->prop_fb_damage_clips) {
> > > *val = (state->fb_damage_clips) ?
> > > state->fb_damage_clips->base.id : 0;
> > > + } else if (property == plane->scaling_filter_property) {
> > > + *val = state->scaling_filter;
> > > } else if (plane->funcs->atomic_get_property) {
> > > return plane->funcs->atomic_get_property(plane, state,
> > > property, val);
> > > } else {
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 4936e1080e41..95502c88966b 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -748,3 +748,81 @@ int drm_mode_crtc_set_obj_prop(struct
> > > drm_mode_object *obj,
> > >
> > > return ret;
> > > }
> > > +
> > > +/**
> > > + * DOC: CRTC scaling filter property
> > > + *
> > > + * SCALING_FILTER:
> > > + *
> > > + * Indicates scaling filter to be used for CRTC scaler
> > > + *
> > > + * The value of this property can be one of the following:
> > > + * Default:
> > > + * Driver's default scaling filter
> > > + * Nearest Neighbor:
> > > + * Nearest Neig
Re: [PATCH 27/28] s390: use __vmalloc_node in alloc_vm_stack
On 08.04.20 13:59, Christoph Hellwig wrote:
> alloc_vm_stack can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/kernel/irq.c | 5 ++---
wrong subject (power vs s390)
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index a25ed47087ee..4518fb1d6bf4 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -735,9 +735,8 @@ void do_IRQ(struct pt_regs *regs)
>
> static void *__init alloc_vm_stack(void)
> {
> - return __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, VMALLOC_START,
> - VMALLOC_END, THREADINFO_GFP, PAGE_KERNEL,
> - 0, NUMA_NO_NODE, (void*)_RET_IP_);
> + return __vmalloc_node(THREAD_SIZE, THREAD_ALIGN, THREADINFO_GFP,
> + NUMA_NO_NODE, (void *)_RET_IP_);
> }
>
> static void __init vmap_irqstack_init(void)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_kms: Remove unnecessary condition check
On Tue, Apr 7, 2020 at 2:30 PM Aurabindo Pillai wrote:
>
> Execution will only reach here if the asserted condition is true.
> Hence there is no need for the additional check.
>
> Signed-off-by: Aurabindo Pillai
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 60591dbc2..9fedfa531 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -179,12 +179,10 @@ int amdgpu_driver_load_kms(struct drm_device *dev,
> unsigned long flags)
> /* Call ACPI methods: require modeset init
> * but failure is not fatal
> */
> - if (!r) {
> - acpi_status = amdgpu_acpi_init(adev);
> - if (acpi_status)
> - dev_dbg(&dev->pdev->dev,
> - "Error during ACPI methods call\n");
> - }
> +
> + acpi_status = amdgpu_acpi_init(adev);
> + if (acpi_status)
> + dev_dbg(&dev->pdev->dev, "Error during ACPI methods call\n");
>
> if (adev->runpm) {
> dev_pm_set_driver_flags(dev->dev, DPM_FLAG_NEVER_SKIP);
> --
> 2.26.0
>
> ___
> 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 09/21] drm/msm/dpu: Use OPP API to set clk/perf state
On some qualcomm platforms DPU needs to express a perforamnce state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean Paul
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 11f2beb..fe5717df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -239,7 +240,7 @@ static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms
*kms, u64 rate)
rate = core_clk->max_rate;
core_clk->rate = rate;
- return msm_dss_clk_set_rate(core_clk, 1);
+ return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
}
static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ce19f1d..949157a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1033,6 +1034,9 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
if (!dpu_kms)
return -ENOMEM;
+ dev_pm_opp_set_clkname(dev, "core");
+ dev_pm_opp_of_add_table(dev);
+
mp = &dpu_kms->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
@@ -1059,6 +1063,7 @@ static void dpu_unbind(struct device *dev, struct device
*master, void *data)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = &dpu_kms->mp;
+ dev_pm_opp_of_remove_table(dev);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(&pdev->dev, mp->clk_config);
mp->num_clk = 0;
@@ -1090,6 +1095,7 @@ static int __maybe_unused dpu_runtime_suspend(struct
device *dev)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = &dpu_kms->mp;
+ dev_pm_opp_set_rate(dev, 0);
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/21] drm/msm: dsi: Use OPP API to set clk/perf state
On SDM845 DSI needs to express a perforamnce state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean Paul
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 4 ++--
drivers/gpu/drm/msm/dsi/dsi_host.c | 48 ++
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 4de771d..ba7583c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -180,10 +180,12 @@ int msm_dsi_runtime_suspend(struct device *dev);
int msm_dsi_runtime_resume(struct device *dev);
int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host);
int dsi_link_clk_set_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host);
int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host);
int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 813d69d..773c4fe 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -210,9 +210,9 @@ static const struct msm_dsi_host_cfg_ops
msm_dsi_6g_host_ops = {
};
static const struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
- .link_clk_set_rate = dsi_link_clk_set_rate_6g,
+ .link_clk_set_rate = dsi_link_clk_set_rate_6g_v2,
.link_clk_enable = dsi_link_clk_enable_6g,
- .link_clk_disable = dsi_link_clk_disable_6g,
+ .link_clk_disable = dsi_link_clk_disable_6g_v2,
.clk_init_ver = dsi_clk_init_6g_v2,
.tx_buf_alloc = dsi_tx_buf_alloc_6g,
.tx_buf_get = dsi_tx_buf_get_6g,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8..c47d9af 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -111,6 +112,8 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
+ struct opp_table *opp;
+
u32 byte_clk_rate;
u32 pixel_clk_rate;
u32 esc_clk_rate;
@@ -537,6 +540,40 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
return 0;
}
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host)
+{
+ int ret;
+ struct device *dev = &msm_host->pdev->dev;
+
+ DBG("Set clk rates: pclk=%d, byteclk=%d",
+ msm_host->mode->clock, msm_host->byte_clk_rate);
+
+ ret = dev_pm_opp_set_rate(dev, msm_host->byte_clk_rate);
+ if (ret) {
+ pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
+ return ret;
+ }
+
+ ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
+ if (ret) {
+ pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
+ return ret;
+ }
+
+ if (msm_host->byte_intf_clk) {
+ ret = clk_set_rate(msm_host->byte_intf_clk,
+ msm_host->byte_clk_rate / 2);
+ if (ret) {
+ pr_err("%s: Failed to set rate byte intf clk, %d\n",
+ __func__, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+
int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host)
{
@@ -665,6 +702,13 @@ void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
+void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host)
+{
+ /* Drop the performance state vote */
+ dev_pm_opp_set_rate(&msm_host->pdev->dev, 0);
+ dsi_link_clk_disable_6g(msm_host);
+}
+
void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
{
clk_disable_unprepare(msm_host->pixel_clk);
@@ -1879,6 +1923,9 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
+ msm_host->opp = dev_pm_opp_set_clkname(&pdev->dev, "byte");
+ dev_pm_opp_of_add_table(&pdev->dev);
+
init_completion(&msm_host->dma_comp);
init_completion(&msm_host->video_comp);
mutex_init(&msm_host->dev_mutex);
@@ -1904,6 +1951,7 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
struct msm_dsi_host *msm_host = t
Re: [PATCH] drm/ttm: Temporarily disable the huge_fault() callback
On 4/8/20 2:19 PM, Christian König wrote: Am 08.04.20 um 14:01 schrieb Thomas Hellström (VMware): Hi, Christian, On 4/8/20 1:53 PM, Thomas Hellström (VMware) wrote: From: "Thomas Hellstrom (VMware)" With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are errors like: BUG: non-zero pgtables_bytes on freeing mm and: BUG: Bad rss-counter state with TTM transparent huge-pages. Until we've figured out what other TTM drivers do differently compared to vmwgfx, disable the huge_fault() callback, eliminating transhuge page-table entries. Cc: Christian König Signed-off-by: Thomas Hellstrom (VMware) Reported-by: Alex Xu (Hello71) Tested-by: Alex Xu (Hello71) Acked-by: Christian König --- Without being able to test and track this down on amdgpu there's little more than this I can do at the moment. Hopefully I'll be able to test on nouveau/ttm after getting back from vacation to see if I can reproduce. It looks like some part of the kernel mistakes a huge page-table entry for a page directory, and that would be a path that is not hit with vmwgfx. Well that looks like an ugly one and I don't know enough about the page table handling to hunt this down either. BTW: Have you seen the coverity warning about "WARN_ON_ONCE(ret = VM_FAULT_FALLBACK);"? Yes, that's a false warning but it might be that it should be rewritten for clarity like so: ret = VM_FAULT_FALLBACK; WARN_ON_ONCE(true); /Thomas Regards, Christian. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] amdgpu: remove load and unload callbacks (v3)
On Wed, Apr 8, 2020 at 3:38 AM Thomas Zimmermann wrote: > > Hi Alex > > Am 07.02.20 um 20:50 schrieb Alex Deucher: > > These are deprecated and the drm will soon start warning when drivers still > > use them. It was a long and twisty road, but seems to work. > > Are you going to convert radeon as well? It's the only remaining KMS > driver that uses load. It's on my todo list, hopefully this kernel cycle. Alex > > Best regards > Thomas > > > > > v2: Add additional patch (13/15) which should fix the crash reported by > > Thomas Zimmermann. > > v3: Fix dp aux registration harder, add missing kconfig guard > > > > Alex Deucher (15): > > drm/amdgpu: rename amdgpu_debugfs_preempt_cleanup > > drm/amdgpu/ttm: move debugfs init into core amdgpu debugfs > > drm/amdgpu/pm: move debugfs init into core amdgpu debugfs > > drm/amdgpu/sa: move debugfs init into core amdgpu debugfs > > drm/amdgpu/fence: move debugfs init into core amdgpu debugfs > > drm/amdgpu/gem: move debugfs init into core amdgpu debugfs > > drm/amdgpu/regs: move debugfs init into core amdgpu debugfs > > drm/amdgpu/firmware: move debugfs init into core amdgpu debugfs > > drm/amdgpu: don't call drm_connector_register for non-MST ports > > drm/amdgpu/display: move debugfs init into core amdgpu debugfs (v2) > > drm/amd/display: move dpcd debugfs members setup > > drm/amdgpu/display: add a late register connector callback > > drm/amdgpu/display: split dp connector registration (v2) > > drm/amdgpu/ring: move debugfs init into core amdgpu debugfs > > drm/amdgpu: drop legacy drm load and unload callbacks > > > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 17 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 69 ++- > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 17 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 +++- > > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3 - > > drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 7 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 1 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 9 +-- > > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h| 2 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 15 +--- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 4 ++ > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 +--- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 + > > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 +-- > > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 1 - > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++ > > .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 + > > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 13 ++-- > > 19 files changed, 140 insertions(+), 89 deletions(-) > > > > -- > 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 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/ttm: clean up ttm_trace_dma_map/ttm_trace_dma_unmap (v2)
On Tue, Apr 7, 2020 at 5:50 AM Christian König wrote: > > Am 07.04.20 um 11:12 schrieb Huang Rui: > > ttm_trace_dma_map/ttm_trace_dma_unmap is never used anymore. > > > > v2: remove the file completely > > > > Signed-off-by: Huang Rui > > Reviewed-by: Christian König > Can one of you make sure this lands in drm-misc? Thanks, Alex > > --- > > include/drm/ttm/ttm_debug.h | 31 --- > > 1 file changed, 31 deletions(-) > > delete mode 100644 include/drm/ttm/ttm_debug.h > > > > diff --git a/include/drm/ttm/ttm_debug.h b/include/drm/ttm/ttm_debug.h > > deleted file mode 100644 > > index b5e460f..000 > > --- a/include/drm/ttm/ttm_debug.h > > +++ /dev/null > > @@ -1,31 +0,0 @@ > > -/** > > - * > > - * Copyright (c) 2017 Advanced Micro Devices, Inc. > > - * All Rights Reserved. > > - * > > - * Permission is hereby granted, free of charge, to any person obtaining a > > - * copy of this software and associated documentation files (the > > - * "Software"), to deal in the Software without restriction, including > > - * without limitation the rights to use, copy, modify, merge, publish, > > - * distribute, sub license, and/or sell copies of the Software, and to > > - * permit persons to whom the Software is furnished to do so, subject to > > - * the following conditions: > > - * > > - * The above copyright notice and this permission notice (including the > > - * next paragraph) shall be included in all copies or substantial portions > > - * of the Software. > > - * > > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > > OR > > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > - * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL > > - * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY > > CLAIM, > > - * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR > > - * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR > > THE > > - * USE OR OTHER DEALINGS IN THE SOFTWARE. > > - * > > - > > **/ > > -/* > > - * Authors: Tom St Denis > > - */ > > -extern void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt); > > -extern void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt); > > ___ > 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
Re: [PATCH/RFC 4/6] dt-bindings: display: rockchip: dw-hdmi: Convert binding to YAML
Hi Maxime,
On Wed, Apr 08, 2020 at 02:25:19PM +0200, Maxime Ripard wrote:
> On Wed, Apr 08, 2020 at 02:45:52PM +0300, Laurent Pinchart wrote:
> > On Tue, Apr 07, 2020 at 09:12:51AM +0200, Maxime Ripard wrote:
> >> On Mon, Apr 06, 2020 at 08:50:28PM +0300, Laurent Pinchart wrote:
> >>> On Mon, Apr 06, 2020 at 07:09:15PM +0200, Maxime Ripard wrote:
> On Mon, Apr 06, 2020 at 02:19:27PM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 06, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> >> On Mon, Apr 06, 2020 at 02:39:33AM +0300, Laurent Pinchart wrote:
> >>> Convert the Rockchip HDMI TX text binding to YAML.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>>
> >>> ---
> >>> .../display/rockchip/dw_hdmi-rockchip.txt | 74
> >>> .../display/rockchip/rockchip,dw-hdmi.yaml| 178
> >>> ++
> >>> 2 files changed, 178 insertions(+), 74 deletions(-)
> >>> delete mode 100644
> >>> Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>> create mode 100644
> >>> Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>>
> >>> b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>> deleted file mode 100644
> >>> index 3d32ce137e7f..
> >>> ---
> >>> a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
> >>> +++ /dev/null
> >>> @@ -1,74 +0,0 @@
> >>> -Rockchip DWC HDMI TX Encoder
> >>> -
> >>> -
> >>> -The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller
> >>> IP
> >>> -with a companion PHY IP.
> >>> -
> >>> -These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> >>> -Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> >>> -following device-specific properties.
> >>> -
> >>> -
> >>> -Required properties:
> >>> -
> >>> -- compatible: should be one of the following:
> >>> - "rockchip,rk3228-dw-hdmi"
> >>> - "rockchip,rk3288-dw-hdmi"
> >>> - "rockchip,rk3328-dw-hdmi"
> >>> - "rockchip,rk3399-dw-hdmi"
> >>> -- reg: See dw_hdmi.txt.
> >>> -- reg-io-width: See dw_hdmi.txt. Shall be 4.
> >>> -- interrupts: HDMI interrupt number
> >>> -- clocks: See dw_hdmi.txt.
> >>> -- clock-names: Shall contain "iahb" and "isfr" as defined in
> >>> dw_hdmi.txt.
> >>> -- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port
> >>> numbered 0
> >>> - corresponding to the video input of the controller. The port shall
> >>> have two
> >>> - endpoints, numbered 0 and 1, connected respectively to the vopb
> >>> and vopl.
> >>> -- rockchip,grf: Shall reference the GRF to mux vopl/vopb.
> >>> -
> >>> -Optional properties
> >>> -
> >>> -- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system
> >>> I2C master
> >>> - or the functionally-reduced I2C master contained in the DWC HDMI.
> >>> When
> >>> - connected to a system I2C master this property contains a phandle
> >>> to that
> >>> - I2C master controller.
> >>> -- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
> >>> -- clock-names: May contain "cec" as defined in dw_hdmi.txt.
> >>> -- clock-names: May contain "grf", power for grf io.
> >>> -- clock-names: May contain "vpll", external clock for some hdmi phy.
> >>> -- phys: from general PHY binding: the phandle for the PHY device.
> >>> -- phy-names: Should be "hdmi" if phys references an external phy.
> >>> -
> >>> -Optional pinctrl entry:
> >>> -- If you have both a "unwedge" and "default" pinctrl entry, dw_hdmi
> >>> - will switch to the unwedge pinctrl state for 10ms if it ever gets
> >>> an
> >>> - i2c timeout. It's intended that this unwedge pinctrl entry will
> >>> - cause the SDA line to be driven low to work around a hardware
> >>> - errata.
> >>> -
> >>> -Example:
> >>> -
> >>> -hdmi: hdmi@ff98 {
> >>> - compatible = "rockchip,rk3288-dw-hdmi";
> >>> - reg = <0xff98 0x2>;
> >>> - reg-io-width = <4>;
> >>> - ddc-i2c-bus = <&i2c5>;
> >>> - rockchip,grf = <&grf>;
> >>> - interrupts = ;
> >>> - clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>;
> >>> - clock-names = "iahb", "isfr";
> >>> - ports {
> >>> - hdmi_in: port {
> >>> - #address-cells = <1>;
> >>> - #size-cells = <0>;
> >>> - hdmi_in_vopb: endpoint@0 {
> >>> - reg = <0>;
> >>> - remote-endpoi
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > plug this problem by demoting nonblocking commits which might cause
> > > > issues by including CRTCs not in the original request to blocking
> > > > commits.
> > > >
> > > > 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).
> > > >
> > > > 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: sta...@vger.kernel.org
> > > > Reviewed-by: Daniel Stone
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > {
> > > > struct drm_mode_config *config = &state->dev->mode_config;
> > > > - int ret;
> > > > + unsigned requested_crtc = 0;
> > > > + unsigned affected_crtc = 0;
> > > > + struct drm_crtc *crtc;
> > > > + struct drm_crtc_state *crtc_state;
> > > > + bool nonblocking = true;
> > > > + int ret, i;
> > > > +
> > > > + /*
> > > > + * For commits that allow modesets drivers can add other CRTCs to
> > > > the
> > > > + * atomic commit, e.g. when they need to reallocate global
> > > > resources.
> > > > + *
> > > > + * But when userspace also requests a nonblocking commit then
> > > > userspace
> > > > + * cannot know that the commit affects other CRTCs, which can
> > > > result in
> > > > + * spurious EBUSY failures. Until we have better uapi plug this by
> > > > + * demoting such commits to blocking mode.
> > > > + */
> > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > + requested_crtc |= drm_crtc_mask(crtc);
> > > >
> > > > ret = drm_atomic_check_only(state);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > +
> > > > + if (affected_crtc != requested_crtc) {
> > > > + /* adding other CRTC is only allowed for modeset commits
> > > > */
> > > > + WARN_ON(!state->allow_modeset);
> > >
> > > Not sure that's really true. What if the driver needs to eg.
> > > redistribute FIFO space or something between the pipes? Or do we
> > > expect drivers to now examine state->allow_modeset to figure out
> > > if they're allowed to do certain things?
> >
> > Maybe we need more fine-grained flags here, but adding other states
> > (and blocking a commit flow) is exactly the uapi headaches this patch
> > tries to solve here. So if our driver currently adds crtc states to
> > reallocate fifo between pipes for an atomic flip then yes we're
> > breaking userspace. Well, everyone figured out by now that you get
> > random EBUSY and dropped frames for no apparent reason at all, and
> > work around it. But happy, they are not.
>
> I don't think we do this currently for the FIFO, but in theor
Re: [PATCH] drm/ttm: Temporarily disable the huge_fault() callback
Am 08.04.20 um 15:49 schrieb Thomas Hellström (VMware): On 4/8/20 2:19 PM, Christian König wrote: Am 08.04.20 um 14:01 schrieb Thomas Hellström (VMware): Hi, Christian, On 4/8/20 1:53 PM, Thomas Hellström (VMware) wrote: From: "Thomas Hellstrom (VMware)" With amdgpu and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y, there are errors like: BUG: non-zero pgtables_bytes on freeing mm and: BUG: Bad rss-counter state with TTM transparent huge-pages. Until we've figured out what other TTM drivers do differently compared to vmwgfx, disable the huge_fault() callback, eliminating transhuge page-table entries. Cc: Christian König Signed-off-by: Thomas Hellstrom (VMware) Reported-by: Alex Xu (Hello71) Tested-by: Alex Xu (Hello71) Acked-by: Christian König --- Without being able to test and track this down on amdgpu there's little more than this I can do at the moment. Hopefully I'll be able to test on nouveau/ttm after getting back from vacation to see if I can reproduce. It looks like some part of the kernel mistakes a huge page-table entry for a page directory, and that would be a path that is not hit with vmwgfx. Well that looks like an ugly one and I don't know enough about the page table handling to hunt this down either. BTW: Have you seen the coverity warning about "WARN_ON_ONCE(ret = VM_FAULT_FALLBACK);"? Yes, that's a false warning but it might be that it should be rewritten for clarity like so: ret = VM_FAULT_FALLBACK; WARN_ON_ONCE(true); Using an additional () also usually works, but I'm not even sure if WARN_ON_ONCE() isn't compiled to a no-op under some circumstances. So better save than sorry, Christian. /Thomas Regards, Christian. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/28] s390: use __vmalloc_node in stack_alloc
On 08.04.20 13:59, Christoph Hellwig wrote:
> stack_alloc can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/s390/kernel/setup.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index 36445dd40fdb..0f0b140b5558 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -305,12 +305,9 @@ void *restart_stack __section(.data);
> unsigned long stack_alloc(void)
> {
> #ifdef CONFIG_VMAP_STACK
> - return (unsigned long)
> - __vmalloc_node_range(THREAD_SIZE, THREAD_SIZE,
> - VMALLOC_START, VMALLOC_END,
> - THREADINFO_GFP,
> - PAGE_KERNEL, 0, NUMA_NO_NODE,
> - __builtin_return_address(0));
> + return (unsigned long)__vmalloc_node(THREAD_SIZE, THREAD_SIZE,
> + THREADINFO_GFP, NUMA_NO_NODE,
> + __builtin_return_address(0));
Looks sane.
Acked-by: Christian Borntraeger
> #else
> return __get_free_pages(GFP_KERNEL, THREAD_SIZE_ORDER);
> #endif
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/ttm: clean up ttm_trace_dma_map/ttm_trace_dma_unmap (v2)
Am 08.04.20 um 16:00 schrieb Alex Deucher: On Tue, Apr 7, 2020 at 5:50 AM Christian König wrote: Am 07.04.20 um 11:12 schrieb Huang Rui: ttm_trace_dma_map/ttm_trace_dma_unmap is never used anymore. v2: remove the file completely Signed-off-by: Huang Rui Reviewed-by: Christian König Can one of you make sure this lands in drm-misc? Done. Christian. Thanks, Alex --- include/drm/ttm/ttm_debug.h | 31 --- 1 file changed, 31 deletions(-) delete mode 100644 include/drm/ttm/ttm_debug.h diff --git a/include/drm/ttm/ttm_debug.h b/include/drm/ttm/ttm_debug.h deleted file mode 100644 index b5e460f..000 --- a/include/drm/ttm/ttm_debug.h +++ /dev/null @@ -1,31 +0,0 @@ -/** - * - * Copyright (c) 2017 Advanced Micro Devices, Inc. - * All Rights Reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the - * "Software"), to deal in the Software without restriction, including - * without limitation the rights to use, copy, modify, merge, publish, - * distribute, sub license, and/or sell copies of the Software, and to - * permit persons to whom the Software is furnished to do so, subject to - * the following conditions: - * - * The above copyright notice and this permission notice (including the - * next paragraph) shall be included in all copies or substantial portions - * of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL - * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, - * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR - * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE - * USE OR OTHER DEALINGS IN THE SOFTWARE. - * - **/ -/* - * Authors: Tom St Denis - */ -extern void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt); -extern void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt); ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cchristian.koenig%40amd.com%7C060c7b4e4194427e510108d7dbc5395c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637219512430412644&sdata=T0ckyGvS2dQp0elZVHvy8PF7yO2LnualED%2FilEhUqUs%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204611] amdgpu error scheduling IBs when waking from sleep
https://bugzilla.kernel.org/show_bug.cgi?id=204611 Vic Luo (viclu...@gmail.com) changed: What|Removed |Added CC||viclu...@gmail.com --- Comment #7 from Vic Luo (viclu...@gmail.com) --- Same for Thinkpad E585 with Ryzen 5 2500U. kernel: [drm:psp_hw_start [amdgpu]] *ERROR* PSP load tmr failed! kernel: [drm:psp_resume [amdgpu]] *ERROR* PSP resume failed kernel: [drm:amdgpu_device_fw_loading [amdgpu]] *ERROR* resume of IP block failed -22 kernel: [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-22). kernel: PM: dpm_run_callback(): pci_pm_resume+0x0/0x80 returns -22 kernel: PM: Device :05:00.0 failed to resume async: error -22 kernel: acpi LNXPOWER:01: Turning OFF kernel: OOM killer enabled. kernel: Restarting tasks ... -- 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 10/28] mm: only allow page table mappings for built-in zsmalloc
On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote: > Hi, > > On 4/8/20 4:59 AM, Christoph Hellwig wrote: > > diff --git a/mm/Kconfig b/mm/Kconfig > > index 36949a9425b8..614cc786b519 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -702,7 +702,7 @@ config ZSMALLOC > > > > config ZSMALLOC_PGTABLE_MAPPING > > bool "Use page table mapping to access object in zsmalloc" > > - depends on ZSMALLOC > > + depends on ZSMALLOC=y > > It's a bool so this shouldn't matter... not needed. My mm/Kconfig has: config ZSMALLOC tristate "Memory allocator for compressed pages" depends on MMU which I think means it can be modular, no? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Apr 8, 2020 at 4:03 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > > plug this problem by demoting nonblocking commits which might cause
> > > > > issues by including CRTCs not in the original request to blocking
> > > > > commits.
> > > > >
> > > > > 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).
> > > > >
> > > > > 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: sta...@vger.kernel.org
> > > > > Reviewed-by: Daniel Stone
> > > > > Signed-off-by: Daniel Vetter
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > > {
> > > > > struct drm_mode_config *config = &state->dev->mode_config;
> > > > > - int ret;
> > > > > + unsigned requested_crtc = 0;
> > > > > + unsigned affected_crtc = 0;
> > > > > + struct drm_crtc *crtc;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > > + bool nonblocking = true;
> > > > > + int ret, i;
> > > > > +
> > > > > + /*
> > > > > + * For commits that allow modesets drivers can add other CRTCs
> > > > > to the
> > > > > + * atomic commit, e.g. when they need to reallocate global
> > > > > resources.
> > > > > + *
> > > > > + * But when userspace also requests a nonblocking commit then
> > > > > userspace
> > > > > + * cannot know that the commit affects other CRTCs, which can
> > > > > result in
> > > > > + * spurious EBUSY failures. Until we have better uapi plug this
> > > > > by
> > > > > + * demoting such commits to blocking mode.
> > > > > + */
> > > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > + requested_crtc |= drm_crtc_mask(crtc);
> > > > >
> > > > > ret = drm_atomic_check_only(state);
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > +
> > > > > + if (affected_crtc != requested_crtc) {
> > > > > + /* adding other CRTC is only allowed for modeset
> > > > > commits */
> > > > > + WARN_ON(!state->allow_modeset);
> > > >
> > > > Not sure that's really true. What if the driver needs to eg.
> > > > redistribute FIFO space or something between the pipes? Or do we
> > > > expect drivers to now examine state->allow_modeset to figure out
> > > > if they're allowed to do certain things?
> > >
> > > Maybe we need more fine-grained flags here, but adding other states
> > > (and blocking a commit flow) is exactly the uapi headaches this patch
> > > tries to solve here. So if our driver currently adds crtc states to
> > > reallocate fifo between pipes for an
Re: [PATCH] drm/amd/amdgpu: add prefix for pr_* prints
On Wed, 2020-04-08 at 09:37 -0400, Aurabindo Pillai wrote:
> amdgpu uses lots of pr_* calls for printing error messages.
> With this prefix, errors shall be more obvious to the end
> use regarding its origin, and may help debugging.
>
> Prefix format:
>
> [xxx.x] amdgpu: ...
[]
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
[]
> @@ -28,6 +28,12 @@
> #ifndef __AMDGPU_H__
> #define __AMDGPU_H__
>
> +#ifdef pr_fmt
> +#undef pr_fmt
> +#endif
> +
> +#define pr_fmt(fmt) "amdgpu: " fmt
> +
> #include "amdgpu_ctx.h"
>
> #include
All the embedded uses of "amdgpu:" in logging
messages should also be deleted.
$ git grep -P '(?:dev_|pr_).*"amdgpu:' drivers/gpu/drm/amd/amdgpu/
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: pr_err("amdgpu:
failed to validate PT BOs\n");
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: pr_err("amdgpu:
failed to validate PD\n");
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:
pr_err("amdgpu: failed to kmap PD, ret=%d\n", ret);
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: pr_info("amdgpu:
switched on\n");
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c: pr_info("amdgpu:
switched off\n");
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:
dev_dbg(adev->dev, "amdgpu: using MSI/MSI-X.\n");
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c: dev_warn(adev->dev, "amdgpu: No
suitable DMA available.\n");
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c: pr_warn("amdgpu: No suitable
DMA available\n");
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c: pr_warn("amdgpu: No suitable
DMA available\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/35] Documentation fixes for Kernel 5.8
Hi Jon, I have a large list of patches this time for the Documentation/. So, I'm starting sending them a little earier. Yet, those are meant to be applied after the end of the merge window. They're based on today's linux-next, with has only 49 patches pending to be applied upstream touching Documentation/, so I don't expect much conflicts if applied early at -rc cycle. Most of the patches here were already submitted, but weren't merged yet at next. So, it seems that nobody picked them yet. In any case, most of those patches here are independent from the others. The number of doc build warnings have been rising with time. The main goal with this series is to get rid of most Sphinx warnings and other errors. Patches 1 to 5: fix broken references detected by this tool: ./scripts/documentation-file-ref-check The other patches fix other random errors due to tags being mis-interpreted or mis-used. You should notice that several patches touch kernel-doc scripts. IMHO, some of the warnings are actually due to kernel-doc being too pedantic. So, I ended by improving some things at the toolset, in order to make it smarter. That's the case of those patches: docs: scripts/kernel-doc: accept blank lines on parameter description scripts: kernel-doc: accept negation like !@var scripts: kernel-doc: proper handle @foo->bar() The last 4 patches address problems with PDF building. The first one address a conflict that will rise during the merge window: Documentation/media will be removed. Instead of just drop it from the list of PDF documents, I opted to drop the entire list, as conf.py will auto-generate from the sources: docs: LaTeX/PDF: drop list of documents Also, right now, PDF output is broken due to a namespace conflict at I2c (two pdf outputs there will have the same name). docs: i2c: rename i2c.svg to i2c_bus.svg The third PDF patch is not really a fix, but it helps a lot to identify if the build succeeded or not, by placing the final PDF output on a separate dir: docs: Makefile: place final pdf docs on a separate dir Finally, the last one solves a bug since the first supported Sphinx version, with also impacts PDF output: basically while nested tables are valid with ReST notation, the toolset only started supporting it on PDF output since version 2.4: docs: update recommended Sphinx version to 2.4.4 PS.: Due to the large number of C/C, I opted to keep a smaller set of C/C at this first e-mail (only e-mails with "L:" tag from MAINTAINERS file). Mauro Carvalho Chehab (35): MAINTAINERS: dt: update display/allwinner file entry docs: dt: fix broken reference to phy-cadence-torrent.yaml docs: fix broken references to text files docs: fix broken references for ReST files that moved around docs: filesystems: fix renamed references docs: amu: supress some Sphinx warnings docs: arm64: booting.rst: get rid of some warnings docs: pci: boot-interrupts.rst: improve html output futex: get rid of a kernel-docs build warning firewire: firewire-cdev.hL get rid of a docs warning scripts: kernel-doc: proper handle @foo->bar() lib: bitmap.c: get rid of some doc warnings ata: libata-core: fix a doc warning fs: inode.c: get rid of docs warnings docs: ras: get rid of some warnings docs: ras: don't need to repeat twice the same thing docs: watch_queue.rst: supress some Sphinx warnings scripts: kernel-doc: accept negation like !@var docs: infiniband: verbs.c: fix some documentation warnings docs: scripts/kernel-doc: accept blank lines on parameter description docs: spi: spi.h: fix a doc building warning docs: drivers: fix some warnings at base/platform.c when building docs docs: fusion: mptbase.c: get rid of a doc build warning docs: mm: slab.h: fix a broken cross-reference docs mm: userfaultfd.rst: use ``foo`` for literals docs: mm: userfaultfd.rst: use a cross-reference for a section docs: vm: index.rst: add an orphan doc to the building system docs: dt: qcom,dwc3.txt: fix cross-reference for a converted file MAINTAINERS: dt: fix pointers for ARM Integrator, Versatile and RealView docs: dt: fix a broken reference for a file converted to json powerpc: docs: cxl.rst: mark two section titles as such docs: LaTeX/PDF: drop list of documents docs: i2c: rename i2c.svg to i2c_bus.svg docs: Makefile: place final pdf docs on a separate dir docs: update recommended Sphinx version to 2.4.4 Documentation/ABI/stable/sysfs-devices-node | 2 +- Documentation/ABI/testing/procfs-smaps_rollup | 2 +- Documentation/Makefile| 6 +- Documentation/PCI/boot-interrupts.rst | 34 +-- Documentation/admin-guide/cpu-load.rst| 2 +- Documentation/admin-guide/mm/userfaultfd.rst | 209 +- Documentation/admin-guide/nfs/nfsroot.rst | 2 +- Documentation/admin-guide/ras.rst | 18 +- Documentation/arm64/amu.rst |
[PATCH 03/35] docs: fix broken references to text files
Several references got broken due to txt to ReST conversion. Several of them can be automatically fixed with: scripts/documentation-file-ref-check --fix Reviewed-by: Mathieu Poirier # hwtracing/coresight/Kconfig Signed-off-by: Mauro Carvalho Chehab --- Documentation/memory-barriers.txt| 2 +- Documentation/process/submit-checklist.rst | 2 +- .../translations/it_IT/process/submit-checklist.rst | 2 +- Documentation/translations/ko_KR/memory-barriers.txt | 2 +- .../translations/zh_CN/filesystems/sysfs.txt | 2 +- .../translations/zh_CN/process/submit-checklist.rst | 2 +- Documentation/virt/kvm/arm/pvtime.rst| 2 +- Documentation/virt/kvm/devices/vcpu.rst | 2 +- Documentation/virt/kvm/hypercalls.rst| 4 ++-- arch/powerpc/include/uapi/asm/kvm_para.h | 2 +- drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/drm_ioctl.c | 2 +- drivers/hwtracing/coresight/Kconfig | 2 +- fs/fat/Kconfig | 8 fs/fuse/Kconfig | 2 +- fs/fuse/dev.c| 2 +- fs/overlayfs/Kconfig | 6 +++--- include/linux/mm.h | 4 ++-- include/uapi/linux/ethtool_netlink.h | 2 +- include/uapi/rdma/rdma_user_ioctl_cmds.h | 2 +- mm/gup.c | 12 ++-- virt/kvm/arm/vgic/vgic-mmio-v3.c | 2 +- virt/kvm/arm/vgic/vgic.h | 4 ++-- 23 files changed, 36 insertions(+), 36 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index e1c355e84edd..eaabc3134294 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -620,7 +620,7 @@ because the CPUs that the Linux kernel supports don't do writes until they are certain (1) that the write will actually happen, (2) of the location of the write, and (3) of the value to be written. But please carefully read the "CONTROL DEPENDENCIES" section and the -Documentation/RCU/rcu_dereference.txt file: The compiler can and does +Documentation/RCU/rcu_dereference.rst file: The compiler can and does break dependencies in a great many highly creative ways. CPU 1 CPU 2 diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst index 8e56337d422d..3f8e9d5d95c2 100644 --- a/Documentation/process/submit-checklist.rst +++ b/Documentation/process/submit-checklist.rst @@ -107,7 +107,7 @@ and elsewhere regarding submitting Linux kernel patches. and why. 26) If any ioctl's are added by the patch, then also update -``Documentation/ioctl/ioctl-number.rst``. +``Documentation/userspace-api/ioctl/ioctl-number.rst``. 27) If your modified source code depends on or uses any of the kernel APIs or features that are related to the following ``Kconfig`` symbols, diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst index 995ee69fab11..3e575502690f 100644 --- a/Documentation/translations/it_IT/process/submit-checklist.rst +++ b/Documentation/translations/it_IT/process/submit-checklist.rst @@ -117,7 +117,7 @@ sottomissione delle patch, in particolare sorgenti che ne spieghi la logica: cosa fanno e perché. 25) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate -``Documentation/ioctl/ioctl-number.rst``. +``Documentation/userspace-api/ioctl/ioctl-number.rst``. 26) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o funzionalità del kernel che è associata a uno dei seguenti simboli diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 2e831ece6e26..e50fe6541335 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -641,7 +641,7 @@ P 는 짝수 번호 캐시 라인에 저장되어 있고, 변수 B 는 홀수 리눅스 커널이 지원하는 CPU 들은 (1) 쓰기가 정말로 일어날지, (2) 쓰기가 어디에 이루어질지, 그리고 (3) 쓰여질 값을 확실히 알기 전까지는 쓰기를 수행하지 않기 때문입니다. 하지만 "컨트롤 의존성" 섹션과 -Documentation/RCU/rcu_dereference.txt 파일을 주의 깊게 읽어 주시기 바랍니다: +Documentation/RCU/rcu_dereference.rst 파일을 주의 깊게 읽어 주시기 바랍니다: 컴파일러는 매우 창의적인 많은 방법으로 종속성을 깰 수 있습니다. CPU 1 CPU 2 diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt index ee1f37da5b23..a15c3ebdfa82 100644 --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt @@ -281,7 +281,7 @@ drivers/ 包含了每个已为特定总线上的设备而挂载的驱动程序 假定驱动没有跨越多个总线类型)。 fs/ 包含了一个为文件系统设立的目录。现在每个想要导出属性的文件系统必须 -在 fs/
[PATCH 05/35] docs: filesystems: fix renamed references
Some filesystem references got broken by a previous patch series I submitted. Address those. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/stable/sysfs-devices-node | 2 +- Documentation/ABI/testing/procfs-smaps_rollup | 2 +- Documentation/admin-guide/cpu-load.rst | 2 +- Documentation/admin-guide/nfs/nfsroot.rst | 2 +- Documentation/driver-api/driver-model/device.rst| 4 ++-- Documentation/driver-api/driver-model/overview.rst | 2 +- Documentation/filesystems/dax.txt | 2 +- Documentation/filesystems/dnotify.txt | 2 +- Documentation/filesystems/ramfs-rootfs-initramfs.rst| 2 +- Documentation/filesystems/sysfs.rst | 2 +- Documentation/powerpc/firmware-assisted-dump.rst| 2 +- Documentation/process/adding-syscalls.rst | 2 +- .../translations/it_IT/process/adding-syscalls.rst | 2 +- Documentation/translations/zh_CN/filesystems/sysfs.txt | 6 +++--- drivers/base/core.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +- fs/Kconfig | 2 +- fs/Kconfig.binfmt | 2 +- fs/adfs/Kconfig | 2 +- fs/affs/Kconfig | 2 +- fs/afs/Kconfig | 6 +++--- fs/bfs/Kconfig | 2 +- fs/cramfs/Kconfig | 2 +- fs/ecryptfs/Kconfig | 2 +- fs/hfs/Kconfig | 2 +- fs/hpfs/Kconfig | 2 +- fs/isofs/Kconfig| 2 +- fs/namespace.c | 2 +- fs/notify/inotify/Kconfig | 2 +- fs/ntfs/Kconfig | 2 +- fs/ocfs2/Kconfig| 2 +- fs/proc/Kconfig | 4 ++-- fs/romfs/Kconfig| 2 +- fs/sysfs/dir.c | 2 +- fs/sysfs/file.c | 2 +- fs/sysfs/mount.c| 2 +- fs/sysfs/symlink.c | 2 +- fs/sysv/Kconfig | 2 +- fs/udf/Kconfig | 2 +- include/linux/kobject.h | 2 +- include/linux/kobject_ns.h | 2 +- include/linux/relay.h | 2 +- include/linux/sysfs.h | 2 +- kernel/relay.c | 2 +- lib/kobject.c | 4 ++-- 45 files changed, 52 insertions(+), 52 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node index df8413cf1468..484fc04bcc25 100644 --- a/Documentation/ABI/stable/sysfs-devices-node +++ b/Documentation/ABI/stable/sysfs-devices-node @@ -54,7 +54,7 @@ Date: October 2002 Contact: Linux Memory Management list Description: Provides information about the node's distribution and memory - utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt + utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.rst What: /sys/devices/system/node/nodeX/numastat Date: October 2002 diff --git a/Documentation/ABI/testing/procfs-smaps_rollup b/Documentation/ABI/testing/procfs-smaps_rollup index 274df44d8b1b..046978193368 100644 --- a/Documentation/ABI/testing/procfs-smaps_rollup +++ b/Documentation/ABI/testing/procfs-smaps_rollup @@ -11,7 +11,7 @@ Description: Additionally, the fields Pss_Anon, Pss_File and Pss_Shmem are not present in /proc/pid/smaps. These fields represent the sum of the Pss field of each type (anon, file, shmem). - For more details, see Documentation/filesystems/proc.txt + For more details, see Documentation/filesystems/proc.rst and the procfs man page. Typical output looks like this: diff --git a/Documentation/admin-guide/cpu-load.rst b/Documentation/admin-guide/cpu-load.rst index 2d01ce43d2a2..ebdecf864080 100644 --- a/Documentation/admin-guide/cpu-load.rst +++ b/Documentation/admin-guide/cpu-load.rst @@ -105,7 +105,7 @@ References -- - http://lkml.or
Re: decruft the vmalloc API
On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote: > Hi all, > > Peter noticed that with some dumb luck you can toast the kernel address > space with exported vmalloc symbols. > > I used this as an opportunity to decruft the vmalloc.c API and make it > much more systematic. This also removes any chance to create vmalloc > mappings outside the designated areas or using executable permissions > from modules. Besides that it removes more than 300 lines of code. I haven't read all your patches yet. Have you tested it on 32-bit ARM, where the module area is located _below_ PAGE_OFFSET and outside of the vmalloc area? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/i915: Introduce scaling filter related registers and bit fields.
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v3:
* None
changes since v2:
* Change macro names to CNL_* and use +(set)*8 instead of adding
another trip through _PICK_EVEN (Ville).
changes since v1:
* None
changes since RFC:
* Parametrize scaler coeffient macros by 'set' (Ville)
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_reg.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a7bd6db164b..e8d9c3261ac2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7296,6 +7296,7 @@ enum {
#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
#define PS_FILTER_MEDIUM (0 << 23)
+#define PS_FILTER_PROGRAMMED (1 << 23)
#define PS_FILTER_EDGE_ENHANCE (2 << 23)
#define PS_FILTER_BILINEAR (3 << 23)
#define PS_VERT3TAP(1 << 21)
@@ -7310,6 +7311,10 @@ enum {
#define PS_VADAPT_MODE_MOST_ADAPT (3 << 5)
#define PS_PLANE_Y_SEL_MASK (7 << 5)
#define PS_PLANE_Y_SEL(plane) (((plane) + 1) << 5)
+#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
+#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
+#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2)
+#define PS_UV_HORZ_FILTER_SELECT(set) ((set) << 1)
#define _PS_PWR_GATE_1A 0x68160
#define _PS_PWR_GATE_2A 0x68260
@@ -7372,6 +7377,17 @@ enum {
#define _PS_ECC_STAT_2B 0x68AD0
#define _PS_ECC_STAT_1C 0x691D0
+#define _PS_COEF_SET0_INDEX_1A0x68198
+#define _PS_COEF_SET0_INDEX_2A0x68298
+#define _PS_COEF_SET0_INDEX_1B0x68998
+#define _PS_COEF_SET0_INDEX_2B0x68A98
+#define PS_COEE_INDEX_AUTO_INC(1 << 10)
+
+#define _PS_COEF_SET0_DATA_1A 0x6819C
+#define _PS_COEF_SET0_DATA_2A 0x6829C
+#define _PS_COEF_SET0_DATA_1B 0x6899C
+#define _PS_COEF_SET0_DATA_2B 0x68A9C
+
#define _ID(id, a, b) _PICK_EVEN(id, a, b)
#define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
_ID(id, _PS_1A_CTRL, _PS_2A_CTRL), \
@@ -7400,7 +7416,13 @@ enum {
#define SKL_PS_ECC_STAT(pipe, id) _MMIO_PIPE(pipe, \
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
+#define CNL_PS_COEF_INDEX_SET(pipe, id, set) _MMIO_PIPE(pipe,\
+ _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A)
+ (set) * 8, \
+ _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B)
+ (set) * 8)
+#define CNL_PS_COEF_DATA_SET(pipe, id, set) _MMIO_PIPE(pipe, \
+ _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A) +
(set) * 8, \
+ _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B) +
(set) * 8)
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/5] drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation
Add documentation for newly introduced KMS plane and CRTC scaling filter properties. changes since v3: * None changes since v1: * None changes since RFC: * Add separate documentation for plane and CRTC. Signed-off-by: Pankaj Bharadiya --- Documentation/gpu/drm-kms.rst | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 397314d08f77..90250aa5395e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -512,6 +512,18 @@ Variable Refresh Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: Variable refresh properties +Plane Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: Plane scaling filter property + +CRTC Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :doc: CRTC scaling filter property + Existing KMS Properties --- -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
