Re: [PATCH v6 05/14] dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding
Hi Marcel,
On Tue, 2021-03-23 at 00:38 +, Marcel Ziswiler wrote:
> On Wed, 2021-03-17 at 11:42 +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp display pixel link.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Liu Ying
> > ---
> > v5->v6:
> > * No change.
> >
> > v4->v5:
> > * No change.
> >
> > v3->v4:
> > * No change.
> >
> > v2->v3:
> > * Add Rob's R-b tag.
> >
> > v1->v2:
> > * Use graph schema. (Laurent)
> > * Require all four pixel link output ports. (Laurent)
> > * Mention pixel link is accessed via SCU firmware. (Rob)
> >
> > .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106
> > +
> > 1 file changed, 106 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> > new file mode 100644
> > index ..3af67cc
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> > @@ -0,0 +1,106 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbridge%2Ffsl%2Cimx8qxp-pixel-link.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7C281077e1c1324aa89ad008d8ed93f1f0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520566973165920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2NDRsaWJ6YGFg%2FWAjT1Yf9Y0OaRDSHG0fWghi9UKNRA%3Dreserved=0
> > +$schema:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7C281077e1c1324aa89ad008d8ed93f1f0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520566973165920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ogBn2bQmj1YwDqg0KDMXZ%2FwL0VkdOA14n5ayBioMcos%3Dreserved=0
> > +
> > +title: Freescale i.MX8qm/qxp Display Pixel Link
> > +
> > +maintainers:
> > + - Liu Ying
> > +
> > +description: |
> > + The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard
> > + asynchronous linkage between pixel sources(display controller or
> > + camera module) and pixel consumers(imaging or displays).
> > + It consists of two distinct functions, a pixel transfer function and a
> > + control interface. Multiple pixel channels can exist per one control
> > channel.
> > + This binding documentation is only for pixel links whose pixel sources
> > are
> > + display controllers.
> > +
> > + The i.MX8qm/qxp Display Pixel Link is accessed via System Controller
> > Unit(SCU)
> > + firmware.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - fsl,imx8qm-dc-pixel-link
> > + - fsl,imx8qxp-dc-pixel-link
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: The pixel link input port node from upstream video
> > source.
> > +
> > +patternProperties:
> > + "^port@[1-4]$":
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: The pixel link output port node to downstream bridge.
> > +
> > +required:
> > + - port@0
> > + - port@1
> > + - port@2
> > + - port@3
> > + - port@4
> > +
> > +required:
> > + - compatible
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +dc0-pixel-link0 {
> > +compatible = "fsl,imx8qxp-dc-pixel-link";
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +/* from dc0 pixel combiner channel0 */
> > +port@0 {
> > +reg = <0>;
> > +
> > +dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint {
> > +remote-endpoint =
> > <_pixel_combiner_ch0_dc0_pixel_link0>;
> > +};
> > +};
> > +
> > +/* to PXL2DPIs in MIPI/LVDS combo subsystems */
> > +port@1 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <1>;
> > +
> > +dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 {
> > +reg = <0>;
> > +remote-endpoint =
> > <_lvds_0_pxl2dpi_dc0_pixel_link0>;
> > +};
> > +
> > +dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 {
> > +reg = <1>;
> > +remote-endpoint =
> > <_lvds_1_pxl2dpi_dc0_pixel_link0>;
>
> Those also seem absent from other examples.
Patch 8/14 adds dt-binding for PXL2DPI. An example for the PXL2DPI
instance
Re: [PATCH v6 03/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
Hi Marcel,
On Tue, 2021-03-23 at 00:34 +, Marcel Ziswiler wrote:
> On Wed, 2021-03-17 at 11:42 +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp pixel combiner.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Liu Ying
> > ---
> > v5->v6:
> > * No change.
> >
> > v4->v5:
> > * No change.
> >
> > v3->v4:
> > * No change.
> >
> > v2->v3:
> > * Add Rob's R-b tag.
> >
> > v1->v2:
> > * Use graph schema. (Laurent)
> > * Use enum instead of oneOf + const for the reg property of pixel combiner
> > channels. (Rob)
> >
> > .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144
> > +
> > 1 file changed, 144 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> > new file mode 100644
> > index ..50bae21
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> > @@ -0,0 +1,144 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbridge%2Ffsl%2Cimx8qxp-pixel-combiner.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7Cb83106f0261d4f715b4208d8ed936cb1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520564736692120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2B4sZ3C9r3cewzQ01YHOvGk%2FCZaqQgg3ALftZ1dPLKIE%3Dreserved=0
> > +$schema:
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=04%7C01%7Cvictor.liu%40nxp.com%7Cb83106f0261d4f715b4208d8ed936cb1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637520564736692120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sP82pZYZXLKhzRRoYPR4C%2FFsDLUka1Fj0%2FA9InuWuvg%3Dreserved=0
> > +
> > +title: Freescale i.MX8qm/qxp Pixel Combiner
> > +
> > +maintainers:
> > + - Liu Ying
> > +
> > +description: |
> > + The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
> > + single display controller and manipulates the two streams to support a
> > number
> > + of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
> > as
> > + either one screen, two screens, or virtual screens. The pixel combiner
> > is
> > + also responsible for generating some of the control signals for the
> > pixel link
> > + output channel.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - fsl,imx8qm-pixel-combiner
> > + - fsl,imx8qxp-pixel-combiner
> > +
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +maxItems: 1
> > +
> > + clock-names:
> > +const: apb
> > +
> > + power-domains:
> > +maxItems: 1
> > +
> > +patternProperties:
> > + "^channel@[0-1]$":
> > +type: object
> > +description: Represents a display stream of pixel combiner.
> > +
> > +properties:
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + reg:
> > +description: The display stream index.
> > +enum: [ 0, 1 ]
> > +
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Input endpoint of the display stream.
> > +
> > + port@1:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Output endpoint of the display stream.
> > +
> > +required:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - reg
> > + - port@0
> > + - port@1
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - "#address-cells"
> > + - "#size-cells"
> > + - reg
> > + - clocks
> > + - clock-names
> > + - power-domains
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +pixel-combiner@5602 {
> > +compatible = "fsl,imx8qxp-pixel-combiner";
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <0x5602 0x1>;
> > +clocks = <_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
> > +clock-names = "apb";
> > +power-domains = < IMX_SC_R_DC_0>;
> > +
> > +channel@0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +reg = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +
> > +dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
> > +remote-endpoint =
> > <_dpu_disp0_dc0_pixel_combiner_ch0>;
>
> While I acknowledge this just
Re: [PATCH] drm/msm/dp: Fixed couple of typos
Quoting Bhaskar Chowdhury (2021-03-17 23:26:50) > s/modueles/modules/ two different places > > Signed-off-by: Bhaskar Chowdhury > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/bridge: ti-sn65dsi86: Read EDID blob over DDC
Quoting Laurent Pinchart (2021-03-17 17:20:43)
> Hi Stephen,
>
> Reviving a bit of an old thread, for a question.
>
> On Mon, Nov 02, 2020 at 10:11:43AM -0800, Stephen Boyd wrote:
> > @@ -265,6 +267,23 @@ connector_to_ti_sn_bridge(struct drm_connector
> > *connector)
> > static int ti_sn_bridge_connector_get_modes(struct drm_connector
> > *connector)
> > {
> > struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> > + struct edid *edid = pdata->edid;
> > + int num, ret;
> > +
> > + if (!edid) {
> > + pm_runtime_get_sync(pdata->dev);
> > + edid = pdata->edid = drm_get_edid(connector, >aux.ddc);
> > + pm_runtime_put(pdata->dev);
>
> Is there any specific reason to use the indirect access method, compared
> to the direct method that translates access to an I2C ancillary address
> to an I2C-over-AUX transaction (see page 20 of SLLSEH2B) ? The direct
> method seems it would be more efficient.
>
No I don't think it matters. I was just using the existing support code
that Sean wrote instead of digging into the details. Maybe Sean ran into
something earlier and abandoned that approach?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/lontium-lt9611uxc: Convert sysfs sprintf/snprintf family to sysfs_emit
Fix the following coccicheck warning:
drivers/gpu//drm/bridge/lontium-lt9611uxc.c:858:8-16: WARNING: use
scnprintf or sprintf
Signed-off-by: Tian Tao
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index fee2795..3cac16d 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -855,7 +855,7 @@ static ssize_t lt9611uxc_firmware_show(struct device *dev,
struct device_attribu
{
struct lt9611uxc *lt9611uxc = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%02x\n", lt9611uxc->fw_version);
+ return sysfs_emit(buf, "%02x\n", lt9611uxc->fw_version);
}
static DEVICE_ATTR_RW(lt9611uxc_firmware);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 01/14] media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
Hi Marcel, On Tue, 2021-03-23 at 00:23 +, Marcel Ziswiler wrote: > On Wed, 2021-03-17 at 11:42 +0800, Liu Ying wrote: > > This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO > > and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner. > > The RGB pixels with padding low per component are transmitted on a 30-bit > > input bus(10-bit per component) from a display controller or a 36-bit > > output bus(12-bit per component) to a pixel link. > > > > Reviewed-by: Robert Foss > > > > Reviewed-by: Laurent Pinchart > > > > Signed-off-by: Liu Ying > > --- > > v5->v6: > > * Add Laurent's R-b tag. > > > > v4->v5: > > * Add Robert's R-b tag. > > > > v3->v4: > > * No change. > > > > v2->v3: > > * No change. > > > > v1->v2: > > * No change. > > > > include/uapi/linux/media-bus-format.h | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/include/uapi/linux/media-bus-format.h > > b/include/uapi/linux/media-bus-format.h > > index 0dfc11e..ec3323d 100644 > > --- a/include/uapi/linux/media-bus-format.h > > +++ b/include/uapi/linux/media-bus-format.h > > @@ -34,7 +34,7 @@ > > > > #define MEDIA_BUS_FMT_FIXED0x0001 > > > > -/* RGB - next is 0x101e */ > > +/* RGB - next is 0x1022 */ > > #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 > > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 > > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 > > @@ -59,9 +59,13 @@ > > #define MEDIA_BUS_FMT_RGB888_3X8_DELTA 0x101d > > #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011 > > #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 > > +#define MEDIA_BUS_FMT_RGB666_1X30_CPADLO 0x101e > > +#define MEDIA_BUS_FMT_RGB888_1X30_CPADLO 0x101f > > #define MEDIA_BUS_FMT_ARGB_1X320x100d > > #define MEDIA_BUS_FMT_RGB888_1X32_PADHI0x100f > > #define MEDIA_BUS_FMT_RGB101010_1X30 0x1018 > > +#define MEDIA_BUS_FMT_RGB666_1X36_CPADLO 0x1020 > > +#define MEDIA_BUS_FMT_RGB888_1X36_CPADLO 0x1021 > > #define MEDIA_BUS_FMT_RGB121212_1X36 0x1019 > > #define MEDIA_BUS_FMT_RGB161616_1X48 0x101a > > I haven't figured out what exactly the idea of this strange ordering of > things is about? Could you enlighten > me? The existing comment in this header file mentions 'The bus formats are grouped by type, bus_width, bits per component, samples per pixel and order of subsamples. Numerical values are sorted using generic numerical sort order (8 thus comes before 10).' So, the way I read the ordering is that fomarts are first grouped as 'type', like 'RGB', 'YUV' and 'Bayer', then sorted by 'bus_width', like '2x8', '1x30' and '1x36', then sorted by 'bits per component', like 'RGB666', 'RGB888' and 'RGB121212'. It looks like 'samples per pixel' and 'order of subsamples' are 'YUV' type relevant. HTH, Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[V2][PATCH] drm: xlnx: zynqmp: release reset to DP controller before accessing DP registers
From: Quanyang Wang
When insmod zynqmp-dpsub.ko after rmmod it, system will hang with the
error log as below:
root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko
[ 88.391289] [drm] Initialized zynqmp-dpsub 1.0.0 20130509 for
fd4a.display on minor 0
[ 88.529906] Console: switching to colour frame buffer device 128x48
[ 88.549402] zynqmp-dpsub fd4a.display: [drm] fb0: zynqmp-dpsubdrm frame
buffer device
[ 88.571624] zynqmp-dpsub fd4a.display: ZynqMP DisplayPort Subsystem
driver probed
root@xilinx-zynqmp:~# rmmod zynqmp_dpsub
[ 94.023404] Console: switching to colour dummy device 80x25
root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko
This is because that in zynqmp_dp_probe it tries to access some DP
registers while the DP controller is still in the reset state. When
running "rmmod zynqmp_dpsub", zynqmp_dp_reset(dp, true) in
zynqmp_dp_phy_exit is called to force the DP controller into the reset
state. Then insmod will call zynqmp_dp_probe to program the DP registers,
but at this moment the DP controller hasn't been brought out of the reset
state yet since the function zynqmp_dp_reset(dp, false) is called later and
this will result the system hang.
Releasing the reset to DP controller before any read/write operation to it
will fix this issue. And for symmetry, move zynqmp_dp_reset() call from
zynqmp_dp_phy_exit() to zynqmp_dp_remove().
Signed-off-by: Quanyang Wang
---
V2:
According to Laurent's comments:
- add zynqmp_dp_reset(dp, true) in error path in zynqmp_dp_probe
- move the zynqmp_dp_reset() call from zynqmp_dp_phy_exit() to
zynqmp_dp_remove()
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 99158ee67d02..337adf0769ad 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -402,10 +402,6 @@ static int zynqmp_dp_phy_init(struct zynqmp_dp *dp)
}
}
- ret = zynqmp_dp_reset(dp, false);
- if (ret < 0)
- return ret;
-
zynqmp_dp_clr(dp, ZYNQMP_DP_PHY_RESET, ZYNQMP_DP_PHY_RESET_ALL_RESET);
/*
@@ -441,8 +437,6 @@ static void zynqmp_dp_phy_exit(struct zynqmp_dp *dp)
ret);
}
- zynqmp_dp_reset(dp, true);
-
for (i = 0; i < dp->num_lanes; i++) {
ret = phy_exit(dp->phy[i]);
if (ret)
@@ -1682,9 +1676,13 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct
drm_device *drm)
return PTR_ERR(dp->reset);
}
+ ret = zynqmp_dp_reset(dp, false);
+ if (ret < 0)
+ return ret;
+
ret = zynqmp_dp_phy_probe(dp);
if (ret)
- return ret;
+ goto err_reset;
/* Initialize the hardware. */
zynqmp_dp_write(dp, ZYNQMP_DP_TX_PHY_POWER_DOWN,
@@ -1696,7 +1694,7 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct
drm_device *drm)
ret = zynqmp_dp_phy_init(dp);
if (ret)
- return ret;
+ goto err_reset;
zynqmp_dp_write(dp, ZYNQMP_DP_TRANSMITTER_ENABLE, 1);
@@ -1708,15 +1706,18 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct
drm_device *drm)
zynqmp_dp_irq_handler, IRQF_ONESHOT,
dev_name(dp->dev), dp);
if (ret < 0)
- goto error;
+ goto err_phy_exit;
dev_dbg(dp->dev, "ZynqMP DisplayPort Tx probed with %u lanes\n",
dp->num_lanes);
return 0;
-error:
+err_phy_exit:
zynqmp_dp_phy_exit(dp);
+err_reset:
+ zynqmp_dp_reset(dp, true);
+
return ret;
}
@@ -1734,4 +1735,5 @@ void zynqmp_dp_remove(struct zynqmp_dpsub *dpsub)
zynqmp_dp_write(dp, ZYNQMP_DP_INT_DS, 0x);
zynqmp_dp_phy_exit(dp);
+ zynqmp_dp_reset(dp, true);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: Remove redundant NULL check
Fix the following coccicheck warnings: ./drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:622:2-8: WARNING: NULL check before some freeing functions is not needed. ./drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:618:2-8: WARNING: NULL check before some freeing functions is not needed. ./drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:616:2-8: WARNING: NULL check before some freeing functions is not needed. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c index d05c359..bd0d66e 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c @@ -612,14 +612,10 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void *data, err_submit_cmds: if (ret && (out_fence_fd >= 0)) put_unused_fd(out_fence_fd); - if (stream) - kvfree(stream); - if (bos) - kvfree(bos); - if (relocs) - kvfree(relocs); - if (pmrs) - kvfree(pmrs); + kvfree(stream); + kvfree(bos); + kvfree(relocs); + kvfree(pmrs); return ret; } -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v1] drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
On Mon, Mar 22, 2021 at 5:44 PM Matthias Kaehlcke wrote: > > On Mon, Mar 22, 2021 at 02:17:12AM -0700, Kalyan Thota wrote: > > From: Kalyan Thota > > > > DPU runtime resume will request for a min vote on the AXI bus as > > it is a necessary step before turning ON the AXI clock. > > > > The change does below > > 1) Move the icc path set before requesting runtime get_sync. > > 2) remove the dependency of hw catalog for min ib vote > > as it is initialized at a later point. > > > > Signed-off-by: Kalyan Thota > > Confirmed that this fixes a bunch of warnings at boot on SC7180 when > (out-of-tree) camera support is enabled: > > [1.832228] gcc_disp_hf_axi_clk status stuck at 'off' > [2.118292] gcc_disp_hf_axi_clk status stuck at 'off' > [2.442383] gcc_disp_hf_axi_clk already disabled > [2.750054] gcc_disp_hf_axi_clk already unprepared > [3.154835] gcc_disp_hf_axi_clk already disabled > [3.421835] gcc_disp_hf_axi_clk already unprepared > > Tested-by: Matthias Kaehlcke thanks for testing on the setup which had this issue.. I've pushed to msm-next BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] drm/tilcdc: fix LCD pixel clock setting
The series was born from a patch to fix the LCD pixel clock setting. Two additional patches have been added to this. One renames a misleading variable name that was probably the cause of the bug and the other fixes a warning message. Changes in v3: - Replace calculated with requested in the warning message. - Swap the positions of the real_pclk_rate, and pclk_rate parameters in the warning message. Changes in v2: - The patch has been added in version 2. - Rename clk_div_rate to real_pclk_rate. - Provide pixel clock rate to tilcdc_pclk_diff(). - The patch has been added in version 2. Dario Binacchi (3): drm/tilcdc: rename req_rate to pclk_rate drm/tilcdc: fix LCD pixel clock setting drm/tilcdc: fix pixel clock setting warning message drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/tilcdc: fix pixel clock setting warning message
The warning message did not printed the LCD pixel clock rate but the LCD
clock divisor input rate. As a consequence, the required and real pixel
clock rates are now passed to the tilcdc_pclk_diff().
Signed-off-by: Dario Binacchi
---
Changes in v3:
- Replace calculated with requested in the warning message.
- Swap the positions of the real_pclk_rate, and pclk_rate parameters
in the warning message.
Changes in v2:
- The patch has been added in version 2.
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index ac6228cb04d9..381a706ab7c2 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -203,7 +203,7 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
- unsigned long clk_rate, real_rate, real_pclk_rate, pclk_rate;
+ unsigned long clk_rate, real_pclk_rate, pclk_rate;
unsigned int clkdiv;
int ret;
@@ -239,12 +239,12 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
* 5% is an arbitrary value - LCDs are usually quite tolerant
* about pixel clock rates.
*/
- real_rate = clkdiv * pclk_rate;
+ real_pclk_rate = clk_rate / clkdiv;
- if (tilcdc_pclk_diff(clk_rate, real_rate) > 5) {
+ if (tilcdc_pclk_diff(pclk_rate, real_pclk_rate) > 5) {
dev_warn(dev->dev,
-"effective pixel clock rate (%luHz) differs
from the calculated rate (%luHz)\n",
-clk_rate, real_rate);
+"effective pixel clock rate (%luHz) differs
from the requested rate (%luHz)\n",
+real_pclk_rate, pclk_rate);
}
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/tilcdc: rename req_rate to pclk_rate
The req_rate name is a little misleading, so let's rename to pclk_rate
(pixel clock rate).
Signed-off-by: Dario Binacchi
---
(no changes since v2)
Changes in v2:
- The patch has been added in version 2.
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 30213708fc99..aeec5786617d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -203,18 +203,18 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
- unsigned long clk_rate, real_rate, req_rate;
+ unsigned long clk_rate, real_rate, pclk_rate;
unsigned int clkdiv;
int ret;
clkdiv = 2; /* first try using a standard divider of 2 */
/* mode.clock is in KHz, set_rate wants parameter in Hz */
- req_rate = crtc->mode.clock * 1000;
+ pclk_rate = crtc->mode.clock * 1000;
- ret = clk_set_rate(priv->clk, req_rate * clkdiv);
+ ret = clk_set_rate(priv->clk, pclk_rate * clkdiv);
clk_rate = clk_get_rate(priv->clk);
- if (ret < 0 || tilcdc_pclk_diff(req_rate, clk_rate) > 5) {
+ if (ret < 0 || tilcdc_pclk_diff(pclk_rate, clk_rate) > 5) {
/*
* If we fail to set the clock rate (some architectures don't
* use the common clock framework yet and may not implement
@@ -229,7 +229,7 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
return;
}
- clkdiv = DIV_ROUND_CLOSEST(clk_rate, req_rate);
+ clkdiv = DIV_ROUND_CLOSEST(clk_rate, pclk_rate);
/*
* Emit a warning if the real clock rate resulting from the
@@ -238,7 +238,7 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
* 5% is an arbitrary value - LCDs are usually quite tolerant
* about pixel clock rates.
*/
- real_rate = clkdiv * req_rate;
+ real_rate = clkdiv * pclk_rate;
if (tilcdc_pclk_diff(clk_rate, real_rate) > 5) {
dev_warn(dev->dev,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/tilcdc: fix LCD pixel clock setting
The tilcdc_pclk_diff() compares the requested pixel clock rate to the
real one, so passing it clk_rate instead of clk_rate / clkdiv caused
it to fail even if the clk_rate was properly set. Adding the
real_pclk_rate variable makes the code more readable.
Signed-off-by: Dario Binacchi
---
(no changes since v2)
Changes in v2:
- Rename clk_div_rate to real_pclk_rate.
- Provide pixel clock rate to tilcdc_pclk_diff().
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index aeec5786617d..ac6228cb04d9 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -203,7 +203,7 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
- unsigned long clk_rate, real_rate, pclk_rate;
+ unsigned long clk_rate, real_rate, real_pclk_rate, pclk_rate;
unsigned int clkdiv;
int ret;
@@ -214,7 +214,8 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
ret = clk_set_rate(priv->clk, pclk_rate * clkdiv);
clk_rate = clk_get_rate(priv->clk);
- if (ret < 0 || tilcdc_pclk_diff(pclk_rate, clk_rate) > 5) {
+ real_pclk_rate = clk_rate / clkdiv;
+ if (ret < 0 || tilcdc_pclk_diff(pclk_rate, real_pclk_rate) > 5) {
/*
* If we fail to set the clock rate (some architectures don't
* use the common clock framework yet and may not implement
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: amd: Remove duplicate includes
../hw_ddc.h, ../hw_gpio.h and ../hw_hpd.h have been included at line 32, so remove them. Signed-off-by: Wan Jiabing --- .../gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c| 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c b/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c index 66e4841f41e4..ca335ea60412 100644 --- a/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c +++ b/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c @@ -48,10 +48,6 @@ #define REGI(reg_name, block, id)\ mm ## block ## id ## _ ## reg_name -#include "../hw_gpio.h" -#include "../hw_ddc.h" -#include "../hw_hpd.h" - #include "reg_helper.h" #include "../hpd_regs.h" -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: A typo fix
s/nothign/nothing/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c index f6ad257a260e..14d784a6fae5 100644 --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c @@ -4185,7 +4185,7 @@ static void icl_pll_disable(struct drm_i915_private *dev_priv, /* * DVFS pre sequence would be here, but in our driver the cdclk code * paths should already be setting the appropriate voltage, hence we do -* nothign here. +* nothing here. */ val = intel_de_read(dev_priv, enable_reg); -- 2.31.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: amd: Remove duplicate include of dce110_resource.h
dce110/dce110_resource.h has been included at line 58, so remove the duplicate include at line 64. Signed-off-by: Wan Jiabing --- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c index 4a3df13c9e49..c4fe21b3b23f 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c @@ -61,7 +61,6 @@ #include "dcn21/dcn21_dccg.h" #include "dcn21_hubbub.h" #include "dcn10/dcn10_resource.h" -#include "dce110/dce110_resource.h" #include "dce/dce_panel_cntl.h" #include "dcn20/dcn20_dwb.h" -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: rcar-du: Shutdown the display on remove
When the device is unbound from the driver (the DU being a platform device, this occurs either when removing the DU module, or when unbinding the device manually through sysfs), the display may be active. Make sure it gets shut down. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 2a06ec1cbefb..9f1a3aad4dd7 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -553,6 +553,7 @@ static int rcar_du_remove(struct platform_device *pdev) struct drm_device *ddev = >ddev; drm_dev_unregister(ddev); + drm_atomic_helper_shutdown(ddev); drm_kms_helper_poll_fini(ddev); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: rcar-du: Don't put reference to drm_device in rcar_du_remove()
The reference to the drm_device that was acquired by
devm_drm_dev_alloc() is released automatically by the devres
infrastructure. It must not be released manually, as that causes a
reference underflow..
Fixes: ea6aae151887 ("drm: rcar-du: Embed drm_device in rcar_du_device")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 43de3d8686e8..2a06ec1cbefb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -556,8 +556,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_kms_helper_poll_fini(ddev);
- drm_dev_put(ddev);
-
return 0;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v1] drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
On Mon, Mar 22, 2021 at 02:17:12AM -0700, Kalyan Thota wrote: > From: Kalyan Thota > > DPU runtime resume will request for a min vote on the AXI bus as > it is a necessary step before turning ON the AXI clock. > > The change does below > 1) Move the icc path set before requesting runtime get_sync. > 2) remove the dependency of hw catalog for min ib vote > as it is initialized at a later point. > > Signed-off-by: Kalyan Thota Confirmed that this fixes a bunch of warnings at boot on SC7180 when (out-of-tree) camera support is enabled: [1.832228] gcc_disp_hf_axi_clk status stuck at 'off' [2.118292] gcc_disp_hf_axi_clk status stuck at 'off' [2.442383] gcc_disp_hf_axi_clk already disabled [2.750054] gcc_disp_hf_axi_clk already unprepared [3.154835] gcc_disp_hf_axi_clk already disabled [3.421835] gcc_disp_hf_axi_clk already unprepared Tested-by: Matthias Kaehlcke ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: rcar-du: Shutdown the display on system shutdown
When the system shuts down or warm reboots, the display may be active,
with the hardware accessing system memory. Upon reboot, the DDR will not
be accessible, which may cause issues.
Implement the platform_driver .shutdown() operation and shut down the
display to fix this.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index bfbff90588cb..43de3d8686e8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -561,6 +561,13 @@ static int rcar_du_remove(struct platform_device *pdev)
return 0;
}
+static void rcar_du_shutdown(struct platform_device *pdev)
+{
+ struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
+
+ drm_atomic_helper_shutdown(>ddev);
+}
+
static int rcar_du_probe(struct platform_device *pdev)
{
struct rcar_du_device *rcdu;
@@ -617,6 +624,7 @@ static int rcar_du_probe(struct platform_device *pdev)
static struct platform_driver rcar_du_platform_driver = {
.probe = rcar_du_probe,
.remove = rcar_du_remove,
+ .shutdown = rcar_du_shutdown,
.driver = {
.name = "rcar-du",
.pm = _du_pm_ops,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading
Hi Stephen, On Mon, Nov 02, 2020 at 05:15:24PM -0800, Stephen Boyd wrote: > Quoting Sam Ravnborg (2020-11-01 09:37:41) > > Hi Stephen. > > > > On Thu, Oct 29, 2020 at 06:17:34PM -0700, Stephen Boyd wrote: > > > This patch series cleans up the DDC code a little bit so that > > > it is more efficient time wise and supports grabbing the EDID > > > of the eDP panel over the aux channel. I timed this on a board > > > I have on my desk and it takes about 20ms to grab the EDID out > > > of the panel and make sure it is valid. > > > > > > The first two patches seem less controversial so I stuck them at > > > the beginning. The third patch does the EDID reading and caches > > > it so we don't have to keep grabbing it over and over again. And > > > finally the last patch updates the reply field so that short > > > reads and nacks over the channel are reflected properly instead of > > > treating them as some sort of error that can't be discerned. > > > > > > Stephen Boyd (4): > > > drm/bridge: ti-sn65dsi86: Combine register accesses in > > > ti_sn_aux_transfer() > > > drm/bridge: ti-sn65dsi86: Make polling a busy loop > > > drm/bridge: ti-sn65dsi86: Read EDID blob over DDC > > > drm/bridge: ti-sn65dsi86: Update reply on aux failures > > > > Series looks good. You can add my a-b on the full series. > > Acked-by: Sam Ravnborg > > > > I can apply after Douglas have had a look at the patches he did not r-b > > yet. > > > > Any chance we can convince you to prepare this bridge driver for use in > > a chained bridge setup where the connector is created by the display > > driver and uses drm_bridge_funcs? > > > > First step wuld be to introduce the use of a panel_bridge. > > Then add get_edid to drm_bridge_funcs and maybe more helpers. > > > > Then natural final step would be to move connector creation to the > > display driver - see how other uses drm_bridge_connector_init() to do so > > - it is relatively simple. > > > > Should be doable - and reach out if you need some help. > > I started to look at this and got stuck at ti_sn_bridge_get_bpp(). Where > can I get the details of the bpc for the downstream bridge or panel? Is > there some function that can tell this bridge what the bpc is for the > attached connector? I've posted a patch series to convert to DRM_BRIDGE_ATTACH_NO_CONNECTOR yesterday (and have CC'ed you), but I've overlooked this particular problem :-S You can't get the connector in the .enable() operation, but you can get it in .atomic_enable(), with drm_atomic_get_new_connector_for_encoder(). This being said, it's probably not the right option. What matters here isn't the bpc for the connector, but the format expected by the next bridge in the chain. drm_bridge_funcs has two operations, .atomic_get_output_bus_fmts() and .atomic_get_input_bus_fmts(), to negotiate that format along a chain of bridges. The panel bridge driver (drivers/gpu/drm/bridge/panel.c) doesn't implement those operations, and neither does display-connector.c, so that may be what we should start with. > I see that td_mode_valid() in > drivers/gpu/drm/bridge/tc358775.c stores away the bpc from the incoming > drm_display_info pointer but I'm not sure that is correct because can't > that be called for various and not necessarily the one we're using? You're right, .mode_valid() shouldn't do that. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning
* Martin Sebor wrote: > > I.e. the real workaround might be to turn off the > > -Wstringop-overread-warning, > > until GCC-11 gets fixed? > > In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow. > GCC 11 breaks it out as a separate warning to make it easier to > control. Both warnings have caught some real bugs but they both > have a nonzero rate of false positives. Other than bug reports > we don't have enough data to say what their S/N ratio might be > but my sense is that it's fairly high in general. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overread > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overflow > > In GCC 11, all access warnings expect objects to be either declared > or allocated. Pointers with constant values are taken to point to > nothing valid (as Arnd mentioned above, this is to detect invalid > accesses to members of structs at address zero). > > One possible solution to the known address problem is to extend GCC > attributes address and io that pin an object to a hardwired address > to all targets (at the moment they're supported on just one or two > targets). I'm not sure this can still happen before GCC 11 releases > sometime in April or May. > > Until then, another workaround is to convert the fixed address to > a volatile pointer before using it for the access, along the lines > below. It should have only a negligible effect on efficiency. Thank you for the detailed answer! I think I'll go with Arnd's original patch - which makes the code a slightly bit cleaner by separating out the check_tboot_version() check into a standalone function. The only ugly aspect is the global nature of the 'tboot' pointer - but that's a self-inflicted wound. I'd also guess that the S/N ratio somewhat unfairly penalizes this warning right now, because the kernel had a decade of growing real fixes via other efforts such as static and dynamic instrumentation as well. So the probability of false positive remaining is in fact higher, and going forward we should see a better S/N ratio of this warning. Most of which will never be seen by upstream maintainers, as the mishaps will stay at the individual developer level. :-) Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning
On Mon, Mar 22, 2021 at 11:09 PM Martin Sebor wrote:
> On 3/22/21 2:29 PM, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> >
> > I.e. the real workaround might be to turn off the
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
>
> In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow.
> GCC 11 breaks it out as a separate warning to make it easier to
> control. Both warnings have caught some real bugs but they both
> have a nonzero rate of false positives. Other than bug reports
> we don't have enough data to say what their S/N ratio might be
> but my sense is that it's fairly high in general.
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overread
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overflow
Unfortunately, stringop-overflow is one of the warnings that is
completely disabled in the kernel at the moment, rather than
enabled at one of the user-selectable higher warning levels.
I have a patch series to change that and to pull some of these
into the lower W=1 or W=2 levels or even enable them by default.
To do this though, I first need to ensure that the actual output
is empty for the normal builds. I added -Wstringop-overflow to
the list of warnings I wanted to address because it is a new
warning and only has a dozen or so occurrences throughout the
kernel.
> In GCC 11, all access warnings expect objects to be either declared
> or allocated. Pointers with constant values are taken to point to
> nothing valid (as Arnd mentioned above, this is to detect invalid
> accesses to members of structs at address zero).
>
> One possible solution to the known address problem is to extend GCC
> attributes address and io that pin an object to a hardwired address
> to all targets (at the moment they're supported on just one or two
> targets). I'm not sure this can still happen before GCC 11 releases
> sometime in April or May.
>
> Until then, another workaround is to convert the fixed address to
> a volatile pointer before using it for the access, along the lines
> below. It should have only a negligible effect on efficiency.
>
> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
> index 4c09ba110204..76326b906010 100644
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -67,7 +67,9 @@ void __init tboot_probe(void)
> /* Map and check for tboot UUID. */
> set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
> tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
> - if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
> + if (memcmp(_uuid,
> + (*(struct tboot* volatile *)())->uuid,
> + sizeof(tboot->uuid))) {
> pr_warn("tboot at 0x%llx is invalid\n",
I think a stray 'volatile' would raise too many red flags here, but
I checked that the RELOC_HIDE() macro has the same effect, e.g.
@@ -66,7 +67,8 @@ void __init tboot_probe(void)
/* Map and check for tboot UUID. */
set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
- tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
+ /* RELOC_HIDE to prevent gcc warnings about NULL pointer */
+ tboot = RELOC_HIDE(NULL, fix_to_virt(FIX_TBOOT_BASE));
if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
tboot = NULL;
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd: Fix a typo in two different sentences
On 3/22/21 2:06 PM, Bhaskar Chowdhury wrote: > > s/defintion/definition/ .two different places. > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/amd/include/atombios.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/include/atombios.h > b/drivers/gpu/drm/amd/include/atombios.h > index c1d7b1d0b952..47eb84598b96 100644 > --- a/drivers/gpu/drm/amd/include/atombios.h > +++ b/drivers/gpu/drm/amd/include/atombios.h > @@ -1987,9 +1987,9 @@ typedef struct _PIXEL_CLOCK_PARAMETERS_V6 > #define PIXEL_CLOCK_V6_MISC_HDMI_BPP_MASK 0x0c > #define PIXEL_CLOCK_V6_MISC_HDMI_24BPP 0x00 > #define PIXEL_CLOCK_V6_MISC_HDMI_36BPP 0x04 > -#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the > correct defintion for 36bpp should be 2 for 36bpp(2:1) > +#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the > correct definition for 36bpp should be 2 for 36bpp(2:1) > #define PIXEL_CLOCK_V6_MISC_HDMI_30BPP 0x08 > -#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the > correct defintion for 30bpp should be 1 for 36bpp(5:4) > +#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the > correct definition for 30bpp should be 1 for 36bpp(5:4) > #define PIXEL_CLOCK_V6_MISC_HDMI_48BPP 0x0c > #define PIXEL_CLOCK_V6_MISC_REF_DIV_SRC 0x10 > #define PIXEL_CLOCK_V6_MISC_GEN_DPREFCLK0x40 > -- -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning
On 3/22/21 2:29 PM, Ingo Molnar wrote:
* Arnd Bergmann wrote:
From: Arnd Bergmann
gcc-11 warns about using string operations on pointers that are
defined at compile time as offsets from a NULL pointer. Unfortunately
that also happens on the result of fix_to_virt(), which is a
compile-time constant for a constantn input:
arch/x86/kernel/tboot.c: In function 'tboot_probe':
arch/x86/kernel/tboot.c:70:13: error: '__builtin_memcmp_eq' specified bound 16
exceeds source size 0 [-Werror=stringop-overread]
70 | if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
| ^~
I hope this can get addressed in gcc-11 before the release.
As a workaround, split up the tboot_probe() function in two halves
to separate the pointer generation from the usage. This is a bit
ugly, and hopefully gcc understands that the code is actually correct
before it learns to peek into the noinline function.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Signed-off-by: Arnd Bergmann
---
arch/x86/kernel/tboot.c | 44 -
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 4c09ba110204..f9af561c3cd4 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -49,6 +49,30 @@ bool tboot_enabled(void)
return tboot != NULL;
}
+/* noinline to prevent gcc from warning about dereferencing constant fixaddr */
+static noinline __init bool check_tboot_version(void)
+{
+ if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
+ pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
+ return false;
+ }
+
+ if (tboot->version < 5) {
+ pr_warn("tboot version is invalid: %u\n", tboot->version);
+ return false;
+ }
+
+ pr_info("found shared page at phys addr 0x%llx:\n",
+ boot_params.tboot_addr);
+ pr_debug("version: %d\n", tboot->version);
+ pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
+ pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
+ pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
+ pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
+
+ return true;
+}
+
void __init tboot_probe(void)
{
/* Look for valid page-aligned address for shared page. */
@@ -66,25 +90,9 @@ void __init tboot_probe(void)
/* Map and check for tboot UUID. */
set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
- tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
- if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
- pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
+ tboot = (void *)fix_to_virt(FIX_TBOOT_BASE);
+ if (!check_tboot_version())
tboot = NULL;
- return;
- }
- if (tboot->version < 5) {
- pr_warn("tboot version is invalid: %u\n", tboot->version);
- tboot = NULL;
- return;
- }
-
- pr_info("found shared page at phys addr 0x%llx:\n",
- boot_params.tboot_addr);
- pr_debug("version: %d\n", tboot->version);
- pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
- pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
- pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
- pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
This is indeed rather ugly - and the other patch that removes a debug
check seems counterproductive as well.
Do we know how many genuine bugs -Wstringop-overread-warning has
caught or is about to catch?
I.e. the real workaround might be to turn off the -Wstringop-overread-warning,
until GCC-11 gets fixed?
In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow.
GCC 11 breaks it out as a separate warning to make it easier to
control. Both warnings have caught some real bugs but they both
have a nonzero rate of false positives. Other than bug reports
we don't have enough data to say what their S/N ratio might be
but my sense is that it's fairly high in general.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overflow
In GCC 11, all access warnings expect objects to be either declared
or allocated. Pointers with constant values are taken to point to
nothing valid (as Arnd mentioned above, this is to detect invalid
accesses to members of structs at address zero).
One possible solution to the known address problem is to extend GCC
attributes address and io that pin an object to a hardwired address
to all targets (at the moment they're supported on just one or two
targets). I'm not sure this can still happen before GCC 11 releases
sometime in April or May.
Until then, another workaround is to convert the fixed address to
a volatile pointer before using it for the access, along
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
> >> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 3/1/21 4:43 PM, Hans de Goede wrote:
> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> Predia Basic tablet would no longer properly light up after reboot.
>
> The backlight still turns back on after reboot, but the LCD shows an
> all black display. The display is also all black during the time that
> EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
>
> In this scenario the panel is initialized so that it appears to be
> working
> and the fastboot code skips doing a modeset. Forcing a modeset by doing a
> chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> /sys/class/graphics/fb0/blank causes the panel to work again.
>
> Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> a no-op when set; and set this on vlv/chv devices when a DSI panel is
> detected, to work around this.
>
> Admittedly this is a bit of a big hammer, but these platforms have been
> around for quite some time now and they have always worked fine without
> the new behavior to shutdown everything on shutdown/reboot. This approach
> simply disables the recently introduced new shutdown behavior in this
> specific case where it is known to cause problems. Which is a nice and
> simple way to deal with this.
>
> Signed-off-by: Hans de Goede
> >>>
> >>> Ping? Since sending this patch I've been seeing the issue addressed by
> >>> this on variour other CHT based devices too.
> >>>
> >>> So we have various devices suffering from a black screen after reboot
> >>> now. This is pretty serious usability regression.
> >>>
> >>> As such it would be good to get this reviewed, or another fix proposed.
> >>
> >> For the quirks we try to limit them to very specific vendor and model ids,
> >> so I wonder if it would be possible to get this information in here instead
> >> to all the vlv with dsi...
> >>
> >> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
> >>
> >> Jani?
> >> Ville?
> >
> > We need to figure out why the panel doesn't start up again.
>
> Note it is the GOP which fails to light it up again. I think we turn something
> off, which after a power-on-reset is on, so the GOP expects it to be on.
Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
Are there any fast vs. slow boot settings in the BIOS setup?
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning
On Mon, Mar 22, 2021 at 9:29 PM Ingo Molnar wrote: > * Arnd Bergmann wrote: > > From: Arnd Bergmann > This is indeed rather ugly - and the other patch that removes a debug > check seems counterproductive as well. > > Do we know how many genuine bugs -Wstringop-overread-warning has > caught or is about to catch? > > I.e. the real workaround might be to turn off the -Wstringop-overread-warning, > until GCC-11 gets fixed? See the [PATCH 0/11] message. The last two patches in the series are for code that I suspect may be broken, the others are basically all false positives. As gcc-11 is not released yet, I don't think we have to apply any of the patches or disable the warning at the moment, but I posted all the patches to get a better understanding on which of them should be addressed in the kernel vs gcc. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
Hi,
On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
>> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/1/21 4:43 PM, Hans de Goede wrote:
After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.
The backlight still turns back on after reboot, but the LCD shows an
all black display. The display is also all black during the time that
EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
In this scenario the panel is initialized so that it appears to be working
and the fastboot code skips doing a modeset. Forcing a modeset by doing a
chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
/sys/class/graphics/fb0/blank causes the panel to work again.
Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
a no-op when set; and set this on vlv/chv devices when a DSI panel is
detected, to work around this.
Admittedly this is a bit of a big hammer, but these platforms have been
around for quite some time now and they have always worked fine without
the new behavior to shutdown everything on shutdown/reboot. This approach
simply disables the recently introduced new shutdown behavior in this
specific case where it is known to cause problems. Which is a nice and
simple way to deal with this.
Signed-off-by: Hans de Goede
>>>
>>> Ping? Since sending this patch I've been seeing the issue addressed by
>>> this on variour other CHT based devices too.
>>>
>>> So we have various devices suffering from a black screen after reboot
>>> now. This is pretty serious usability regression.
>>>
>>> As such it would be good to get this reviewed, or another fix proposed.
>>
>> For the quirks we try to limit them to very specific vendor and model ids,
>> so I wonder if it would be possible to get this information in here instead
>> to all the vlv with dsi...
>>
>> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>>
>> Jani?
>> Ville?
>
> We need to figure out why the panel doesn't start up again.
Note it is the GOP which fails to light it up again. I think we turn something
off, which after a power-on-reset is on, so the GOP expects it to be on.
> If it has
> problems with this then surely it also fails if we just happen to reboot
> with the panel already off?
I would assume so, yes, but that only happens on say a "reboot --force"
over ssh, while the screen is off. Which are rather exceptional circumstances.
Where as just a regular reboot is quite normal and now results in a black
screen. And recovery of this condition by a normal user involves a
power-cycle by pressing the power-button for 10 seconds (these are tablets
so the force-power-off time is quite long), which most users don't even know
they can do...
> Oh a modeset fixes it? Then I guess it's just fastboot fail due to DSI
> code being crap?
This is not a fastboot issue, if I make the grub menu show every boot,
the grub-menu is also all black, as the GOP fails to properly initialize
the panel when this happens fastboot just inherits this condition.
Assuming that we want to have the EFI gfx/console work on reboot
(for say the grub menu), then disabling fastboot is not going to help.
Also note that the Windows boot-splash with the circling dots uses the
efifb, so rebooting into Windows also leads to a blackscreen at least
until Windows has booted all the way. Note I have not tried Windows,
so I don't know if Windows will recover from the black screen once
its gfx driver loads, or if it stays black then too.
> If no one is willing to fix it then I guess we just
> need to disable fastboot for DSI somehow.
See above, this is a GOP issue, so there is nothing for us to fix,
what we need to do is stop leaving the hw in a state which the GOP
cannot deal with. Which leads me to believe that we just need to disable
the "graceful shutdown" on the combination of DSI + BYT/CHT.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd: Fix a typo in two different sentences
s/defintion/definition/ .two different places. Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/amd/include/atombios.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h index c1d7b1d0b952..47eb84598b96 100644 --- a/drivers/gpu/drm/amd/include/atombios.h +++ b/drivers/gpu/drm/amd/include/atombios.h @@ -1987,9 +1987,9 @@ typedef struct _PIXEL_CLOCK_PARAMETERS_V6 #define PIXEL_CLOCK_V6_MISC_HDMI_BPP_MASK 0x0c #define PIXEL_CLOCK_V6_MISC_HDMI_24BPP 0x00 #define PIXEL_CLOCK_V6_MISC_HDMI_36BPP 0x04 -#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the correct defintion for 36bpp should be 2 for 36bpp(2:1) +#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the correct definition for 36bpp should be 2 for 36bpp(2:1) #define PIXEL_CLOCK_V6_MISC_HDMI_30BPP 0x08 -#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the correct defintion for 30bpp should be 1 for 36bpp(5:4) +#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the correct definition for 30bpp should be 1 for 36bpp(5:4) #define PIXEL_CLOCK_V6_MISC_HDMI_48BPP 0x0c #define PIXEL_CLOCK_V6_MISC_REF_DIV_SRC 0x10 #define PIXEL_CLOCK_V6_MISC_GEN_DPREFCLK0x40 -- 2.31.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212397] New: Resume from suspend (S3) does not bring back video anymore
https://bugzilla.kernel.org/show_bug.cgi?id=212397 Bug ID: 212397 Summary: Resume from suspend (S3) does not bring back video anymore Product: Drivers Version: 2.5 Kernel Version: 5.11.7 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: amits...@gmx.net Regression: No After updating from v5.10 to v5.11, resume from suspend is broken: I don't get video output at all. I have a ThinkPad T60, with RV515/M54 [Mobility Radeon X1400] GPU. I'm running Fedora 33 with gnome on X11 (not Wayland - Wayland display does not work on this GPU). Upon resume, dmesg shows me: Mär 22 18:30:57 trundl.on kernel: usb usb5: root hub lost power or was reset Mär 22 18:30:57 trundl.on kernel: [ cut here ] Mär 22 18:30:57 trundl.on kernel: ACPI: EC: event unblocked Mär 22 18:30:57 trundl.on kernel: WARNING: CPU: 0 PID: 7973 at include/drm/ttm/ttm_bo_api.h:615 radeon_bo_unpin+0x47/0x60 [radeon] Mär 22 18:30:57 trundl.on kernel: Modules linked in: uas usb_storage xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_nat_tftp nf> Mär 22 18:30:57 trundl.on kernel: platform_profile ledtrig_audio snd_timer snd rfkill soundcore acpi_cpufreq zram ip_tables xfs dm_c> Mär 22 18:30:57 trundl.on kernel: CPU: 0 PID: 7973 Comm: kworker/u4:13 Not tainted 5.11.7-200.fc33.x86_64 #1 Mär 22 18:30:57 trundl.on kernel: Hardware name: LENOVO 8743CTO/8743CTO, BIOS 7IET37WW (1.18 ) 04/01/2010 Mär 22 18:30:57 trundl.on kernel: Workqueue: events_unbound async_run_entry_fn Mär 22 18:30:57 trundl.on kernel: RIP: 0010:radeon_bo_unpin+0x47/0x60 [radeon] Mär 22 18:30:57 trundl.on kernel: Code: 8b 87 d8 01 00 00 48 8b 97 e0 02 00 00 48 c1 e0 0c 83 bf 14 02 00 00 02 74 08 48 29 82 48 2d > Mär 22 18:30:57 trundl.on kernel: RSP: 0018:a13081cebd88 EFLAGS: 00010246 Mär 22 18:30:57 trundl.on kernel: RAX: RBX: 90d174bec000 RCX: 0004 Mär 22 18:30:57 trundl.on kernel: RDX: RSI: RDI: 90d174bd6c00 Mär 22 18:30:57 trundl.on kernel: RBP: 90d141b8a0c8 R08: R09: a13081cebd64 Mär 22 18:30:57 trundl.on kernel: R10: 000f R11: 0001 R12: 90d174bd6c00 Mär 22 18:30:57 trundl.on kernel: R13: 90d174f26000 R14: 0010 R15: Mär 22 18:30:57 trundl.on kernel: FS: () GS:90d1fcc0() knlGS: Mär 22 18:30:57 trundl.on kernel: CS: 0010 DS: ES: CR0: 80050033 Mär 22 18:30:57 trundl.on kernel: CR2: 7fa1d4039ce6 CR3: 75bcc000 CR4: 06f0 Mär 22 18:30:57 trundl.on kernel: Call Trace: Mär 22 18:30:57 trundl.on kernel: radeon_gart_table_vram_unpin+0x47/0xa0 [radeon] Mär 22 18:30:57 trundl.on kernel: rv515_resume+0x74/0xb0 [radeon] Mär 22 18:30:57 trundl.on kernel: usb usb2: root hub lost power or was reset Mär 22 18:30:57 trundl.on kernel: radeon_resume_kms+0x5c/0x350 [radeon] Mär 22 18:30:57 trundl.on kernel: ? pci_pm_poweroff_noirq+0x110/0x110 Mär 22 18:30:57 trundl.on kernel: dpm_run_callback+0x4c/0x120 Mär 22 18:30:57 trundl.on kernel: device_resume+0xa7/0x200 Mär 22 18:30:57 trundl.on kernel: async_resume+0x19/0x30 Mär 22 18:30:57 trundl.on kernel: async_run_entry_fn+0x39/0x160 Mär 22 18:30:57 trundl.on kernel: process_one_work+0x1ec/0x380 Mär 22 18:30:57 trundl.on kernel: worker_thread+0x53/0x3e0 Mär 22 18:30:57 trundl.on kernel: ? process_one_work+0x380/0x380 Mär 22 18:30:57 trundl.on kernel: kthread+0x11b/0x140 Mär 22 18:30:57 trundl.on kernel: ? __kthread_bind_mask+0x60/0x60 Mär 22 18:30:57 trundl.on kernel: ret_from_fork+0x22/0x30 Mär 22 18:30:57 trundl.on kernel: ---[ end trace ff7b7de1d8244926 ]--- Mär 22 18:30:57 trundl.on kernel: usb usb3: root hub lost power or was reset Mär 22 18:30:57 trundl.on kernel: usb usb4: root hub lost power or was reset Mär 22 18:30:57 trundl.on kernel: [ cut here ] Mär 22 18:30:57 trundl.on kernel: TPM returned invalid status Mär 22 18:30:57 trundl.on kernel: WARNING: CPU: 1 PID: 7956 at drivers/char/tpm/tpm_tis_core.c:205 tpm_tis_status+0x66/0x70 Mär 22 18:30:57 trundl.on kernel: Modules linked in: uas usb_storage xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_nat_tftp nf> Mär 22 18:30:57 trundl.on kernel: platform_profile ledtrig_audio snd_timer snd rfkill soundcore acpi_cpufreq zram ip_tables xfs dm_c> Mär 22 18:30:57 trundl.on kernel: CPU: 1 PID: 7956 Comm: systemd-sleep Tainted: GW 5.11.7-200.fc33.x86_64 #1 Mär 22 18:30:57 trundl.on kernel: Hardware name: LENOVO 8743CTO/8743CTO, BIOS 7IET37WW (1.18 ) 04/01/2010 Mär 22 18:30:57 trundl.on kernel: RIP: 0010:tpm_tis_status+0x66/0x70 Mär 22 18:30:57 trundl.on kernel: Code: 23 75 05
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 3/1/21 4:43 PM, Hans de Goede wrote:
> > > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> > > displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> > > Predia Basic tablet would no longer properly light up after reboot.
> > >
> > > The backlight still turns back on after reboot, but the LCD shows an
> > > all black display. The display is also all black during the time that
> > > EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
> > >
> > > In this scenario the panel is initialized so that it appears to be working
> > > and the fastboot code skips doing a modeset. Forcing a modeset by doing a
> > > chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> > > /sys/class/graphics/fb0/blank causes the panel to work again.
> > >
> > > Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> > > a no-op when set; and set this on vlv/chv devices when a DSI panel is
> > > detected, to work around this.
> > >
> > > Admittedly this is a bit of a big hammer, but these platforms have been
> > > around for quite some time now and they have always worked fine without
> > > the new behavior to shutdown everything on shutdown/reboot. This approach
> > > simply disables the recently introduced new shutdown behavior in this
> > > specific case where it is known to cause problems. Which is a nice and
> > > simple way to deal with this.
> > >
> > > Signed-off-by: Hans de Goede
> >
> > Ping? Since sending this patch I've been seeing the issue addressed by
> > this on variour other CHT based devices too.
> >
> > So we have various devices suffering from a black screen after reboot
> > now. This is pretty serious usability regression.
> >
> > As such it would be good to get this reviewed, or another fix proposed.
>
> For the quirks we try to limit them to very specific vendor and model ids,
> so I wonder if it would be possible to get this information in here instead
> to all the vlv with dsi...
>
> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>
> Jani?
> Ville?
We need to figure out why the panel doesn't start up again. If it has
problems with this then surely it also fails if we just happen to reboot
with the panel already off?
Oh a modeset fixes it? Then I guess it's just fastboot fail due to DSI
code being crap? If no one is willing to fix it then I guess we just
need to disable fastboot for DSI somehow.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used
On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/1/21 4:43 PM, Hans de Goede wrote:
> > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> > displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> > Predia Basic tablet would no longer properly light up after reboot.
> >
> > The backlight still turns back on after reboot, but the LCD shows an
> > all black display. The display is also all black during the time that
> > EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
> >
> > In this scenario the panel is initialized so that it appears to be working
> > and the fastboot code skips doing a modeset. Forcing a modeset by doing a
> > chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> > /sys/class/graphics/fb0/blank causes the panel to work again.
> >
> > Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> > a no-op when set; and set this on vlv/chv devices when a DSI panel is
> > detected, to work around this.
> >
> > Admittedly this is a bit of a big hammer, but these platforms have been
> > around for quite some time now and they have always worked fine without
> > the new behavior to shutdown everything on shutdown/reboot. This approach
> > simply disables the recently introduced new shutdown behavior in this
> > specific case where it is known to cause problems. Which is a nice and
> > simple way to deal with this.
> >
> > Signed-off-by: Hans de Goede
>
> Ping? Since sending this patch I've been seeing the issue addressed by
> this on variour other CHT based devices too.
>
> So we have various devices suffering from a black screen after reboot
> now. This is pretty serious usability regression.
>
> As such it would be good to get this reviewed, or another fix proposed.
For the quirks we try to limit them to very specific vendor and model ids,
so I wonder if it would be possible to get this information in here instead
to all the vlv with dsi...
Or avoid the quirk "infra" and skip to all vlv with active dsi?!
Jani?
Ville?
>
> Regards,
>
> Hans
>
>
>
> > ---
> > drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +++
> > drivers/gpu/drm/i915/i915_drv.c| 3 +++
> > drivers/gpu/drm/i915/i915_drv.h| 1 +
> > 3 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> > b/drivers/gpu/drm/i915/display/vlv_dsi.c
> > index f94025ec603a..792ef868b6af 100644
> > --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> > @@ -1949,6 +1949,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
> >
> > vlv_dsi_add_properties(intel_connector);
> >
> > + /* Some BIOS-es fail to re-init the DSI panel on reboot if we turn it
> > off */
> > + dev_priv->quirks |= QUIRK_SKIP_SHUTDOWN;
> > +
> > return;
> >
> > err_cleanup_connector:
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 8e9cb44e66e5..92f2af55af6d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1048,6 +1048,9 @@ static void intel_shutdown_encoders(struct
> > drm_i915_private *dev_priv)
> >
> > void i915_driver_shutdown(struct drm_i915_private *i915)
> > {
> > + if (i915->quirks & QUIRK_SKIP_SHUTDOWN)
> > + return;
> > +
> > disable_rpm_wakeref_asserts(>runtime_pm);
> >
> > i915_gem_suspend(i915);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 26d69d06aa6d..272cd7cb22d4 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -517,6 +517,7 @@ struct i915_psr {
> > #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > #define QUIRK_INCREASE_T12_DELAY (1<<6)
> > #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > +#define QUIRK_SKIP_SHUTDOWN (1<<8)
> >
> > struct intel_fbdev;
> > struct intel_fbc_work;
> >
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc-11 warns about using string operations on pointers that are
> defined at compile time as offsets from a NULL pointer. Unfortunately
> that also happens on the result of fix_to_virt(), which is a
> compile-time constant for a constantn input:
>
> arch/x86/kernel/tboot.c: In function 'tboot_probe':
> arch/x86/kernel/tboot.c:70:13: error: '__builtin_memcmp_eq' specified bound
> 16 exceeds source size 0 [-Werror=stringop-overread]
>70 | if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
> | ^~
>
> I hope this can get addressed in gcc-11 before the release.
>
> As a workaround, split up the tboot_probe() function in two halves
> to separate the pointer generation from the usage. This is a bit
> ugly, and hopefully gcc understands that the code is actually correct
> before it learns to peek into the noinline function.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> Signed-off-by: Arnd Bergmann
> ---
> arch/x86/kernel/tboot.c | 44 -
> 1 file changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
> index 4c09ba110204..f9af561c3cd4 100644
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -49,6 +49,30 @@ bool tboot_enabled(void)
> return tboot != NULL;
> }
>
> +/* noinline to prevent gcc from warning about dereferencing constant fixaddr
> */
> +static noinline __init bool check_tboot_version(void)
> +{
> + if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
> + pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
> + return false;
> + }
> +
> + if (tboot->version < 5) {
> + pr_warn("tboot version is invalid: %u\n", tboot->version);
> + return false;
> + }
> +
> + pr_info("found shared page at phys addr 0x%llx:\n",
> + boot_params.tboot_addr);
> + pr_debug("version: %d\n", tboot->version);
> + pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
> + pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
> + pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
> + pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
> +
> + return true;
> +}
> +
> void __init tboot_probe(void)
> {
> /* Look for valid page-aligned address for shared page. */
> @@ -66,25 +90,9 @@ void __init tboot_probe(void)
>
> /* Map and check for tboot UUID. */
> set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
> - tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
> - if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
> - pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
> + tboot = (void *)fix_to_virt(FIX_TBOOT_BASE);
> + if (!check_tboot_version())
> tboot = NULL;
> - return;
> - }
> - if (tboot->version < 5) {
> - pr_warn("tboot version is invalid: %u\n", tboot->version);
> - tboot = NULL;
> - return;
> - }
> -
> - pr_info("found shared page at phys addr 0x%llx:\n",
> - boot_params.tboot_addr);
> - pr_debug("version: %d\n", tboot->version);
> - pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
> - pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
> - pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
> - pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
This is indeed rather ugly - and the other patch that removes a debug
check seems counterproductive as well.
Do we know how many genuine bugs -Wstringop-overread-warning has
caught or is about to catch?
I.e. the real workaround might be to turn off the -Wstringop-overread-warning,
until GCC-11 gets fixed?
Thanks,
Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
On Mon 22-03-21 14:05:48, Matthew Wilcox wrote:
> On Mon, Mar 22, 2021 at 02:49:27PM +0100, Daniel Vetter wrote:
> > On Sun, Mar 21, 2021 at 03:18:28PM +0100, Christian König wrote:
> > > Am 20.03.21 um 14:17 schrieb Daniel Vetter:
> > > > On Sat, Mar 20, 2021 at 10:04 AM Christian König
> > > > wrote:
> > > > > Am 19.03.21 um 20:06 schrieb Daniel Vetter:
> > > > > > On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian König wrote:
> > > > > > > Am 19.03.21 um 18:52 schrieb Daniel Vetter:
> > > > > > > > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
> > > > > > > > > Don't print a warning when we fail to allocate a page for
> > > > > > > > > swapping things out.
> > > > > > > > >
> > > > > > > > > Also rely on memalloc_nofs_save/memalloc_nofs_restore instead
> > > > > > > > > of GFP_NOFS.
> > > > > > > > Uh this part doesn't make sense. Especially since you only do
> > > > > > > > it for the
> > > > > > > > debugfs file, not in general. Which means you've just
> > > > > > > > completely broken
> > > > > > > > the shrinker.
> > > > > > > Are you sure? My impression is that GFP_NOFS should now work much
> > > > > > > more out
> > > > > > > of the box with the memalloc_nofs_save()/memalloc_nofs_restore().
> > > > > > Yeah, if you'd put it in the right place :-)
> > > > > >
> > > > > > But also -mm folks are very clear that memalloc_no*() family is for
> > > > > > dire
> > > > > > situation where there's really no other way out. For anything where
> > > > > > you
> > > > > > know what you're doing, you really should use explicit gfp flags.
> > > > > My impression is just the other way around. You should try to avoid
> > > > > the
> > > > > NOFS/NOIO flags and use the memalloc_no* approach instead.
> > > > Where did you get that idea?
> > >
> > > Well from the kernel comment on GFP_NOFS:
> > >
> > > * %GFP_NOFS will use direct reclaim but will not use any filesystem
> > > interfaces.
> > > * Please try to avoid using this flag directly and instead use
> > > * memalloc_nofs_{save,restore} to mark the whole scope which
> > > cannot/shouldn't
> > > * recurse into the FS layer with a short explanation why. All allocation
> > > * requests will inherit GFP_NOFS implicitly.
> >
> > Huh that's interesting, since iirc Willy or Dave told me the opposite, and
> > the memalloc_no* stuff is for e.g. nfs calling into network layer (needs
> > GFP_NOFS) or swap on top of a filesystems (even needs GFP_NOIO I think).
> >
> > Adding them, maybe I got confused.
>
> My impression is that the scoped API is preferred these days.
>
> https://www.kernel.org/doc/html/latest/core-api/gfp_mask-from-fs-io.html
>
> I'd probably need to spend a few months learning the DRM subsystem to
> have a more detailed opinion on whether passing GFP flags around explicitly
> or using the scope API is the better approach for your situation.
yes, in an ideal world we would have a clearly defined scope of the
reclaim recursion wrt FS/IO associated with it. I've got back to
https://lore.kernel.org/amd-gfx/20210319140857.2262-1-christian.koe...@amd.com/
and there are two things standing out. Why does ttm_tt_debugfs_shrink_show
really require NOFS semantic? And why does it play with
fs_reclaim_acquire?
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: mmp: Few typo fixes
On 3/22/21 6:02 AM, Bhaskar Chowdhury wrote:
>
> s/configed/configured/
> s/registed/registered/
> s/defintions/definitions/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> include/video/mmp_disp.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/video/mmp_disp.h b/include/video/mmp_disp.h
> index 77252cb46361..ea8b4331b7a1 100644
> --- a/include/video/mmp_disp.h
> +++ b/include/video/mmp_disp.h
> @@ -172,7 +172,7 @@ struct mmp_panel {
> /* use node to register to list */
> struct list_head node;
> const char *name;
> - /* path name used to connect to proper path configed */
> + /* path name used to connect to proper path configured */
> const char *plat_path_name;
> struct device *dev;
> int panel_type;
> @@ -291,7 +291,7 @@ static inline int mmp_overlay_set_addr(struct mmp_overlay
> *overlay,
> * it defined a common interface that plat driver need to implement
> */
> struct mmp_path_info {
> - /* driver data, set when registed*/
> + /* driver data, set when registered*/
> const char *name;
> struct device *dev;
> int id;
> @@ -309,7 +309,7 @@ extern void mmp_unregister_path(struct mmp_path *path);
> extern void mmp_register_panel(struct mmp_panel *panel);
> extern void mmp_unregister_panel(struct mmp_panel *panel);
>
> -/* defintions for platform data */
> +/* definitions for platform data */
> /* interface for buffer driver */
> struct mmp_buffer_driver_mach_info {
> const char *name;
> --
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
Am 22.03.21 um 18:02 schrieb Daniel Vetter:
On Mon, Mar 22, 2021 at 5:06 PM Michal Hocko wrote:
On Mon 22-03-21 14:05:48, Matthew Wilcox wrote:
On Mon, Mar 22, 2021 at 02:49:27PM +0100, Daniel Vetter wrote:
On Sun, Mar 21, 2021 at 03:18:28PM +0100, Christian König wrote:
Am 20.03.21 um 14:17 schrieb Daniel Vetter:
On Sat, Mar 20, 2021 at 10:04 AM Christian König
wrote:
Am 19.03.21 um 20:06 schrieb Daniel Vetter:
On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian König wrote:
Am 19.03.21 um 18:52 schrieb Daniel Vetter:
On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König wrote:
Don't print a warning when we fail to allocate a page for swapping things out.
Also rely on memalloc_nofs_save/memalloc_nofs_restore instead of GFP_NOFS.
Uh this part doesn't make sense. Especially since you only do it for the
debugfs file, not in general. Which means you've just completely broken
the shrinker.
Are you sure? My impression is that GFP_NOFS should now work much more out
of the box with the memalloc_nofs_save()/memalloc_nofs_restore().
Yeah, if you'd put it in the right place :-)
But also -mm folks are very clear that memalloc_no*() family is for dire
situation where there's really no other way out. For anything where you
know what you're doing, you really should use explicit gfp flags.
My impression is just the other way around. You should try to avoid the
NOFS/NOIO flags and use the memalloc_no* approach instead.
Where did you get that idea?
Well from the kernel comment on GFP_NOFS:
* %GFP_NOFS will use direct reclaim but will not use any filesystem
interfaces.
* Please try to avoid using this flag directly and instead use
* memalloc_nofs_{save,restore} to mark the whole scope which
cannot/shouldn't
* recurse into the FS layer with a short explanation why. All allocation
* requests will inherit GFP_NOFS implicitly.
Huh that's interesting, since iirc Willy or Dave told me the opposite, and
the memalloc_no* stuff is for e.g. nfs calling into network layer (needs
GFP_NOFS) or swap on top of a filesystems (even needs GFP_NOIO I think).
Adding them, maybe I got confused.
My impression is that the scoped API is preferred these days.
https://www.kernel.org/doc/html/latest/core-api/gfp_mask-from-fs-io.html
I'd probably need to spend a few months learning the DRM subsystem to
have a more detailed opinion on whether passing GFP flags around explicitly
or using the scope API is the better approach for your situation.
yes, in an ideal world we would have a clearly defined scope of the
reclaim recursion wrt FS/IO associated with it. I've got back to
https://lore.kernel.org/amd-gfx/20210319140857.2262-1-christian.koe...@amd.com/
and there are two things standing out. Why does ttm_tt_debugfs_shrink_show
really require NOFS semantic? And why does it play with
fs_reclaim_acquire?
It's our shrinker. shrink_show simply triggers that specific shrinker
asking it to shrink everything it can, which helps a lot with testing
without having to drive the entire system against the OOM wall.
fs_reclaim_acquire is there to make sure lockdep understands that this
is a shrinker and that it checks all the dependencies for us like if
we'd be in real reclaim. There is some drop caches interfaces in proc
iirc, but those drop everything, and they don't have the fs_reclaim
annotations to teach lockdep about what we're doing.
To summarize the debugfs code is basically to test if that stuff really
works with GFP_NOFS.
My only concern is that if I could rely on memalloc_no* being used we
could optimize this quite a bit further.
Regards,
Christian.
-Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj
On Mon, Mar 22, 2021 at 11:59 AM Daniel Vetter wrote:
>
> On Fri, Mar 19, 2021 at 05:38:56PM -0500, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> > that userspace can do itself, trivially. Unfortunately, it's used by
> > the media driver so we can't do that. We can, however, do the next-best
> > thing which is to embed a syncobj in the context and do exactly what
> > we'd expect from userspace internally.
> >
> > This has a couple of advantages. One is that we're no longer leaking a
> > detail of the current execlist scheduler which will be problematic when
> > we try to add GuC scheduling. Second is that, together with deleting
> > the CLONE_CONTEXT API, we should now have a 1:1 mapping between
> > intel_context and intel_timeline which should make some of our locking
> > mess a bit easier.
> >
> > Signed-off-by: Jason Ekstrand
> > Cc: Maarten Lankhorst
> > Cc: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 47 ---
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 8 +++-
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
> > 3 files changed, 32 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f88bac19333ec..e094f4a1ca4cd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -67,6 +67,8 @@
> > #include
> > #include
> >
> > +#include
> > +
> > #include "gt/gen6_ppgtt.h"
> > #include "gt/intel_context.h"
> > #include "gt/intel_engine_heartbeat.h"
> > @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context
> > *ce,
> > ce->vm = vm;
> > }
> >
> > - GEM_BUG_ON(ce->timeline);
> > - if (ctx->timeline)
> > - ce->timeline = intel_timeline_get(ctx->timeline);
> > -
> > if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > intel_engine_has_timeslices(ce->engine))
> > __set_bit(CONTEXT_USE_SEMAPHORES, >flags);
> > @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
> > mutex_destroy(>engines_mutex);
> > mutex_destroy(>lut_mutex);
> >
> > - if (ctx->timeline)
> > - intel_timeline_put(ctx->timeline);
> > + if (ctx->syncobj)
> > + drm_syncobj_put(ctx->syncobj);
> >
> > put_pid(ctx->pid);
> > mutex_destroy(>mutex);
> > @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context
> > *ctx,
> > i915_vm_close(vm);
> > }
> >
> > -static void __set_timeline(struct intel_timeline **dst,
> > -struct intel_timeline *src)
> > -{
> > - struct intel_timeline *old = *dst;
> > -
> > - *dst = src ? intel_timeline_get(src) : NULL;
> > -
> > - if (old)
> > - intel_timeline_put(old);
> > -}
> > -
> > -static void __apply_timeline(struct intel_context *ce, void *timeline)
> > -{
> > - __set_timeline(>timeline, timeline);
> > -}
> > -
> > -static void __assign_timeline(struct i915_gem_context *ctx,
> > - struct intel_timeline *timeline)
> > -{
> > - __set_timeline(>timeline, timeline);
> > - context_apply_all(ctx, __apply_timeline, timeline);
> > -}
> > -
> > static struct i915_gem_context *
> > i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> > {
> > struct i915_gem_context *ctx;
> > + int ret;
> >
> > if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> > !HAS_EXECLISTS(i915))
> > @@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private
> > *i915, unsigned int flags)
> > }
> >
> > if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> > - struct intel_timeline *timeline;
> > -
> > - timeline = intel_timeline_create(>gt);
> > - if (IS_ERR(timeline)) {
> > + ret = drm_syncobj_create(>syncobj,
> > + DRM_SYNCOBJ_CREATE_SIGNALED,
> > + NULL);
> > + if (ret) {
> > context_close(ctx);
> > - return ERR_CAST(timeline);
> > + return ERR_PTR(ret);
> > }
> > -
> > - __assign_timeline(ctx, timeline);
> > - intel_timeline_put(timeline);
> > }
> >
> > trace_i915_context_create(ctx);
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > index 676592e27e7d2..8a5fdd163b79d 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > @@ -83,7 +83,13 @@ struct i915_gem_context {
> > struct i915_gem_engines __rcu *engines;
> > struct
Re: [PATCH] drm/msm/dpu: Fix a typo
On 3/21/21 11:27 PM, Bhaskar Chowdhury wrote:
>
> s/struture/structure/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> index 09a3fb3e89f5..bb9ceadeb0bb 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> @@ -343,7 +343,7 @@ enum dpu_3d_blend_mode {
>
> /** struct dpu_format - defines the format configuration which
> * allows DPU HW to correctly fetch and decode the format
> - * @base: base msm_format struture containing fourcc code
> + * @base: base msm_format structure containing fourcc code
> * @fetch_planes: how the color components are packed in pixel format
> * @element: element color ordering
> * @bits: element bit widths
> --
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: Fix a typo
On 3/22/21 5:06 AM, Bhaskar Chowdhury wrote: > > s/poiner/pointer/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > index d6717d6672f7..a448eb039334 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > @@ -258,7 +258,7 @@ void dpu_kms_encoder_enable(struct drm_encoder *encoder); > > /** > * dpu_kms_get_clk_rate() - get the clock rate > - * @dpu_kms: poiner to dpu_kms structure > + * @dpu_kms: pointer to dpu_kms structure > * @clock_name: clock name to get the rate > * > * Return: current clock rate > -- -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/tiny: add driver for newhaven,1.8-128160EF
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
3 files changed, 238 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9163.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa759..9de0c0eeea6f5 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -41,6 +41,19 @@ config TINYDRM_HX8357D
If M is selected the module will be called hx8357d.
+config TINYDRM_ILI9163
+ tristate "DRM support for ILI9163 display panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9163 panels:
+ * NHD-1.8-128160EF 128x160 TFT
+
+ If M is selected the module will be called ili9163.
+
config TINYDRM_ILI9225
tristate "DRM support for ILI9225 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35fb..78016b2ed11b5 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -3,6 +3,7 @@
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
+obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
new file mode 100644
index 0..6fa9e59b69321
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9163_FRMCTR10xb1
+
+#define ILI9163_PWCTRL10xc0
+#define ILI9163_PWCTRL20xc1
+#define ILI9163_VMCTRL10xc5
+#define ILI9163_VMCTRL20xc7
+#define ILI9163_PWCTRLA0xcb
+#define ILI9163_PWCTRLB0xcf
+
+#define ILI9163_EN3GAM 0xf2
+
+#define ILI9163_MADCTL_BGR BIT(3)
+#define ILI9163_MADCTL_MV BIT(5)
+#define ILI9163_MADCTL_MX BIT(6)
+#define ILI9163_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = >dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, ))
+ return;
+
+ drm_dbg_kms(>drm, "\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ /* Gamma */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x04);
+ mipi_dbi_command(dbi, ILI9163_EN3GAM, 0x00);
+
+ /* Frame Rate */
+ mipi_dbi_command(dbi, ILI9163_FRMCTR1, 0x0a, 0x14);
+
+ /* Power Control */
+ mipi_dbi_command(dbi, ILI9163_PWCTRL1, 0x0a, 0x00);
+ mipi_dbi_command(dbi, ILI9163_PWCTRL2, 0x02);
+
+ /* VCOM */
+ mipi_dbi_command(dbi, ILI9163_VMCTRL1, 0x2f, 0x3e);
+ mipi_dbi_command(dbi, ILI9163_VMCTRL2, 0x40);
+
+ /* Memory Access Control */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
MIPI_DCS_PIXEL_FMT_16BIT);
+
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(100);
+
+ mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_ON);
+ msleep(100);
+
+out_enable:
+ switch (dbidev->rotation) {
+ default:
+ addr_mode = 0;
+ break;
+ case 90:
+ addr_mode = ILI9163_MADCTL_MV | ILI9163_MADCTL_MX;
+ break;
+ case 180:
+ addr_mode = ILI9163_MADCTL_MX | ILI9163_MADCTL_MY;
+ break;
+ case 270:
+ addr_mode = ILI9163_MADCTL_MV | ILI9163_MADCTL_MY;
+ break;
+ }
+ addr_mode |= ILI9163_MADCTL_BGR;
+ mipi_dbi_command(dbi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+ mipi_dbi_enable_flush(dbidev, crtc_state, plane_state);
+out_exit:
+ drm_dev_exit(idx);
+}
+
+static const struct drm_simple_display_pipe_funcs ili9163_pipe_funcs = {
+ .enable = yx240qv29_enable,
+ .disable = mipi_dbi_pipe_disable,
+ .update =
[PATCH v4 1/2] dt-bindings: display: add bindings for newhaven, 1.8-128160EF
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../bindings/display/ilitek,ili9163.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ilitek,ili9163.yaml
diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9163.yaml
b/Documentation/devicetree/bindings/display/ilitek,ili9163.yaml
new file mode 100644
index 0..b98c6b871b790
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9163.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ilitek,ili9163.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9163 display panels device tree bindings
+
+maintainers:
+ - Daniel Mack
+
+description:
+ This binding is for display panels using an Ilitek ILI9163 controller in SPI
+ mode.
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - newhaven,1.8-128160EF
+ - ilitek,ili9163
+ - const: ilitek,ili9163
+
+ spi-max-frequency:
+maximum: 3200
+
+ dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+ backlight: true
+ reg: true
+ reset-gpios: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - dc-gpios
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+backlight: backlight {
+compatible = "gpio-backlight";
+gpios = < 22 GPIO_ACTIVE_HIGH>;
+};
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0{
+compatible = "waveshare,rpi-lcd-35", "ilitek,ili9486";
+reg = <0>;
+spi-max-frequency = <3200>;
+dc-gpios = < 24 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 25 GPIO_ACTIVE_HIGH>;
+rotation = <180>;
+backlight = <>;
+};
+};
+
+...
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] gpu: drm: add driver for ili9361 panel
This is v3 of the series. Changelog: v2 -> v3: * Turn Documentation into yaml format v3 -> v4: * Fix reference error in yaml file Daniel Mack (2): dt-bindings: display: add bindings for newhaven,1.8-128160EF drm/tiny: add driver for newhaven,1.8-128160EF .../bindings/display/ilitek,ili9163.yaml | 70 ++ drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9163.c| 224 ++ 4 files changed, 308 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9163.yaml create mode 100644 drivers/gpu/drm/tiny/ili9163.c -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/5] drm: rockchip: add sound support to rk3066 hdmi driver
ping
On 12/6/20 2:33 PM, Johan Jonker wrote:
> From: Zheng Yang
>
> Add sound support to the rk3066 HDMI driver.
>
> The I2S input of the HDMI TX allows transmission of
> DVD-Audio and decoded Dolby Digital
> to A/V Receivers and high-end displays.
> The interface supports 2 to 8 channels audio up to 192 kHz.
> The HDMI TX supports variable word length of
> 16bits to 32bits for I2S audio inputs.(This driver 24bit max)
> There are three I2S input modes supported.(This driver HDMI_I2S only)
> On RK3066/PX2 the HDMI TX audio source is connected to I2S_8CH.
>
> Signed-off-by: Zheng Yang
> Signed-off-by: Johan Jonker
> ---
> drivers/gpu/drm/rockchip/Kconfig | 2 +
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 277
> -
> 2 files changed, 278 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig
> index 310aa1546..4c20445dc 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -11,6 +11,8 @@ config DRM_ROCKCHIP
> select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
> select DRM_RGB if ROCKCHIP_RGB
> select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
> + select SND_SOC_HDMI_CODEC if ROCKCHIP_RK3066_HDMI && SND_SOC
> + select SND_SOC_ROCKCHIP_I2S if ROCKCHIP_RK3066_HDMI && SND_SOC
> help
> Choose this option if you have a Rockchip soc chipset.
> This driver provides kernel mode setting and buffer
> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> index 1c546c3a8..2f8654023 100644
> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> @@ -13,6 +13,8 @@
> #include
> #include
>
> +#include
> +
> #include "rk3066_hdmi.h"
>
> #include "rockchip_drm_drv.h"
> @@ -20,9 +22,16 @@
>
> #define DEFAULT_PLLA_RATE 3000
>
> +struct audio_info {
> + int channels;
> + int sample_rate;
> + int sample_width;
> +};
> +
> struct hdmi_data_info {
> int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
> bool sink_is_hdmi;
> + bool sink_has_audio;
> unsigned int enc_out_format;
> unsigned int colorimetry;
> };
> @@ -54,12 +63,19 @@ struct rk3066_hdmi {
>
> unsigned int tmdsclk;
>
> + struct platform_device *audio_pdev;
> + struct audio_info audio;
> + bool audio_enable;
> +
> struct hdmi_data_info hdmi_data;
> struct drm_display_mode previous_mode;
> };
>
> #define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
>
> +static int
> +rk3066_hdmi_config_audio(struct rk3066_hdmi *hdmi, struct audio_info *audio);
> +
> static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
> {
> return readl_relaxed(hdmi->regs + offset);
> @@ -205,6 +221,23 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi
> *hdmi,
> HDMI_INFOFRAME_AVI, 0, 0, 0);
> }
>
> +static int rk3066_hdmi_config_aai(struct rk3066_hdmi *hdmi,
> + struct audio_info *audio)
> +{
> + union hdmi_infoframe frame;
> + int rc;
> +
> + rc = hdmi_audio_infoframe_init();
> +
> + frame.audio.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
> + frame.audio.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
> + frame.audio.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
> + frame.audio.channels = hdmi->audio.channels;
> +
> + return rk3066_hdmi_upload_frame(hdmi, rc, ,
> + HDMI_INFOFRAME_AAI, 0, 0, 0);
> +}
> +
> static int rk3066_hdmi_config_video_timing(struct rk3066_hdmi *hdmi,
> struct drm_display_mode *mode)
> {
> @@ -353,6 +386,7 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
> hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK,
> HDMI_VIDEO_MODE_HDMI);
> rk3066_hdmi_config_avi(hdmi, mode);
> + rk3066_hdmi_config_audio(hdmi, >audio);
> } else {
> hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK, 0);
> }
> @@ -369,9 +403,20 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
>*/
> rk3066_hdmi_i2c_init(hdmi);
>
> - /* Unmute video output. */
> + /* Unmute video and audio output. */
> hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
> HDMI_VIDEO_AUDIO_DISABLE_MASK, HDMI_AUDIO_DISABLE);
> + if (hdmi->audio_enable) {
> + hdmi_modb(hdmi, HDMI_VIDEO_CTRL2, HDMI_AUDIO_DISABLE, 0);
> + /* Reset audio capture logic. */
> + hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
> + HDMI_AUDIO_CP_LOGIC_RESET_MASK,
> + HDMI_AUDIO_CP_LOGIC_RESET);
> + usleep_range(900, 1000);
> + hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
> + HDMI_AUDIO_CP_LOGIC_RESET_MASK, 0);
Re: [PATCH 03/11] security: commoncap: fix -Wstringop-overread warning
On Mon, Mar 22, 2021 at 05:02:41PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > gcc-11 introdces a harmless warning for cap_inode_getsecurity: > > security/commoncap.c: In function ‘cap_inode_getsecurity’: > security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region > of size 0 [-Werror=stringop-overread] > 440 | memcpy(>data, >data, > sizeof(__le32) * 2 * VFS_CAP_U32); > | > ^~ > > The problem here is that tmpbuf is initialized to NULL, so gcc assumes > it is not accessible unless it gets set by vfs_getxattr_alloc(). This is > a legitimate warning as far as I can tell, but the code is correct since > it correctly handles the error when that function fails. > > Add a separate NULL check to tell gcc about it as well. > > Signed-off-by: Arnd Bergmann > --- Seems reasonable, Acked-by: Christian Brauner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] vfio/pci: remove vfio_pci_nvlink2
On Mon, 22 Mar 2021 16:01:54 +0100
Christoph Hellwig wrote:
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 8ce36c1d53ca11..db7e782419d5d9 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -332,19 +332,6 @@ struct vfio_region_info_cap_type {
> #define VFIO_REGION_SUBTYPE_INTEL_IGD_HOST_CFG (2)
> #define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG(3)
>
> -/* 10de vendor PCI sub-types */
> -/*
> - * NVIDIA GPU NVlink2 RAM is coherent RAM mapped onto the host address space.
> - */
> -#define VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM (1)
> -
> -/* 1014 vendor PCI sub-types */
> -/*
> - * IBM NPU NVlink2 ATSD (Address Translation Shootdown) register of NPU
> - * to do TLB invalidation on a GPU.
> - */
> -#define VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD (1)
> -
> /* sub-types for VFIO_REGION_TYPE_GFX */
> #define VFIO_REGION_SUBTYPE_GFX_EDID(1)
>
> @@ -637,33 +624,6 @@ struct vfio_device_migration_info {
> */
> #define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3
>
> -/*
> - * Capability with compressed real address (aka SSA - small system address)
> - * where GPU RAM is mapped on a system bus. Used by a GPU for DMA routing
> - * and by the userspace to associate a NVLink bridge with a GPU.
> - */
> -#define VFIO_REGION_INFO_CAP_NVLINK2_SSATGT 4
> -
> -struct vfio_region_info_cap_nvlink2_ssatgt {
> - struct vfio_info_cap_header header;
> - __u64 tgt;
> -};
> -
> -/*
> - * Capability with an NVLink link speed. The value is read by
> - * the NVlink2 bridge driver from the bridge's "ibm,nvlink-speed"
> - * property in the device tree. The value is fixed in the hardware
> - * and failing to provide the correct value results in the link
> - * not working with no indication from the driver why.
> - */
> -#define VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD 5
> -
> -struct vfio_region_info_cap_nvlink2_lnkspd {
> - struct vfio_info_cap_header header;
> - __u32 link_speed;
> - __u32 __pad;
> -};
> -
> /**
> * VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
> * struct vfio_irq_info)
I'll leave any attempt to defend keeping this code to Alexey, but
minimally these region sub-types and capability IDs should probably be
reserved to avoid breaking whatever userspace might exist to consume
these. Our ID space is sufficiently large that we don't need to
recycle them any time soon. Thanks,
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/gud: Remove unneeded semicolon
From: kernel test robot
drivers/gpu/drm/gud/gud_connector.c:658:2-3: Unneeded semicolon
drivers/gpu/drm/gud/gud_connector.c:186:2-3: Unneeded semicolon
drivers/gpu/drm/gud/gud_drv.c:511:3-4: Unneeded semicolon
drivers/gpu/drm/gud/gud_pipe.c:127:4-5: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver")
Reported-by: kernel test robot
Signed-off-by: kernel test robot
[fix subject and squash 3 per file patches]
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_connector.c | 4 ++--
drivers/gpu/drm/gud/gud_drv.c | 2 +-
drivers/gpu/drm/gud/gud_pipe.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gud/gud_connector.c
b/drivers/gpu/drm/gud/gud_connector.c
index 9ae5a0020449..ae051133e050 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -183,7 +183,7 @@ static int gud_connector_detect(struct drm_connector
*connector,
default:
ret = connector_status_unknown;
break;
- };
+ }
if (status & GUD_CONNECTOR_STATUS_CHANGED)
connector->epoch_counter += 1;
@@ -655,7 +655,7 @@ static int gud_connector_create(struct gud_device *gdrm,
unsigned int index,
default: /* future types */
connector_type = DRM_MODE_CONNECTOR_USB;
break;
- };
+ }
drm_connector_helper_add(connector, _connector_helper_funcs);
ret = drm_connector_init(drm, connector, _connector_funcs,
connector_type);
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index 727612124dd0..e8b672dc9832 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -508,7 +508,7 @@ static int gud_probe(struct usb_interface *intf, const
struct usb_device_id *id)
case DRM_FORMAT_XRGB:
xrgb_supported = true;
break;
- };
+ }
fmt_buf_size = drm_format_info_min_pitch(info, 0,
drm->mode_config.max_width) *
drm->mode_config.max_height;
diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
index ab96afb94241..2f83ab6b8e61 100644
--- a/drivers/gpu/drm/gud/gud_pipe.c
+++ b/drivers/gpu/drm/gud/gud_pipe.c
@@ -124,7 +124,7 @@ static size_t gud_xrgb_to_color(u8 *dst, const struct
drm_format_info *forma
default:
WARN_ON_ONCE(1);
return len;
- };
+ }
*block |= pix << pixshift;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/gud: fix sizeof use
From: kernel test robot
drivers/gpu/drm/gud/gud_connector.c:710:37-43: ERROR: application of sizeof to
pointer
sizeof when applied to a pointer typed expression gives the size of
the pointer
Generated by: scripts/coccinelle/misc/noderef.cocci
Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver")
Reported-by: kernel test robot
Signed-off-by: kernel test robot
[fix subject]
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gud/gud_connector.c
b/drivers/gpu/drm/gud/gud_connector.c
index ec495dcd6122..9ae5a0020449 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -707,7 +707,7 @@ int gud_get_connectors(struct gud_device *gdrm)
return -ENOMEM;
ret = gud_usb_get(gdrm, GUD_REQ_GET_CONNECTORS, 0,
- descs, GUD_CONNECTORS_MAX_NUM * sizeof(descs));
+ descs, GUD_CONNECTORS_MAX_NUM * sizeof(*descs));
if (ret < 0)
goto free;
if (!ret || ret % sizeof(*descs)) {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: display: add bindings for newhaven, 1.8-128160EF
On Mon, 22 Mar 2021 10:52:22 +0100, Daniel Mack wrote: > This adds documentation for a new ILI9163 based, SPI connected display. > > Signed-off-by: Daniel Mack > --- > .../bindings/display/ilitek,ili9163.yaml | 70 +++ > 1 file changed, 70 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/ilitek,ili9163.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: ./Documentation/devicetree/bindings/display/ilitek,ili9163.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/display/ilitek,ili9163.yaml# /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/ilitek,ili9163.yaml: duplicate '$id' value 'http://devicetree.org/schemas/display/ilitek,ili9486.yaml#' See https://patchwork.ozlabs.org/patch/1456455 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 1/2] backlight: qcom-wled: Fix FSC update issue for WLED5
On Thu, 18 Mar 2021, Kiran Gunda wrote: > Currently, for WLED5, the FSC (Full scale current) setting is not > updated properly due to driver toggling the wrong register after > an FSC update. > > On WLED5 we should only toggle the MOD_SYNC bit after a brightness > update. For an FSC update we need to toggle the SYNC bits instead. > > Fix it by adopting the common wled3_sync_toggle() for WLED5 and > introducing new code to the brightness update path to compensate. > > Signed-off-by: Kiran Gunda > Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/qcom-wled.c | 25 +++-- > 1 file changed, 19 insertions(+), 6 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Restrict sentinel requests further
On Thu, 18 Mar 2021 at 17:04, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > Disallow sentinel requests follow previous sentinels to make request > cancellation work better when faced with a chain of requests which have > all been marked as in error. Could you elaborate some more on why this makes request cancellation work better? > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > index 4c2acb5a6c0a..4b870eca9693 100644 > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c > @@ -896,7 +896,7 @@ static bool can_merge_rq(const struct i915_request *prev, > if (__i915_request_is_complete(next)) > return true; > > - if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) & > + if (unlikely((i915_request_flags(prev) | i915_request_flags(next)) & > (BIT(I915_FENCE_FLAG_NOPREEMPT) | > BIT(I915_FENCE_FLAG_SENTINEL > return false; > -- > 2.27.0 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/44] Add HMM-based SVM memory manager to KFD v2
On Mon, Mar 22, 2021 at 5:07 PM Felix Kuehling wrote: > > Am 2021-03-22 um 10:15 a.m. schrieb Daniel Vetter: > > On Mon, Mar 22, 2021 at 06:58:16AM -0400, Felix Kuehling wrote: > >> Since the last patch series I sent on Jan 6 a lot has changed. Patches 1-33 > >> are the cleaned up, rebased on amd-staging-drm-next 5.11 version from about > >> a week ago. The remaining 11 patches are current work-in-progress with > >> further cleanup and fixes. > >> > >> MMU notifiers and CPU page faults now can split ranges and update our range > >> data structures without taking heavy locks by doing some of the critical > >> work in a deferred work handler. This includes updating MMU notifiers and > >> the SVM range interval tree. In the mean time, new ranges can live as > >> children of their parent ranges until the deferred work handler > >> consolidates > >> them in the main interval tree. > > I'm totally swammped with intel stuff unfortunately, so not really time to > > dig in. Can you give me the spoiler on how the (gfx10+ iirc) page fault > > inversion is planned to be handled now? Or that still tbd? > > Navi is still TBD. This patch series focuses on GFXv9 because that's the > IP our data center GPUs are on. The code here has two modes of > operations, one that relies on page faults and one that relies on > preemptions. The latter should work on Navi just fine. So that's our > minimal fallback option. > > > > > > Other thing I noticed is that amdkfd still uses the mmu_notifier directly, > > and not the mmu_interval_notifier. But you're talking a lot about managing > > intervals here, and so I'm wondering whether we shouldn't do this in core > > code? Everyone will have the same painful locking problems here (well atm > > everyone = you only I think), sharing this imo would make a ton of > > sense. > > We use mmu_interval_notifiers in all the range-based code, including > even our legacy userptr code. The only non-interval notifier that's > still in use in KFD is the one we use for cleanup on process termination. I guess my git grep got wrong, I thought I've only found it in the amdgpu userptr code, not on the amdkfd side of things. Sounds all good. -Daniel > > > > > > I think the other one is moving over more generic pasid code, but I think > > that's going to be less useful here and maybe more a long term project. > > Yes, it's unrelated to this work. > > Regards, > Felix > > > > > > Cheers, Daniel > > > >> We also added proper DMA mapping of system memory pages. > >> > >> Current work in progress is cleaning up all the locking, simplifying our > >> code and data structures and resolving a few known bugs. > >> > >> This series and the corresponding ROCm Thunk and KFDTest changes are also > >> available on gitub: > >> > >> https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/tree/fxkamd/hmm-wip > >> > >> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/tree/fxkamd/hmm-wip > >> > >> An updated Thunk > >> > >> Alex Sierra (10): > >> drm/amdgpu: replace per_device_list by array > >> drm/amdkfd: helper to convert gpu id and idx > >> drm/amdkfd: add xnack enabled flag to kfd_process > >> drm/amdkfd: add ioctl to configure and query xnack retries > >> drm/amdgpu: enable 48-bit IH timestamp counter > >> drm/amdkfd: SVM API call to restore page tables > >> drm/amdkfd: add svm_bo reference for eviction fence > >> drm/amdgpu: add param bit flag to create SVM BOs > >> drm/amdgpu: svm bo enable_signal call condition > >> drm/amdgpu: add svm_bo eviction to enable_signal cb > >> > >> Felix Kuehling (22): > >> drm/amdkfd: map svm range to GPUs > >> drm/amdkfd: svm range eviction and restore > >> drm/amdkfd: validate vram svm range from TTM > >> drm/amdkfd: HMM migrate ram to vram > >> drm/amdkfd: HMM migrate vram to ram > >> drm/amdkfd: invalidate tables on page retry fault > >> drm/amdkfd: page table restore through svm API > >> drm/amdkfd: add svm_bo eviction mechanism support > >> drm/amdkfd: refine migration policy with xnack on > >> drm/amdkfd: add svm range validate timestamp > >> drm/amdkfd: multiple gpu migrate vram to vram > >> drm/amdkfd: Fix dma unmapping > >> drm/amdkfd: Call mutex_destroy > >> drm/amdkfd: Fix spurious restore failures > >> drm/amdkfd: Fix svm_bo_list locking in eviction worker > >> drm/amdkfd: Simplify split_by_granularity > >> drm/amdkfd: Point out several race conditions > >> drm/amdkfd: Return pdd from kfd_process_device_from_gduid > >> drm/amdkfd: Remove broken deferred mapping > >> drm/amdkfd: Allow invalid pages in migration.src > >> drm/amdkfd: Correct locking during migration and mapping > >> drm/amdkfd: Nested locking and invalidation of child ranges > >> > >> Philip Yang (12): > >> drm/amdkfd: add svm ioctl API > >> drm/amdkfd: register svm range > >> drm/amdkfd: add svm ioctl GET_ATTR op > >> drm/amdgpu: add common HMM get pages function > >> drm/amdkfd: validate svm range system memory > >>
Re: [PATCH] drm/ttm: stop warning on TT shrinker failure
On Mon, Mar 22, 2021 at 5:06 PM Michal Hocko wrote:
>
> On Mon 22-03-21 14:05:48, Matthew Wilcox wrote:
> > On Mon, Mar 22, 2021 at 02:49:27PM +0100, Daniel Vetter wrote:
> > > On Sun, Mar 21, 2021 at 03:18:28PM +0100, Christian König wrote:
> > > > Am 20.03.21 um 14:17 schrieb Daniel Vetter:
> > > > > On Sat, Mar 20, 2021 at 10:04 AM Christian König
> > > > > wrote:
> > > > > > Am 19.03.21 um 20:06 schrieb Daniel Vetter:
> > > > > > > On Fri, Mar 19, 2021 at 07:53:48PM +0100, Christian König wrote:
> > > > > > > > Am 19.03.21 um 18:52 schrieb Daniel Vetter:
> > > > > > > > > On Fri, Mar 19, 2021 at 03:08:57PM +0100, Christian König
> > > > > > > > > wrote:
> > > > > > > > > > Don't print a warning when we fail to allocate a page for
> > > > > > > > > > swapping things out.
> > > > > > > > > >
> > > > > > > > > > Also rely on memalloc_nofs_save/memalloc_nofs_restore
> > > > > > > > > > instead of GFP_NOFS.
> > > > > > > > > Uh this part doesn't make sense. Especially since you only do
> > > > > > > > > it for the
> > > > > > > > > debugfs file, not in general. Which means you've just
> > > > > > > > > completely broken
> > > > > > > > > the shrinker.
> > > > > > > > Are you sure? My impression is that GFP_NOFS should now work
> > > > > > > > much more out
> > > > > > > > of the box with the
> > > > > > > > memalloc_nofs_save()/memalloc_nofs_restore().
> > > > > > > Yeah, if you'd put it in the right place :-)
> > > > > > >
> > > > > > > But also -mm folks are very clear that memalloc_no*() family is
> > > > > > > for dire
> > > > > > > situation where there's really no other way out. For anything
> > > > > > > where you
> > > > > > > know what you're doing, you really should use explicit gfp flags.
> > > > > > My impression is just the other way around. You should try to avoid
> > > > > > the
> > > > > > NOFS/NOIO flags and use the memalloc_no* approach instead.
> > > > > Where did you get that idea?
> > > >
> > > > Well from the kernel comment on GFP_NOFS:
> > > >
> > > > * %GFP_NOFS will use direct reclaim but will not use any filesystem
> > > > interfaces.
> > > > * Please try to avoid using this flag directly and instead use
> > > > * memalloc_nofs_{save,restore} to mark the whole scope which
> > > > cannot/shouldn't
> > > > * recurse into the FS layer with a short explanation why. All
> > > > allocation
> > > > * requests will inherit GFP_NOFS implicitly.
> > >
> > > Huh that's interesting, since iirc Willy or Dave told me the opposite, and
> > > the memalloc_no* stuff is for e.g. nfs calling into network layer (needs
> > > GFP_NOFS) or swap on top of a filesystems (even needs GFP_NOIO I think).
> > >
> > > Adding them, maybe I got confused.
> >
> > My impression is that the scoped API is preferred these days.
> >
> > https://www.kernel.org/doc/html/latest/core-api/gfp_mask-from-fs-io.html
> >
> > I'd probably need to spend a few months learning the DRM subsystem to
> > have a more detailed opinion on whether passing GFP flags around explicitly
> > or using the scope API is the better approach for your situation.
>
> yes, in an ideal world we would have a clearly defined scope of the
> reclaim recursion wrt FS/IO associated with it. I've got back to
> https://lore.kernel.org/amd-gfx/20210319140857.2262-1-christian.koe...@amd.com/
> and there are two things standing out. Why does ttm_tt_debugfs_shrink_show
> really require NOFS semantic? And why does it play with
> fs_reclaim_acquire?
It's our shrinker. shrink_show simply triggers that specific shrinker
asking it to shrink everything it can, which helps a lot with testing
without having to drive the entire system against the OOM wall.
fs_reclaim_acquire is there to make sure lockdep understands that this
is a shrinker and that it checks all the dependencies for us like if
we'd be in real reclaim. There is some drop caches interfaces in proc
iirc, but those drop everything, and they don't have the fs_reclaim
annotations to teach lockdep about what we're doing.
-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: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj
On Fri, Mar 19, 2021 at 05:38:56PM -0500, Jason Ekstrand wrote:
> I'd love to delete the SINGLE_TIMELINE API because it leaks an
> implementation detail of contexts through to the API and is something
> that userspace can do itself, trivially. Unfortunately, it's used by
> the media driver so we can't do that. We can, however, do the next-best
> thing which is to embed a syncobj in the context and do exactly what
> we'd expect from userspace internally.
>
> This has a couple of advantages. One is that we're no longer leaking a
> detail of the current execlist scheduler which will be problematic when
> we try to add GuC scheduling. Second is that, together with deleting
> the CLONE_CONTEXT API, we should now have a 1:1 mapping between
> intel_context and intel_timeline which should make some of our locking
> mess a bit easier.
>
> Signed-off-by: Jason Ekstrand
> Cc: Maarten Lankhorst
> Cc: Matthew Brost
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 47 ---
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 8 +++-
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
> 3 files changed, 32 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index f88bac19333ec..e094f4a1ca4cd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -67,6 +67,8 @@
> #include
> #include
>
> +#include
> +
> #include "gt/gen6_ppgtt.h"
> #include "gt/intel_context.h"
> #include "gt/intel_engine_heartbeat.h"
> @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context
> *ce,
> ce->vm = vm;
> }
>
> - GEM_BUG_ON(ce->timeline);
> - if (ctx->timeline)
> - ce->timeline = intel_timeline_get(ctx->timeline);
> -
> if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> intel_engine_has_timeslices(ce->engine))
> __set_bit(CONTEXT_USE_SEMAPHORES, >flags);
> @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
> mutex_destroy(>engines_mutex);
> mutex_destroy(>lut_mutex);
>
> - if (ctx->timeline)
> - intel_timeline_put(ctx->timeline);
> + if (ctx->syncobj)
> + drm_syncobj_put(ctx->syncobj);
>
> put_pid(ctx->pid);
> mutex_destroy(>mutex);
> @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
> i915_vm_close(vm);
> }
>
> -static void __set_timeline(struct intel_timeline **dst,
> -struct intel_timeline *src)
> -{
> - struct intel_timeline *old = *dst;
> -
> - *dst = src ? intel_timeline_get(src) : NULL;
> -
> - if (old)
> - intel_timeline_put(old);
> -}
> -
> -static void __apply_timeline(struct intel_context *ce, void *timeline)
> -{
> - __set_timeline(>timeline, timeline);
> -}
> -
> -static void __assign_timeline(struct i915_gem_context *ctx,
> - struct intel_timeline *timeline)
> -{
> - __set_timeline(>timeline, timeline);
> - context_apply_all(ctx, __apply_timeline, timeline);
> -}
> -
> static struct i915_gem_context *
> i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> {
> struct i915_gem_context *ctx;
> + int ret;
>
> if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> !HAS_EXECLISTS(i915))
> @@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915,
> unsigned int flags)
> }
>
> if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> - struct intel_timeline *timeline;
> -
> - timeline = intel_timeline_create(>gt);
> - if (IS_ERR(timeline)) {
> + ret = drm_syncobj_create(>syncobj,
> + DRM_SYNCOBJ_CREATE_SIGNALED,
> + NULL);
> + if (ret) {
> context_close(ctx);
> - return ERR_CAST(timeline);
> + return ERR_PTR(ret);
> }
> -
> - __assign_timeline(ctx, timeline);
> - intel_timeline_put(timeline);
> }
>
> trace_i915_context_create(ctx);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 676592e27e7d2..8a5fdd163b79d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -83,7 +83,13 @@ struct i915_gem_context {
> struct i915_gem_engines __rcu *engines;
> struct mutex engines_mutex; /* guards writes to engines */
>
> - struct intel_timeline *timeline;
> + /**
> + * @syncobj: Shared timeline syncobj
> + *
> + * When the SHARED_TIMELINE flag is set on context creation, this
> + * provides automatic implicit synchronization
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API
On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin wrote: > > > On 22/03/2021 14:57, Daniel Vetter wrote: > > On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin > > wrote: > >> > >> > >> On 22/03/2021 14:09, Daniel Vetter wrote: > >>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote: > > On 19/03/2021 22:38, Jason Ekstrand wrote: > > This API allows one context to grab bits out of another context upon > > creation. It can be used as a short-cut for setparam(getparam()) for > > things like I915_CONTEXT_PARAM_VM. However, it's never been used by any > > real userspace. It's used by a few IGT tests and that's it. Since it > > doesn't add any real value (most of the stuff you can CLONE you can copy > > in other ways), drop it. > > No complaints to remove if it ended up unused outside IGT. Latter is a > _big_ > problem though, since it is much more that a few IGT tests. So I really > think there really needs to be an evaluation and a plan for that (we > don't > want to lose 50% of the coverage over night). > > > There is one thing that this API allows you to clone which you cannot > > clone via getparam/setparam: timelines. However, timelines are an > > implementation detail of i915 and not really something that needs to be > > Not really true timelines are i915 implementation detail. They are in > fact a > dma-fence context:seqno concept, nothing more that than. I think you are > probably confusing struct intel_timeline with the timeline wording in the > uapi. Former is i915 implementation detail, but context:seqno are truly > userspace timelines. > >>> > >>> I think you're both saying the same thing and talking a bit past each > >>> another. > >>> > >>> Yes the timeline is just a string of dma_fence, that's correct. Now > >>> usually if you submit batches with execbuf, we have 3 ways to synchronize > >>> concurrent submission: implicit sync, sync_file and drm_syncob. They all > >>> map to different needs in different protocols/render apis. > >>> > >>> Now in one additional case the kernel makes sure that batchbuffers are > >>> ordered, and that's when you submit them to the same hw ctx. Because > >>> there's only 1 hw context and you really can't have batchbuffers run on > >>> that single hw context out of order. That's what the timeline object we > >>> talk about here is. But that largely is an internal implementation detail, > >>> which happens to also use most/all the same infrastructure as the > >>> dma_fence uapi pieces above. > >>> > >>> Now the internal implementation detail leaking here is that we exposed > >>> this to userspace, without there being any need for this. What Jason > >>> implements with syncobj in the next patch is essentially what userspace > >>> should have been using for cross-engine sync. media userspace doesn't care > >>> about interop with winsys/client apis, so they equally could have used > >>> implicit sync or sync_file here (which I think is the solution now for the > >>> new uapi prepped internally), since they all are about equally powerful > >>> for stringing batchbuffers together. > >> > >> Are you saying we exposed a single timeline of execution per hw context > >> via the single timeline flag?! > > > > Nope. > > > >> Timelines of execution were always exposed. Any "engine" (ring > >> previously) in I915_EXEC_RING_MASK was a single timeline of execution. > >> It is completely the same with engine map engines, which are also > >> different indices into I915_EXEC_RING_MASK space. > >> > >> Userspace was aware of these timelines forever as well. Media was > >> creating multiple contexts to have multiple timelines (so parallelism). > >> Everyone knew that engine-hopping submissions needs to be either > >> implicitly or explicitly synchronised, etc. > > > > Yup, I think we're saying the same thing here. > > > >> So I really don't see that we have leaked timelines as a concept *now*. > >> What the patch has exposed to userspace is a new way to sync between > >> timelines and nothing more. > > > > We've leaked it as something you can now share across hw context. > > Okay so we agree on most things but apparently have different > definitions of what it means to leak internal implementation details. > > While at the same time proof that we haven't leaked the internal > implementation details is that Jason was able to implement the single > timeline flag with a drm syncobj at the execbuf top level. (Well mostly, > ignoring the probably inconsequential difference of one vs multiple > fence contexts.) It's not a matching implementation. It's only good enough for what media needs, and essentially what media should have done to begin with. There's substantially different behaviour between SINGLE_TIMELINE and what Jason has done here when you race concurrent execbuf calls: Former guarantees total ordering, the latter doesn't even try. They are not
[PATCH] drm/omap: fix misleading indentation in pixinc()
From: Arnd Bergmann
An old patch added a 'return' statement after each BUG() in this driver,
which was necessary at the time, but has become redundant after the BUG()
definition was updated to handle this properly.
gcc-11 now warns about one such instance, where the 'return' statement
was incorrectly indented:
drivers/gpu/drm/omapdrm/dss/dispc.c: In function ‘pixinc’:
drivers/gpu/drm/omapdrm/dss/dispc.c:2093:9: error: this ‘else’ clause does not
guard... [-Werror=misleading-indentation]
2093 | else
| ^~~~
drivers/gpu/drm/omapdrm/dss/dispc.c:2095:17: note: ...this statement, but the
latter is misleadingly indented as if it were guarded by the ‘else’
2095 | return 0;
| ^~
Address this by removing the return again and changing the BUG()
to be unconditional to make this more intuitive.
Fixes: c6eee968d40d ("OMAPDSS: remove compiler warnings when CONFIG_BUG=n")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index f4cbef8ccace..5619420cc2cc 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2090,9 +2090,8 @@ static s32 pixinc(int pixels, u8 ps)
return 1 + (pixels - 1) * ps;
else if (pixels < 0)
return 1 - (-pixels + 1) * ps;
- else
- BUG();
- return 0;
+
+ BUG();
}
static void calc_offset(u16 screen_width, u16 width,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: journada720: fix Wmisleading-indentation warning
From: Arnd Bergmann
With gcc-11, we get a warning about code that looks correct
but badly indented:
drivers/video/backlight/jornada720_bl.c: In function ‘jornada_bl_update_status’:
drivers/video/backlight/jornada720_bl.c:66:11: error: this ‘else’ clause does
not guard... [-Werror=misleading-indentation]
66 | } else /* turn on backlight */
| ^~~~
Change the formatting according to our normal conventions.
Fixes: 13a7b5dc0d17 ("backlight: Adds HP Jornada 700 series backlight driver")
Signed-off-by: Arnd Bergmann
---
drivers/video/backlight/jornada720_bl.c | 44 -
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/video/backlight/jornada720_bl.c
b/drivers/video/backlight/jornada720_bl.c
index 996f7ba3b373..066d0dc98f60 100644
--- a/drivers/video/backlight/jornada720_bl.c
+++ b/drivers/video/backlight/jornada720_bl.c
@@ -66,30 +66,30 @@ static int jornada_bl_update_status(struct backlight_device
*bd)
} else /* turn on backlight */
PPSR |= PPC_LDD1;
- /* send command to our mcu */
- if (jornada_ssp_byte(SETBRIGHTNESS) != TXDUMMY) {
- dev_info(>dev, "failed to set brightness\n");
- ret = -ETIMEDOUT;
- goto out;
- }
+ /* send command to our mcu */
+ if (jornada_ssp_byte(SETBRIGHTNESS) != TXDUMMY) {
+ dev_info(>dev, "failed to set brightness\n");
+ ret = -ETIMEDOUT;
+ goto out;
+ }
- /*
-* at this point we expect that the mcu has accepted
-* our command and is waiting for our new value
-* please note that maximum brightness is 255,
-* but due to physical layout it is equal to 0, so we simply
-* invert the value (MAX VALUE - NEW VALUE).
-*/
- if (jornada_ssp_byte(BL_MAX_BRIGHT - bd->props.brightness)
- != TXDUMMY) {
- dev_err(>dev, "set brightness failed\n");
- ret = -ETIMEDOUT;
- }
+ /*
+* at this point we expect that the mcu has accepted
+* our command and is waiting for our new value
+* please note that maximum brightness is 255,
+* but due to physical layout it is equal to 0, so we simply
+* invert the value (MAX VALUE - NEW VALUE).
+*/
+ if (jornada_ssp_byte(BL_MAX_BRIGHT - bd->props.brightness)
+ != TXDUMMY) {
+ dev_err(>dev, "set brightness failed\n");
+ ret = -ETIMEDOUT;
+ }
- /*
-* If infact we get an TXDUMMY as output we are happy and dont
-* make any further comments about it
-*/
+ /*
+* If infact we get an TXDUMMY as output we are happy and dont
+* make any further comments about it
+*/
out:
jornada_ssp_end();
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 07/10] drm: rcar-du: Provide for_each_group helper
Refactoring of the group control code will soon require more iteration
over the available groups. Simplify this process by introducing a group
iteration helper.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Don't assign __group in the condition part of the for statement of the
for_each_rcdu_group() macro
---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 ++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 02ca2d0e1b55..e792ba7f5145 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -104,6 +104,11 @@ static inline struct rcar_du_device
*to_rcar_du_device(struct drm_device *dev)
return container_of(dev, struct rcar_du_device, ddev);
}
+#define for_each_rcdu_group(__rcdu, __group, __i) \
+ for ((__i) = 0, (__group) = &(__rcdu)->groups[0]; \
+(__i) < DIV_ROUND_UP((__rcdu)->num_crtcs, 2); \
+__i++, __group++)
+
static inline bool rcar_du_has(struct rcar_du_device *rcdu,
unsigned int feature)
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3c10c329c81c..732aac342dab 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -771,9 +771,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
struct drm_device *dev = >ddev;
struct drm_encoder *encoder;
+ struct rcar_du_group *rgrp;
unsigned int dpad0_sources;
unsigned int num_encoders;
- unsigned int num_groups;
unsigned int swindex;
unsigned int hwindex;
unsigned int i;
@@ -820,11 +820,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
return ret;
/* Initialize the groups. */
- num_groups = DIV_ROUND_UP(rcdu->num_crtcs, 2);
-
- for (i = 0; i < num_groups; ++i) {
- struct rcar_du_group *rgrp = >groups[i];
-
+ for_each_rcdu_group(rcdu, rgrp, i) {
mutex_init(>lock);
rgrp->dev = rcdu;
@@ -866,8 +862,6 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
/* Create the CRTCs. */
for (swindex = 0, hwindex = 0; swindex < rcdu->num_crtcs; ++hwindex) {
- struct rcar_du_group *rgrp;
-
/* Skip unpopulated DU channels. */
if (!(rcdu->info->channels_mask & BIT(hwindex)))
continue;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 09/10] drm: rcar-du: Perform group setup from the atomic tail handler
Create rcar_du_group_atomic_check() and rcar_du_group_atomic_setup()
functions to track and apply group state through the DRM atomic state.
The use_count field is moved from the rcar_du_group structure to an
enabled field in the rcar_du_group_state structure.
This allows separating group setup from the configuration of the CRTCs
that are part of the group, simplifying the CRTC code and improving
overall readability. The existing rcar_du_group_{get,put}() functions
are now redundant and removed.
The groups share clocking with the CRTCs within the group, and so are
accessible only when one of its CRTCs has been powered through
rcar_du_crtc_atomic_exit_standby().
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Shorted macro length, and added relevant documentation to its usage
and function.
Changes since v2:
- Simplify error handling in rcar_du_crtc_enable()
- Rename rcar_du_group_atomic_pre_commit() to
rcar_du_group_atomic_setup() and turn it into a void function
- Remove rcar_du_group_atomic_post_commit()
- Replace group state use_count field by enabled
- Rename group state variable from rstate to gstate
Changes since v1:
- All register sequences now maintained.
- Clock management is no longer handled by the group
(_crtc_{exit,enter}_standby handles this for us)
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 18 +
drivers/gpu/drm/rcar-du/rcar_du_group.c | 102
drivers/gpu/drm/rcar-du/rcar_du_group.h | 12 ++-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 ++
4 files changed, 87 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7ca721e6b9d7..020eb75732a7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -528,12 +528,10 @@ static int rcar_du_crtc_exit_standby(struct rcar_du_crtc
*rcrtc)
return ret;
ret = clk_prepare_enable(rcrtc->extclock);
- if (ret < 0)
- goto error_clock;
-
- ret = rcar_du_group_get(rcrtc->group);
- if (ret < 0)
- goto error_group;
+ if (ret < 0) {
+ clk_disable_unprepare(rcrtc->clock);
+ return ret;
+ }
/* Set display off and background to black. */
rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
@@ -543,18 +541,10 @@ static int rcar_du_crtc_exit_standby(struct rcar_du_crtc
*rcrtc)
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
return 0;
-
-error_group:
- clk_disable_unprepare(rcrtc->extclock);
-error_clock:
- clk_disable_unprepare(rcrtc->clock);
- return ret;
}
static void rcar_du_crtc_enter_standby(struct rcar_du_crtc *rcrtc)
{
- rcar_du_group_put(rcrtc->group);
-
clk_disable_unprepare(rcrtc->extclock);
clk_disable_unprepare(rcrtc->clock);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 7c13def703b7..fdd4a60f5f5e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -24,6 +24,7 @@
*/
#include
+#include
#include
#include
@@ -183,38 +184,6 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
mutex_unlock(>lock);
}
-/*
- * rcar_du_group_get - Acquire a reference to the DU channels group
- *
- * Acquiring the first reference setups core registers. A reference must be
held
- * before accessing any hardware registers.
- *
- * This function must be called with the DRM mode_config lock held.
- *
- * Return 0 in case of success or a negative error code otherwise.
- */
-int rcar_du_group_get(struct rcar_du_group *rgrp)
-{
- if (rgrp->use_count)
- goto done;
-
- rcar_du_group_setup(rgrp);
-
-done:
- rgrp->use_count++;
- return 0;
-}
-
-/*
- * rcar_du_group_put - Release a reference to the DU
- *
- * This function must be called with the DRM mode_config lock held.
- */
-void rcar_du_group_put(struct rcar_du_group *rgrp)
-{
- --rgrp->use_count;
-}
-
static void __rcar_du_group_start_stop(struct rcar_du_group *rgrp, bool start)
{
struct rcar_du_device *rcdu = rgrp->dev;
@@ -399,6 +368,34 @@ static const struct drm_private_state_funcs
rcar_du_group_state_funcs = {
.atomic_destroy_state = rcar_du_group_atomic_destroy_state,
};
+/**
+ * for_each_oldnew_group_in_state - iterate over all groups in an atomic update
+ * @__state: drm_atomic_state pointer
+ * @__obj: drm_private_obj iteration cursor
+ * @__old: drm_private_state iteration cursor for the old state
+ * @__new: drm_private_state iteration cursor for the new state
+ * @__i: unsigned int iteration cursor, for macro-internal use
+ *
+ * Iterate over all private objects in an atomic update, processing only those
+ * which represent rcar_du_group_state, tracking both old and new
[PATCH v5 10/10] drm: rcar-du: Centralise routing configuration in commit tail handler
From: Laurent Pinchart
Routing configuration for the DU is complex. Depending on the SoC
generation various routing options are available:
- The VSP to DU routing is not available on Gen1, is configurable on
Gen2 and is fixed on Gen3. When configurable, the routing affects both
CRTC groups but is set in a register of the first CRTC group.
- The DU channel to DPAD output routing is explicitly configurable on
some SoCs of the Gen2 and Gen3 family. When configurable, the DPAD
outputs never offer routing options to CRTCs belonging to different
groups.
- On all SoCs the routing of DU channels to DU pin controllers (internal
output of the DU channels) can be swapped within a group. This feature
is only used on Gen1 to control routing of the DPAD1 output.
Routing is thus handled at the group level, but for Gen2 hardware
requires configuration of the DPAD0 and VSPD1 routing in the first group
even when only the second group is enabled.
Routing at the group level is currently configured when applying CRTC
configuration. Global routing is configured at the same time, and is
additionally configured by the plane setup code to set VSPD1 routing.
This results in code paths that are difficult to follow.
Simplify the routing configuration by performing it all directly, based
on CRTC and CRTC group state. Group-level routing is moved to group
setup as it only depends on the group state and the state of the CRTCs
it contains. Global routing is moved to the commit tail handler, and
based on global DU state.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
Changes since v3:
- s/DPAD1/DPAD0/
- s/VSP1D/VSPD1/
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 -
drivers/gpu/drm/rcar-du/rcar_du_group.c | 156
drivers/gpu/drm/rcar-du/rcar_du_group.h | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 16 +--
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 10 +-
6 files changed, 116 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 020eb75732a7..b5f07fd9c4be 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -747,9 +747,8 @@ int rcar_du_crtc_atomic_modeset(struct drm_device *dev,
!crtc_state->active)
continue;
- /* Configure display timings and output routing. */
+ /* Configure display timings. */
rcar_du_crtc_set_display_timing(rcrtc);
- rcar_du_group_set_routing(rcrtc->group);
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_modeset(rcrtc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index e792ba7f5145..ed0b57722f37 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -95,7 +95,6 @@ struct rcar_du_device {
} props;
unsigned int dpad0_source;
- unsigned int dpad1_source;
unsigned int vspd1_sink;
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index fdd4a60f5f5e..368676507097 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -46,6 +46,10 @@ void rcar_du_group_write(struct rcar_du_group *rgrp, u32
reg, u32 data)
rcar_du_write(rgrp->dev, rgrp->mmio_offset + reg, data);
}
+/*
-
+ * Static Group Setup
+ */
+
static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
{
u32 defr6 = DEFR6_CODE;
@@ -59,37 +63,6 @@ static void rcar_du_group_setup_pins(struct rcar_du_group
*rgrp)
rcar_du_group_write(rgrp, DEFR6, defr6);
}
-static void rcar_du_group_setup_defr8(struct rcar_du_group *rgrp)
-{
- struct rcar_du_device *rcdu = rgrp->dev;
- u32 defr8 = DEFR8_CODE;
-
- if (rcdu->info->gen < 3) {
- defr8 |= DEFR8_DEFE8;
-
- /*
-* On Gen2 the DEFR8 register for the first group also controls
-* RGB output routing to DPAD0 and VSPD1 routing to DU0/1/2 for
-* DU instances that support it.
-*/
- if (rgrp->index == 0) {
- defr8 |= DEFR8_DRGBS_DU(rcdu->dpad0_source);
- if (rgrp->dev->vspd1_sink == 2)
- defr8 |= DEFR8_VSCS;
- }
- } else {
- /*
-* On Gen3 VSPD routing can't be configured, and DPAD routing
-* is set in the group corresponding to the DPAD output (no Gen3
-* SoC has multiple DPAD sources belonging to separate groups).
-*/
- if (rgrp->index == rcdu->dpad0_source / 2)
- defr8
[PATCH v5 06/10] drm: rcar-du: Handle CRTC configuration from commit tail handler
The CRTC mode setting and routing configuration are performed at the
earliest of atomic enable and atomic begin, to ensure that a valid
configuration is applied to the hardware before the CRTC gets enabled
and before planes are setup (the latter being required in particular by
the VSP). This requires the rcar_du_crtc structure to track the CRTC
enabled state.
Simplify the code and remove the manual state tracking by moving CRTC
setup to a new rcar_du_crtc_atomic_modeset() function, called directly
from the commit tail handler. The function iterates over all CRTCs in
the state transaction and performs CRTC mode setting, routing
configuration and VSP configuration.
drm_crtc_vblank_on() has to be called from the atomic begin handler, to
ensure that vertical blanking reporting is enabled before the call to
drm_crtc_vblank_get() in the atomic flush handler. As the
drm_crtc_vblank_on() and drm_crtc_vblank_off() calls don't need to be
balanced this is not an issue. A balanced alternative would have been to
call drm_crtc_vblank_on() and drm_crtc_vblank_off() from the CRTC exit
and enter standby handlers respectively, but
drm_atomic_helper_commit_modeset_disables() complains if
drm_crtc_vblank_off() hasn't been called by the atomic disable handler.
As a result, the vsp1_du_atomic_flush() operation can be called with the
DRM pipeline disabled. Correct operation has been ensured by "media:
vsp1: drm: Don't configure hardware when the pipeline is disabled".
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Deconstruct rcar_du_crtc_setup() completely
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 89 +++---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 +
3 files changed, 42 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 55c0e0259153..7ca721e6b9d7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -519,22 +519,6 @@ static void rcar_du_cmm_setup(struct drm_crtc *crtc)
* Start/Stop and Suspend/Resume
*/
-static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
-{
- /* Configure display timings and output routing */
- rcar_du_crtc_set_display_timing(rcrtc);
- rcar_du_group_set_routing(rcrtc->group);
-
- /* Enable the VSP compositor. */
- if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
- rcar_du_vsp_modeset(rcrtc);
- rcar_du_vsp_enable(rcrtc);
- }
-
- /* Turn vertical blanking interrupt reporting on. */
- drm_crtc_vblank_on(>crtc);
-}
-
static int rcar_du_crtc_exit_standby(struct rcar_du_crtc *rcrtc)
{
int ret;
@@ -575,24 +559,6 @@ static void rcar_du_crtc_enter_standby(struct rcar_du_crtc
*rcrtc)
clk_disable_unprepare(rcrtc->clock);
}
-static void rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
-{
- /*
-* Guard against double-get, as the function is called from both the
-* .atomic_enable() and .atomic_begin() handlers.
-*/
- if (rcrtc->initialized)
- return;
-
- rcar_du_crtc_setup(rcrtc);
- rcrtc->initialized = true;
-}
-
-static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
-{
- rcrtc->initialized = false;
-}
-
static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
{
bool interlaced;
@@ -768,6 +734,40 @@ int rcar_du_crtc_atomic_enter_standby(struct drm_device
*dev,
return 0;
}
+/*
+ * Configure the mode for all CRTCs that require it. For now we only handle
mode
+ * set on the VSP, CRTC configuration will be handled later.
+ */
+int rcar_du_crtc_atomic_modeset(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ unsigned int i;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+
+ /*
+* Skip commits that don't change the mode. We manually skip
+* inactive CRTCs as disabling a CRTC is considered as a mode
+* set by drm_atomic_crtc_needs_modeset().
+*/
+ if (!drm_atomic_crtc_needs_modeset(crtc_state) ||
+ !crtc_state->active)
+ continue;
+
+ /* Configure display timings and output routing. */
+ rcar_du_crtc_set_display_timing(rcrtc);
+ rcar_du_group_set_routing(rcrtc->group);
+
+ if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
+ rcar_du_vsp_modeset(rcrtc);
+ }
+
+ return 0;
+}
+
static void rcar_du_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
@@ -777,8
[PATCH v5 08/10] drm: rcar-du: Create a group state object
Create a new private state object for the DU groups, and move the
initialisation of a group object to a new function rcar_du_group_init().
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Rebase to v5.11
- Fix pointer passing for drm_atomic_private_obj_init()
- Fix checkpatch.pl --strict warning about if (state == NULL)
Changes since v2:
- Call mutex_destroy() when cleaning up the group
- Include mutex.h and slab.h
- Squash "drm: rcar-du: Add rcar_du_get_{old,new}_group_state()"
---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 144
drivers/gpu/drm/rcar-du/rcar_du_group.h | 29 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 27 +
3 files changed, 177 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 88a783ceb3e9..7c13def703b7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -25,6 +25,11 @@
#include
#include
+#include
+
+#include
+#include
+#include
#include "rcar_du_drv.h"
#include "rcar_du_group.h"
@@ -361,3 +366,142 @@ int rcar_du_group_set_routing(struct rcar_du_group *rgrp)
return rcar_du_set_dpad0_vsp1_routing(rgrp->dev);
}
+
+/*
-
+ * Group State Handling
+ */
+
+static struct drm_private_state *
+rcar_du_group_atomic_duplicate_state(struct drm_private_obj *obj)
+{
+ struct rcar_du_group_state *state;
+
+ if (WARN_ON(!obj->state))
+ return NULL;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_private_obj_duplicate_state(obj, >state);
+
+ return >state;
+}
+
+static void rcar_du_group_atomic_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ kfree(to_rcar_group_state(state));
+}
+
+static const struct drm_private_state_funcs rcar_du_group_state_funcs = {
+ .atomic_duplicate_state = rcar_du_group_atomic_duplicate_state,
+ .atomic_destroy_state = rcar_du_group_atomic_destroy_state,
+};
+
+/**
+ * rcar_du_get_old_group_state - get old group state, if it exists
+ * @state: global atomic state object
+ * @rgrp: group to grab
+ *
+ * This function returns the old group state for the given group, or
+ * NULL if the group is not part of the global atomic state.
+ */
+struct rcar_du_group_state *
+rcar_du_get_old_group_state(struct drm_atomic_state *state,
+ struct rcar_du_group *rgrp)
+{
+ struct drm_private_obj *obj = >private;
+ struct drm_private_state *pstate;
+ unsigned int i;
+
+ for (i = 0; i < state->num_private_objs; i++) {
+ if (obj == state->private_objs[i].ptr) {
+ pstate = state->private_objs[i].old_state;
+ return to_rcar_group_state(pstate);
+ }
+ }
+
+ return NULL;
+}
+
+/**
+ * rcar_du_get_new_group_state - get new group state, if it exists
+ * @state: global atomic state object
+ * @rgrp: group to grab
+ *
+ * This function returns the new group state for the given group, or
+ * NULL if the group is not part of the global atomic state.
+ */
+struct rcar_du_group_state *
+rcar_du_get_new_group_state(struct drm_atomic_state *state,
+ struct rcar_du_group *rgrp)
+{
+ struct drm_private_obj *obj = >private;
+ struct drm_private_state *pstate;
+ unsigned int i;
+
+ for (i = 0; i < state->num_private_objs; i++) {
+ if (obj == state->private_objs[i].ptr) {
+ pstate = state->private_objs[i].new_state;
+ return to_rcar_group_state(pstate);
+ }
+ }
+
+ return NULL;
+}
+
+/*
-
+ * Init and Cleanup
+ */
+
+/*
+ * rcar_du_group_init - Initialise and reset a group object
+ *
+ * Return 0 in case of success or a negative error code otherwise.
+ */
+int rcar_du_group_init(struct rcar_du_device *rcdu, struct rcar_du_group *rgrp,
+ unsigned int index)
+{
+ static const unsigned int mmio_offsets[] = {
+ DU0_REG_OFFSET, DU2_REG_OFFSET
+ };
+
+ struct rcar_du_group_state *state;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ drm_atomic_private_obj_init(>ddev, >private, >state,
+ _du_group_state_funcs);
+
+ mutex_init(>lock);
+
+ rgrp->dev = rcdu;
+ rgrp->mmio_offset = mmio_offsets[index];
+ rgrp->index = index;
+ /* Extract the channel mask for this group only. */
+ rgrp->channels_mask = (rcdu->info->channels_mask >> (2 * index))
+
[PATCH v5 04/10] media: vsp1: drm: Remove vsp1_du_setup_lif()
The vsp1_du_setup_lif() function is deprecated, and the users have been
removed. Remove the implementation and the associated configuration
structure.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 46 --
include/media/vsp1.h | 22
2 files changed, 68 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 4132027ead6c..a48986a24c31 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -814,52 +814,6 @@ int vsp1_du_atomic_disable(struct device *dev, unsigned
int pipe_index)
}
EXPORT_SYMBOL_GPL(vsp1_du_atomic_disable);
-/**
- * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
- * @dev: the VSP device
- * @pipe_index: the DRM pipeline index
- * @cfg: the LIF configuration
- *
- * Configure the output part of VSP DRM pipeline for the given frame @cfg.width
- * and @cfg.height. This sets up formats on the BRx source pad, the WPF sink
and
- * source pads, and the LIF sink pad.
- *
- * The @pipe_index argument selects which DRM pipeline to setup. The number of
- * available pipelines depend on the VSP instance.
- *
- * As the media bus code on the blend unit source pad is conditioned by the
- * configuration of its sink 0 pad, we also set up the formats on all blend
unit
- * sinks, even if the configuration will be overwritten later by
- * vsp1_du_setup_rpf(). This ensures that the blend unit configuration is set
to
- * a well defined state.
- *
- * Return 0 on success or a negative error code on failure.
- */
-int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
- const struct vsp1_du_lif_config *cfg)
-{
- struct vsp1_du_modeset_config modes;
- struct vsp1_du_enable_config enable;
- int ret;
-
- if (!cfg)
- return vsp1_du_atomic_disable(dev, pipe_index);
-
- modes.width = cfg->width;
- modes.height = cfg->height;
- modes.interlaced = cfg->interlaced;
-
- ret = vsp1_du_atomic_modeset(dev, pipe_index, );
- if (ret)
- return ret;
-
- enable.callback = cfg->callback;
- enable.callback_data = cfg->callback_data;
-
- return vsp1_du_atomic_enable(dev, pipe_index, );
-}
-EXPORT_SYMBOL_GPL(vsp1_du_setup_lif);
-
/**
* vsp1_du_atomic_begin - Prepare for an atomic update
* @dev: the VSP device
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 253db8029752..a4eda8c9d048 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -20,28 +20,6 @@ int vsp1_du_init(struct device *dev);
#define VSP1_DU_STATUS_COMPLETEBIT(0)
#define VSP1_DU_STATUS_WRITEBACK BIT(1)
-/**
- * struct vsp1_du_lif_config - VSP LIF configuration - Deprecated
- * @width: output frame width
- * @height: output frame height
- * @interlaced: true for interlaced pipelines
- * @callback: frame completion callback function (optional). When a callback
- * is provided, the VSP driver guarantees that it will be called once
- * and only once for each vsp1_du_atomic_flush() call.
- * @callback_data: data to be passed to the frame completion callback
- */
-struct vsp1_du_lif_config {
- unsigned int width;
- unsigned int height;
- bool interlaced;
-
- void (*callback)(void *data, unsigned int status, u32 crc);
- void *callback_data;
-};
-
-int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
- const struct vsp1_du_lif_config *cfg);
-
/**
* struct vsp1_du_modeset_config - VSP display mode configuration
* @width: output frame width
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 05/10] drm: rcar-du: Handle CRTC standby from commit tail handler
Manage the power state, and initial configuration of the CRTC from the
commit tail handler. CRTCs which need to be activated are taken out of
standby, and any deactivated CRTCs are put into standby.
This aims at removing CRTC state tracking from the rcar_du_crtc
structure. The initial configuration of the CRTC background colours and
disabling of all planes is taken out of rcar_du_crtc_setup() and moved
inline into rcar_du_crtc_enable(). rcar_du_crtc_get() and
rcar_du_crtc_put() are kept as they are needed to configure the VSP at
the correct time, this will be addressed in a separate change.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Add more documentation
- Keep rcar_du_crtc_get() and rcar_du_crtc_put()
- Renamed rcar_du_crtc_enable() to rcar_du_crtc_exit_standby() and
rcar_du_crtc_disable() to rcar_du_crtc_enter_standby()
- Reword commit message
Changes since v1:
- Registers sequence confirmed unchanged
- Re-ordered in the series to handle before groups
- Do not merge rcar_du_crtc_setup() (now handled by _crtc_pre_commit)
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 90 --
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 5 ++
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++
3 files changed, 81 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 53838dde2f29..55c0e0259153 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -521,17 +521,10 @@ static void rcar_du_cmm_setup(struct drm_crtc *crtc)
static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
{
- /* Set display off and background to black */
- rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
- rcar_du_crtc_write(rcrtc, BPOR, BPOR_RGB(0, 0, 0));
-
/* Configure display timings and output routing */
rcar_du_crtc_set_display_timing(rcrtc);
rcar_du_group_set_routing(rcrtc->group);
- /* Start with all planes disabled. */
- rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
-
/* Enable the VSP compositor. */
if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
rcar_du_vsp_modeset(rcrtc);
@@ -542,17 +535,10 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
drm_crtc_vblank_on(>crtc);
}
-static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
+static int rcar_du_crtc_exit_standby(struct rcar_du_crtc *rcrtc)
{
int ret;
- /*
-* Guard against double-get, as the function is called from both the
-* .atomic_enable() and .atomic_begin() handlers.
-*/
- if (rcrtc->initialized)
- return 0;
-
ret = clk_prepare_enable(rcrtc->clock);
if (ret < 0)
return ret;
@@ -565,8 +551,12 @@ static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
if (ret < 0)
goto error_group;
- rcar_du_crtc_setup(rcrtc);
- rcrtc->initialized = true;
+ /* Set display off and background to black. */
+ rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
+ rcar_du_crtc_write(rcrtc, BPOR, BPOR_RGB(0, 0, 0));
+
+ /* Start with all planes disabled. */
+ rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
return 0;
@@ -577,13 +567,29 @@ static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
return ret;
}
-static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
+static void rcar_du_crtc_enter_standby(struct rcar_du_crtc *rcrtc)
{
rcar_du_group_put(rcrtc->group);
clk_disable_unprepare(rcrtc->extclock);
clk_disable_unprepare(rcrtc->clock);
+}
+
+static void rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
+{
+ /*
+* Guard against double-get, as the function is called from both the
+* .atomic_enable() and .atomic_begin() handlers.
+*/
+ if (rcrtc->initialized)
+ return;
+
+ rcar_du_crtc_setup(rcrtc);
+ rcrtc->initialized = true;
+}
+static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
+{
rcrtc->initialized = false;
}
@@ -714,6 +720,54 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
+/*
+ * Take all CRTCs that are made active in this commit out of standby.
+ * CRTCs that are deactivated by the commit are untouched and will be
+ * put in standby by rcar_du_crtc_atomic_enter_standby().
+ */
+int rcar_du_crtc_atomic_exit_standby(struct drm_device *dev,
+struct drm_atomic_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ unsigned int i;
+ int ret;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+
+ if
[PATCH v5 03/10] drm: rcar-du: Convert to the new VSP atomic API
The configuration API between the VSP and the DU has been updated to
provide finer grain control over modesetting, and enablement.
Split rcar_du_vsp_enable() into rcar_du_vsp_modeset() and
rcar_du_vsp_enable() accordingly, and update each function to use the
new VSP API.
There are no further users of the deprecated vsp1_du_setup_lif() which
can now be removed.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Minor formatting changes
Changes since v3:
- Minor formatting for checkpatch.pl --strict
- Fix inlinc typo in disabled option code paths.
Reported-by: kernel test robot
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 20 ++--
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 3 +++
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index ea7e39d03545..53838dde2f29 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -533,8 +533,10 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
/* Enable the VSP compositor. */
- if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
+ if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
+ rcar_du_vsp_modeset(rcrtc);
rcar_du_vsp_enable(rcrtc);
+ }
/* Turn vertical blanking interrupt reporting on. */
drm_crtc_vblank_on(>crtc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 23e41c83c875..16bd5bbf7b6c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -47,16 +47,14 @@ static void rcar_du_vsp_complete(void *private, unsigned
int status, u32 crc)
drm_crtc_add_crc_entry(>crtc, false, 0, );
}
-void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
+void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc)
{
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
struct rcar_du_device *rcdu = crtc->dev;
- struct vsp1_du_lif_config cfg = {
+ struct vsp1_du_modeset_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
.interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE,
- .callback = rcar_du_vsp_complete,
- .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
@@ -93,12 +91,22 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
*/
crtc->group->need_restart = true;
- vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, );
+ vsp1_du_atomic_modeset(crtc->vsp->vsp, crtc->vsp_pipe, );
+}
+
+void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
+{
+ struct vsp1_du_enable_config cfg = {
+ .callback = rcar_du_vsp_complete,
+ .callback_data = crtc,
+ };
+
+ vsp1_du_atomic_enable(crtc->vsp->vsp, crtc->vsp_pipe, );
}
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
{
- vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
+ vsp1_du_atomic_disable(crtc->vsp->vsp, crtc->vsp_pipe);
}
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 9b4724159378..82f2ffc9887f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -58,6 +58,7 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
#ifdef CONFIG_DRM_RCAR_VSP
int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
unsigned int crtcs);
+void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc);
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
@@ -73,6 +74,8 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
{
return -ENXIO;
}
+
+static inline void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 02/10] media: vsp1: drm: Don't configure hardware when the pipeline is disabled
From: Laurent Pinchart
The vsp1_du_atomic_flush() function calls vsp1_du_pipeline_configure()
to configure the hardware pipeline. The function is currently guaranteed
to be called with the pipeline enabled, but this will change by future
rework of the DU driver. Guard the hardware configuration to skip it
when the pipeline is disabled. The hardware will be configured the next
time the pipeline gets enabled.
Reviewed-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 13 -
drivers/media/platform/vsp1/vsp1_drm.h | 2 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index b2c98229c0f1..4132027ead6c 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -723,6 +723,8 @@ int vsp1_du_atomic_enable(struct device *dev, unsigned int
pipe_index,
/* Configure all entities in the pipeline. */
vsp1_du_pipeline_configure(pipe);
+ drm_pipe->enabled = true;
+
unlock:
mutex_unlock(>drm->lock);
@@ -799,6 +801,8 @@ int vsp1_du_atomic_disable(struct device *dev, unsigned int
pipe_index)
pipe->brx->pipe = NULL;
pipe->brx = NULL;
+ drm_pipe->enabled = false;
+
mutex_unlock(>drm->lock);
vsp1_dlm_reset(pipe->output->dlm);
@@ -991,7 +995,14 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int
pipe_index,
}
vsp1_du_pipeline_setup_inputs(vsp1, pipe);
- vsp1_du_pipeline_configure(pipe);
+
+ /*
+* We may get called before the pipeline gets enabled, postpone
+* configuration in that case. vsp1_du_pipeline_configure() will be
+* called from vsp1_du_atomic_enable().
+*/
+ if (drm_pipe->enabled)
+ vsp1_du_pipeline_configure(pipe);
done:
mutex_unlock(>drm->lock);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
b/drivers/media/platform/vsp1/vsp1_drm.h
index e85ad4366fbb..d780dafc1324 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -20,6 +20,7 @@
/**
* vsp1_drm_pipeline - State for the API exposed to the DRM driver
* @pipe: the VSP1 pipeline used for display
+ * @enabled: true if the pipeline is enabled
* @width: output display width
* @height: output display height
* @force_brx_release: when set, release the BRx during the next
reconfiguration
@@ -31,6 +32,7 @@
*/
struct vsp1_drm_pipeline {
struct vsp1_pipeline pipe;
+ bool enabled;
unsigned int width;
unsigned int height;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 01/10] media: vsp1: drm: Split vsp1_du_setup_lif()
Break vsp1_du_setup_lif() into components more suited to the DRM Atomic
API. The existing vsp1_du_setup_lif() API call is maintained as it is
still used from the DU.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Minor formatting updates to fix checkpatch.pl --strict
- Spelling correction.
Changes since v2:
- Minor formatting changes
- Fix NULL pointer dereference in vsp1_du_setup_lif()
---
drivers/media/platform/vsp1/vsp1_drm.c | 219 ++---
include/media/vsp1.h | 31 +++-
2 files changed, 187 insertions(+), 63 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 06f74d410973..b2c98229c0f1 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -616,10 +616,10 @@ int vsp1_du_init(struct device *dev)
EXPORT_SYMBOL_GPL(vsp1_du_init);
/**
- * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
+ * vsp1_du_atomic_modeset - Configure the mode as part of an atomic update
* @dev: the VSP device
* @pipe_index: the DRM pipeline index
- * @cfg: the LIF configuration
+ * @cfg: the mode configuration
*
* Configure the output part of VSP DRM pipeline for the given frame @cfg.width
* and @cfg.height. This sets up formats on the BRx source pad, the WPF sink
and
@@ -636,14 +636,12 @@ EXPORT_SYMBOL_GPL(vsp1_du_init);
*
* Return 0 on success or a negative error code on failure.
*/
-int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
- const struct vsp1_du_lif_config *cfg)
+int vsp1_du_atomic_modeset(struct device *dev, unsigned int pipe_index,
+ const struct vsp1_du_modeset_config *cfg)
{
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe;
struct vsp1_pipeline *pipe;
- unsigned long flags;
- unsigned int i;
int ret;
if (pipe_index >= vsp1->info->lif_count)
@@ -652,60 +650,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
pipe_index,
drm_pipe = >drm->pipe[pipe_index];
pipe = _pipe->pipe;
- if (!cfg) {
- struct vsp1_brx *brx;
-
- mutex_lock(>drm->lock);
-
- brx = to_brx(>brx->subdev);
-
- /*
-* NULL configuration means the CRTC is being disabled, stop
-* the pipeline and turn the light off.
-*/
- ret = vsp1_pipeline_stop(pipe);
- if (ret == -ETIMEDOUT)
- dev_err(vsp1->dev, "DRM pipeline stop timeout\n");
-
- for (i = 0; i < ARRAY_SIZE(pipe->inputs); ++i) {
- struct vsp1_rwpf *rpf = pipe->inputs[i];
-
- if (!rpf)
- continue;
-
- /*
-* Remove the RPF from the pipe and the list of BRx
-* inputs.
-*/
- WARN_ON(!rpf->entity.pipe);
- rpf->entity.pipe = NULL;
- list_del(>entity.list_pipe);
- pipe->inputs[i] = NULL;
-
- brx->inputs[rpf->brx_input].rpf = NULL;
- }
-
- drm_pipe->du_complete = NULL;
- pipe->num_inputs = 0;
-
- dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
- __func__, pipe->lif->index,
- BRX_NAME(pipe->brx));
-
- list_del(>brx->list_pipe);
- pipe->brx->pipe = NULL;
- pipe->brx = NULL;
-
- mutex_unlock(>drm->lock);
-
- vsp1_dlm_reset(pipe->output->dlm);
- vsp1_device_put(vsp1);
-
- dev_dbg(vsp1->dev, "%s: pipeline disabled\n", __func__);
-
- return 0;
- }
-
drm_pipe->width = cfg->width;
drm_pipe->height = cfg->height;
pipe->interlaced = cfg->interlaced;
@@ -722,8 +666,43 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
pipe_index,
goto unlock;
ret = vsp1_du_pipeline_setup_output(vsp1, pipe);
- if (ret < 0)
- goto unlock;
+
+unlock:
+ mutex_unlock(>drm->lock);
+
+ return ret;
+}
+
+/**
+ * vsp1_du_atomic_enable - Enable and start a DU pipeline
+ * @dev: the VSP device
+ * @pipe_index: the DRM pipeline index
+ * @cfg: the enablement configuration
+ *
+ * The @pipe_index argument selects which DRM pipeline to enable. The number of
+ * available pipelines depends on the VSP instance.
+ *
+ * The configuration passes a callback function to register notification of
+ * frame completion events.
+ *
+ * Return 0 on success or a negative error code on failure.
+ */
+int vsp1_du_atomic_enable(struct device *dev, unsigned int pipe_index,
+
[PATCH v5 00/10] drm: rcar-du: Rework CRTC and groups for atomic commits
This patch series refactors atomic commit tail handling in the R-Car DU driver to simplify the code flow, and open the door to further optimisations. This iteration rebases the previous work and fixes a bug reported by the build bots. The R-Car DU is a bit of a strange beast, with support for up to four CRTCs that share resources in groups of two CRTCs. Depending on the generation, planes can be shared (on Gen 1 and Gen 2), and output routing configuration is also handled at the group level to some extent. Furthermore, many configuration parameters, especially those related to routing or clock handling, require the whole group to be restarted to take effect, even when the parameter itself affects a single CRTC only. This hardware architecture is difficult to handle properly on the software side, and has resulted in group usage being reference-counted while CRTC usage only tracks the enabled state. Calls are then unbalanced and difficult to trace, especially for the configuration of output routing, and implementation of new shared resources is hindered. This patch series aims at solving this problem. The series starts with 4 patches that touch the API between the DU and VSP drivers. It became apparent that we need to split the configuration of the VSP to allow fine grain control of setting the mode configuration and enabling/disabling of the pipeline. To support the cross-component API, the new interface is added in patch 01/10, including an implementation of vsp1_du_setup_lif() to support the transition. Patch 02/10 prepares for the new call flow that will call the atomic flush handler before enabling the pipeline. The DRM usage is adapted in patch 03/10, before the call is removed entirely in patch 04/10. The next two patches convert CRTC clock handling and initial setup, potentially called from both the CRTC .atomic_begin() and .atomic_enable() operations, to a simpler code flow controlled by the commit tail handler. Patch 05/10 takes the CRTCs out of standby and put them back in standby respectively at the beginning and end of the commit tail handler, based on the CRTC atomic state instead of state information stored in the custom rcar_du_crtc structure. Patch 06/10 then performs a similar change for the CRTC mode setting configuration. Finally, the last four patches introduce a DRM private object for the CRTC groups, along with an associated state. Patch 07/10 adds a helper macro to easily iterate over CRTC groups, and patch 08/10 adds the group private objects and empty states. Patches 09/10 and 10/10 respectively move the group setup and routing configuration under control of the commit tail handler, simplifying the configuration and moving state information from driver structures to state structures. More refactoring is expected, with plane assignment being moved to group states, and group restart being optimised to avoid flickering. Better configuration of pixel clocks could also be implemented on top of this series. The whole series has been tested on Salvator-XS with the DU test suite (http://git.ideasonboard.com/renesas/kms-tests.git). No failure or change in behaviour has been noticed. Kieran Bingham (8): media: vsp1: drm: Split vsp1_du_setup_lif() drm: rcar-du: Convert to the new VSP atomic API media: vsp1: drm: Remove vsp1_du_setup_lif() drm: rcar-du: Handle CRTC standby from commit tail handler drm: rcar-du: Handle CRTC configuration from commit tail handler drm: rcar-du: Provide for_each_group helper drm: rcar-du: Create a group state object drm: rcar-du: Perform group setup from the atomic tail handler Laurent Pinchart (2): media: vsp1: drm: Don't configure hardware when the pipeline is disabled drm: rcar-du: Centralise routing configuration in commit tail handler drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 160 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 9 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 6 +- drivers/gpu/drm/rcar-du/rcar_du_group.c | 390 +++- drivers/gpu/drm/rcar-du/rcar_du_group.h | 44 ++- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 63 ++-- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 10 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 20 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 3 + drivers/media/platform/vsp1/vsp1_drm.c | 188 drivers/media/platform/vsp1/vsp1_drm.h | 2 + include/media/vsp1.h| 25 +- 12 files changed, 644 insertions(+), 276 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
On Mon, Mar 22, 2021 at 5:01 PM Jason Ekstrand wrote:
>
> On Mon, Mar 22, 2021 at 7:01 AM Jani Nikula
> wrote:
> >
> > On Sat, 20 Mar 2021, Jason Ekstrand wrote:
> > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This
> > > API
> >
> > Small nit, I think it would be useful to reference commits with the
> > citation style:
> >
> > 88be76cdafc7 ("drm/i915: Allow userspace to specify ringsize on
> > construction")
>
> Done.
>
> >
> > I use this monster in my .gitconfig:
> >
> > [alias]
> > cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed
> > -e 's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"
>
> Thanks for the tip!
dim script from maintainer-tools has a bunch of these helpers
(andother one is dim fixes for generating Cc: lists) which should work
even without commit rights and all that set up:
https://gitlab.freedesktop.org/drm/maintainer-tools/-/blob/master/dim
Cheers, Daniel
>
> > With that, 'git cite ' will give you the nice reference with
> > 12 chars of sha1 regardless of core.abbrev config.
> >
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> ___
> 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: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API
Ugh... timezones. On Mon, Mar 22, 2021 at 10:31 AM Tvrtko Ursulin wrote: > > > On 22/03/2021 14:57, Daniel Vetter wrote: > > On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin > > wrote: > >> > >> > >> On 22/03/2021 14:09, Daniel Vetter wrote: > >>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote: > > On 19/03/2021 22:38, Jason Ekstrand wrote: > > This API allows one context to grab bits out of another context upon > > creation. It can be used as a short-cut for setparam(getparam()) for > > things like I915_CONTEXT_PARAM_VM. However, it's never been used by any > > real userspace. It's used by a few IGT tests and that's it. Since it > > doesn't add any real value (most of the stuff you can CLONE you can copy > > in other ways), drop it. > > No complaints to remove if it ended up unused outside IGT. Latter is a > _big_ > problem though, since it is much more that a few IGT tests. So I really > think there really needs to be an evaluation and a plan for that (we > don't > want to lose 50% of the coverage over night). You should look at my IGT patch set. I'm not deleting any tests except those that explicitly test the clone API. All the other tests which use cloning to save a few lines when constructing new contexts are updated to not require the cloning API. > > There is one thing that this API allows you to clone which you cannot > > clone via getparam/setparam: timelines. However, timelines are an > > implementation detail of i915 and not really something that needs to be > > Not really true timelines are i915 implementation detail. They are in > fact a > dma-fence context:seqno concept, nothing more that than. I think you are > probably confusing struct intel_timeline with the timeline wording in the > uapi. Former is i915 implementation detail, but context:seqno are truly > userspace timelines. > >>> > >>> I think you're both saying the same thing and talking a bit past each > >>> another. > >>> > >>> Yes the timeline is just a string of dma_fence, that's correct. Now > >>> usually if you submit batches with execbuf, we have 3 ways to synchronize > >>> concurrent submission: implicit sync, sync_file and drm_syncob. They all > >>> map to different needs in different protocols/render apis. Right. We've always had the concept that everything submitted to given HW context happens in-order. As Daniel said below, allowing out-of-order execution on a single HW context would be a bit nuts because HW contexts are, by definition, stateful. What this API adds is a way to do in-order synchronization across multiple HW contexts which is both new and unnecessary given the other primitives available. > >>> Now in one additional case the kernel makes sure that batchbuffers are > >>> ordered, and that's when you submit them to the same hw ctx. Because > >>> there's only 1 hw context and you really can't have batchbuffers run on > >>> that single hw context out of order. That's what the timeline object we > >>> talk about here is. But that largely is an internal implementation detail, > >>> which happens to also use most/all the same infrastructure as the > >>> dma_fence uapi pieces above. > >>> > >>> Now the internal implementation detail leaking here is that we exposed > >>> this to userspace, without there being any need for this. What Jason > >>> implements with syncobj in the next patch is essentially what userspace > >>> should have been using for cross-engine sync. media userspace doesn't care > >>> about interop with winsys/client apis, so they equally could have used > >>> implicit sync or sync_file here (which I think is the solution now for the > >>> new uapi prepped internally), since they all are about equally powerful > >>> for stringing batchbuffers together. > >> > >> Are you saying we exposed a single timeline of execution per hw context > >> via the single timeline flag?! > > > > Nope. > > > >> Timelines of execution were always exposed. Any "engine" (ring > >> previously) in I915_EXEC_RING_MASK was a single timeline of execution. > >> It is completely the same with engine map engines, which are also > >> different indices into I915_EXEC_RING_MASK space. > >> > >> Userspace was aware of these timelines forever as well. Media was > >> creating multiple contexts to have multiple timelines (so parallelism). > >> Everyone knew that engine-hopping submissions needs to be either > >> implicitly or explicitly synchronised, etc. > > > > Yup, I think we're saying the same thing here. > > > >> So I really don't see that we have leaked timelines as a concept *now*. > >> What the patch has exposed to userspace is a new way to sync between > >> timelines and nothing more. > > > > We've leaked it as something you can now share across hw context. > > Okay so we agree on most things but apparently have different > definitions of what it means to leak internal implementation
Re: [PATCH 2/2] video: backlight: qcom-wled: Add PMI8994 compatible
On Sun, Feb 28, 2021 at 01:41:05PM +0100, Konrad Dybcio wrote:
> Add a compatible for PMI8994 WLED. It uses the V4 of WLED IP.
>
> Signed-off-by: Konrad Dybcio
Reviewed-by: Daniel Thompson
Daniel.
> ---
> drivers/video/backlight/qcom-wled.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
> index 3bc7800eb0a9..497b9035a908 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -1704,6 +1704,7 @@ static int wled_remove(struct platform_device *pdev)
>
> static const struct of_device_id wled_match_table[] = {
> { .compatible = "qcom,pm8941-wled", .data = (void *)3 },
> + { .compatible = "qcom,pmi8994-wled", .data = (void *)4 },
> { .compatible = "qcom,pmi8998-wled", .data = (void *)4 },
> { .compatible = "qcom,pm660l-wled", .data = (void *)4 },
> { .compatible = "qcom,pm8150l-wled", .data = (void *)5 },
> --
> 2.30.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: leds: backlight: qcom-wled: Add PMI8994 compatible
On Sun, Feb 28, 2021 at 01:41:04PM +0100, Konrad Dybcio wrote: > Document the newly added PMI8994 compatible. > > Signed-off-by: Konrad Dybcio (For Lee) Acked-by: Daniel Thompson Daniel. > --- > Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > index 47938e372987..d839e75d9788 100644 > --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > @@ -19,6 +19,7 @@ properties: >compatible: > enum: >- qcom,pm8941-wled > + - qcom,pmi8994-wled >- qcom,pmi8998-wled >- qcom,pm660l-wled >- qcom,pm8150l-wled > -- > 2.30.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj
On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
wrote:
>
>
> On 19/03/2021 22:38, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> > that userspace can do itself, trivially. Unfortunately, it's used by
> > the media driver so we can't do that. We can, however, do the next-best
> > thing which is to embed a syncobj in the context and do exactly what
> > we'd expect from userspace internally.
> >
> > This has a couple of advantages. One is that we're no longer leaking a
> > detail of the current execlist scheduler which will be problematic when
> > we try to add GuC scheduling. Second is that, together with deleting
>
> Narrative needs to be corrected as with the previous patch.
>
> > the CLONE_CONTEXT API, we should now have a 1:1 mapping between
> > intel_context and intel_timeline which should make some of our locking
> > mess a bit easier.
>
> Mess or complexity? Could you expand with some details so it's easier to
> understand? (I am thinking what gets easier, how and why, if this is done.)
Both? I guess "complexity" is a less abrasive way of stating it.
I've not dug into the actual refactor yet but we should be able to
drop the whole RCU business on intel_timeline that we have right now
just to facilitate sharing like this. Fewer objects that are shared
deep inside i915 with their own locks and RCUs seems like an advantage
to me. Especially when we already have nice generic infrastructure
for this.
> >
> > Signed-off-by: Jason Ekstrand
> > Cc: Maarten Lankhorst
> > Cc: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 47 ---
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 8 +++-
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
> > 3 files changed, 32 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f88bac19333ec..e094f4a1ca4cd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -67,6 +67,8 @@
> > #include
> > #include
> >
> > +#include
> > +
> > #include "gt/gen6_ppgtt.h"
> > #include "gt/intel_context.h"
> > #include "gt/intel_engine_heartbeat.h"
> > @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context
> > *ce,
> > ce->vm = vm;
> > }
> >
> > - GEM_BUG_ON(ce->timeline);
> > - if (ctx->timeline)
> > - ce->timeline = intel_timeline_get(ctx->timeline);
> > -
> > if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> > intel_engine_has_timeslices(ce->engine))
> > __set_bit(CONTEXT_USE_SEMAPHORES, >flags);
> > @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
> > mutex_destroy(>engines_mutex);
> > mutex_destroy(>lut_mutex);
> >
> > - if (ctx->timeline)
> > - intel_timeline_put(ctx->timeline);
> > + if (ctx->syncobj)
> > + drm_syncobj_put(ctx->syncobj);
> >
> > put_pid(ctx->pid);
> > mutex_destroy(>mutex);
> > @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context
> > *ctx,
> > i915_vm_close(vm);
> > }
> >
> > -static void __set_timeline(struct intel_timeline **dst,
> > -struct intel_timeline *src)
> > -{
> > - struct intel_timeline *old = *dst;
> > -
> > - *dst = src ? intel_timeline_get(src) : NULL;
> > -
> > - if (old)
> > - intel_timeline_put(old);
> > -}
> > -
> > -static void __apply_timeline(struct intel_context *ce, void *timeline)
> > -{
> > - __set_timeline(>timeline, timeline);
> > -}
> > -
> > -static void __assign_timeline(struct i915_gem_context *ctx,
> > - struct intel_timeline *timeline)
> > -{
> > - __set_timeline(>timeline, timeline);
> > - context_apply_all(ctx, __apply_timeline, timeline);
> > -}
> > -
> > static struct i915_gem_context *
> > i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> > {
> > struct i915_gem_context *ctx;
> > + int ret;
> >
> > if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> > !HAS_EXECLISTS(i915))
> > @@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private
> > *i915, unsigned int flags)
> > }
> >
> > if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
>
> If removal works out I would suggest deprecating the flag starting from
> some future platform. Maybe for GT gen greater than 12 you could already
> start rejecting in order to future proof.
>
> > - struct intel_timeline *timeline;
> > -
> > - timeline = intel_timeline_create(>gt);
> > - if (IS_ERR(timeline)) {
> > + ret = drm_syncobj_create(>syncobj,
> > +
Re: [PATCH 00/44] Add HMM-based SVM memory manager to KFD v2
Am 2021-03-22 um 10:15 a.m. schrieb Daniel Vetter: > On Mon, Mar 22, 2021 at 06:58:16AM -0400, Felix Kuehling wrote: >> Since the last patch series I sent on Jan 6 a lot has changed. Patches 1-33 >> are the cleaned up, rebased on amd-staging-drm-next 5.11 version from about >> a week ago. The remaining 11 patches are current work-in-progress with >> further cleanup and fixes. >> >> MMU notifiers and CPU page faults now can split ranges and update our range >> data structures without taking heavy locks by doing some of the critical >> work in a deferred work handler. This includes updating MMU notifiers and >> the SVM range interval tree. In the mean time, new ranges can live as >> children of their parent ranges until the deferred work handler consolidates >> them in the main interval tree. > I'm totally swammped with intel stuff unfortunately, so not really time to > dig in. Can you give me the spoiler on how the (gfx10+ iirc) page fault > inversion is planned to be handled now? Or that still tbd? Navi is still TBD. This patch series focuses on GFXv9 because that's the IP our data center GPUs are on. The code here has two modes of operations, one that relies on page faults and one that relies on preemptions. The latter should work on Navi just fine. So that's our minimal fallback option. > > Other thing I noticed is that amdkfd still uses the mmu_notifier directly, > and not the mmu_interval_notifier. But you're talking a lot about managing > intervals here, and so I'm wondering whether we shouldn't do this in core > code? Everyone will have the same painful locking problems here (well atm > everyone = you only I think), sharing this imo would make a ton of > sense. We use mmu_interval_notifiers in all the range-based code, including even our legacy userptr code. The only non-interval notifier that's still in use in KFD is the one we use for cleanup on process termination. > > I think the other one is moving over more generic pasid code, but I think > that's going to be less useful here and maybe more a long term project. Yes, it's unrelated to this work. Regards, Felix > > Cheers, Daniel > >> We also added proper DMA mapping of system memory pages. >> >> Current work in progress is cleaning up all the locking, simplifying our >> code and data structures and resolving a few known bugs. >> >> This series and the corresponding ROCm Thunk and KFDTest changes are also >> available on gitub: >> https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/tree/fxkamd/hmm-wip >> >> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/tree/fxkamd/hmm-wip >> >> An updated Thunk >> >> Alex Sierra (10): >> drm/amdgpu: replace per_device_list by array >> drm/amdkfd: helper to convert gpu id and idx >> drm/amdkfd: add xnack enabled flag to kfd_process >> drm/amdkfd: add ioctl to configure and query xnack retries >> drm/amdgpu: enable 48-bit IH timestamp counter >> drm/amdkfd: SVM API call to restore page tables >> drm/amdkfd: add svm_bo reference for eviction fence >> drm/amdgpu: add param bit flag to create SVM BOs >> drm/amdgpu: svm bo enable_signal call condition >> drm/amdgpu: add svm_bo eviction to enable_signal cb >> >> Felix Kuehling (22): >> drm/amdkfd: map svm range to GPUs >> drm/amdkfd: svm range eviction and restore >> drm/amdkfd: validate vram svm range from TTM >> drm/amdkfd: HMM migrate ram to vram >> drm/amdkfd: HMM migrate vram to ram >> drm/amdkfd: invalidate tables on page retry fault >> drm/amdkfd: page table restore through svm API >> drm/amdkfd: add svm_bo eviction mechanism support >> drm/amdkfd: refine migration policy with xnack on >> drm/amdkfd: add svm range validate timestamp >> drm/amdkfd: multiple gpu migrate vram to vram >> drm/amdkfd: Fix dma unmapping >> drm/amdkfd: Call mutex_destroy >> drm/amdkfd: Fix spurious restore failures >> drm/amdkfd: Fix svm_bo_list locking in eviction worker >> drm/amdkfd: Simplify split_by_granularity >> drm/amdkfd: Point out several race conditions >> drm/amdkfd: Return pdd from kfd_process_device_from_gduid >> drm/amdkfd: Remove broken deferred mapping >> drm/amdkfd: Allow invalid pages in migration.src >> drm/amdkfd: Correct locking during migration and mapping >> drm/amdkfd: Nested locking and invalidation of child ranges >> >> Philip Yang (12): >> drm/amdkfd: add svm ioctl API >> drm/amdkfd: register svm range >> drm/amdkfd: add svm ioctl GET_ATTR op >> drm/amdgpu: add common HMM get pages function >> drm/amdkfd: validate svm range system memory >> drm/amdkfd: deregister svm range >> drm/amdgpu: export vm update mapping interface >> drm/amdkfd: register HMM device private zone >> drm/amdkfd: support xgmi same hive mapping >> drm/amdkfd: copy memory through gart table >> drm/amdgpu: reserve fence slot to update page table >> drm/amdkfd: Add SVM API support capability bits >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|4 + >>
[PATCH 11/11] [RFC] drm/i915/dp: fix array overflow warning
From: Arnd Bergmann
gcc-11 warns that intel_dp_check_mst_status() has a local array of
fourteen bytes and passes the last four bytes into a function that
expects a six-byte array:
drivers/gpu/drm/i915/display/intel_dp.c: In function
‘intel_dp_check_mst_status’:
drivers/gpu/drm/i915/display/intel_dp.c:4556:22: error: ‘drm_dp_channel_eq_ok’
reading 6 bytes from a region of size 4 [-Werror=stringop-overread]
4556 | !drm_dp_channel_eq_ok([10],
intel_dp->lane_count)) {
|
^~~~
drivers/gpu/drm/i915/display/intel_dp.c:4556:22: note: referencing argument 1
of type ‘const u8 *’ {aka ‘const unsigned char *’}
In file included from drivers/gpu/drm/i915/display/intel_dp.c:38:
include/drm/drm_dp_helper.h:1459:6: note: in a call to function
‘drm_dp_channel_eq_ok’
1459 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
| ^~~~
Clearly something is wrong here, but I can't quite figure out what.
Changing the array size to 16 bytes avoids the warning, but is
probably the wrong solution here.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8c12d5375607..830e2515f119 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -65,7 +65,7 @@
#include "intel_vdsc.h"
#include "intel_vrr.h"
-#define DP_DPRX_ESI_LEN 14
+#define DP_DPRX_ESI_LEN 16
/* DP DSC throughput values used for slice count calculations KPixels/s */
#define DP_DSC_PEAK_PIXEL_RATE 272
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] drm/i915: avoid stringop-overread warning on pri_latency
From: Arnd Bergmann
gcc-11 warns about what appears to be an out-of-range array access:
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3108:3:
drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’ reading
16 bytes from a region of size 10 [-Werror=stringop-overread]
3057 | intel_print_wm_latency(dev_priv, "Primary",
dev_priv->wm.pri_latency);
|
^
drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
drivers/gpu/drm/i915/intel_pm.c:3057:9: note: referencing argument 3 of type
‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
2994 | static void intel_print_wm_latency(struct drm_i915_private *dev_priv,
| ^~
My guess is that this code is actually safe because the size of the
array depends on the hardware generation, and the function checks for
that, but at the same time I would not expect the compiler to work it
out correctly, and the code seems a little fragile with regards to
future changes. Simply increasing the size of the array should help.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26d69d06aa6d..3567602e0a35 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1095,11 +1095,11 @@ struct drm_i915_private {
* in 0.5us units for WM1+.
*/
/* primary */
- u16 pri_latency[5];
+ u16 pri_latency[8];
/* sprite */
- u16 spr_latency[5];
+ u16 spr_latency[8];
/* cursor */
- u16 cur_latency[5];
+ u16 cur_latency[8];
/*
* Raw watermark memory latency values
* for SKL for all 8 levels
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] scsi: lpfc: fix gcc -Wstringop-overread warning
From: Arnd Bergmann
gcc-11 warns about an strnlen with a length larger than the size of the
passed buffer:
drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_nvme_info_show':
drivers/scsi/lpfc/lpfc_attr.c:518:25: error: 'strnlen' specified bound 4095
exceeds source size 24 [-Werror=stringop-overread]
518 | strnlen(LPFC_NVME_INFO_MORE_STR, PAGE_SIZE - 1)
| ^~~
In this case, the code is entirely valid, as the string is properly
terminated, and the size argument is only there out of extra caution
in case it exceeds a page.
This cannot really happen here, so just simplify it to a sizeof().
Fixes: afff0d2321ea ("scsi: lpfc: Add Buffer overflow check, when nvme_info
larger than PAGE_SIZE")
Signed-off-by: Arnd Bergmann
---
drivers/scsi/lpfc/lpfc_attr.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index bdd9a29f4201..f6d886f9dfb3 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -512,11 +512,9 @@ lpfc_nvme_info_show(struct device *dev, struct
device_attribute *attr,
"6314 Catching potential buffer "
"overflow > PAGE_SIZE = %lu bytes\n",
PAGE_SIZE);
- strlcpy(buf + PAGE_SIZE - 1 -
- strnlen(LPFC_NVME_INFO_MORE_STR, PAGE_SIZE - 1),
+ strlcpy(buf + PAGE_SIZE - 1 - sizeof(LPFC_NVME_INFO_MORE_STR),
LPFC_NVME_INFO_MORE_STR,
- strnlen(LPFC_NVME_INFO_MORE_STR, PAGE_SIZE - 1)
- + 1);
+ sizeof(LPFC_NVME_INFO_MORE_STR) + 1);
}
return len;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/11] atmel: avoid gcc -Wstringop-overflow warning
From: Arnd Bergmann
gcc-11 notices that the fields as defined in the ass_req_format
structure do not match the actual use of that structure:
cc1: error: writing 4 bytes into a region of size between 18446744073709551613
and 2 [-Werror=stringop-overflow=]
drivers/net/wireless/atmel/atmel.c:2884:20: note: at offset [4, 6] into
destination object ‘ap’ of size 6
2884 | u8 ap[ETH_ALEN]; /* nothing after here directly
accessible */
|^~
drivers/net/wireless/atmel/atmel.c:2885:20: note: at offset [4, 6] into
destination object ‘ssid_el_id’ of size 1
2885 | u8 ssid_el_id;
|^~
This is expected here because the actual structure layout is variable.
As the code does not actually access the individual fields, replace
them with a comment and fixed-length array so prevent gcc from
complaining about it.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/atmel/atmel.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/atmel/atmel.c
b/drivers/net/wireless/atmel/atmel.c
index 707fe66727f8..ff9152d600e1 100644
--- a/drivers/net/wireless/atmel/atmel.c
+++ b/drivers/net/wireless/atmel/atmel.c
@@ -2881,13 +2881,18 @@ static void send_association_request(struct
atmel_private *priv, int is_reassoc)
struct ass_req_format {
__le16 capability;
__le16 listen_interval;
- u8 ap[ETH_ALEN]; /* nothing after here directly accessible */
- u8 ssid_el_id;
- u8 ssid_len;
- u8 ssid[MAX_SSID_LENGTH];
- u8 sup_rates_el_id;
- u8 sup_rates_len;
- u8 rates[4];
+ u8 ssid_el[ETH_ALEN + 2 + MAX_SSID_LENGTH + 2 + 4];
+ /*
+* nothing after here directly accessible:
+*
+* u8 ap[ETH_ALEN];
+* u8 ssid_el_id;
+* u8 ssid_len;
+* u8 ssid[MAX_SSID_LENGTH];
+* u8 sup_rates_el_id;
+* u8 sup_rates_len;
+* u8 rates[4];
+*/
} body;
header.frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
@@ -2907,13 +2912,13 @@ static void send_association_request(struct
atmel_private *priv, int is_reassoc)
body.listen_interval = cpu_to_le16(priv->listen_interval *
priv->beacon_period);
+ ssid_el_p = body.ssid_el;
/* current AP address - only in reassoc frame */
if (is_reassoc) {
- memcpy(body.ap, priv->CurrentBSSID, ETH_ALEN);
- ssid_el_p = _el_id;
+ memcpy(ssid_el_p, priv->CurrentBSSID, ETH_ALEN);
+ ssid_el_p += ETH_ALEN;
bodysize = 18 + priv->SSID_size;
} else {
- ssid_el_p = [0];
bodysize = 12 + priv->SSID_size;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] ARM: sharpsl_param: work around -Wstringop-overread warning
From: Arnd Bergmann
gcc warns that accessing a pointer based on a numeric constant may
be an offset into a NULL pointer, and would therefore has zero
accessible bytes:
arch/arm/common/sharpsl_param.c: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.c:43:9: error: ‘memcpy’ reading 64 bytes from a
region of size 0 [-Werror=stringop-overread]
43 | memcpy(_param, param_start(PARAM_BASE), sizeof(struct
sharpsl_param_info));
|
^~
In this particular case, the warning is bogus since this is the actual
pointer, not an offset on a NULL pointer. Add a local variable to shut
up the warning and hope it doesn't come back.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Signed-off-by: Arnd Bergmann
---
arch/arm/common/sharpsl_param.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
index efeb5724d9e9..6237ede2f0c7 100644
--- a/arch/arm/common/sharpsl_param.c
+++ b/arch/arm/common/sharpsl_param.c
@@ -40,7 +40,9 @@ EXPORT_SYMBOL(sharpsl_param);
void sharpsl_save_param(void)
{
- memcpy(_param, param_start(PARAM_BASE), sizeof(struct
sharpsl_param_info));
+ struct sharpsl_param_info *params = param_start(PARAM_BASE);
+
+ memcpy(_param, params, sizeof(*params));
if (sharpsl_param.comadj_keyword != COMADJ_MAGIC)
sharpsl_param.comadj=-1;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/11] cgroup: fix -Wzero-length-bounds warnings
From: Arnd Bergmann
When cgroups are enabled, but every single subsystem is turned off,
CGROUP_SUBSYS_COUNT is zero, and the cgrp->subsys[] array has no
members.
gcc-11 points out that this leads to an invalid access in any function
that might access this array:
kernel/cgroup/cgroup.c: In function 'cgroup_addrm_files':
kernel/cgroup/cgroup.c:460:58: warning: array subscript '' is outside
the bounds of an interior zero-length array 'struct cgroup_subsys_state *[0]'
[-Wzero-length-bounds]
kernel/cgroup/cgroup.c:460:24: note: in expansion of macro
'rcu_dereference_check'
460 | return rcu_dereference_check(cgrp->subsys[ss->id],
|^
In file included from include/linux/cgroup.h:28,
from kernel/cgroup/cgroup-internal.h:5,
from kernel/cgroup/cgroup.c:31:
include/linux/cgroup-defs.h:422:43: note: while referencing 'subsys'
422 | struct cgroup_subsys_state __rcu *subsys[CGROUP_SUBSYS_COUNT];
I'm not sure what is expected to happen for such a configuration,
presumably these functions are never calls in that case. Adding a
sanity check in each function we get the warning for manages to shut
up the warnings and do nothing instead.
Signed-off-by: Arnd Bergmann
---
I'm grouping this together with the -Wstringop-overread warnings,
since the underlying logic in gcc seems to be the same.
---
kernel/cgroup/cgroup.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 9153b20e5cc6..3477f1dc7872 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -456,7 +456,7 @@ static u16 cgroup_ss_mask(struct cgroup *cgrp)
static struct cgroup_subsys_state *cgroup_css(struct cgroup *cgrp,
struct cgroup_subsys *ss)
{
- if (ss)
+ if (ss && (CGROUP_SUBSYS_COUNT > 0))
return rcu_dereference_check(cgrp->subsys[ss->id],
lockdep_is_held(_mutex));
else
@@ -534,6 +534,9 @@ struct cgroup_subsys_state *cgroup_e_css(struct cgroup
*cgrp,
{
struct cgroup_subsys_state *css;
+ if (CGROUP_SUBSYS_COUNT == 0)
+ return NULL;
+
do {
css = cgroup_css(cgrp, ss);
@@ -561,6 +564,9 @@ struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup
*cgrp,
{
struct cgroup_subsys_state *css;
+ if (CGROUP_SUBSYS_COUNT == 0)
+ return NULL;
+
rcu_read_lock();
do {
@@ -630,7 +636,7 @@ struct cgroup_subsys_state *of_css(struct kernfs_open_file
*of)
* the matching css from the cgroup's subsys table is guaranteed to
* be and stay valid until the enclosing operation is complete.
*/
- if (cft->ss)
+ if (cft->ss && CGROUP_SUBSYS_COUNT > 0)
return rcu_dereference_raw(cgrp->subsys[cft->ss->id]);
else
return >self;
@@ -2343,6 +2349,9 @@ struct task_struct *cgroup_taskset_next(struct
cgroup_taskset *tset,
struct css_set *cset = tset->cur_cset;
struct task_struct *task = tset->cur_task;
+ if (CGROUP_SUBSYS_COUNT == 0)
+ return NULL;
+
while (>mg_node != tset->csets) {
if (!task)
task = list_first_entry(>mg_tasks,
@@ -4523,7 +4532,7 @@ void css_task_iter_start(struct cgroup_subsys_state *css,
unsigned int flags,
it->ss = css->ss;
it->flags = flags;
- if (it->ss)
+ if (it->ss && CGROUP_SUBSYS_COUNT > 0)
it->cset_pos = >cgroup->e_csets[css->ss->id];
else
it->cset_pos = >cgroup->cset_links;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/11] qnx: avoid -Wstringop-overread warning
From: Arnd Bergmann
gcc-11 warns that the size of the link name is longer than the di_fname
field:
fs/qnx4/dir.c: In function ‘qnx4_readdir’:
fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds source size 16
[-Werror=stringop-overread]
51 | size = strnlen(de->di_fname, size);
|^~~
In file included from fs/qnx4/qnx4.h:3,
from fs/qnx4/dir.c:16:
include/uapi/linux/qnx4_fs.h:45:25: note: source object declared here
45 | chardi_fname[QNX4_SHORT_NAME_MAX];
The problem here is that we access the same pointer using two different
structure layouts, but gcc determines the object size based on
whatever it encounters first.
Change the strnlen to use the correct field size in each case, and
change the first access to be on the longer field.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Signed-off-by: Arnd Bergmann
---
fs/qnx4/dir.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/qnx4/dir.c b/fs/qnx4/dir.c
index a6ee23aadd28..68046450e543 100644
--- a/fs/qnx4/dir.c
+++ b/fs/qnx4/dir.c
@@ -39,21 +39,20 @@ static int qnx4_readdir(struct file *file, struct
dir_context *ctx)
ix = (ctx->pos >> QNX4_DIR_ENTRY_SIZE_BITS) %
QNX4_INODES_PER_BLOCK;
for (; ix < QNX4_INODES_PER_BLOCK; ix++, ctx->pos +=
QNX4_DIR_ENTRY_SIZE) {
offset = ix * QNX4_DIR_ENTRY_SIZE;
- de = (struct qnx4_inode_entry *) (bh->b_data + offset);
- if (!de->di_fname[0])
+ le = (struct qnx4_link_info *)(bh->b_data + offset);
+ de = (struct qnx4_inode_entry *)(bh->b_data + offset);
+ if (!le->dl_fname[0])
continue;
if (!(de->di_status & (QNX4_FILE_USED|QNX4_FILE_LINK)))
continue;
if (!(de->di_status & QNX4_FILE_LINK))
- size = QNX4_SHORT_NAME_MAX;
+ size = strnlen(de->di_fname,
sizeof(de->di_fname));
else
- size = QNX4_NAME_MAX;
- size = strnlen(de->di_fname, size);
+ size = strnlen(le->dl_fname,
sizeof(le->dl_fname));
QNX4DEBUG((KERN_INFO "qnx4_readdir:%.*s\n", size,
de->di_fname));
if (!(de->di_status & QNX4_FILE_LINK))
ino = blknum * QNX4_INODES_PER_BLOCK + ix - 1;
else {
- le = (struct qnx4_link_info*)de;
ino = ( le32_to_cpu(le->dl_inode_blk) - 1 ) *
QNX4_INODES_PER_BLOCK +
le->dl_inode_ndx;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] ath11: Wstringop-overread warning
From: Arnd Bergmann
gcc-11 with the kernel address sanitizer prints a warning for this
driver:
In function 'ath11k_peer_assoc_h_vht',
inlined from 'ath11k_peer_assoc_prepare' at
drivers/net/wireless/ath/ath11k/mac.c:1632:2:
drivers/net/wireless/ath/ath11k/mac.c:1164:13: error:
'ath11k_peer_assoc_h_vht_masked' reading 16 bytes from a region of size 4
[-Werror=stringop-overread]
1164 | if (ath11k_peer_assoc_h_vht_masked(vht_mcs_mask))
| ^~~~
drivers/net/wireless/ath/ath11k/mac.c: In function 'ath11k_peer_assoc_prepare':
drivers/net/wireless/ath/ath11k/mac.c:1164:13: note: referencing argument 1 of
type 'const u16 *' {aka 'const short unsigned int *'}
drivers/net/wireless/ath/ath11k/mac.c:969:1: note: in a call to function
'ath11k_peer_assoc_h_vht_masked'
969 | ath11k_peer_assoc_h_vht_masked(const u16
vht_mcs_mask[NL80211_VHT_NSS_MAX])
| ^~
According to analysis from gcc developers, this is a glitch in the
way gcc tracks the size of struct members. This should really get
fixed in gcc, but it's also easy to work around this instance
by changing the function prototype to no include the length of
the array.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath11k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c
b/drivers/net/wireless/ath/ath11k/mac.c
index b391169576e2..5cb7ed53f3c4 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -966,7 +966,7 @@ ath11k_peer_assoc_h_ht_masked(const u8
ht_mcs_mask[IEEE80211_HT_MCS_MASK_LEN])
}
static bool
-ath11k_peer_assoc_h_vht_masked(const u16 vht_mcs_mask[NL80211_VHT_NSS_MAX])
+ath11k_peer_assoc_h_vht_masked(const u16 vht_mcs_mask[])
{
int nss;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] security: commoncap: fix -Wstringop-overread warning
From: Arnd Bergmann gcc-11 introdces a harmless warning for cap_inode_getsecurity: security/commoncap.c: In function ‘cap_inode_getsecurity’: security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region of size 0 [-Werror=stringop-overread] 440 | memcpy(>data, >data, sizeof(__le32) * 2 * VFS_CAP_U32); | ^~ The problem here is that tmpbuf is initialized to NULL, so gcc assumes it is not accessible unless it gets set by vfs_getxattr_alloc(). This is a legitimate warning as far as I can tell, but the code is correct since it correctly handles the error when that function fails. Add a separate NULL check to tell gcc about it as well. Signed-off-by: Arnd Bergmann --- security/commoncap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/commoncap.c b/security/commoncap.c index 28f4d25480df..9a36ed6dd737 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -400,7 +400,7 @@ int cap_inode_getsecurity(struct user_namespace *mnt_userns, , size, GFP_NOFS); dput(dentry); - if (ret < 0) + if (ret < 0 || !tmpbuf) return ret; fs_ns = inode->i_sb->s_user_ns; -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning
From: Arnd Bergmann
gcc-11 warns about using string operations on pointers that are
defined at compile time as offsets from a NULL pointer. Unfortunately
that also happens on the result of fix_to_virt(), which is a
compile-time constant for a constantn input:
arch/x86/kernel/tboot.c: In function 'tboot_probe':
arch/x86/kernel/tboot.c:70:13: error: '__builtin_memcmp_eq' specified bound 16
exceeds source size 0 [-Werror=stringop-overread]
70 | if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
| ^~
I hope this can get addressed in gcc-11 before the release.
As a workaround, split up the tboot_probe() function in two halves
to separate the pointer generation from the usage. This is a bit
ugly, and hopefully gcc understands that the code is actually correct
before it learns to peek into the noinline function.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Signed-off-by: Arnd Bergmann
---
arch/x86/kernel/tboot.c | 44 -
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 4c09ba110204..f9af561c3cd4 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -49,6 +49,30 @@ bool tboot_enabled(void)
return tboot != NULL;
}
+/* noinline to prevent gcc from warning about dereferencing constant fixaddr */
+static noinline __init bool check_tboot_version(void)
+{
+ if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
+ pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
+ return false;
+ }
+
+ if (tboot->version < 5) {
+ pr_warn("tboot version is invalid: %u\n", tboot->version);
+ return false;
+ }
+
+ pr_info("found shared page at phys addr 0x%llx:\n",
+ boot_params.tboot_addr);
+ pr_debug("version: %d\n", tboot->version);
+ pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
+ pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
+ pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
+ pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
+
+ return true;
+}
+
void __init tboot_probe(void)
{
/* Look for valid page-aligned address for shared page. */
@@ -66,25 +90,9 @@ void __init tboot_probe(void)
/* Map and check for tboot UUID. */
set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
- tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
- if (memcmp(_uuid, >uuid, sizeof(tboot->uuid))) {
- pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
+ tboot = (void *)fix_to_virt(FIX_TBOOT_BASE);
+ if (!check_tboot_version())
tboot = NULL;
- return;
- }
- if (tboot->version < 5) {
- pr_warn("tboot version is invalid: %u\n", tboot->version);
- tboot = NULL;
- return;
- }
-
- pr_info("found shared page at phys addr 0x%llx:\n",
- boot_params.tboot_addr);
- pr_debug("version: %d\n", tboot->version);
- pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
- pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
- pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
- pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
}
static pgd_t *tboot_pg_dir;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] x86: compressed: avoid gcc-11 -Wstringop-overread warning
From: Arnd Bergmann
gcc gets confused by the comparison of a pointer to an integer listeral,
with the assumption that this is an offset from a NULL pointer and that
dereferencing it is invalid:
In file included from arch/x86/boot/compressed/misc.c:18:
In function ‘parse_elf’,
inlined from ‘extract_kernel’ at arch/x86/boot/compressed/misc.c:442:2:
arch/x86/boot/compressed/../string.h:15:23: error: ‘__builtin_memcpy’ reading
64 bytes from a region of size 0 [-Werror=stringop-overread]
15 | #define memcpy(d,s,l) __builtin_memcpy(d,s,l)
| ^~~
arch/x86/boot/compressed/misc.c:283:9: note: in expansion of macro ‘memcpy’
283 | memcpy(, output, sizeof(ehdr));
| ^~
I could not find any good workaround for this, but as this is only
a warning for a failure during early boot, removing the line entirely
works around the warning.
This should probably get addressed in gcc instead, before 11.1 gets
released.
Signed-off-by: Arnd Bergmann
---
arch/x86/boot/compressed/misc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 3a214cc3239f..9ada64e66cb7 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -430,8 +430,6 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
error("Destination address too large");
#endif
#ifndef CONFIG_RELOCATABLE
- if ((unsigned long)output != LOAD_PHYSICAL_ADDR)
- error("Destination address does not match LOAD_PHYSICAL_ADDR");
if (virt_addr != LOAD_PHYSICAL_ADDR)
error("Destination virtual address changed when not
relocatable");
#endif
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] treewide: address gcc-11 -Wstringop-overread warnings
From: Arnd Bergmann The coming gcc release introduces a new warning for string operations reading beyond the end of a fixed-length object. After testing randconfig kernels for a while, think I have patches for any such warnings that came up on x86, arm and arm64. Most of these warnings are false-positive ones, either gcc warning about something that is entirely correct, or about something that looks suspicious but turns out to be correct after all. The two patches for the i915 driver look like something that might be actual bugs, but I am not sure about those either. We probably want some combination of workaround like the ones I post here and changes to gcc to have fewer false positives in the release. I'm posting the entire set of workaround that give me a cleanly building kernel for reference here. Arnd Arnd Bergmann (11): x86: compressed: avoid gcc-11 -Wstringop-overread warning x86: tboot: avoid Wstringop-overread-warning security: commoncap: fix -Wstringop-overread warning ath11: Wstringop-overread warning qnx: avoid -Wstringop-overread warning cgroup: fix -Wzero-length-bounds warnings ARM: sharpsl_param: work around -Wstringop-overread warning atmel: avoid gcc -Wstringop-overflow warning scsi: lpfc: fix gcc -Wstringop-overread warning drm/i915: avoid stringop-overread warning on pri_latency [RFC] drm/i915/dp: fix array overflow warning arch/arm/common/sharpsl_param.c | 4 ++- arch/x86/boot/compressed/misc.c | 2 -- arch/x86/kernel/tboot.c | 44 +++-- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 6 ++-- drivers/net/wireless/ath/ath11k/mac.c | 2 +- drivers/net/wireless/atmel/atmel.c | 25 -- drivers/scsi/lpfc/lpfc_attr.c | 6 ++-- fs/qnx4/dir.c | 11 +++ kernel/cgroup/cgroup.c | 15 +++-- security/commoncap.c| 2 +- 11 files changed, 69 insertions(+), 50 deletions(-) Cc: x...@kernel.org Cc: Ning Sun Cc: Jani Nikula Cc: Kalle Valo Cc: Simon Kelley Cc: James Smart Cc: "James E.J. Bottomley" Cc: Anders Larsen Cc: Tejun Heo Cc: Serge Hallyn Cc: Imre Deak Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Cc: tboot-de...@lists.sourceforge.net Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: ath...@lists.infradead.org Cc: linux-wirel...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: cgro...@vger.kernel.org Cc: linux-security-mod...@vger.kernel.org -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
On Mon, Mar 22, 2021 at 7:01 AM Jani Nikula wrote:
>
> On Sat, 20 Mar 2021, Jason Ekstrand wrote:
> > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
>
> Small nit, I think it would be useful to reference commits with the
> citation style:
>
> 88be76cdafc7 ("drm/i915: Allow userspace to specify ringsize on construction")
Done.
>
> I use this monster in my .gitconfig:
>
> [alias]
> cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed -e
> 's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"
Thanks for the tip!
> With that, 'git cite ' will give you the nice reference with
> 12 chars of sha1 regardless of core.abbrev config.
>
>
> BR,
> Jani.
>
> --
> 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 v5 01/21] gpu: host1x: Use different lock classes for each client
22.03.2021 18:19, Mikko Perttunen пишет:
> On 22.3.2021 16.48, Dmitry Osipenko wrote:
>> 22.03.2021 17:46, Thierry Reding пишет:
>>> On Mon, Jan 11, 2021 at 02:59:59PM +0200, Mikko Perttunen wrote:
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initialization site by macro.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/bus.c | 7 ---
include/linux/host1x.h | 9 -
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 347fb962b6c9..8fc79e9cb652 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -715,13 +715,14 @@ EXPORT_SYMBOL(host1x_driver_unregister);
* device and call host1x_device_init(), which will in turn call
each client's
* _client_ops.init implementation.
*/
-int host1x_client_register(struct host1x_client *client)
+int __host1x_client_register(struct host1x_client *client,
+ struct lock_class_key *key)
>>>
>>> I've seen the kbuild robot warn about this because the kerneldoc is now
>>> out of date.
>>>
{
struct host1x *host1x;
int err;
INIT_LIST_HEAD(>list);
- mutex_init(>lock);
+ __mutex_init(>lock, "host1x client lock", key);
>>>
>>> Should we maybe attempt to make this unique? Could we use something like
>>> dev_name(client->dev) for this?
>>
>> I'm curious who the lockdep warning could be triggered at all, I don't
>> recall ever seeing it. Mikko, could you please clarify how to reproduce
>> the warning?
>>
>
> This is pretty difficult to read but I guess it's some interaction
> related to the delayed initialization of host1x clients? In any case, I
> consistently get it at boot (though it may be triggered by vic probe
> instead of nvdec).
>
> I'll fix the kbuild robot warnings and see if I can add a
> client-specific lock name for v6.
Thank you for the clarification! We now actually have a similar problem on
Tegra20 after fixing the coupling of display controllers using the
dc1_client->parent=dc0_client and I see the same warning when DC1 is enabled.
[3.808338]
[3.808355] WARNING: possible recursive locking detected
[3.808376] 5.12.0-rc3-next-20210319-00176-g60867e51e180 #7219 Tainted: G
W
[3.808406]
[3.808421] kworker/1:2/108 is trying to acquire lock:
[3.808449] c36b70a4 (>lock){+.+.}-{3:3}, at:
host1x_client_resume+0x17/0x58
[3.808586]
but task is already holding lock:
[3.808603] c34df8a4 (>lock){+.+.}-{3:3}, at:
host1x_client_resume+0x17/0x58
[3.808712]
other info that might help us debug this:
[3.808729] Possible unsafe locking scenario:
[3.808744]CPU0
[3.808757]
[3.808771] lock(>lock);
[3.808810] lock(>lock);
[3.808821]
*** DEADLOCK ***
[3.808825] May be due to missing lock nesting notation
[3.808829] 15 locks held by kworker/1:2/108:
[3.808836] #0: c20068a8 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x15a/0x608
[3.808878] #1: c2bbbf18 (deferred_probe_work){+.+.}-{0:0}, at:
process_one_work+0x15a/0x608
[3.808912] #2: c366d4d8 (>mutex){}-{3:3}, at:
__device_attach+0x29/0xdc
[3.808953] #3: c141a980 (devices_lock){+.+.}-{3:3}, at:
host1x_client_register+0x35/0xfc
[3.808986] #4: c34df64c (>devices_lock){+.+.}-{3:3}, at:
host1x_client_register+0x51/0xfc
[3.809017] #5: c34ed4d8 (>mutex){}-{3:3}, at:
__device_attach+0x29/0xdc
[3.809050] #6: c13faf5c (registration_lock){+.+.}-{3:3}, at:
register_framebuffer+0x2d/0x274
[3.809092] #7: c132566c (console_lock){+.+.}-{0:0}, at:
register_framebuffer+0x219/0x274
[3.809124] #8: c36e7848 (_info->lock){+.+.}-{3:3}, at:
register_framebuffer+0x19f/0x274
[3.809157] #9: c36d2d6c (>lock){+.+.}-{3:3}, at:
__drm_fb_helper_restore_fbdev_mode_unlocked+0x41/0x8c
[3.809199] #10: c36f00e8 (>master_mutex){+.+.}-{3:3}, at:
drm_master_internal_acquire+0x17/0x28
[3.809233] #11: c36d2c50 (>modeset_mutex){+.+.}-{3:3}, at:
drm_client_modeset_commit_locked+0x1d/0x138
[3.809272] #12: c2bbba28 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
drm_client_modeset_commit_atomic+0x2f/0x1c4
[3.809306] #13: c36e6448 (crtc_ww_class_mutex){+.+.}-{3:3}, at:
drm_modeset_backoff+0x63/0x190
[3.809337] #14: c34df8a4 (>lock){+.+.}-{3:3}, at:
host1x_client_resume+0x17/0x58
[3.809369]
stack backtrace:
[3.809375] CPU: 1 PID: 108 Comm: kworker/1:2 Tainted: GW
5.12.0-rc3-next-20210319-00176-g60867e51e180 #7219
[3.809387] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[3.809396] Workqueue: events deferred_probe_work_func
[3.809417] []
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
On Mon, Mar 22, 2021 at 5:52 AM Matthew Auld wrote: > > On Sat, 20 Mar 2021 at 14:48, Jason Ekstrand wrote: > > > > On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand wrote: > > > > > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API > > > has never been used by any real userspace. > > > > After further digging, there is a compute-runtime PR for this. I > > still think we should drop it and I've updated the commit message > > locally with the following rationale: > > > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API > > was originally added for OpenCL but the compute-runtime PR has sat open > > for a year without action so we can still pull it out if we want. I > > argue we should drop it for three reasons: > > > > 1. If the compute-runtime PR has sat open for a year, this clearly > > isn't that important. > > > > 2. It's a very leaky API. Ring size is an implementation detail of the > > current execlist scheduler and really only makes sense there. It > > can't apply to the older ring-buffer scheduler on pre-execlist > > hardware because that's shared across all contexts and it won't > > apply to the GuC scheduler that's in the pipeline. > > Just a drive-by-comment. I thought the lrc model was shared between > execlists and the GuC, so in both cases we get something like a ring > per engine per context which the driver can emit commands into. Why > doesn't ring size still apply with the GuC scheduler? Even if they both have a ring in some sense, the number of bytes which correspond to a single request is going to be different and that difference isn't visible to userspace so bytes is the wrong unit. --Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 16 bpc fixed point (RGBA16) framebuffer support for core and AMD.
On Fri, Mar 19, 2021 at 10:03:12PM +0100, Mario Kleiner wrote: > Hi, > > this patch series adds the fourcc's for 16 bit fixed point unorm > framebuffers to the core, and then an implementation for AMD gpu's > with DisplayCore. > > This is intended to allow for pageflipping to, and direct scanout of, > Vulkan swapchain images in the format VK_FORMAT_R16G16B16A16_UNORM. > I have patched AMD's GPUOpen amdvlk OSS driver to enable this format > for swapchains, mapping to DRM_FORMAT_XBGR16161616: > Link: > https://github.com/kleinerm/pal/commit/a25d4802074b13a8d5f7edc96ae45469ecbac3c4 We should also add support for these formats into igt.a Should be semi-easy by just adding the suitable float<->uint16 conversion stuff. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Individual request cancellation
On Thu, 18 Mar 2021 at 17:04, Tvrtko Ursulin
wrote:
>
> From: Chris Wilson
>
> Currently, we cancel outstanding requests within a context when the
> context is closed. We may also want to cancel individual requests using
> the same graceful preemption mechanism.
>
> v2 (Tvrtko):
> * Cancel waiters carefully considering no timeline lock and RCU.
> * Fixed selftests.
>
> v3 (Tvrtko):
> * Remove error propagation to waiters for now.
>
> Signed-off-by: Chris Wilson
> Signed-off-by: Tvrtko Ursulin
> ---
> .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 +
> .../drm/i915/gt/intel_execlists_submission.c | 9 +-
> drivers/gpu/drm/i915/i915_request.c | 52 -
> drivers/gpu/drm/i915/i915_request.h | 4 +-
> drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
> 5 files changed, 261 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 0b062fad1837..e2fb3ae2aaf3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -314,6 +314,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
> mutex_unlock(>timeline->mutex);
> }
>
> + intel_engine_flush_scheduler(engine);
> intel_engine_pm_put(engine);
> return err;
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 85ff5fe861b4..4c2acb5a6c0a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -421,6 +421,11 @@ static void reset_active(struct i915_request *rq,
> ce->lrc.lrca = lrc_update_regs(ce, engine, head);
> }
>
> +static bool bad_request(const struct i915_request *rq)
> +{
> + return rq->fence.error && i915_request_started(rq);
> +}
> +
> static struct intel_engine_cs *
> __execlists_schedule_in(struct i915_request *rq)
> {
> @@ -433,7 +438,7 @@ __execlists_schedule_in(struct i915_request *rq)
> !intel_engine_has_heartbeat(engine)))
> intel_context_set_banned(ce);
>
> - if (unlikely(intel_context_is_banned(ce)))
> + if (unlikely(intel_context_is_banned(ce) || bad_request(rq)))
> reset_active(rq, engine);
>
> if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> @@ -1112,7 +1117,7 @@ static unsigned long active_preempt_timeout(struct
> intel_engine_cs *engine,
> return 0;
>
> /* Force a fast reset for terminated contexts (ignoring sysfs!) */
> - if (unlikely(intel_context_is_banned(rq->context)))
> + if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
> return 1;
>
> return READ_ONCE(engine->props.preempt_timeout_ms);
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index e7b4c4bc41a6..b4511ac05e9a 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -33,7 +33,10 @@
> #include "gem/i915_gem_context.h"
> #include "gt/intel_breadcrumbs.h"
> #include "gt/intel_context.h"
> +#include "gt/intel_engine.h"
> +#include "gt/intel_engine_heartbeat.h"
> #include "gt/intel_gpu_commands.h"
> +#include "gt/intel_reset.h"
> #include "gt/intel_ring.h"
> #include "gt/intel_rps.h"
>
> @@ -429,20 +432,22 @@ void __i915_request_skip(struct i915_request *rq)
> rq->infix = rq->postfix;
> }
>
> -void i915_request_set_error_once(struct i915_request *rq, int error)
> +bool i915_request_set_error_once(struct i915_request *rq, int error)
> {
> int old;
>
> GEM_BUG_ON(!IS_ERR_VALUE((long)error));
>
> if (i915_request_signaled(rq))
> - return;
> + return false;
>
> old = READ_ONCE(rq->fence.error);
> do {
> if (fatal_error(old))
> - return;
> + return false;
> } while (!try_cmpxchg(>fence.error, , error));
> +
> + return true;
> }
>
> struct i915_request *i915_request_mark_eio(struct i915_request *rq)
> @@ -609,6 +614,47 @@ void i915_request_unsubmit(struct i915_request *request)
> spin_unlock_irqrestore(>lock, flags);
> }
>
> +static struct intel_engine_cs *active_engine(struct i915_request *rq)
> +{
> + struct intel_engine_cs *engine, *locked;
> +
> + locked = READ_ONCE(rq->engine);
> + spin_lock_irq(>sched.lock);
> + while (unlikely(locked != (engine = READ_ONCE(rq->engine {
> + spin_unlock(>sched.lock);
> + locked = engine;
> + spin_lock(>sched.lock);
> + }
> +
> + engine = NULL;
> + if (i915_request_is_active(rq) && !__i915_request_is_complete(rq))
> + engine = locked;
> +
> + spin_unlock_irq(>sched.lock);
> +
> + return
Latest i915 / TTM repo?
Hi, Dave! I was wondering whether you code share the latest status and location of your latest i915/TTM code? Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers: gpu: Remove duplicate include of amdgpu_hdp.h
amdgpu_hdp.h has been included at line 91, so remove the duplicate include. Signed-off-by: Wan Jiabing --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 49267eb64302..68836c22ef25 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -107,7 +107,6 @@ #include "amdgpu_gfxhub.h" #include "amdgpu_df.h" #include "amdgpu_smuio.h" -#include "amdgpu_hdp.h" #define MAX_GPU_INSTANCE 16 -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers: gpu: Remove duplicate include of if000c.h
nvif/if000c.h has been included at line 33, so remove the duplicate include at line 36. Signed-off-by: Wan Jiabing --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index 92987daa5e17..f5cc057b123b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c @@ -33,7 +33,6 @@ #include #include #include -#include #include -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drivers: gpu: priv.h is included twice
priv.h has been included at line 22, so remove the duplicate include at line 24. Signed-off-by: Wan Jiabing --- drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c index c39e797dc7c9..09524168431c 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c @@ -20,8 +20,6 @@ * OTHER DEALINGS IN THE SOFTWARE. */ #include "priv.h" - -#include "priv.h" #include static void * -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API
On 22/03/2021 14:57, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin wrote: On 22/03/2021 14:09, Daniel Vetter wrote: On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote: On 19/03/2021 22:38, Jason Ekstrand wrote: This API allows one context to grab bits out of another context upon creation. It can be used as a short-cut for setparam(getparam()) for things like I915_CONTEXT_PARAM_VM. However, it's never been used by any real userspace. It's used by a few IGT tests and that's it. Since it doesn't add any real value (most of the stuff you can CLONE you can copy in other ways), drop it. No complaints to remove if it ended up unused outside IGT. Latter is a _big_ problem though, since it is much more that a few IGT tests. So I really think there really needs to be an evaluation and a plan for that (we don't want to lose 50% of the coverage over night). There is one thing that this API allows you to clone which you cannot clone via getparam/setparam: timelines. However, timelines are an implementation detail of i915 and not really something that needs to be Not really true timelines are i915 implementation detail. They are in fact a dma-fence context:seqno concept, nothing more that than. I think you are probably confusing struct intel_timeline with the timeline wording in the uapi. Former is i915 implementation detail, but context:seqno are truly userspace timelines. I think you're both saying the same thing and talking a bit past each another. Yes the timeline is just a string of dma_fence, that's correct. Now usually if you submit batches with execbuf, we have 3 ways to synchronize concurrent submission: implicit sync, sync_file and drm_syncob. They all map to different needs in different protocols/render apis. Now in one additional case the kernel makes sure that batchbuffers are ordered, and that's when you submit them to the same hw ctx. Because there's only 1 hw context and you really can't have batchbuffers run on that single hw context out of order. That's what the timeline object we talk about here is. But that largely is an internal implementation detail, which happens to also use most/all the same infrastructure as the dma_fence uapi pieces above. Now the internal implementation detail leaking here is that we exposed this to userspace, without there being any need for this. What Jason implements with syncobj in the next patch is essentially what userspace should have been using for cross-engine sync. media userspace doesn't care about interop with winsys/client apis, so they equally could have used implicit sync or sync_file here (which I think is the solution now for the new uapi prepped internally), since they all are about equally powerful for stringing batchbuffers together. Are you saying we exposed a single timeline of execution per hw context via the single timeline flag?! Nope. Timelines of execution were always exposed. Any "engine" (ring previously) in I915_EXEC_RING_MASK was a single timeline of execution. It is completely the same with engine map engines, which are also different indices into I915_EXEC_RING_MASK space. Userspace was aware of these timelines forever as well. Media was creating multiple contexts to have multiple timelines (so parallelism). Everyone knew that engine-hopping submissions needs to be either implicitly or explicitly synchronised, etc. Yup, I think we're saying the same thing here. So I really don't see that we have leaked timelines as a concept *now*. What the patch has exposed to userspace is a new way to sync between timelines and nothing more. We've leaked it as something you can now share across hw context. Okay so we agree on most things but apparently have different definitions of what it means to leak internal implementation details. While at the same time proof that we haven't leaked the internal implementation details is that Jason was able to implement the single timeline flag with a drm syncobj at the execbuf top level. (Well mostly, ignoring the probably inconsequential difference of one vs multiple fence contexts.) Which is possible because of how it's internally implemented (I think load balancer relies on that), but not really a synchronization Virtual engine is a single timeline by definition and it is still that regardless of the implementation details (execlists or GuC, in both cases it is a single hardware context and a single timeline). primitive we want to export as such to userspace. We have other interfaces and concepts for that. Yes, that is the only point to argue IMO. We can say it wasn't needed and should have been avoided, but I still maintain we can't really say we leaked anything backend specific to userspace via it. Regards, Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
On 15/03/2021 05:23, Zhang, Jack (Jian) wrote:
[AMD Public Use]
Hi, Rob/Tomeu/Steven,
Would you please help to review this patch for panfrost driver?
Thanks,
Jack Zhang
-Original Message-
From: Jack Zhang
Sent: Monday, March 15, 2021 1:21 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig, Christian
; Grodzovsky, Andrey ; Liu, Monk
; Deng, Emily
Cc: Zhang, Jack (Jian)
Subject: [PATCH v3] drm/scheduler re-insert Bailing job to avoid memleak
re-insert Bailing jobs to avoid memory leak.
V2: move re-insert step to drm/scheduler logic
V3: add panfrost's return value for bailing jobs
in case it hits the memleak issue.
This commit message could do with some work - it's really hard to
decipher what the actual problem you're solving is.
Signed-off-by: Jack Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 8 ++--
drivers/gpu/drm/panfrost/panfrost_job.c| 4 ++--
drivers/gpu/drm/scheduler/sched_main.c | 8 +++-
include/drm/gpu_scheduler.h| 1 +
5 files changed, 19 insertions(+), 6 deletions(-)
[...]
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 6003cfeb1322..e2cb4f32dae1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -444,7 +444,7 @@ static enum drm_gpu_sched_stat panfrost_job_timedout(struct
drm_sched_job
* spurious. Bail out.
*/
if (dma_fence_is_signaled(job->done_fence))
- return DRM_GPU_SCHED_STAT_NOMINAL;
+ return DRM_GPU_SCHED_STAT_BAILING;
dev_err(pfdev->dev, "gpu sched timeout, js=%d, config=0x%x, status=0x%x, head=0x%x, tail=0x%x, sched_job=%p",
js,
@@ -456,7 +456,7 @@ static enum drm_gpu_sched_stat panfrost_job_timedout(struct
drm_sched_job
/* Scheduler is already stopped, nothing to do. */
if (!panfrost_scheduler_stop(>js->queue[js], sched_job))
- return DRM_GPU_SCHED_STAT_NOMINAL;
+ return DRM_GPU_SCHED_STAT_BAILING;
/* Schedule a reset if there's no reset in progress. */
if (!atomic_xchg(>reset.pending, 1))
This looks correct to me - in these two cases drm_sched_stop() is not
called on the sched_job, so it looks like currently the job will be leaked.
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 92d8de24d0a1..a44f621fb5c4 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -314,6 +314,7 @@ static void drm_sched_job_timedout(struct work_struct *work)
{
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+ int ret;
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
@@ -331,8 +332,13 @@ static void drm_sched_job_timedout(struct work_struct *work)
list_del_init(>list);
spin_unlock(>job_list_lock);
- job->sched->ops->timedout_job(job);
+ ret = job->sched->ops->timedout_job(job);
+ if (ret == DRM_GPU_SCHED_STAT_BAILING) {
+ spin_lock(>job_list_lock);
+ list_add(>node, >ring_mirror_list);
+ spin_unlock(>job_list_lock);
+ }
I think we could really do with a comment somewhere explaining what
"bailing" means in this context. For the Panfrost case we have two cases:
* The GPU job actually finished while the timeout code was running
(done_fence is signalled).
* The GPU is already in the process of being reset (Panfrost has
multiple queues, so mostly like a bad job in another queue).
I'm also not convinced that (for Panfrost) it makes sense to be adding
the jobs back to the list. For the first case above clearly the job
could just be freed (it's complete). The second case is more interesting
and Panfrost currently doesn't handle this well. In theory the driver
could try to rescue the job ('soft stop' in Mali language) so that it
could be resubmitted. Panfrost doesn't currently support that, so
attempting to resubmit the job is almost certainly going to fail.
It's on my TODO list to look at improving Panfrost in this regard, but
sadly still quite far down.
Steve
/*
* Guilty job did complete and hence needs to be manually
removed
* See drm_sched_stop doc.
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 4ea8606d91fe..8093ac2427ef 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -210,6 +210,7 @@ enum drm_gpu_sched_stat {
DRM_GPU_SCHED_STAT_NONE, /* Reserve 0 */
DRM_GPU_SCHED_STAT_NOMINAL,
DRM_GPU_SCHED_STAT_ENODEV,
+ DRM_GPU_SCHED_STAT_BAILING,
};
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH v5 01/21] gpu: host1x: Use different lock classes for each client
On 22.3.2021 16.48, Dmitry Osipenko wrote:
22.03.2021 17:46, Thierry Reding пишет:
On Mon, Jan 11, 2021 at 02:59:59PM +0200, Mikko Perttunen wrote:
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initialization site by macro.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/bus.c | 7 ---
include/linux/host1x.h | 9 -
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 347fb962b6c9..8fc79e9cb652 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -715,13 +715,14 @@ EXPORT_SYMBOL(host1x_driver_unregister);
* device and call host1x_device_init(), which will in turn call each client's
* _client_ops.init implementation.
*/
-int host1x_client_register(struct host1x_client *client)
+int __host1x_client_register(struct host1x_client *client,
+ struct lock_class_key *key)
I've seen the kbuild robot warn about this because the kerneldoc is now
out of date.
{
struct host1x *host1x;
int err;
INIT_LIST_HEAD(>list);
- mutex_init(>lock);
+ __mutex_init(>lock, "host1x client lock", key);
Should we maybe attempt to make this unique? Could we use something like
dev_name(client->dev) for this?
I'm curious who the lockdep warning could be triggered at all, I don't
recall ever seeing it. Mikko, could you please clarify how to reproduce
the warning?
This is pretty difficult to read but I guess it's some interaction
related to the delayed initialization of host1x clients? In any case, I
consistently get it at boot (though it may be triggered by vic probe
instead of nvdec).
I'll fix the kbuild robot warnings and see if I can add a
client-specific lock name for v6.
Mikko
[ 38.128257] WARNING: possible recursive locking detected
[ 38.133567] 5.11.0-rc2-next-20210108+ #102 Tainted: G S
[ 38.140089]
[ 38.145395] systemd-udevd/239 is trying to acquire lock:
[ 38.150703] 997aa218 (>lock){+.+.}-{3:3}, at:
host1x_client_resume+0x30/0x100 [host1x]
[ 38.160142]
[ 38.160142] but task is already holding lock:
[ 38.165968] 80c3b148 (>lock){+.+.}-{3:3}, at:
host1x_client_resume+0x30/0x100 [host1x]
[ 38.175398]
[ 38.175398] other info that might help us debug this:
[ 38.181918] Possible unsafe locking scenario:
[ 38.181918]
[ 38.187830]CPU0
[ 38.190275]
[ 38.192719] lock(>lock);
[ 38.196129] lock(>lock);
[ 38.199537]
[ 38.199537] *** DEADLOCK ***
[ 38.199537]
[ 38.205449] May be due to missing lock nesting notation
[ 38.205449]
[ 38.212228] 6 locks held by systemd-udevd/239:
[ 38.216669] #0: 9261c188 (>mutex){}-{3:3}, at:
device_driver_attach+0x60/0x130
[ 38.225487] #1: 89a17168 (devices_lock){+.+.}-{3:3}, at:
host1x_client_register+0x7c/0x220 [host1x]
[ 38.235441] #2: 83f94bb8 (>devices_lock){+.+.}-{3:3},
at: host1x_client_register+0xac/0x220 [host1x]
[ 38.245996] #3: a2267190 (>mutex){}-{3:3}, at:
__device_attach+0x8c/0x230
[ 38.254372] #4: 92c880f0 (>lock){+.+.}-{3:3}, at:
tegra_display_hub_prepare+0xd8/0x170 [tegra_drm]
[ 38.264788] #5: 80c3b148 (>lock){+.+.}-{3:3}, at:
host1x_client_resume+0x30/0x100 [host1x]
[ 38.274658]
[ 38.274658] stack backtrace:
[ 38.279012] CPU: 0 PID: 239 Comm: systemd-udevd Tainted: G S
5.11.0-rc2-next-20210108+ #102
[ 38.288660] Hardware name: NVIDIA Jetson TX2 Developer Kit (DT)
[ 38.294577] Call trace:
[ 38.297022] dump_backtrace+0x0/0x2c0
[ 38.300695] show_stack+0x18/0x6c
[ 38.304013] dump_stack+0x120/0x19c
[ 38.307507] __lock_acquire+0x171c/0x2c34
[ 38.311521] lock_acquire.part.0+0x230/0x490
[ 38.315793] lock_acquire+0x70/0x90
[ 38.319285] __mutex_lock+0x11c/0x6d0
[ 38.322952] mutex_lock_nested+0x58/0x90
[ 38.326877] host1x_client_resume+0x30/0x100 [host1x]
[ 38.332047] host1x_client_resume+0x44/0x100 [host1x]
[ 38.337200] tegra_display_hub_prepare+0xf8/0x170 [tegra_drm]
[ 38.343084] host1x_drm_probe+0x1fc/0x4f0 [tegra_drm]
[ 38.348256] host1x_device_probe+0x3c/0x50 [host1x]
[ 38.353240] really_probe+0x148/0x6f0
[ 38.356906] driver_probe_device+0x78/0xe4
[ 38.361005] __device_attach_driver+0x10c/0x170
[ 38.365536] bus_for_each_drv+0xf0/0x160
[ 38.369461] __device_attach+0x168/0x230
[ 38.373385] device_initial_probe+0x14/0x20
[ 38.377571] bus_probe_device+0xec/0x100
[ 38.381494] device_add+0x580/0xbcc
[ 38.384985] host1x_subdev_register+0x178/0x1cc [host1x]
[ 38.390397] host1x_client_register+0x138/0x220 [host1x]
[ 38.395808] nvdec_probe+0x240/0x3ec [tegra_drm]
[ 38.400549] platform_probe+0x8c/0x110
[ 38.404302] really_probe+0x148/0x6f0
[ 38.407966] driver_probe_device+0x78/0xe4
[ 38.412065] device_driver_attach+0x120/0x130
[ 38.416423]
Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.
"friendly ping"
On Wed, Mar 10, 2021 at 11:14 AM Mark Yacoub
wrote:
> From: Mark Yacoub
>
> On initializing the framebuffer, call drm_any_plane_has_format to do a
> check if the modifier is supported. drm_any_plane_has_format calls
> dm_plane_format_mod_supported which is extended to validate that the
> modifier is on the list of the plane's supported modifiers.
>
> The bug was caught using igt-gpu-tools test:
> kms_addfb_basic.addfb25-bad-modifier
>
> Tested on ChromeOS Zork by turning on the display, running an overlay
> test, and running a YT video.
>
> Cc: Alex Deucher
> Cc: Bas Nieuwenhuizen
> Signed-off-by: default avatarMark Yacoub
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index afa5f8ad0f563..a947b5aa420d2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -908,6 +908,19 @@ int amdgpu_display_gem_fb_verify_and_init(
> _fb_funcs);
> if (ret)
> goto err;
> + /* Verify that the modifier is supported. */
> + if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
> + mode_cmd->modifier[0])) {
> + struct drm_format_name_buf format_name;
> + drm_dbg_kms(dev,
> + "unsupported pixel format %s / modifier
> 0x%llx\n",
> + drm_get_format_name(mode_cmd->pixel_format,
> + _name),
> + mode_cmd->modifier[0]);
> +
> + ret = -EINVAL;
> + goto err;
> + }
>
> ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
> if (ret)
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 961abf1cf040c..21314024a83ce 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3939,6 +3939,7 @@ static bool dm_plane_format_mod_supported(struct
> drm_plane *plane,
> {
> struct amdgpu_device *adev = drm_to_adev(plane->dev);
> const struct drm_format_info *info = drm_format_info(format);
> + int i;
>
> enum dm_micro_swizzle microtile =
> modifier_gfx9_swizzle_mode(modifier) & 3;
>
> @@ -3952,6 +3953,14 @@ static bool dm_plane_format_mod_supported(struct
> drm_plane *plane,
> if (modifier == DRM_FORMAT_MOD_LINEAR)
> return true;
>
> + /* Check that the modifier is on the list of the plane's supported
> modifiers. */
> + for (i = 0; i < plane->modifier_count; i++) {
> + if (modifier == plane->modifiers[i])
> + break;
> + }
> + if (i == plane->modifier_count)
> + return false;
> +
> /*
> * The arbitrary tiling support for multiplane formats has not
> been hooked
> * up.
> --
> 2.30.1.766.gb4fecdf3b7-goog
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: remove the nvlink2 pci_vfio subdriver
On Mon, Mar 22, 2021 at 04:01:53PM +0100, Christoph Hellwig wrote: > Hi all, > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware > feature without any open source component - what would normally be > the normal open source userspace that we require for kernel drivers, > although in this particular case user space could of course be a > kernel driver in a VM. It also happens to be a complete mess that > does not properly bind to PCI IDs, is hacked into the vfio_pci driver > and also pulles in over 1000 lines of code always build into powerpc > kernels that have Power NV support enabled. Because of all these > issues and the lack of breaking userspace when it is removed I think > the best idea is to simply kill. > > Diffstat: > arch/powerpc/platforms/powernv/npu-dma.c | 705 > --- > b/arch/powerpc/include/asm/opal.h|3 > b/arch/powerpc/include/asm/pci-bridge.h |1 > b/arch/powerpc/include/asm/pci.h |7 > b/arch/powerpc/platforms/powernv/Makefile|2 > b/arch/powerpc/platforms/powernv/opal-call.c |2 > b/arch/powerpc/platforms/powernv/pci-ioda.c | 185 --- > b/arch/powerpc/platforms/powernv/pci.c | 11 > b/arch/powerpc/platforms/powernv/pci.h | 17 > b/arch/powerpc/platforms/pseries/pci.c | 23 > b/drivers/vfio/pci/Kconfig |6 > b/drivers/vfio/pci/Makefile |1 > b/drivers/vfio/pci/vfio_pci.c| 18 > b/drivers/vfio/pci/vfio_pci_private.h| 14 > b/include/uapi/linux/vfio.h | 40 - > drivers/vfio/pci/vfio_pci_nvlink2.c | 490 -- > 16 files changed, 8 insertions(+), 1517 deletions(-) I thought this was supposed to be removed a few years ago! Anyway, no objection from me: Acked-by: Greg Kroah-Hartman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4, 08/10] soc: mediatek: mmsys: add component RDMA4
Hi, Matthias:
Yongqiang Niu 於 2021年1月5日 週二 上午11:07寫道：
>
> This patch add component RDMA4
>
> Signed-off-by: Yongqiang Niu
> Reviewed-by: Chun-Kuang Hu
How do you think about this patch? One drm patch [1] depends on this patch.
[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/20210202081237.774442-4-hsi...@chromium.org/
Regards,
Chun-Kuang.
> ---
> include/linux/soc/mediatek/mtk-mmsys.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 13546e9..2c11617 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -38,6 +38,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_RDMA1,
> DDP_COMPONENT_RDMA2,
> + DDP_COMPONENT_RDMA4,
> DDP_COMPONENT_UFOE,
> DDP_COMPONENT_WDMA0,
> DDP_COMPONENT_WDMA1,
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
