Re: [PATCH] dma-buf: Add support for mapping buffers with DMA attributes
On Tue, 2021-08-31 at 14:47 +0200, Daniel Vetter wrote:
> On Mon, Aug 30, 2021 at 10:39:11AM +0800, guangming@mediatek.com
> wrote:
> > From: Guangming Cao
> >
> > When mapping the memory represented by a dma-buf into a device's
> > address space, it might be desireable to map the memory with
> > certain DMA attributes. Thus, introduce the dma_mapping_attrs
> > field in the dma_buf_attachment structure so that when
> > the memory is mapped with dma_buf_map_attachment, it is mapped
> > with the desired DMA attributes.
> >
> > Signed-off-by: Isaac J. Manjarres
> > Signed-off-by: Sandeep Patil
> > Signed-off-by: Guangming Cao
>
> Can you pls include the code that's going to use this here too?
>
> At a glance all the attributes you might want to set are supposed to
> be
> under the control of the exporter, not the importer.
> -Daniel
>
Hi Daniel,
Sorry for late. Currently I couldn't upload the coding going to use
this part because of some miscellaneous reasons.
Just as I said in commit message, for dma_heap, users can't skip cache
sync or other opetrations when map iova[dma_buf_map_attachment] by
fill (struct dma_buf_attachment).dma_map_attrs, it's not dma_map_attrs
expected(link:
https://github.com/torvalds/linux/blob/master/Documentation/core-api/dma-attributes.rst#dma_attr_skip_cpu_sync
).
Correspondingly, if they use dma_buf to map iova[dma_buf_map_attrs],
they will not meet this issue. So, I think it's a design flaw for
dma_heap.
BRs!
Guangming
> > ---
> > drivers/dma-buf/heaps/cma_heap.c| 6 --
> > drivers/dma-buf/heaps/system_heap.c | 6 --
> > include/linux/dma-buf.h | 3 +++
> > 3 files changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-
> > buf/heaps/cma_heap.c
> > index 0c05b79870f9..2c9feb3bfc3e 100644
> > --- a/drivers/dma-buf/heaps/cma_heap.c
> > +++ b/drivers/dma-buf/heaps/cma_heap.c
> > @@ -99,9 +99,10 @@ static struct sg_table
> > *cma_heap_map_dma_buf(struct dma_buf_attachment *attachme
> > {
> > struct dma_heap_attachment *a = attachment->priv;
> > struct sg_table *table = >table;
> > + int attrs = attachment->dma_map_attrs;
> > int ret;
> >
> > - ret = dma_map_sgtable(attachment->dev, table, direction, 0);
> > + ret = dma_map_sgtable(attachment->dev, table, direction,
> > attrs);
> > if (ret)
> > return ERR_PTR(-ENOMEM);
> > a->mapped = true;
> > @@ -113,9 +114,10 @@ static void cma_heap_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,
> >enum dma_data_direction direction)
> > {
> > struct dma_heap_attachment *a = attachment->priv;
> > + int attrs = attachment->dma_map_attrs;
> >
> > a->mapped = false;
> > - dma_unmap_sgtable(attachment->dev, table, direction, 0);
> > + dma_unmap_sgtable(attachment->dev, table, direction, attrs);
> > }
> >
> > static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf
> > *dmabuf,
> > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-
> > buf/heaps/system_heap.c
> > index 23a7e74ef966..fc7b1e02988e 100644
> > --- a/drivers/dma-buf/heaps/system_heap.c
> > +++ b/drivers/dma-buf/heaps/system_heap.c
> > @@ -130,9 +130,10 @@ static struct sg_table
> > *system_heap_map_dma_buf(struct dma_buf_attachment *attac
> > {
> > struct dma_heap_attachment *a = attachment->priv;
> > struct sg_table *table = a->table;
> > + int attrs = attachment->dma_map_attrs;
> > int ret;
> >
> > - ret = dma_map_sgtable(attachment->dev, table, direction, 0);
> > + ret = dma_map_sgtable(attachment->dev, table, direction,
> > attrs);
> > if (ret)
> > return ERR_PTR(ret);
> >
> > @@ -145,9 +146,10 @@ static void system_heap_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,
> > enum dma_data_direction
> > direction)
> > {
> > struct dma_heap_attachment *a = attachment->priv;
> > + int attrs = attachment->dma_map_attrs;
> >
> > a->mapped = false;
> > - dma_unmap_sgtable(attachment->dev, table, direction, 0);
> > + dma_unmap_sgtable(attachment->dev, table, direction, attrs);
> > }
> >
> > static int system_heap_dma_buf_begin_cpu_access(struct dma_buf
> > *dmabuf,
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index efdc56b9d95f..4d650731766e 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -379,6 +379,8 @@ struct dma_buf_attach_ops {
> > * @importer_ops: importer operations for this attachment, if
> > provided
> > * dma_buf_map/unmap_attachment() must be called with the dma_resv
> > lock held.
> > * @importer_priv: importer specific attachment data.
> > + * @dma_map_attrs: DMA attributes to be used when the exporter
> > maps the buffer
> > + * through dma_buf_map_attachment.
> > *
> > * This structure holds the attachment information between the
> > dma_buf buffer
> > * and its user device(s). The list contains
[PATCH v11 4/4] drm/bridge: anx7625: add HDMI audio function
Add audio HDMI codec function support, enable it through device true
flag "analogix,audio-enable".
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 226 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
2 files changed, 231 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 92038c4661ff..12e148298ba9 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -33,6 +33,7 @@
#include
#include
+#include
#include
#include "anx7625.h"
@@ -153,6 +154,20 @@ static int anx7625_write_and(struct anx7625_data *ctx,
return anx7625_reg_write(ctx, client, offset, (val & (mask)));
}
+static int anx7625_write_and_or(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 offset, u8 and_mask, u8 or_mask)
+{
+ int val;
+
+ val = anx7625_reg_read(ctx, client, offset);
+ if (val < 0)
+ return val;
+
+ return anx7625_reg_write(ctx, client,
+offset, (val & and_mask) | (or_mask));
+}
+
static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
{
int i, ret;
@@ -1353,6 +1368,9 @@ static int anx7625_parse_dt(struct device *dev,
else
DRM_DEV_DEBUG_DRIVER(dev, "found MIPI DSI host node.\n");
+ if (of_property_read_bool(np, "analogix,audio-enable"))
+ pdata->audio_en = 1;
+
ret = drm_of_find_panel_or_bridge(np, 1, 0, , NULL);
if (ret < 0) {
if (ret == -ENODEV)
@@ -1423,6 +1441,208 @@ static enum drm_connector_status
anx7625_sink_detect(struct anx7625_data *ctx)
connector_status_disconnected;
}
+static int anx7625_audio_hw_params(struct device *dev, void *data,
+ struct hdmi_codec_daifmt *fmt,
+ struct hdmi_codec_params *params)
+{
+ struct anx7625_data *ctx = dev_get_drvdata(dev);
+ int wl, ch, rate;
+ int ret = 0;
+
+ if (fmt->fmt != HDMI_DSP_A) {
+ DRM_DEV_ERROR(dev, "only supports DSP_A\n");
+ return -EINVAL;
+ }
+
+ DRM_DEV_DEBUG_DRIVER(dev, "setting %d Hz, %d bit, %d channels\n",
+params->sample_rate, params->sample_width,
+params->cea.channels);
+
+ ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6,
+ ~I2S_SLAVE_MODE,
+ TDM_SLAVE_MODE);
+
+ /* Word length */
+ switch (params->sample_width) {
+ case 16:
+ wl = AUDIO_W_LEN_16_20MAX;
+ break;
+ case 18:
+ wl = AUDIO_W_LEN_18_20MAX;
+ break;
+ case 20:
+ wl = AUDIO_W_LEN_20_20MAX;
+ break;
+ case 24:
+ wl = AUDIO_W_LEN_24_24MAX;
+ break;
+ default:
+ DRM_DEV_DEBUG_DRIVER(dev, "wordlength: %d bit not support",
+params->sample_width);
+ return -EINVAL;
+ }
+ ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_5,
+ 0xf0, wl);
+
+ /* Channel num */
+ switch (params->cea.channels) {
+ case 2:
+ ch = I2S_CH_2;
+ break;
+ case 4:
+ ch = TDM_CH_4;
+ break;
+ case 6:
+ ch = TDM_CH_6;
+ break;
+ case 8:
+ ch = TDM_CH_8;
+ break;
+ default:
+ DRM_DEV_DEBUG_DRIVER(dev, "channel number: %d not support",
+params->cea.channels);
+ return -EINVAL;
+ }
+ ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6, 0x1f, ch << 5);
+ if (ch > I2S_CH_2)
+ ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6, AUDIO_LAYOUT);
+ else
+ ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CHANNEL_STATUS_6, ~AUDIO_LAYOUT);
+
+ /* FS */
+ switch (params->sample_rate) {
+ case 32000:
+ rate = AUDIO_FS_32K;
+ break;
+ case 44100:
+ rate = AUDIO_FS_441K;
+ break;
+ case 48000:
+ rate = AUDIO_FS_48K;
+ break;
+ case 88200:
+ rate = AUDIO_FS_882K;
+ break;
+ case 96000:
+ rate = AUDIO_FS_96K;
+ break;
+ case
[PATCH v11 3/4] drm/bridge: anx7625: add MIPI DPI input feature
The basic anx7625 driver only support MIPI DSI rx signal input.
This patch add MIPI DPI rx input configuration support, after apply
this patch, the driver can support DSI rx or DPI rx by adding
'bus-type' in DT.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 246 --
drivers/gpu/drm/bridge/analogix/anx7625.h | 18 +-
2 files changed, 204 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 469037f2fd3d..92038c4661ff 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include "anx7625.h"
@@ -152,18 +153,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
return anx7625_reg_write(ctx, client, offset, (val & (mask)));
}
-static int anx7625_write_and_or(struct anx7625_data *ctx,
- struct i2c_client *client,
- u8 offset, u8 and_mask, u8 or_mask)
+static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
{
- int val;
+ int i, ret;
- val = anx7625_reg_read(ctx, client, offset);
- if (val < 0)
- return val;
+ ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CONTROL_REGISTER, 0x80);
+ for (i = 0; i < 13; i++)
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_BIT_MATRIX_12 + i,
+0x18 + i);
- return anx7625_reg_write(ctx, client,
-offset, (val & and_mask) | (or_mask));
+ return ret;
}
static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
@@ -221,38 +222,6 @@ static int anx7625_video_mute_control(struct anx7625_data
*ctx,
return ret;
}
-static int anx7625_config_audio_input(struct anx7625_data *ctx)
-{
- struct device *dev = >client->dev;
- int ret;
-
- /* Channel num */
- ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
-
- /* FS */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_4,
- 0xf0, AUDIO_FS_48K);
- /* Word length */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_5,
- 0xf0, AUDIO_W_LEN_24_24MAX);
- /* I2S */
- ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
- ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
-AUDIO_CONTROL_REGISTER, ~TDM_TIMING_MODE);
- /* Audio change flag */
- ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
- AP_AV_STATUS, AP_AUDIO_CHG);
-
- if (ret < 0)
- DRM_DEV_ERROR(dev, "fail to config audio.\n");
-
- return ret;
-}
-
/* Reduction of fraction a/b */
static void anx7625_reduction_of_a_fraction(unsigned long *a, unsigned long *b)
{
@@ -431,7 +400,7 @@ static int anx7625_dsi_video_timing_config(struct
anx7625_data *ctx)
ret |= anx7625_write_and(ctx, ctx->i2c.rx_p1_client,
MIPI_LANE_CTRL_0, 0xfc);
ret |= anx7625_write_or(ctx, ctx->i2c.rx_p1_client,
- MIPI_LANE_CTRL_0, 3);
+ MIPI_LANE_CTRL_0, ctx->pdata.mipi_lanes - 1);
/* Htotal */
htotal = ctx->dt.hactive.min + ctx->dt.hfront_porch.min +
@@ -615,6 +584,76 @@ static int anx7625_dsi_config(struct anx7625_data *ctx)
return ret;
}
+static int anx7625_api_dpi_config(struct anx7625_data *ctx)
+{
+ struct device *dev = >client->dev;
+ u16 freq = ctx->dt.pixelclock.min / 1000;
+ int ret;
+
+ /* configure pixel clock */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ PIXEL_CLOCK_L, freq & 0xFF);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+PIXEL_CLOCK_H, (freq >> 8));
+
+ /* set DPI mode */
+ /* set to DPI PLL module sel */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_DIGITAL_PLL_9, 0x20);
+ /* power down MIPI */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_LANE_CTRL_10, 0x08);
+ /* enable DPI mode */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p1_client,
+MIPI_DIGITAL_PLL_18, 0x1C);
+ /* set first edge */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+
[PATCH v11 2/4] drm/bridge: anx7625: fix not correct return value
At some time, the original code may return non zero value, force return 0
if operation finished.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 1a871f6b6822..469037f2fd3d 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -191,10 +191,10 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
AP_AUX_CTRL_STATUS);
if (val < 0 || (val & 0x0F)) {
DRM_DEV_ERROR(dev, "aux status %02x\n", val);
- val = -EIO;
+ return -EIO;
}
- return val;
+ return 0;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
--
2.25.1
[PATCH v11 1/4] dt-bindings:drm/bridge:anx7625:add vendor define
Add 'bus-type' and 'data-lanes' define for port0. Add DP tx lane0,
lane1 swing register setting array, and audio enable flag.
The device which cannot pass DP tx PHY CTS caused by long PCB trace or
embedded MUX, adjusting ANX7625 PHY parameters can pass the CTS test. The
adjusting type include Pre-emphasis, Vp-p, Rterm(Resistor Termination)
and Rsel(Driven Strength). Each lane has maximum 20 registers for
these settings.
Signed-off-by: Xin Ji
---
.../display/bridge/analogix,anx7625.yaml | 65 ++-
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index ab48ab2f4240..1d3e88daca04 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -43,14 +43,70 @@ properties:
vdd33-supply:
description: Regulator that provides the supply 3.3V power.
+ analogix,lane0-swing:
+$ref: /schemas/types.yaml#/definitions/uint8-array
+minItems: 1
+maxItems: 20
+description:
+ an array of swing register setting for DP tx lane0 PHY.
+ Registers 0~9 are Swing0_Pre0, Swing1_Pre0, Swing2_Pre0,
+ Swing3_Pre0, Swing0_Pre1, Swing1_Pre1, Swing2_Pre1, Swing0_Pre2,
+ Swing1_Pre2, Swing0_Pre3, they are for [Boost control] and
+ [Swing control] setting.
+ Registers 0~9, bit 3:0 is [Boost control], these bits control
+ post cursor manual, increase the [Boost control] to increase
+ Pre-emphasis value.
+ Registers 0~9, bit 6:4 is [Swing control], these bits control
+ swing manual, increase [Swing control] setting to add Vp-p value
+ for each Swing, Pre.
+ Registers 10~19 are Swing0_Pre0, Swing1_Pre0, Swing2_Pre0,
+ Swing3_Pre0, Swing0_Pre1, Swing1_Pre1, Swing2_Pre1, Swing0_Pre2,
+ Swing1_Pre2, Swing0_Pre3, they are for [R select control] and
+ [R Termination control] setting.
+ Registers 10~19, bit 4:0 is [R select control], these bits are
+ compensation manual, increase it can enhance IO driven strength
+ and Vp-p.
+ Registers 10~19, bit 5:6 is [R termination control], these bits
+ adjust 50ohm impedance of DP tx termination. 00:55 ohm,
+ 01:50 ohm(default), 10:45 ohm, 11:40 ohm.
+
+ analogix,lane1-swing:
+$ref: /schemas/types.yaml#/definitions/uint8-array
+minItems: 1
+maxItems: 20
+description:
+ an array of swing register setting for DP tx lane1 PHY.
+ DP TX lane1 swing register setting same with lane0
+ swing, please refer lane0-swing property description.
+
+ analogix,audio-enable:
+type: boolean
+description: let the driver enable audio HDMI codec function or not.
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
-$ref: /schemas/graph.yaml#/properties/port
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
description:
- Video port for MIPI DSI input.
+ MIPI DSI/DPI input.
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint: true
+
+ bus-type:
+enum: [1, 5]
+default: 1
+
+ data-lanes: true
port@1:
$ref: /schemas/graph.yaml#/properties/port
@@ -87,6 +143,9 @@ examples:
vdd10-supply = <_mipibrdg>;
vdd18-supply = <_mipibrdg>;
vdd33-supply = <_mipibrdg>;
+analogix,audio-enable;
+analogix,lane0-swing = /bits/ 8 <0x14 0x54 0x64 0x74>;
+analogix,lane1-swing = /bits/ 8 <0x14 0x54 0x64 0x74>;
ports {
#address-cells = <1>;
@@ -96,6 +155,8 @@ examples:
reg = <0>;
anx7625_in: endpoint {
remote-endpoint = <_dsi>;
+bus-type = <5>;
+data-lanes = <0 1 2 3>;
};
};
--
2.25.1
[PATCH v11 0/4] Add MIPI rx DPI support
Hi all, this patch series implement MIPI rx DPI feature. Please help to review. This is the v11 version, rebase all patches on the latest code. Any mistakes, please let me know, I'll fix it in the next series. Change history: v11: Fix Rob Herring comment - Move swing register description in property. - Remove additional property. v10: Fix Rob Herring and Laurent Pinchart comments - Add more description about lane swing configuration in commit message. v9: Fix Neil Amstrong comment - use macro define 'V4L2_FWNODE_BUS_TYPE_PARALLEL' instead of fixing value. v8: Fix Laurent Pinchart comment - Expand the commit message. v7: - Rebase DT on the latest branch 'drm-misc-next'. - Remove HDCP patch. v6: Fix kernel robot compile warning v5: Fix Rob Herring, Hsin-Yi, Robert Foss comments - Rebase code on the branch 'drm-misc-next', refer video-interfaces.yaml - Seprate HDCP function to a new patch - Fix driver not correctly get 'bus-type' 'data-lanes' - Add audio HDMI codec function support v4: Fix Rob Herring comment - Rebase code on the branch 'drm-misc-next' - Change 'analogix,hdcp-support' type to boolean v3: Fix Rob Herring, Dan Carpenter, Nicolas comment - Split the patch, fix not correct return data - Fix several coding format - Split DP tx swing register setting to two property - Add HDCP support vender flag - remove 'analogix,swing-setting' and 'analogix,mipi-dpi-in' property v2: Fix Rob Herring comment - Fix yamllint warnings/errors in analogix,anx7625.yaml - Fix kernel robot compile warning v1: initial MIPI rx DPI feature support Xin Ji (4): dt-bindings:drm/bridge:anx7625:add vendor define drm/bridge: anx7625: fix not correct return value drm/bridge: anx7625: add MIPI DPI input feature drm/bridge: anx7625: add HDMI audio function .../display/bridge/analogix,anx7625.yaml | 65 ++- drivers/gpu/drm/bridge/analogix/anx7625.c | 458 -- drivers/gpu/drm/bridge/analogix/anx7625.h | 23 +- 3 files changed, 491 insertions(+), 55 deletions(-) -- 2.25.1
RE: [RFC v1 3/6] drm: Add a capability flag to support additional flip completion signalling
Hi Pekka,
>
> Hi Vivek!
>
> > > On Mon, 13 Sep 2021 16:35:26 -0700
> > > Vivek Kasireddy wrote:
> > >
> > > > If a driver supports this capability, it means that there would be an
> > > > additional signalling mechanism for a page flip completion in addition
> > > > to out_fence or DRM_MODE_PAGE_FLIP_EVENT.
> > > >
> > > > This capability may only be relevant for Virtual KMS drivers and is
> > > > currently
> > > > used only by virtio-gpu. Also, it can provide a potential solution for:
> > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/514
> > > >
> > > > Signed-off-by: Vivek Kasireddy
> > > > ---
> > > > drivers/gpu/drm/drm_ioctl.c | 3 +++
> > > > include/drm/drm_mode_config.h | 8
> > > > include/uapi/drm/drm.h| 1 +
> > > > 3 files changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > > index 8b8744dcf691..8a420844f8bc 100644
> > > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > > @@ -302,6 +302,9 @@ static int drm_getcap(struct drm_device *dev, void
> > > > *data,
> struct
> > > drm_file *file_
> > > > case DRM_CAP_CRTC_IN_VBLANK_EVENT:
> > > > req->value = 1;
> > > > break;
> > > > + case DRM_CAP_RELEASE_FENCE:
> > > > + req->value = dev->mode_config.release_fence;
> > > > + break;
> > >
> > > Hi Vivek,
> > >
> > > is this actually necessary?
> > >
> > > I would think that userspace figures out the existence of the release
> > > fence capability by seeing that the KMS property "RELEASE_FENCE_PTR"
> > > either exists or not.
> > [Vivek] Yeah, that makes sense. However, in order for the userspace to not
> > see
> > this property, we'd have to prevent drm core from exposing it; which means
> > we
> > need to check dev->mode_config.release_fence before attaching the property
> > to the crtc.
>
> Kernel implementation details, I don't bother with those personally. ;-)
>
> Sounds right.
>
> > >
> > > However, would we not need a client cap instead?
> > >
> > > If a KMS driver knows that userspace is aware of "RELEASE_FENCE_PTR"
> > > and will use it when necessary, then the KMS driver can send the
> > > pageflip completion without waiting for the host OS to signal the old
> > > buffer as free for re-use.
> > [Vivek] Right, the KMS driver can just look at whether the release_fence was
> > added by the userspace (in the atomic commit) to determine whether it needs
> > to wait for the old fb.
>
> You could do it that way, but is it a good idea? I'm not sure.
>
> > > If the KMS driver does not know that userspace can handle pageflip
> > > completing "too early", then it has no choice but to wait until the old
> > > buffer is really free before signalling pageflip completion.
> > >
> > > Wouldn't that make sense?
> > [Vivek] Yes; DRM_CAP_RELEASE_FENCE may not be necessary to
> > implement the behavior you suggest which makes sense.
> >
> > >
> > >
> > > Otherwise, this proposal sounds fine to me.
> > [Vivek] Did you get a chance to review the Weston MR:
> > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/668
> >
> > Could you please take a look?
>
> Unfortunately I cannot promise any timely feedback on that, I try to
> concentrate on CM However, I'm not the only Weston reviewer, I
> hope.
[Kasireddy, Vivek] I was going to say it's a small patch to review but, ok np,
I'll
ping Simon or Michel or Daniel.
Thanks,
Vivek
>
>
> Thanks,
> pq
>
> >
> > Thanks,
> > Vivek
> >
> > >
> > >
> > > Thanks,
> > > pq
> > >
> > >
> > > > default:
> > > > return -EINVAL;
> > > > }
> > > > diff --git a/include/drm/drm_mode_config.h
> > > > b/include/drm/drm_mode_config.h
> > > > index 12b964540069..944bebf359d7 100644
> > > > --- a/include/drm/drm_mode_config.h
> > > > +++ b/include/drm/drm_mode_config.h
> > > > @@ -935,6 +935,14 @@ struct drm_mode_config {
> > > > */
> > > > bool normalize_zpos;
> > > >
> > > > + /**
> > > > +* @release_fence:
> > > > +*
> > > > +* If this option is set, it means there would be an additional
> > > > signalling
> > > > +* mechanism for a page flip completion.
> > > > +*/
> > > > + bool release_fence;
> > > > +
> > > > /**
> > > > * @modifiers_property: Plane property to list support
> > > > modifier/format
> > > > * combination.
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 3b810b53ba8b..8b8985f65581 100644
> > > > --- a/include/uapi/drm/drm.h
> > > > +++ b/include/uapi/drm/drm.h
> > > > @@ -767,6 +767,7 @@ struct drm_gem_open {
> > > > * Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
> > > > */
> > > > #define DRM_CAP_SYNCOBJ_TIMELINE 0x14
> > > > +#define DRM_CAP_RELEASE_FENCE 0x15
> > > >
> > > > /* DRM_IOCTL_GET_CAP ioctl argument type */
> > > > struct
Re: [PATCH 0/4] drm/i915: Make the driver not oops on load on old machines
On Thu, 14 Oct 2021 at 19:09, Ville Syrjala wrote: > > From: Ville Syrjälä > > Fix a pile of regression on older machines which just oops the driver > on load. > For all 4: Reviewed-by: Dave Airlie though it would be nice if the clflushes has more justifications on initial patch submission/review, maybe something for gt team to keep an eye for patches coming out from internal. Dave.
Re: [PATCH v3 2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
Am Dienstag, 28. September 2021, 23:35:50 CEST schrieb Brian Norris:
> Since commit 43c2de1002d2, we perform most HW configuration in the
> bind() function. This configuration may be lost on suspend/resume, so we
> need to call it again. That may lead to errors like this after system
> suspend/resume:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet).
>
> Note that early mailing list versions of this driver borrowed Rockchip's
> downstream/BSP solution, to do HW configuration in mode_set() (which
> *is* called at the appropriate pre-enable() times),
not always though. In non-atomic settings .mode_set actually doesn't
seem to be called every time. I've experienced this when drm disables
atomic when X11 is running.
So having real suspend/resume callbacks makes quite a lot of sense :-)
Heiko
> but that was
> discarded along the way. I've avoided that still, because mode_set()
> documentation doesn't suggest this kind of purpose as far as I can tell.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Cc:
> Signed-off-by: Brian Norris
> ---
>
> Changes in v3:
> - New patch, to fix related PM issue discovered after patch 1
>
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 37 +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 45676b23c019..21c67343cc6c 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -268,6 +268,8 @@ struct dw_mipi_dsi_rockchip {
> struct dw_mipi_dsi *dmd;
> const struct rockchip_dw_dsi_chip_data *cdata;
> struct dw_mipi_dsi_plat_data pdata;
> +
> + bool dsi_bound;
> };
>
> struct dphy_pll_parameter_map {
> @@ -964,6 +966,8 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> goto out_pm_runtime;
> }
>
> + dsi->dsi_bound = true;
> +
> return 0;
>
> out_pm_runtime:
> @@ -983,6 +987,8 @@ static void dw_mipi_dsi_rockchip_unbind(struct device
> *dev,
> if (dsi->is_slave)
> return;
>
> + dsi->dsi_bound = false;
> +
> dw_mipi_dsi_unbind(dsi->dmd);
>
> clk_disable_unprepare(dsi->pllref_clk);
> @@ -1277,6 +1283,36 @@ static const struct phy_ops dw_mipi_dsi_dphy_ops = {
> .exit = dw_mipi_dsi_dphy_exit,
> };
>
> +static int __maybe_unused dw_mipi_dsi_rockchip_resume(struct device *dev)
> +{
> + struct dw_mipi_dsi_rockchip *dsi = dev_get_drvdata(dev);
> + int ret;
> +
> + /*
> + * Re-configure DSI state, if we were previously initialized. We need
> + * to do this before rockchip_drm_drv tries to re-enable() any panels.
> + */
> + if (dsi->dsi_bound) {
> + ret = clk_prepare_enable(dsi->grf_clk);
> + if (ret) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk:
> %d\n", ret);
> + return ret;
> + }
> +
> + dw_mipi_dsi_rockchip_config(dsi);
> + if (dsi->slave)
> + dw_mipi_dsi_rockchip_config(dsi->slave);
> +
> + clk_disable_unprepare(dsi->grf_clk);
> + }
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops dw_mipi_dsi_rockchip_pm_ops = {
> + SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, dw_mipi_dsi_rockchip_resume)
> +};
> +
> static int dw_mipi_dsi_rockchip_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -1594,6 +1630,7 @@ struct platform_driver dw_mipi_dsi_rockchip_driver = {
> .remove = dw_mipi_dsi_rockchip_remove,
> .driver = {
> .of_match_table = dw_mipi_dsi_rockchip_dt_ids,
> + .pm = _mipi_dsi_rockchip_pm_ops,
> .name = "dw-mipi-dsi-rockchip",
> },
> };
>
Re: [PATCH] drm/panel:Adjust sync values for Feixin K101-IM2BYL02 panel
Thanks for applying.
Den 17.10.2021 kl. 19.24 skrev Sam Ravnborg:
Hi Dan,
On Wed, Aug 18, 2021 at 11:48:18PM +0200, Dan Johansen wrote:
This adjusts sync values according to the datasheet
Fixes: 1c243751c095bb95e2795f076ea7a0bcdd60a93a ("drm/panel: ilitek-ili9881c: add
support for Feixin K101-IM2BYL02 panel")
Co-developed-by: Marius Gripsgard
Signed-off-by: Dan Johansen
Sorry for not picking this up sooner - I have been away for a while.
The patch is now applied to drm-misc-fixes and will show up in the
upstream kernel in 1-2 week from now.
I updated the subject and the fixes tag while applying.
Thanks.
The Co-developed-by: is supposed to be paired with a Signed-off-by:
by the same person. Something to do right next time.
Didn't know that. Thanks, will remember for next time!
Sam
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 0145129d7c66..534dd7414d42 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -590,14 +590,14 @@ static const struct drm_display_mode
k101_im2byl02_default_mode = {
.clock = 69700,
.hdisplay = 800,
- .hsync_start= 800 + 6,
- .hsync_end = 800 + 6 + 15,
- .htotal = 800 + 6 + 15 + 16,
+ .hsync_start= 800 + 52,
+ .hsync_end = 800 + 52 + 8,
+ .htotal = 800 + 52 + 8 + 48,
.vdisplay = 1280,
- .vsync_start= 1280 + 8,
- .vsync_end = 1280 + 8 + 48,
- .vtotal = 1280 + 8 + 48 + 52,
+ .vsync_start= 1280 + 16,
+ .vsync_end = 1280 + 16 + 6,
+ .vtotal = 1280 + 16 + 6 + 15,
.width_mm = 135,
.height_mm = 217,
--
2.32.0
--
Kind regards
*Dan Johansen*
Project lead of the *Manjaro ARM* project
Manjaro-ARM
Re: [PATCH v3 0/4] Fix Rockchip MIPI DSI display init timeouts
On Tue, 28 Sep 2021 14:35:48 -0700, Brian Norris wrote:
> The Rockchip DSI driver has had a number of bugs over time and has
> usually only worked by chance. A number of users have noticed that
> things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all
> lane config except LCDC mux to bind()"), although it was fixing several
> real issues of its own that had been present forever in the upstream
> driver (but notably, not in the downstream/BSP driver).
>
> [...]
Applied, thanks!
[1/4] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
commit: 514db871922f103886ad4d221cf406b4fcc5e74a
[2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
commit: e584cdc1549932f87a2707b56bc588cfac5d89e0
[3/4] drm/rockchip: dsi: Fix unbalanced clock on probe error
commit: 251888398753924059f3bb247a44153a2853137f
[4/4] drm/rockchip: dsi: Disable PLL clock on bind error
commit: 5a614570172e1c9f59035d259dd735acd4f1c01b
Best regards,
--
Heiko Stuebner
Re: [PATCH] drm/rockchip: vop: Add timeout for DSP hold
On Fri, 8 Oct 2021 15:31:04 -0700, Brian Norris wrote: > If hardware is malfunctioning (e.g., misconfigured clocks?), we can get > stuck here forever, holding various DRM locks and eventually locking up > the entire system. It's better to complain loudly and move on, than to > lock up the system. > > In local tests, this operation takes less than 20ms. Applied, thanks! [1/1] drm/rockchip: vop: Add timeout for DSP hold commit: 085af7d28897deb08a4f64a29e55525f963cc041 Best regards, -- Heiko Stuebner
Re: [PATCH] drm/i915/gt: make a gt sysfs group and move power management files
Hi Sujaritha,
[...]
> > +void intel_gt_sysfs_unregister(struct intel_gt *gt)
> > +{
> > +}
>
> Is there a reason for this function to not be populated ?
yes, there is, indeed, something missing here. There has been a
fix bout this floating around from Chris about sysfs_gt kobjects.
I will check if we can add the fix at the next verion.
Thanks,
Andi
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
On 10/17/21 7:40 PM, Sam Ravnborg wrote:
Hi Marek,
On Sun, Oct 17, 2021 at 07:29:51PM +0200, Marek Vasut wrote:
On 10/17/21 6:49 PM, Sam Ravnborg wrote:
[...]
+ /*
+* Encoder might sample data on different clock edge than the display,
+* for example OnSemi FIN3385 has a dedicated strapping pin to select
+* the sampling edge.
+*/
+ if (lvds_codec->connector_type == DRM_MODE_CONNECTOR_LVDS &&
+ !of_property_read_u32(dev->of_node, "pclk-sample", )) {
+ lvds_codec->timings.input_bus_flags = val ?
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE :
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE;
+ }
+
/*
* The panel_bridge bridge is attached to the panel's of_node,
* but we need a bridge attached to our of_node for our user
* to look up.
*/
lvds_codec->bridge.of_node = dev->of_node;
+ lvds_codec->bridge.timings = _codec->timings;
I do not understand how this will work. The only field that is set is
timings.input_bus_flags
but any user will see bridge.timings is set and will think this is all
timing info.
Maybe I just misses something obvious?
Is there anything else in those timings that should be set ? See
include/drm/drm_bridge.h around line 640
setup_time_ps/hold_time_ps/dual_link isn't supported by this driver, so it
is 0 or false anyway, i.e. no change.
Just me being confused with display_timings. Patch looks good.
Reviewed-by: Sam Ravnborg
Ping me in a few days to apply it if there is no more feedback.
ACK
Re: [PATCH] drm: mxsfb: Fix NULL pointer dereference crash on unload
On 10/17/21 7:52 PM, Sam Ravnborg wrote:
Hi Marek,
On Wed, Sep 08, 2021 at 08:24:20PM +0200, Daniel Vetter wrote:
On Tue, Sep 07, 2021 at 04:49:00AM +0200, Marek Vasut wrote:
The mxsfb->crtc.funcs may already be NULL when unloading the driver,
in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from
mxsfb_unload() leads to NULL pointer dereference.
Since all we care about is masking the IRQ and mxsfb->base is still
valid, just use that to clear and mask the IRQ.
Fixes: ae1ed00932819 ("drm: mxsfb: Stop using DRM simple display pipeline
helper")
Signed-off-by: Marek Vasut
Cc: Daniel Abrecht
Cc: Emil Velikov
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Stefan Agner
You probably want a drm_atomic_helper_shutdown instead of trying to do all
that manually. We've also added a bunch more devm and drmm_ functions to
automate the cleanup a lot more here, e.g. your drm_mode_config_cleanup is
in the wrong place.
I have applied v2 of this patch today - but failed to see any response
in v2 to this comment from Daniel. Was it lost somehow?
Hmmm, I'll investigate that ^ in the next round of mxsfb clean ups.
Re: [PATCH v2 4/4] vgaswitcheroo: do not check for NULL debugfs dentry
On Wed, Oct 13, 2021 at 08:36:01PM +0200, Nirmoy Das wrote:
> Debugfs APIs returns encoded error on failure so use
> debugfs_lookup() instead of checking for NULL.
The commit message no longer matches up with the patch itself
(debugfs_lookup() isn't called).
My suggestion would be something like:
Retry creation of the vga_switcheroo debugfs if a previous
invocation of debugfs_create_dir() returned an error code.
With that addressed,
Reviewed-by: Lukas Wunner
Thanks,
Lukas
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/vga/vga_switcheroo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/vga/vga_switcheroo.c
> b/drivers/gpu/vga/vga_switcheroo.c
> index 365e6ddbe90f..07ab8d85e899 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -914,7 +914,7 @@ static void vga_switcheroo_debugfs_fini(struct vgasr_priv
> *priv)
> static void vga_switcheroo_debugfs_init(struct vgasr_priv *priv)
> {
> /* already initialised */
> - if (priv->debugfs_root)
> + if (priv->debugfs_root && !IS_ERR(priv->debugfs_root))
> return;
>
> priv->debugfs_root = debugfs_create_dir("vgaswitcheroo", NULL);
> --
> 2.32.0
[PATCH v6] dt-bindings: drm/msm/gpu: convert to YAML
Conversion of text binding for Adreno GPU to the YAML format.
Signed-off-by: David Heidelberg
---
v2:
- added compatbile description from Rob Clark
- dropped reg description
- reg numbers increased to 3 (since we also have uncommon cx_dbgc)
- specified interconnect-names items range
- defined zap-shader as an object and added it's properties
- enforce 0 clocks for Andreno >= 6xx since it's defined in GMU node
v3:
- fix patterns (add backslash before dot)
- add additional clocks
- adreno@ -> gpu@
- add few const and change enum to anyOf
- added clock & clock-names placeholder in non-conditional part
(description)
v4:
- clock & clock-names - true,false instead maxItems
- impl. #stream-id-cells, nvmem-cell-names, nvmem-cells
- dropped requirement on firmware-name in zap_shader
v5:
- maxOtems -> maxItems typo fix
v6:
- enum -> const to fix ordering
- opp-table is object
- spacing
- drop undocumented and unused #stream-id-cells
.../devicetree/bindings/display/msm/gpu.txt | 157 --
.../devicetree/bindings/display/msm/gpu.yaml | 288 ++
2 files changed, 288 insertions(+), 157 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/msm/gpu.txt
create mode 100644 Documentation/devicetree/bindings/display/msm/gpu.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
deleted file mode 100644
index 090dcb3fc34d..
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ /dev/null
@@ -1,157 +0,0 @@
-Qualcomm adreno/snapdragon GPU
-
-Required properties:
-- compatible: "qcom,adreno-XYZ.W", "qcom,adreno" or
- "amd,imageon-XYZ.W", "amd,imageon"
-for example: "qcom,adreno-306.0", "qcom,adreno"
- Note that you need to list the less specific "qcom,adreno" (since this
- is what the device is matched on), in addition to the more specific
- with the chip-id.
- If "amd,imageon" is used, there should be no top level msm device.
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The interrupt signal from the gpu.
-- clocks: device clocks (if applicable)
- See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required by a3xx, a4xx and a5xx
- cores:
- * "core"
- * "iface"
- * "mem_iface"
- For GMU attached devices the GPU clocks are not used and are not required.
The
- following devices should not list clocks:
- - qcom,adreno-630.2
-- iommus: optional phandle to an adreno iommu instance
-- operating-points-v2: optional phandle to the OPP operating points
-- interconnects: optional phandle to an interconnect provider. See
- ../interconnect/interconnect.txt for details. Some A3xx and all A4xx
platforms
- will have two paths; all others will have one path.
-- interconnect-names: The names of the interconnect paths that correspond to
the
- interconnects property. Values must be gfx-mem and ocmem.
-- qcom,gmu: For GMU attached devices a phandle to the GMU device that will
- control the power for the GPU. Applicable targets:
-- qcom,adreno-630.2
-- zap-shader: For a5xx and a6xx devices this node contains a memory-region that
- points to reserved memory to store the zap shader that can be used to help
- bring the GPU out of secure mode.
-- firmware-name: optional property of the 'zap-shader' node, listing the
- relative path of the device specific zap firmware.
-- sram: phandle to the On Chip Memory (OCMEM) that's present on some a3xx and
-a4xx Snapdragon SoCs. See
-Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
-
-Optional properties:
-- #cooling-cells: The value must be 2. For details, please refer
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml.
-
-Example 3xx/4xx:
-
-/ {
- ...
-
- gpu: adreno@fdb0 {
- compatible = "qcom,adreno-330.2",
-"qcom,adreno";
- reg = <0xfdb0 0x1>;
- reg-names = "kgsl_3d0_reg_memory";
- interrupts = ;
- interrupt-names = "kgsl_3d0_irq";
- clock-names = "core",
- "iface",
- "mem_iface";
- clocks = < OXILI_GFX3D_CLK>,
-< OXILICX_AHB_CLK>,
-< OXILICX_AXI_CLK>;
- sram = <_sram>;
- power-domains = < OXILICX_GDSC>;
- operating-points-v2 = <_opp_table>;
- iommus = <_iommu 0>;
- #cooling-cells = <2>;
- };
-
- gpu_sram: ocmem@fdd0 {
- compatible = "qcom,msm8974-ocmem";
-
- reg = <0xfdd0 0x2000>,
- <0xfec0 0x18>;
- reg-names = "ctrl",
- "mem";
-
- clocks = < RPM_SMD_OCMEMGX_CLK>,
-< OCMEMCX_OCMEMNOC_CLK>;
-
Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount
On Sat, Oct 16, 2021 at 8:45 AM Jason Gunthorpe wrote: > > On Thu, Oct 14, 2021 at 06:37:35PM -0700, Dan Williams wrote: > > On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote: > > > > > > On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote: > > > > > > Does anyone know why devmap is pte_special anyhow? > > > > > > > > It does not need to be special as mentioned here: > > > > > > > > https://lore.kernel.org/all/CAPcyv4iFeVDVPn6uc=aksyuvkiu3-fk-n16ijvzq3n8ot00...@mail.gmail.com/ > > > > > > I added a remark there > > > > > > Not special means more to me, it means devmap should do the refcounts > > > properly like normal memory pages. > > > > > > It means vm_normal_page should return !NULL and it means insert_page, > > > not insert_pfn should be used to install them in the PTE. VMAs should > > > not be MIXED MAP, but normal struct page maps. > > > > > > I think this change alone would fix all the refcount problems > > > everwhere in DAX and devmap. > > > > > > > The refcount dependencies also go away after this... > > > > > > > > https://lore.kernel.org/all/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com/ > > > > > > > > ...but you can see that patches 1 and 2 in that series depend on being > > > > able to guarantee that all mappings are invalidated when the undelying > > > > device that owns the pgmap goes away. > > > > > > If I have put everything together right this is because of what I > > > pointed to here. FS-DAX is installing 0 refcount pages into PTEs and > > > expecting that to work sanely. > > > > > > This means the page map cannot be removed until all the PTEs are fully > > > flushed, which buggily doesn't happen because of the missing unplug. > > > > > > However, this is all because nobody incrd a refcount to represent the > > > reference in the PTE and since this ment that 0 refcount pages were > > > wrongly stuffed into PTEs then devmap used the refcount == 1 hack to > > > unbreak GUP? > > > > > > So.. Is there some reason why devmap pages are trying so hard to avoid > > > sane refcounting??? > > > > I wouldn't put it that way. It's more that the original sin of > > ZONE_DEVICE that sought to reuse the lru field space, by never having > > a zero recount, then got layered upon and calcified in malignant ways. > > In the meantime surrounding infrastructure got decrustified. Work like > > the 'struct page' cleanup among other things, made it clearer and > > clearer over time that the original design choice needed to be fixed. > > So, there used to be some reason, but with the current code > arrangement it is not the case? This is why it looks so strange when > reading it.. > > AFIACT we are good on the LRU stuff now? Eg release_pages() does not > use page->lru for is_zone_device_page()? Yes, the lru collision was fixed by the 'struct page' cleanup. > > > The MIXED_MAP and insert_pfn were a holdover from page-less DAX, but > > now that we have page-available DAX, yes, we can skip the FS > > notification and just rely on typical refcounting and hanging until > > the FS has a chance to uninstall the PTEs. You're right, the FS > > notification is an improvement to the conversion, not a requirement. > > It all sounds so simple. I looked at this for a good long time and the > first major roadblock is huge pages. > > The mm side is designed around THP which puts a single high order page > into the PUD/PMD such that the mm only has to juggle one page. This a > very sane and reasonable thing to do. > > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with > THP would make using normal refconting much simpler. I looked at > teaching the mm core to deal with page arrays - it is certainly > doable, but it is quite inefficient and ugly mm code. THP does not support PUD, and neither does FSDAX, so it's only PMDs we need to worry about. > > So, can we fix DAX and TTM - the only uses of PUD/PMDs I could find? > > Joao has a series that does this to device-dax: > > https://lore.kernel.org/all/20210827145819.16471-1-joao.m.mart...@oracle.com/ That assumes there's never any need to fracture a huge page which FSDAX could not support unless the filesystem was built with 2MB block size. > TTM is kind of broken already but does have a struct page, and it is > probably already a high order one. Maybe it is OK? I will ask Thomas > > That leaves FSDAX. Can this be fixed? I know nothing of filesystems or > fsdax to guess. Sounds like folios to me .. My thought here is to assemble a compound page on the fly when establishing the FSDAX PMD mapping. > Assuming changing FSDAX is hard.. How would DAX people feel about just > deleting the PUD/PMD support until it can be done with compound pages? There are end users that would notice the PMD regression, and I think FSDAX PMDs with proper compound page metadata is on the same order of work as fixing the refcount. > Doing so would allow fixing the lifecycle, cleaning up gup and > basically delete a huge wack of
Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount
On Sat, Oct 16, 2021 at 9:39 AM Matthew Wilcox wrote: > > On Sat, Oct 16, 2021 at 12:44:50PM -0300, Jason Gunthorpe wrote: > > Assuming changing FSDAX is hard.. How would DAX people feel about just > > deleting the PUD/PMD support until it can be done with compound pages? > > I think there are customers who would find that an unacceptable answer :-) No, not given the number of end users that ask for help debugging PMD support.
Re: [PATCH] drm: panel-orientation-quirks: Add quirk for GPD Win3
Hi Mario,
Before we can apply this you need to:
- Add a description of the patch
- Add you s-o-b - see SubmittingPatches in Documentation/
Sam
On Fri, Sep 17, 2021 at 04:57:19PM +0200, Mario wrote:
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index f6bdec7fa925..f6177c1d9872 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -185,6 +185,12 @@ static const struct dmi_system_id orientation_data[] = {
> DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
> },
> .driver_data = (void *)_win2,
> + }, {/* GPD Win 3 */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1618-03")
> + },
> + .driver_data = (void *)_rightside_up,
> }, {/* I.T.Works TW891 */
> .matches = {
> DMI_EXACT_MATCH(DMI_SYS_VENDOR, "To be filled by O.E.M."),
> --
> 2.33.0
Re: [PATCH] drm: mxsfb: Fix NULL pointer dereference crash on unload
Hi Marek,
On Wed, Sep 08, 2021 at 08:24:20PM +0200, Daniel Vetter wrote:
> On Tue, Sep 07, 2021 at 04:49:00AM +0200, Marek Vasut wrote:
> > The mxsfb->crtc.funcs may already be NULL when unloading the driver,
> > in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from
> > mxsfb_unload() leads to NULL pointer dereference.
> >
> > Since all we care about is masking the IRQ and mxsfb->base is still
> > valid, just use that to clear and mask the IRQ.
> >
> > Fixes: ae1ed00932819 ("drm: mxsfb: Stop using DRM simple display pipeline
> > helper")
> > Signed-off-by: Marek Vasut
> > Cc: Daniel Abrecht
> > Cc: Emil Velikov
> > Cc: Laurent Pinchart
> > Cc: Sam Ravnborg
> > Cc: Stefan Agner
>
> You probably want a drm_atomic_helper_shutdown instead of trying to do all
> that manually. We've also added a bunch more devm and drmm_ functions to
> automate the cleanup a lot more here, e.g. your drm_mode_config_cleanup is
> in the wrong place.
I have applied v2 of this patch today - but failed to see any response
in v2 to this comment from Daniel. Was it lost somehow?
Sam
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
Hi Marek,
On Sun, Oct 17, 2021 at 07:29:51PM +0200, Marek Vasut wrote:
> On 10/17/21 6:49 PM, Sam Ravnborg wrote:
>
> [...]
>
> > > + /*
> > > + * Encoder might sample data on different clock edge than the display,
> > > + * for example OnSemi FIN3385 has a dedicated strapping pin to select
> > > + * the sampling edge.
> > > + */
> > > + if (lvds_codec->connector_type == DRM_MODE_CONNECTOR_LVDS &&
> > > + !of_property_read_u32(dev->of_node, "pclk-sample", )) {
> > > + lvds_codec->timings.input_bus_flags = val ?
> > > + DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE :
> > > + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE;
> > > + }
> > > +
> > > /*
> > >* The panel_bridge bridge is attached to the panel's of_node,
> > >* but we need a bridge attached to our of_node for our user
> > >* to look up.
> > >*/
> > > lvds_codec->bridge.of_node = dev->of_node;
> > > + lvds_codec->bridge.timings = _codec->timings;
> > I do not understand how this will work. The only field that is set is
> > timings.input_bus_flags
> > but any user will see bridge.timings is set and will think this is all
> > timing info.
> >
> > Maybe I just misses something obvious?
>
> Is there anything else in those timings that should be set ? See
> include/drm/drm_bridge.h around line 640
>
> setup_time_ps/hold_time_ps/dual_link isn't supported by this driver, so it
> is 0 or false anyway, i.e. no change.
Just me being confused with display_timings. Patch looks good.
Reviewed-by: Sam Ravnborg
Ping me in a few days to apply it if there is no more feedback.
Sam
Re: [PATCH v2 0/2] Add Sony Tulip Truly NT35521 panel support
Hi Shawn, On Mon, Aug 09, 2021 at 01:10:06PM +0800, Shawn Guo wrote: > It adds driver for Sony Tulip Truly NT35521 5.24" 1280x720 DSI panel, > which can be found on Sony Xperia M4 Aqua phone. > > Changes for v2: > - Add `port` node into bindings. > - Re-create the driver using linux-mdss-dsi-panel-driver-generator[1]. > - Rename the driver to include Sony Tulip. > - Model 5V control GPIOs with regulators. > - Rename Backlight GPIO as "backlight-gpios". > > [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator > > Shawn Guo (2): > dt-bindings: display: Add Sony Tulip Truly NT35521 panel support > drm/panel: Add Sony Tulip Truly NT35521 driver I finally got around to process drm patches again. I have applied the driver to drm-misc-next and it will show up in -next in 1 to 2 weeks. Sorry for the long delay! Sam
Re: [PATCH v2] drm/panel/tianma-tl057fvxp01: add panel for Motorola Moto G6
Hi Julian,
On Sun, Aug 08, 2021 at 04:08:54PM -0400, Julian Braha wrote:
> This is a 5.7" 2160x1080 panel found on the Motorola Moto G6.
> There may be other smartphones using it, as well.
>
> Signed-off-by: Julian Braha
Sorry for coming back so late. Driver looks good and is almost
ready to apply. One detail you need to fix, see below.
Sam
> ---
> +
> +static const struct of_device_id tianma_tl057fvxp01_of_match[] = {
> + { .compatible = "tianma,tl057fvxp01" },
> + { /* sentinel */ }
> +};
The compatible needs to be documented before I can include the driver in
the kernel. Please add a patch that document the compatible - maybe as a
new binding file but preferably as part of one of the existing binding
files.
Sam
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
On 10/17/21 6:49 PM, Sam Ravnborg wrote:
[...]
+ /*
+* Encoder might sample data on different clock edge than the display,
+* for example OnSemi FIN3385 has a dedicated strapping pin to select
+* the sampling edge.
+*/
+ if (lvds_codec->connector_type == DRM_MODE_CONNECTOR_LVDS &&
+ !of_property_read_u32(dev->of_node, "pclk-sample", )) {
+ lvds_codec->timings.input_bus_flags = val ?
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE :
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE;
+ }
+
/*
* The panel_bridge bridge is attached to the panel's of_node,
* but we need a bridge attached to our of_node for our user
* to look up.
*/
lvds_codec->bridge.of_node = dev->of_node;
+ lvds_codec->bridge.timings = _codec->timings;
I do not understand how this will work. The only field that is set is
timings.input_bus_flags
but any user will see bridge.timings is set and will think this is all
timing info.
Maybe I just misses something obvious?
Is there anything else in those timings that should be set ? See
include/drm/drm_bridge.h around line 640
setup_time_ps/hold_time_ps/dual_link isn't supported by this driver, so
it is 0 or false anyway, i.e. no change.
Re: [PATCH] drm/panel:Adjust sync values for Feixin K101-IM2BYL02 panel
Hi Dan,
On Wed, Aug 18, 2021 at 11:48:18PM +0200, Dan Johansen wrote:
> This adjusts sync values according to the datasheet
>
> Fixes:1c243751c095bb95e2795f076ea7a0bcdd60a93a ("drm/panel:
> ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel")
> Co-developed-by: Marius Gripsgard
> Signed-off-by: Dan Johansen
Sorry for not picking this up sooner - I have been away for a while.
The patch is now applied to drm-misc-fixes and will show up in the
upstream kernel in 1-2 week from now.
I updated the subject and the fixes tag while applying.
The Co-developed-by: is supposed to be paired with a Signed-off-by:
by the same person. Something to do right next time.
Sam
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> index 0145129d7c66..534dd7414d42 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> @@ -590,14 +590,14 @@ static const struct drm_display_mode
> k101_im2byl02_default_mode = {
> .clock = 69700,
>
> .hdisplay = 800,
> - .hsync_start= 800 + 6,
> - .hsync_end = 800 + 6 + 15,
> - .htotal = 800 + 6 + 15 + 16,
> + .hsync_start= 800 + 52,
> + .hsync_end = 800 + 52 + 8,
> + .htotal = 800 + 52 + 8 + 48,
>
> .vdisplay = 1280,
> - .vsync_start= 1280 + 8,
> - .vsync_end = 1280 + 8 + 48,
> - .vtotal = 1280 + 8 + 48 + 52,
> + .vsync_start= 1280 + 16,
> + .vsync_end = 1280 + 16 + 6,
> + .vtotal = 1280 + 16 + 6 + 15,
>
> .width_mm = 135,
> .height_mm = 217,
> --
> 2.32.0
Re: [PATCH 1/2] drm/panel: Add BOE BF060Y8M-AJ0 5.99" AMOLED panel driver
Hi AngeloGioacchino, On Wed, Sep 01, 2021 at 07:31:14PM +0200, AngeloGioacchino Del Regno wrote: > This adds support for the BOE BF060Y8M-AJ0 5.99" AMOLED module > that can be found in some F(x)Tec Pro1 and Elephone U1 devices. > > Signed-off-by: AngeloGioacchino Del Regno > Applied the bindings patch and this patch to drm-misc-next. They will show up in -next in 1-2 weeks. Sam
Re: [PATCH 1/2] drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels
Hi AngeloGioacchino, On Wed, Sep 01, 2021 at 07:31:26PM +0200, AngeloGioacchino Del Regno wrote: > Add a driver for panels using the Novatek NT35950 Display Driver IC, > including support for the Sharp LS055D1SX04, found in some Sony Xperia > Z5 Premium and XZ Premium smartphones. > > Signed-off-by: AngeloGioacchino Del Regno > Driver looks good and I have applied it to drm-misc-next. As we cannot apply a driver without the bindings, the bindings patch was applied first. I also added the r-b from Marijn on the driver. The patches will show up in -next in 1-2 weeks from now. Sam
[PATCH 3/3] arm64: dts: rockchip: enable gamma control on RK3399
Define the memory region on RK3399 VOPs containing the gamma LUT at
base+0x2000.
Signed-off-by: Hugh Cole-Baker
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 3871c7fd83b0..9cbf6ccdd256 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1619,7 +1619,7 @@ i2s2: i2s@ff8a {
vopl: vop@ff8f {
compatible = "rockchip,rk3399-vop-lit";
- reg = <0x0 0xff8f 0x0 0x3efc>;
+ reg = <0x0 0xff8f 0x0 0x2000>, <0x0 0xff8f2000 0x0 0x400>;
interrupts = ;
assigned-clocks = < ACLK_VOP1>, < HCLK_VOP1>;
assigned-clock-rates = <4>, <1>;
@@ -1676,7 +1676,7 @@ vopl_mmu: iommu@ff8f3f00 {
vopb: vop@ff90 {
compatible = "rockchip,rk3399-vop-big";
- reg = <0x0 0xff90 0x0 0x3efc>;
+ reg = <0x0 0xff90 0x0 0x2000>, <0x0 0xff902000 0x0 0x1000>;
interrupts = ;
assigned-clocks = < ACLK_VOP0>, < HCLK_VOP0>;
assigned-clock-rates = <4>, <1>;
--
2.24.3 (Apple Git-128)
[PATCH 0/3] drm/rockchip: support gamma control on RK3399
This extends the Rockchip VOP driver to support setting the gamma LUT on the RK3399 SoC. Previously, the driver supported gamma control for the RK3288 only. On the RK3399 the method for updating the LUT is slightly different. This implementation was based on the code and description from the vendor kernel [1]. The RK3399 also has the address resources for the VOP general registers and the gamma LUT located adjacent to each other, not on either side of the IOMMU address as on the RK3288, but for simplicity this series follows the existing DT binding which requires the gamma LUT as a second address resource. This should enable gamma control and "night mode" on all RK3399-based devices such as the Pinebook Pro, it has been tested using the "redshift" app and GNOME's "Night Light" feature on a RockPro64 SBC. The changes should not affect RK3288 gamma support using the existing code path, testing on RK3288 would be welcome. [1]: https://github.com/rockchip-linux/kernel/commit/4a361fa5d433dabe64b0fae49b49c0fcd16982fa Hugh Cole-Baker (3): drm/rockchip: define gamma registers for RK3399 drm/rockchip: support gamma control on RK3399 arm64: dts: rockchip: enable gamma control on RK3399 arch/arm64/boot/dts/rockchip/rk3399.dtsi| 4 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 89 +++-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 24 +- drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 + 5 files changed, 90 insertions(+), 30 deletions(-) -- 2.24.3 (Apple Git-128)
[PATCH 1/3] drm/rockchip: define gamma registers for RK3399
The VOP on RK3399 has a different approach from previous versions for
setting a gamma lookup table, using an update_gamma_lut register. As
this differs from RK3288, give RK3399 its own set of "common" register
definitions.
Signed-off-by: Hugh Cole-Baker
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 24 +++--
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 +
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 857d97cdc67c..14179e89bd21 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -99,6 +99,8 @@ struct vop_common {
struct vop_reg dither_down_en;
struct vop_reg dither_up;
struct vop_reg dsp_lut_en;
+ struct vop_reg update_gamma_lut;
+ struct vop_reg lut_buffer_index;
struct vop_reg gate_en;
struct vop_reg mmu_en;
struct vop_reg out_mode;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 1f7353f0684a..16b70c2d87d2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -865,6 +865,24 @@ static const struct vop_output rk3399_output = {
.mipi_dual_channel_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 3),
};
+static const struct vop_common rk3399_common = {
+ .standby = VOP_REG_SYNC(RK3399_SYS_CTRL, 0x1, 22),
+ .gate_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 23),
+ .mmu_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 20),
+ .dither_down_sel = VOP_REG(RK3399_DSP_CTRL1, 0x1, 4),
+ .dither_down_mode = VOP_REG(RK3399_DSP_CTRL1, 0x1, 3),
+ .dither_down_en = VOP_REG(RK3399_DSP_CTRL1, 0x1, 2),
+ .pre_dither_down = VOP_REG(RK3399_DSP_CTRL1, 0x1, 1),
+ .dither_up = VOP_REG(RK3399_DSP_CTRL1, 0x1, 6),
+ .dsp_lut_en = VOP_REG(RK3399_DSP_CTRL1, 0x1, 0),
+ .update_gamma_lut = VOP_REG(RK3399_DSP_CTRL1, 0x1, 7),
+ .lut_buffer_index = VOP_REG(RK3399_DBG_POST_REG1, 0x1, 1),
+ .data_blank = VOP_REG(RK3399_DSP_CTRL0, 0x1, 19),
+ .dsp_blank = VOP_REG(RK3399_DSP_CTRL0, 0x3, 18),
+ .out_mode = VOP_REG(RK3399_DSP_CTRL0, 0xf, 0),
+ .cfg_done = VOP_REG_SYNC(RK3399_REG_CFG_DONE, 0x1, 0),
+};
+
static const struct vop_yuv2yuv_phy rk3399_yuv2yuv_win01_data = {
.y2r_coefficients = {
VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 0, 0x, 0),
@@ -944,7 +962,7 @@ static const struct vop_data rk3399_vop_big = {
.version = VOP_VERSION(3, 5),
.feature = VOP_FEATURE_OUTPUT_RGB10,
.intr = _vop_intr,
- .common = _common,
+ .common = _common,
.modeset = _modeset,
.output = _output,
.afbc = _vop_afbc,
@@ -952,6 +970,7 @@ static const struct vop_data rk3399_vop_big = {
.win = rk3399_vop_win_data,
.win_size = ARRAY_SIZE(rk3399_vop_win_data),
.win_yuv2yuv = rk3399_vop_big_win_yuv2yuv_data,
+ .lut_size = 1024,
};
static const struct vop_win_data rk3399_vop_lit_win_data[] = {
@@ -970,13 +989,14 @@ static const struct vop_win_yuv2yuv_data
rk3399_vop_lit_win_yuv2yuv_data[] = {
static const struct vop_data rk3399_vop_lit = {
.version = VOP_VERSION(3, 6),
.intr = _vop_intr,
- .common = _common,
+ .common = _common,
.modeset = _modeset,
.output = _output,
.misc = _misc,
.win = rk3399_vop_lit_win_data,
.win_size = ARRAY_SIZE(rk3399_vop_lit_win_data),
.win_yuv2yuv = rk3399_vop_lit_win_yuv2yuv_data,
+ .lut_size = 256,
};
static const struct vop_win_data rk3228_vop_win_data[] = {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 0b3cd65ba5c1..406e981c75bd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -628,6 +628,7 @@
#define RK3399_YUV2YUV_WIN 0x02c0
#define RK3399_YUV2YUV_POST0x02c4
#define RK3399_AUTO_GATING_EN 0x02cc
+#define RK3399_DBG_POST_REG1 0x036c
#define RK3399_WIN0_CSC_COE0x03a0
#define RK3399_WIN1_CSC_COE0x03c0
#define RK3399_WIN2_CSC_COE0x03e0
--
2.24.3 (Apple Git-128)
[PATCH 2/3] drm/rockchip: support gamma control on RK3399
The RK3399 has a 1024-entry gamma LUT with 10 bits per component on its
"big" VOP and a 256-entry, 8 bit per component LUT on the "little" VOP.
Compared to the RK3288, it no longer requires disabling gamma while
updating the LUT. On the RK3399, the LUT can be updated at any time as
the hardware has two LUT buffers, one can be written while the other is
in use. A swap of the buffers is triggered by writing 1 to the
update_gamma_lut register.
Signed-off-by: Hugh Cole-Baker
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 89 +++--
1 file changed, 63 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ba9e14da41b4..937ad82abe69 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -66,6 +67,9 @@
#define VOP_REG_SET(vop, group, name, v) \
vop_reg_set(vop, >data->group->name, 0, ~0, v, #name)
+#define VOP_HAS_REG(vop, group, name) \
+ (!!(vop->data->group->name.mask))
+
#define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0, mask = 0; \
@@ -1204,17 +1208,22 @@ static bool vop_dsp_lut_is_enabled(struct vop *vop)
return vop_read_reg(vop, 0, >data->common->dsp_lut_en);
}
+static u32 vop_lut_buffer_index(struct vop *vop)
+{
+ return vop_read_reg(vop, 0, >data->common->lut_buffer_index);
+}
+
static void vop_crtc_write_gamma_lut(struct vop *vop, struct drm_crtc *crtc)
{
struct drm_color_lut *lut = crtc->state->gamma_lut->data;
- unsigned int i;
+ unsigned int i, bpc = ilog2(vop->data->lut_size);
for (i = 0; i < crtc->gamma_size; i++) {
u32 word;
- word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
- (drm_color_lut_extract(lut[i].green, 10) << 10) |
- drm_color_lut_extract(lut[i].blue, 10);
+ word = (drm_color_lut_extract(lut[i].red, bpc) << (2 * bpc)) |
+ (drm_color_lut_extract(lut[i].green, bpc) << bpc) |
+ drm_color_lut_extract(lut[i].blue, bpc);
writel(word, vop->lut_regs + i * 4);
}
}
@@ -1224,38 +1233,66 @@ static void vop_crtc_gamma_set(struct vop *vop, struct
drm_crtc *crtc,
{
struct drm_crtc_state *state = crtc->state;
unsigned int idle;
+ u32 lut_idx, old_idx;
int ret;
if (!vop->lut_regs)
return;
- /*
-* To disable gamma (gamma_lut is null) or to write
-* an update to the LUT, clear dsp_lut_en.
-*/
- spin_lock(>reg_lock);
- VOP_REG_SET(vop, common, dsp_lut_en, 0);
- vop_cfg_done(vop);
- spin_unlock(>reg_lock);
- /*
-* In order to write the LUT to the internal memory,
-* we need to first make sure the dsp_lut_en bit is cleared.
-*/
- ret = readx_poll_timeout(vop_dsp_lut_is_enabled, vop,
-idle, !idle, 5, 30 * 1000);
- if (ret) {
- DRM_DEV_ERROR(vop->dev, "display LUT RAM enable timeout!\n");
- return;
- }
+ if (!state->gamma_lut || !VOP_HAS_REG(vop, common, update_gamma_lut)) {
+ /*
+* To disable gamma (gamma_lut is null) or to write
+* an update to the LUT, clear dsp_lut_en.
+*/
+ spin_lock(>reg_lock);
+ VOP_REG_SET(vop, common, dsp_lut_en, 0);
+ vop_cfg_done(vop);
+ spin_unlock(>reg_lock);
- if (!state->gamma_lut)
- return;
+ /*
+* In order to write the LUT to the internal memory,
+* we need to first make sure the dsp_lut_en bit is cleared.
+*/
+ ret = readx_poll_timeout(vop_dsp_lut_is_enabled, vop,
+idle, !idle, 5, 30 * 1000);
+ if (ret) {
+ DRM_DEV_ERROR(vop->dev, "display LUT RAM enable
timeout!\n");
+ return;
+ }
+
+ if (!state->gamma_lut)
+ return;
+ } else {
+ /*
+* On RK3399 the gamma LUT can updated without clearing
dsp_lut_en,
+* by setting update_gamma_lut then waiting for
lut_buffer_index change
+*/
+ old_idx = vop_lut_buffer_index(vop);
+ }
spin_lock(>reg_lock);
vop_crtc_write_gamma_lut(vop, crtc);
VOP_REG_SET(vop, common, dsp_lut_en, 1);
+ VOP_REG_SET(vop, common, update_gamma_lut, 1);
vop_cfg_done(vop);
spin_unlock(>reg_lock);
+
+ if (VOP_HAS_REG(vop, common, update_gamma_lut)) {
+ ret =
Re: [PATCH] drm/bridge: ti-sn65dsi83: Optimize reset line toggling
Hi Marek, On Sat, Oct 16, 2021 at 11:04:02PM +0200, Marek Vasut wrote: > Current code always sets reset line low in .pre_enable callback and > holds it low for 10ms. This is sub-optimal and increases the time > between enablement of the DSI83 and valid LVDS clock. > > Rework the reset handling such that the reset line is held low for 10ms > both in probe() of the driver and .disable callback, which guarantees > that the reset line was always held low for more than 10ms and therefore > the reset line timing requirement is satisfied. Furthermore, move the > reset handling into .enable callback so the entire DSI83 initialization > is now in one place. > > This reduces DSI83 enablement delay by up to 10ms. > > Signed-off-by: Marek Vasut > Cc: Laurent Pinchart > Cc: Linus Walleij > Cc: Robert Foss > Cc: Sam Ravnborg > Cc: dri-devel@lists.freedesktop.org Applied to drm-misc-next, Sam
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for pixel data sampling edge select
Hi Marek,
On Sun, Oct 17, 2021 at 02:12:04AM +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pclk-sample", not
> the same as the one used by display timings but rather the same as used by
> media, and configure bus flags based on this DT property.
Late to the party here - sorry.
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
> V2: - Limit the pixelclk-active to encoders only
> - Update DT binding document
> V3: - Determine whether this is encoder from connector, i.e.
> lvds_codec->connector_type == DRM_MODE_CONNECTOR_LVDS
> V4: - Switch to pclk-sample. Note that the value of this is inverted,
> so all the existing users of pixelclk-active using previous
> previous version of this patch must be reworked
> V5: Rebase on recent linux-next
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> b/drivers/gpu/drm/bridge/lvds-codec.c
> index f991842a161f..702ea803a743 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -21,6 +21,7 @@ struct lvds_codec {
> struct device *dev;
> struct drm_bridge bridge;
> struct drm_bridge *panel_bridge;
> + struct drm_bridge_timings timings;
> struct regulator *vcc;
> struct gpio_desc *powerdown_gpio;
> u32 connector_type;
> @@ -119,6 +120,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> struct device_node *bus_node;
> struct drm_panel *panel;
> struct lvds_codec *lvds_codec;
> + u32 val;
> int ret;
>
> lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> @@ -187,12 +189,25 @@ static int lvds_codec_probe(struct platform_device
> *pdev)
> }
> }
>
> + /*
> + * Encoder might sample data on different clock edge than the display,
> + * for example OnSemi FIN3385 has a dedicated strapping pin to select
> + * the sampling edge.
> + */
> + if (lvds_codec->connector_type == DRM_MODE_CONNECTOR_LVDS &&
> + !of_property_read_u32(dev->of_node, "pclk-sample", )) {
> + lvds_codec->timings.input_bus_flags = val ?
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE :
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE;
> + }
> +
> /*
>* The panel_bridge bridge is attached to the panel's of_node,
>* but we need a bridge attached to our of_node for our user
>* to look up.
>*/
> lvds_codec->bridge.of_node = dev->of_node;
> + lvds_codec->bridge.timings = _codec->timings;
I do not understand how this will work. The only field that is set is
timings.input_bus_flags
but any user will see bridge.timings is set and will think this is all
timing info.
Maybe I just misses something obvious?
Sam
> drm_bridge_add(_codec->bridge);
>
> platform_set_drvdata(pdev, lvds_codec);
> --
> 2.33.0
Re: [Freedreno] [PATCH] drm/msm/dp: Move debugfs files into subdirectory
On Fri 15 Oct 16:53 PDT 2021, abhin...@codeaurora.org wrote:
> On 2021-10-15 16:17, Bjorn Andersson wrote:
> > In the cleanup path of the MSM DP driver the DP driver's debugfs files
> > are destroyed by invoking debugfs_remove_recursive() on debug->root,
> > which during initialization has been set to minor->debugfs_root.
> >
> > To allow cleaning up the DP driver's debugfs files either each dentry
> > needs to be kept track of or the files needs to be put in a subdirectory
> > which can be removed in one go.
> >
> > By choosing to put the debugfs files in a subdirectory, based on the
> > name of the associated connector this also solves the problem that these
> > names would collide as support for multiple DP instances are introduced.
> >
> > One alternative solution to the problem with colliding file names would
> > have been to put keep track of the individual files and put them under
> > the connector's debugfs directory. But while the drm_connector has been
> > allocated, its associated debugfs directory has not been created at the
> > time of initialization of the dp_debug.
> >
> > Signed-off-by: Bjorn Andersson
>
> I have been thinking about this problem ever since multi-DP has been posted
> :)
> Creating sub-directories seems right but at the moment it looks like IGT
> which
> uses these debugfs nodes doesnt check sub-directories:
>
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tools/msm_dp_compliance.c#L215
>
> It looks for the DP debugfs nodes under /sys/kernel/debug/dri/*/
>
> We have to fix IGT too to be able to handle multi-DP cases. I will try to
> come up
> with a proposal to address this.
>
> Till then, can we go with the other solution to keep track of the dentries?
>
I'm afraid I don't see what you're proposing.
Afaict we need one set of dp_test{type,active,data} per DP controller,
so even doing this by keeping track of the dentries requires that we
rename the files based on some identifier (id or connector name) - which
will cause igt to break.
As such, I think the practical path forward is that we merge the
multi-DP series as currently proposed. This will not cause any issues on
single-DP systems, but on multi-DP systems we will have warnings about
duplicate debugfs entries in the kernel logs.
Then you can figure out how to rework igt to deal with the multiple DP
instances and update the dp_debug interface accordingly.
Which also implies that we should hold this patch back. But if we go
that path, I think we should fix dp_debug_deinit() so that it doesn't
remove /sys/kernel/debug/dri/128 when the DP driver is unloaded.
Regards,
Bjorn
> > ---
> >
> > This depends on
> > https://lore.kernel.org/linux-arm-msm/20211010030435.4000642-1-bjorn.anders...@linaro.org/
> > reducing the connector from a double pointer.
> >
> > drivers/gpu/drm/msm/dp/dp_debug.c | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
> > b/drivers/gpu/drm/msm/dp/dp_debug.c
> > index da4323556ef3..67da4c69eca1 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_debug.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_debug.c
> > @@ -210,26 +210,29 @@ static const struct file_operations
> > test_active_fops = {
> > static int dp_debug_init(struct dp_debug *dp_debug, struct drm_minor
> > *minor)
> > {
> > int rc = 0;
> > + char path[64];
> > struct dp_debug_private *debug = container_of(dp_debug,
> > struct dp_debug_private, dp_debug);
> >
> > - debugfs_create_file("dp_debug", 0444, minor->debugfs_root,
> > + snprintf(path, sizeof(path), "msm_dp-%s", debug->connector->name);
> > +
> > + debug->root = debugfs_create_dir(path, minor->debugfs_root);
> > +
> > + debugfs_create_file("dp_debug", 0444, debug->root,
> > debug, _debug_fops);
> >
> > debugfs_create_file("msm_dp_test_active", 0444,
> > - minor->debugfs_root,
> > + debug->root,
> > debug, _active_fops);
> >
> > debugfs_create_file("msm_dp_test_data", 0444,
> > - minor->debugfs_root,
> > + debug->root,
> > debug, _test_data_fops);
> >
> > debugfs_create_file("msm_dp_test_type", 0444,
> > - minor->debugfs_root,
> > + debug->root,
> > debug, _test_type_fops);
> >
> > - debug->root = minor->debugfs_root;
> > -
> > return rc;
> > }
Re: [PATCH] drm: mxsfb: Fix NULL pointer dereference crash on unload
Hi Marek,
On Sat, Oct 16, 2021 at 11:04:46PM +0200, Marek Vasut wrote:
> The mxsfb->crtc.funcs may already be NULL when unloading the driver,
> in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from
> mxsfb_unload() leads to NULL pointer dereference.
>
> Since all we care about is masking the IRQ and mxsfb->base is still
> valid, just use that to clear and mask the IRQ.
>
> Fixes: ae1ed00932819 ("drm: mxsfb: Stop using DRM simple display pipeline
> helper")
> Signed-off-by: Marek Vasut
> Cc: Daniel Abrecht
> Cc: Emil Velikov
> Cc: Laurent Pinchart
> Cc: Sam Ravnborg
> Cc: Stefan Agner
Applied to drm-misc-fixes.
Sam
Re: [PATCH v5 7/7] drm/msm/dp: Add sc8180x DP controllers
On Sat 16 Oct 20:32 CDT 2021, Stephen Boyd wrote: > Quoting Bjorn Andersson (2021-10-16 15:18:43) > > The sc8180x has 2 DP and 1 eDP controllers, add support for these to the > > DP driver. > > > > Link: > > https://lore.kernel.org/linux-arm-msm/20210725042436.3967173-7-bjorn.anders...@linaro.org/ > > BTW, was the link intentional? No, I didn't intend for this Link to go upstream, just forgot to clean it out as I was sending out the patches. @Rob, @Dmitry, can you drop this as you apply the patch, or would you prefer a resend? Thanks, Bjorn
Re: (subset) [PATCH] ARM: dts: qcom-apq8064: stop using legacy clock names for HDMI
On Fri, 15 Oct 2021 00:42:21 +0300, Dmitry Baryshkov wrote: > Stop using legacy clock names (with _clk suffix) for HDMI and HDMI PHY > device tree nodes. > > Applied, thanks! [1/1] ARM: dts: qcom-apq8064: stop using legacy clock names for HDMI commit: 03d4e43fc5beded1aa67c12b7c7e6932ae9a40cc Best regards, -- Bjorn Andersson
Re: [PATCH 16/28] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2
Thanks for the notice. Going to take a deeper look into this tomorrow.
Basically looks like we messed up the fence ref count somehow.
Thanks,
Christian.
Am 17.10.21 um 16:40 schrieb Nicolas Frattaroli:
On Dienstag, 5. Oktober 2021 13:37:30 CEST Christian König wrote:
Simplifying the code a bit.
v2: use dma_resv_for_each_fence
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c index 042c16b5d54a..5bc5f775abe1
100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -699,30 +699,16 @@ int drm_sched_job_add_implicit_dependencies(struct
drm_sched_job *job, struct drm_gem_object *obj,
bool write)
{
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
int ret;
- struct dma_fence **fences;
- unsigned int i, fence_count;
-
- if (!write) {
- struct dma_fence *fence = dma_resv_get_excl_unlocked(obj-
resv);
-
- return drm_sched_job_add_dependency(job, fence);
- }
-
- ret = dma_resv_get_fences(obj->resv, NULL, _count, );
- if (ret || !fence_count)
- return ret;
- for (i = 0; i < fence_count; i++) {
- ret = drm_sched_job_add_dependency(job, fences[i]);
+ dma_resv_for_each_fence(, obj->resv, write, fence) {
+ ret = drm_sched_job_add_dependency(job, fence);
if (ret)
- break;
+ return ret;
}
-
- for (; i < fence_count; i++)
- dma_fence_put(fences[i]);
- kfree(fences);
- return ret;
+ return 0;
}
EXPORT_SYMBOL(drm_sched_job_add_implicit_dependencies);
Hi Christian,
unfortunately, this breaks lima on the rk3328 quite badly. Running glmark2-
es2-drm just locks up the device with the following traces:
[ 39.624100] [ cut here ]
[ 39.624555] refcount_t: addition on 0; use-after-free.
[ 39.625058] WARNING: CPU: 0 PID: 123 at lib/refcount.c:25
refcount_warn_saturate+0xa4/0x150
[ 39.625825] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.626753] CPU: 0 PID: 123 Comm: pp Tainted: G C5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.627614] Hardware name: Pine64 Rock64 (DT)
[ 39.628004] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.628628] pc : refcount_warn_saturate+0xa4/0x150
[ 39.629062] lr : refcount_warn_saturate+0xa4/0x150
[ 39.629495] sp : ffc0124d3d90
[ 39.629794] x29: ffc0124d3d90 x28: x27:
[ 39.630441] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.631087] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.631731] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.632377] x17: 0001 x16: 0001 x15:
0765076507720766
[ 39.633022] x14: 072d077207650774 x13: 0765076507720766 x12:
072d077207650774
[ 39.633668] x11: 0720072007200720 x10: ffc011c4b1b0 x9 :
ffc01010ac54
[ 39.634314] x8 : dfff x7 : ffc011cfb1b0 x6 :
0001
[ 39.634960] x5 : ff807fb4d980 x4 : x3 :
0027
[ 39.635605] x2 : x1 : x0 :
ff8000e1f000
[ 39.636250] Call trace:
[ 39.636475] refcount_warn_saturate+0xa4/0x150
[ 39.636879] drm_sched_entity_pop_job+0x414/0x4a0
[ 39.637307] drm_sched_main+0xe4/0x450
[ 39.637651] kthread+0x12c/0x140
[ 39.637949] ret_from_fork+0x10/0x20
[ 39.638279] ---[ end trace 47528e09b2512330 ]---
[ 39.638783] [ cut here ]
[ 39.639214] refcount_t: underflow; use-after-free.
[ 39.639687] WARNING: CPU: 0 PID: 123 at lib/refcount.c:28
refcount_warn_saturate+0xf8/0x150
[ 39.640447] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.641373] CPU: 0 PID: 123 Comm: pp Tainted: GWC5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.642237] Hardware name: Pine64 Rock64 (DT)
[ 39.642632] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.643257] pc : refcount_warn_saturate+0xf8/0x150
[ 39.643693] lr : refcount_warn_saturate+0xf8/0x150
[ 39.644128] sp : ffc0124d3d90
[ 39.644430] x29: ffc0124d3d90 x28: x27:
[ 39.645077] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.645724] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.646372] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.647020] x17: 0001 x16: 0001 x15:
Re: [PATCH 16/28] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2
On Dienstag, 5. Oktober 2021 13:37:30 CEST Christian König wrote:
> Simplifying the code a bit.
>
> v2: use dma_resv_for_each_fence
>
> Signed-off-by: Christian König
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 26 ++
> 1 file changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c index 042c16b5d54a..5bc5f775abe1
> 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -699,30 +699,16 @@ int drm_sched_job_add_implicit_dependencies(struct
> drm_sched_job *job, struct drm_gem_object *obj,
> bool write)
> {
> + struct dma_resv_iter cursor;
> + struct dma_fence *fence;
> int ret;
> - struct dma_fence **fences;
> - unsigned int i, fence_count;
> -
> - if (!write) {
> - struct dma_fence *fence = dma_resv_get_excl_unlocked(obj-
>resv);
> -
> - return drm_sched_job_add_dependency(job, fence);
> - }
> -
> - ret = dma_resv_get_fences(obj->resv, NULL, _count, );
> - if (ret || !fence_count)
> - return ret;
>
> - for (i = 0; i < fence_count; i++) {
> - ret = drm_sched_job_add_dependency(job, fences[i]);
> + dma_resv_for_each_fence(, obj->resv, write, fence) {
> + ret = drm_sched_job_add_dependency(job, fence);
> if (ret)
> - break;
> + return ret;
> }
> -
> - for (; i < fence_count; i++)
> - dma_fence_put(fences[i]);
> - kfree(fences);
> - return ret;
> + return 0;
> }
> EXPORT_SYMBOL(drm_sched_job_add_implicit_dependencies);
Hi Christian,
unfortunately, this breaks lima on the rk3328 quite badly. Running glmark2-
es2-drm just locks up the device with the following traces:
[ 39.624100] [ cut here ]
[ 39.624555] refcount_t: addition on 0; use-after-free.
[ 39.625058] WARNING: CPU: 0 PID: 123 at lib/refcount.c:25
refcount_warn_saturate+0xa4/0x150
[ 39.625825] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.626753] CPU: 0 PID: 123 Comm: pp Tainted: G C5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.627614] Hardware name: Pine64 Rock64 (DT)
[ 39.628004] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.628628] pc : refcount_warn_saturate+0xa4/0x150
[ 39.629062] lr : refcount_warn_saturate+0xa4/0x150
[ 39.629495] sp : ffc0124d3d90
[ 39.629794] x29: ffc0124d3d90 x28: x27:
[ 39.630441] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.631087] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.631731] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.632377] x17: 0001 x16: 0001 x15:
0765076507720766
[ 39.633022] x14: 072d077207650774 x13: 0765076507720766 x12:
072d077207650774
[ 39.633668] x11: 0720072007200720 x10: ffc011c4b1b0 x9 :
ffc01010ac54
[ 39.634314] x8 : dfff x7 : ffc011cfb1b0 x6 :
0001
[ 39.634960] x5 : ff807fb4d980 x4 : x3 :
0027
[ 39.635605] x2 : x1 : x0 :
ff8000e1f000
[ 39.636250] Call trace:
[ 39.636475] refcount_warn_saturate+0xa4/0x150
[ 39.636879] drm_sched_entity_pop_job+0x414/0x4a0
[ 39.637307] drm_sched_main+0xe4/0x450
[ 39.637651] kthread+0x12c/0x140
[ 39.637949] ret_from_fork+0x10/0x20
[ 39.638279] ---[ end trace 47528e09b2512330 ]---
[ 39.638783] [ cut here ]
[ 39.639214] refcount_t: underflow; use-after-free.
[ 39.639687] WARNING: CPU: 0 PID: 123 at lib/refcount.c:28
refcount_warn_saturate+0xf8/0x150
[ 39.640447] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.641373] CPU: 0 PID: 123 Comm: pp Tainted: GWC5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.642237] Hardware name: Pine64 Rock64 (DT)
[ 39.642632] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.643257] pc : refcount_warn_saturate+0xf8/0x150
[ 39.643693] lr : refcount_warn_saturate+0xf8/0x150
[ 39.644128] sp : ffc0124d3d90
[ 39.644430] x29: ffc0124d3d90 x28: x27:
[ 39.645077] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.645724] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.646372] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.647020] x17: 0001 x16: 0001 x15:
072007200720072e
[ 39.647666] x14: 0765076507720766 x13: 072007200720072e x12:
0765076507720766
[ 39.648312] x11: 0720072007200720 x10:
Re: [PATCH RFC] virtio: wrap config->reset calls
On Wed, Oct 13, 2021 at 06:55:31AM -0400, Michael S. Tsirkin wrote: > This will enable cleanups down the road. > The idea is to disable cbs, then add "flush_queued_cbs" callback > as a parameter, this way drivers can flush any work > queued after callbacks have been disabled. > > Signed-off-by: Michael S. Tsirkin Acked-by: Wolfram Sang # for I2C changes signature.asc Description: PGP signature
Patch "drm/fbdev: Clamp fbdev surface size if too large" has been added to the 5.14-stable tree
This is a note to let you know that I've just added the patch titled
drm/fbdev: Clamp fbdev surface size if too large
to the 5.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fbdev-clamp-fbdev-surface-size-if-too-large.patch
and it can be found in the queue-5.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From b693e42921e0220c0d564c55c6cdc680b0f85390 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 5 Oct 2021 09:03:55 +0200
Subject: drm/fbdev: Clamp fbdev surface size if too large
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit b693e42921e0220c0d564c55c6cdc680b0f85390 upstream.
Clamp the fbdev surface size of the available maximumi height to avoid
failing to init console emulation. An example error is shown below.
bad framebuffer height 2304, should be >= 768 && <= 768
[drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup
generic emulation (ret=-22)
This is especially a problem with drivers that have very small screen
sizes and cannot over-allocate at all.
v2:
* reduce warning level (Ville)
Signed-off-by: Thomas Zimmermann
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Reviewed-by: Ville Syrjälä
Reviewed-by: Alex Deucher
Reported-by: Amanoel Dawod
Reported-by: Zoltán Kővágó
Reported-by: Michael Stapelberg
Cc: Daniel Vetter
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.14+
Link:
https://patchwork.freedesktop.org/patch/msgid/20211005070355.7680-1-tzimmerm...@suse.de
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_fb_helper.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1506,6 +1506,7 @@ static int drm_fb_helper_single_fb_probe
{
struct drm_client_dev *client = _helper->client;
struct drm_device *dev = fb_helper->dev;
+ struct drm_mode_config *config = >mode_config;
int ret = 0;
int crtc_count = 0;
struct drm_connector_list_iter conn_iter;
@@ -1663,6 +1664,11 @@ static int drm_fb_helper_single_fb_probe
/* Handle our overallocation */
sizes.surface_height *= drm_fbdev_overalloc;
sizes.surface_height /= 100;
+ if (sizes.surface_height > config->max_height) {
+ drm_dbg_kms(dev, "Fbdev over-allocation too large; clamping
height to %d\n",
+ config->max_height);
+ sizes.surface_height = config->max_height;
+ }
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, );
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.14/drm-fbdev-clamp-fbdev-surface-size-if-too-large.patch
Re: [PATCH v13 20/35] mtd: rawnand: tegra: Add runtime PM and OPP support
01.10.2021 18:01, Ulf Hansson пишет:
> On Fri, 1 Oct 2021 at 16:35, Dmitry Osipenko wrote:
>>
>> 01.10.2021 17:24, Ulf Hansson пишет:
>>> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
The NAND on Tegra belongs to the core power domain and we're going to
enable GENPD support for the core domain. Now NAND must be resumed using
runtime PM API in order to initialize the NAND power state. Add runtime PM
and OPP support to the NAND driver.
Acked-by: Miquel Raynal
Signed-off-by: Dmitry Osipenko
---
drivers/mtd/nand/raw/tegra_nand.c | 55 ++-
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/raw/tegra_nand.c
b/drivers/mtd/nand/raw/tegra_nand.c
index 32431bbe69b8..098fcc9cb9df 100644
--- a/drivers/mtd/nand/raw/tegra_nand.c
+++ b/drivers/mtd/nand/raw/tegra_nand.c
@@ -17,8 +17,11 @@
#include
#include
#include
+#include
#include
+#include
+
#define COMMAND0x00
#define COMMAND_GO BIT(31)
#define COMMAND_CLE BIT(30)
@@ -1151,6 +1154,7 @@ static int tegra_nand_probe(struct platform_device
*pdev)
return -ENOMEM;
ctrl->dev = >dev;
+ platform_set_drvdata(pdev, ctrl);
nand_controller_init(>controller);
ctrl->controller.ops = _nand_controller_ops;
@@ -1166,14 +1170,22 @@ static int tegra_nand_probe(struct platform_device
*pdev)
if (IS_ERR(ctrl->clk))
return PTR_ERR(ctrl->clk);
- err = clk_prepare_enable(ctrl->clk);
+ err = devm_pm_runtime_enable(>dev);
+ if (err)
+ return err;
+
+ err = devm_tegra_core_dev_init_opp_table_common(>dev);
+ if (err)
+ return err;
+
+ err = pm_runtime_resume_and_get(>dev);
if (err)
return err;
err = reset_control_reset(rst);
if (err) {
dev_err(ctrl->dev, "Failed to reset HW: %d\n", err);
- goto err_disable_clk;
+ goto err_put_pm;
}
writel_relaxed(HWSTATUS_CMD_DEFAULT, ctrl->regs + HWSTATUS_CMD);
@@ -1188,21 +1200,19 @@ static int tegra_nand_probe(struct platform_device
*pdev)
dev_name(>dev), ctrl);
if (err) {
dev_err(ctrl->dev, "Failed to get IRQ: %d\n", err);
- goto err_disable_clk;
+ goto err_put_pm;
}
writel_relaxed(DMA_MST_CTRL_IS_DONE, ctrl->regs + DMA_MST_CTRL);
err = tegra_nand_chips_init(ctrl->dev, ctrl);
if (err)
- goto err_disable_clk;
-
- platform_set_drvdata(pdev, ctrl);
+ goto err_put_pm;
>>>
>>> There is no corresponding call pm_runtime_put() here. Is it
>>> intentional to always leave the device runtime resumed after ->probe()
>>> has succeeded?
>>>
>>> I noticed you included some comments about this for some other
>>> drivers, as those needed more tweaks. Is that also the case for this
>>> driver?
>>
>> Could you please clarify? There is pm_runtime_put() in both probe-error
>> and remove() code paths here.
>
> I was not considering the error path of ->probe() (or ->remove()), but
> was rather thinking about when ->probe() completes successfully. Then
> you keep the device runtime resumed, because you have called
> pm_runtime_resume_and_get() for it.
>
> Shouldn't you have a corresponding pm_runtime_put() in ->probe(),
> allowing it to be runtime suspended, until the device is really needed
> later on. No?
This driver doesn't support active power management. I don't have Tegra
hardware that uses NAND storage for testing, so it's up to somebody else
to implement dynamic power management. NAND doesn't require high
voltages, so it's fine to keep the old driver behaviour by keeping
hardware resumed since the probe time.
