Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588
On Thu, Nov 16, 2023 at 03:24:54PM +0800, Andy Yan wrote:
> > case ROCKCHIP_VOP2_EP_HDMI0:
> > case ROCKCHIP_VOP2_EP_HDMI1:
> > ...
> > }
> >
> > would look a bit better overall.
> >
> > > + /*
> > > + * K = 2: dclk_core = if_pixclk_rate > if_dclk_rate
> > > + * K = 1: dclk_core = hdmie_edp_dclk > if_pixclk_rate
> > > + */
> > > + if (output_mode == ROCKCHIP_OUT_MODE_YUV420) {
> > > + dclk_rate = dclk_rate >> 1;
> > > + K = 2;
> > > + }
> > > +
> > > + if_pixclk_rate = (dclk_core_rate << 1) / K;
> > > + if_dclk_rate = dclk_core_rate / K;
> > > +
> > > + *if_pixclk_div = dclk_rate / if_pixclk_rate;
> > > + *if_dclk_div = dclk_rate / if_dclk_rate;
> > Not sure if this will change with future extensions, but currently
> > *if_pixclk_div will always be 2 and *if_dclk_div will alway be 4,
> > so maybe better write it like this
>
>
> Yes, the calculation of *if_pixclk_div is always 2 and *if_dclk_div is always
> 4,
>
> I think calculation formula can give us a clear explanation why is 2 or 4.
>
> considering the great power of rk3588, i think it can calculate it very easy.
Sure it can. My concern is not the CPU time it takes to do that
equation, but more the readability of the code. For me as a reader it
might be more easily acceptable that both dividers have fixed values
than it is to understand the equation.
Your mileage may vary, I won't insist on this.
>
> >
> >
> > > + *dclk_core_div = dclk_rate / dclk_core_rate;
> > *dclk_core_div is calculated the same way for all cases. You could pull
> > this out of the if/else.
> Okay, will do.
> >
> > > + } else if (vop2_output_if_is_edp(id)) {
> > > + /* edp_pixclk = edp_dclk > dclk_core */
> > > + if_pixclk_rate = v_pixclk / K;
> > > + if_dclk_rate = v_pixclk / K;
> > if_dclk_rate is unused here.
>
>
> It will be removed in next version.
>
> >
> > > + dclk_rate = if_pixclk_rate * K;
> > > + *dclk_core_div = dclk_rate / dclk_core_rate;
> > > + *if_pixclk_div = dclk_rate / if_pixclk_rate;
> > > + *if_dclk_div = *if_pixclk_div;
> > Both *if_pixclk_div and *if_dclk_div will always be 1.
>
> Actually, they will be the value of K here, if it work at split mode(two
>
> edp connect to one VP, one show the image for left half, one for right half,
>
> a function like a dual channel mipi dsi).
>
> I know it split mode is not supported by the current mainline, but i think
> keep
Ok.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 1/1] backlight: pwm_bl: Use dev_err_probe
Let dev_err_probe handle the -EPROBE_DEFER case and also add an entry to
/sys/kernel/debug/devices_deferred when deferred.
Signed-off-by: Alexander Stein
---
drivers/video/backlight/pwm_bl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 289bd9ce4d36d..3825c2b67c53b 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -509,8 +509,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->pwm = devm_pwm_get(>dev, NULL);
if (IS_ERR(pb->pwm)) {
ret = PTR_ERR(pb->pwm);
- if (ret != -EPROBE_DEFER)
- dev_err(>dev, "unable to request PWM\n");
+ dev_err_probe(>dev, ret, "unable to request PWM\n");
goto err_alloc;
}
--
2.34.1
Re: [PATCH v2 0/5] drm: Allow the damage helpers to handle buffer damage
Zack Rusin writes: Hello Zack, > On Wed, 2023-11-15 at 14:15 +0100, Javier Martinez Canillas wrote: [...] >> >> Changes in v2: >> - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's >> .atomic_check, instead of having different helpers (Thomas Zimmermann). >> - Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's >> .atomic_check instead of using a different helpers (Thomas Zimmermann). >> - Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's >> .atomic_check instead of using a different helpers (Thomas Zimmermann). > > The series looks good to me, thanks for tackling this. I'm surprised that we > don't Thanks. Can I get your r-b or a-b ? > have any IGT tests for this. Seems like it shouldn't be too hard to test it > in a > generic way with just a couple of dumb buffers. > Yes, I haven't looked at it but also think that shouldn't be that hard. > z -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588
Hi Sascha:
Thanks for your review.
Let's confirm your remarks in function vop2_calc_cru_cfg fist,
others are small nits I think can be easy to address.
On 11/15/23 17:08, Sascha Hauer wrote:
Hi Andy,
Thanks for your patches, some remarks inline.
On Tue, Nov 14, 2023 at 07:28:55PM +0800, Andy Yan wrote:
From: Andy Yan
VOP2 on rk3588:
Four video ports:
VP0 Max 4096x2160
VP1 Max 4096x2160
VP2 Max 4096x2160
VP3 Max 2048x1080
4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
4 4K Esmart windows with line RGB/YUV support
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 324 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 57
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 215
include/dt-bindings/soc/rockchip,vop2.h | 4 +
4 files changed, 593 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 0d7dc543bef3..ba61c0233937 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -191,6 +191,9 @@ struct vop2 {
struct regmap *map;
struct regmap *sys_grf;
+ struct regmap *vop_grf;
+ struct regmap *vo1_grf;
+ struct regmap *sys_pmu;
/* physical map length of vop2 register */
u32 len;
@@ -209,6 +212,7 @@ struct vop2 {
unsigned int enable_count;
struct clk *hclk;
struct clk *aclk;
+ struct clk *pclk;
/* optional internal rgb encoder */
struct rockchip_rgb *rgb;
@@ -217,6 +221,13 @@ struct vop2 {
struct vop2_win win[];
};
+#define vop2_output_if_is_hdmi(x) (x == ROCKCHIP_VOP2_EP_HDMI0 || x == ROCKCHIP_VOP2_EP_HDMI1)
+#define vop2_output_if_is_dp(x)(x == ROCKCHIP_VOP2_EP_DP0 || x
== ROCKCHIP_VOP2_EP_DP1)
+#define vop2_output_if_is_edp(x) (x == ROCKCHIP_VOP2_EP_EDP0 || x ==
ROCKCHIP_VOP2_EP_EDP1)
+#define vop2_output_if_is_mipi(x) (x == ROCKCHIP_VOP2_EP_MIPI0 || x ==
ROCKCHIP_VOP2_EP_MIPI1)
+#define vop2_output_if_is_lvds(x) (x == ROCKCHIP_VOP2_EP_LVDS0 || x ==
ROCKCHIP_VOP2_EP_LVDS1)
+#define vop2_output_if_is_dpi(x) (x == ROCKCHIP_VOP2_EP_RGB0)
+
static const struct regmap_config vop2_regmap_config;
static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
@@ -271,9 +282,12 @@ static bool vop2_cluster_window(const struct vop2_win *win)
static void vop2_cfg_done(struct vop2_video_port *vp)
{
struct vop2 *vop2 = vp->vop2;
+ u32 val;
- regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE,
- BIT(vp->id) | RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN);
+ val = BIT(vp->id) | (BIT(vp->id) << 16) |
+ RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN;
+
+ regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val);
}
static void vop2_win_disable(struct vop2_win *win)
@@ -863,13 +877,32 @@ static int vop2_core_clks_prepare_enable(struct vop2
*vop2)
goto err;
}
+ ret = clk_prepare_enable(vop2->pclk);
+ if (ret < 0) {
+ drm_err(vop2->drm, "failed to enable pclk - %d\n", ret);
+ goto err1;
+ }
+
return 0;
+err1:
+ clk_disable_unprepare(vop2->aclk);
err:
clk_disable_unprepare(vop2->hclk);
return ret;
}
+static void vop2_power_domain_all_on(struct vop2 *vop2)
The function name sounds like it would return the current status rather
than enabling them. Better vop2_power_domain_enable_all(). Also a
rk3588_ prefix would be nice.
+{
+ u32 pd;
+
+ pd = vop2_readl(vop2, RK3588_SYS_PD_CTRL);
+ pd &= ~(VOP2_PD_CLUSTER0 | VOP2_PD_CLUSTER1 | VOP2_PD_CLUSTER2 |
+ VOP2_PD_CLUSTER3 | VOP2_PD_ESMART);
+
+ vop2_writel(vop2, RK3588_SYS_PD_CTRL, pd);
+}
+
static void vop2_enable(struct vop2 *vop2)
{
int ret;
@@ -901,6 +934,9 @@ static void vop2_enable(struct vop2 *vop2)
if (vop2->data->soc_id == 3566)
vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
+ if (vop2->data->soc_id == 3588)
+ vop2_power_domain_all_on(vop2);
+
vop2_writel(vop2, RK3568_REG_CFG_DONE,
RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN);
/*
@@ -926,6 +962,7 @@ static void vop2_disable(struct vop2 *vop2)
pm_runtime_put_sync(vop2->dev);
+ clk_disable_unprepare(vop2->pclk);
clk_disable_unprepare(vop2->aclk);
clk_disable_unprepare(vop2->hclk);
}
@@ -1293,7 +1330,11 @@ static void vop2_plane_atomic_update(struct drm_plane
*plane,
vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 1);
vop2_win_write(win, VOP2_WIN_AFBC_FORMAT, afbc_format);
vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap);
- vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
+ if (vop2->data->soc_id == 3566 || vop2->data->soc_id == 3568)
+
Re: [PATCH v3 7/7] PCI: Exclude PCIe ports used for virtual links in pcie_bandwidth_available()
On 11/16/2023 2:39 AM, Mario Limonciello wrote:
On 11/15/2023 11:04, Mario Limonciello wrote:
On 11/14/2023 21:23, Lazar, Lijo wrote:
On 11/15/2023 1:37 AM, Mario Limonciello wrote:
The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s
and
behave as a PCIe Gen1 device. The actual performance of these ports is
controlled by the fabric implementation.
Callers for pcie_bandwidth_available() will always find the PCIe ports
used for tunneling as a limiting factor potentially leading to
incorrect
performance decisions.
To prevent such problems check explicitly for ports that are marked as
virtual links or as thunderbolt controllers and skip them when looking
for bandwidth limitations of the hierarchy. If the only device
connected
is a port used for tunneling then report that device.
Callers to pcie_bandwidth_available() could make this change on their
own as well but then they wouldn't be able to detect other potential
speed bottlenecks from the hierarchy without duplicating
pcie_bandwidth_available() logic.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925#note_2145860
Link: https://www.usb.org/document-library/usb4r-specification-v20
USB4 V2 with Errata and ECN through June 2023
Section 11.2.1
Signed-off-by: Mario Limonciello
---
v2->v3:
* Split from previous patch version
* Look for thunderbolt or virtual link
---
drivers/pci/pci.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0ff7883cc774..b1fb2258b211 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6269,11 +6269,20 @@ static u32 pcie_calc_bw_limits(struct
pci_dev *dev, u32 bw,
* limiting_dev, speed, and width pointers are supplied)
information about
* that point. The bandwidth returned is in Mb/s, i.e.,
megabits/second of
* raw bandwidth.
+ *
+ * This excludes the bandwidth calculation that has been returned
from a
+ * PCIe device that is used for transmitting tunneled PCIe traffic
over a virtual
+ * link part of larger hierarchy. Examples include Thunderbolt3 and
USB4 links.
+ * The calculation is excluded because the USB4 specification
specifies that the
+ * max speed returned from PCIe configuration registers for the
tunneling link is
+ * always PCI 1x 2.5 GT/s. When only tunneled devices are present,
the bandwidth
+ * returned is the bandwidth available from the first tunneled device.
*/
u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev
**limiting_dev,
enum pci_bus_speed *speed,
enum pcie_link_width *width)
{
+ struct pci_dev *vdev = NULL;
u32 bw = 0;
if (speed)
@@ -6282,10 +6291,20 @@ u32 pcie_bandwidth_available(struct pci_dev
*dev, struct pci_dev **limiting_dev,
*width = PCIE_LNK_WIDTH_UNKNOWN;
while (dev) {
+ if (dev->is_virtual_link || dev->is_thunderbolt) {
+ if (!vdev)
+ vdev = dev;
+ goto skip;
+ }
One problem with this is it *silently* ignores the bandwidth limiting
device - the bandwidth may not be really available if there are
virtual links in between. That is a change in behavior from the
messages shown in __pcie_print_link_status.
That's a good point. How about a matching behavioral change to
__pcie_print_link_status() where it looks at the entire hierarchy for
any links marked as virtual and prints a message along the lines of:
"This value may be further limited by virtual links".
I'll wait for some more feedback on the series before posting another
version, but I did put this together and this is a sample from dmesg of
the wording I'm planning on using for the next version:
31.504 Gb/s available PCIe bandwidth, this may be further limited by
conditions of virtual link :00:03.1
This will cover the the message, but for any real user of the API this
is not good enough as the speed returned doesn't really indicate the
bandwidth available. Or, modify the description such that users know
that the value cannot be trusted when there is virtual link in between
(probably the API should indicate that through some param/return code)
and act accordingly.
Thanks,
Lijo
Thanks,
Lijo
bw = pcie_calc_bw_limits(dev, bw, limiting_dev, speed,
width);
+skip:
dev = pci_upstream_bridge(dev);
}
+ /* If nothing "faster" found on hierarchy, limit to first
virtual link */
+ if (vdev && !bw)
+ bw = pcie_calc_bw_limits(vdev, bw, limiting_dev, speed,
width);
+
return bw;
}
EXPORT_SYMBOL(pcie_bandwidth_available);
Re: [PATCH v2 0/5] drm: Allow the damage helpers to handle buffer damage
On Wed, 2023-11-15 at 14:15 +0100, Javier Martinez Canillas wrote:
> Hello,
>
> This series is to fix an issue that surfaced after damage clipping was
> enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
> fb damage clips property for the primary plane").
>
> After that change, flickering artifacts was reported to be present with
> both weston and wlroots wayland compositors when running in a virtual
> machine. The cause was identified by Sima Vetter, who pointed out that
> virtio-gpu does per-buffer uploads and for this reason it needs to do
> a buffer damage handling, instead of frame damage handling.
>
> Their suggestion was to extend the damage helpers to cover that case
> and given that there's isn't a buffer damage accumulation algorithm
> (e.g: buffer age), just do a full plane update if the framebuffer that
> is attached to a plane changed since the last plane update (page-flip).
>
> It is a v2 that addresses issues pointed out by Thomas Zimmermann in v1:
> https://lists.freedesktop.org/archives/dri-devel/2023-November/430138.html
>
> Patch #1 adds a ignore_damage_clips field to struct drm_plane_state to be
> set by drivers that want the damage helpers to ignore the damage clips.
>
> Patch #2 fixes the virtio-gpu damage handling logic by asking the damage
> helper to ignore the damage clips if the framebuffer attached to a plane
> has changed since the last page-flip.
>
> Patch #3 does the same but for the vmwgfx driver that also needs to handle
> buffer damage and should have the same issue (although I haven't tested it
> due not having a VMWare setup).
>
> Patch #4 adds to the KMS damage tracking kernel-doc some paragraphs about
> damage tracking types and references to links that explain frame damage vs
> buffer damage.
>
> Finally patch #5 adds an item to the DRM todo, about the need to implement
> some buffer damage accumulation algorithm instead of just doing full plane
> updates in this case.
>
> Because commit 01f05940a9a7 landed in v6.4, the first 2 patches are marked
> as Fixes and Cc stable.
>
> I've tested this on a VM with weston, was able to reproduce the issue
> reported and the patches did fix the problem.
>
> Best regards,
> Javier
>
> Changes in v2:
> - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's
> .atomic_check, instead of having different helpers (Thomas Zimmermann).
> - Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's
> .atomic_check instead of using a different helpers (Thomas Zimmermann).
> - Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's
> .atomic_check instead of using a different helpers (Thomas Zimmermann).
The series looks good to me, thanks for tackling this. I'm surprised that we
don't
have any IGT tests for this. Seems like it shouldn't be too hard to test it in a
generic way with just a couple of dumb buffers.
z
Re: [PATCH] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
Hi Biju,
Thank you for the patch.
On Wed, Nov 15, 2023 at 03:09:32PM +, Biju Das wrote:
> The rcar_du_vsps_init() doesn't free the np allocated by
> of_parse_phandle_with_fixed_args() for the non-error case.
>
> Fix memory leak for the non-error case.
Good catch.
> Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same
> VSP")
> Signed-off-by: Biju Das
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> index 70d8ad065bfa..5cd54ea33313 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> @@ -747,8 +747,6 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
> goto error;
> }
>
> - return 0;
> -
> error:
If the code path is used in non-error cases as well, I'd prefer renaming
it to "done".
> for (i = 0; i < ARRAY_SIZE(vsps); ++i)
> of_node_put(vsps[i].np);
The next line is
return ret;
When reached in the non-error case, ret is guaranteed to be
non-negative, as it has been assigned to the return value of
rcar_du_vsp_init(), with an
if (ret < 0)
error check following it. While rcar_du_vsp_init() doesn't return a
positive value today, the code here would break in a way that may not be
immediately visible during review if this changed. I thus recommend
either assigning
ret = 0;
in the success case, just before the "done" label, or changing the
if (ret < 0)
test with
if (ret)
after the call to rcar_du_vsp_init(). I think I have a preference for
the latter.
--
Regards,
Laurent Pinchart
Re: [PATCH V3 3/6] nv3051d: Add Powkiddy RK2023 Panel Support
On 11/15/2023 4:17 PM, Chris Morgan wrote:
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of these panels are identical in
size (70x57) it is possible future panels may not be.
Tested on my RG351V, RG353P, RG353V, and RK2023.
Signed-off-by: Chris Morgan
Reviewed-by: Jessica Zhang
---
.../gpu/drm/panel/panel-newvision-nv3051d.c | 55 +++
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index c44c6945662f..94d89ffd596b 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_flags;
+ u32 mode_flags;
};
struct panel_nv3051d {
@@ -387,15 +388,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
- /*
-* The panel in the RG351V is identical to the 353P, except it
-* requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-*/
- if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
- dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = ctx->panel_info->mode_flags;
drm_panel_init(>panel, >dev, _nv3051d_funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -483,16 +476,56 @@ static const struct drm_display_mode
nv3051d_rgxx3_modes[] = {
},
};
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+ {
+ .hdisplay = 640,
+ .hsync_start= 640 + 40,
+ .hsync_end = 640 + 40 + 2,
+ .htotal = 640 + 40 + 2 + 80,
+ .vdisplay = 480,
+ .vsync_start= 480 + 18,
+ .vsync_end = 480 + 18 + 2,
+ .vtotal = 480 + 18 + 2 + 4,
+ .clock = 24150,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ },
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
.display_modes = nv3051d_rgxx3_modes,
.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
.width_mm = 70,
.height_mm = 57,
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+ .display_modes = nv3051d_rgxx3_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+ .display_modes = nv3051d_rk2023_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
};
static const struct of_device_id newvision_nv3051d_of_match[] = {
- { .compatible = "newvision,nv3051d", .data = _rgxx3_info },
+ { .compatible = "anbernic,rg351v-panel", .data = _rg351v_info },
+ { .compatible = "anbernic,rg353p-panel", .data = _rg353p_info },
+ { .compatible = "powkiddy,rk2023-panel", .data = _rk2023_info },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
--
2.34.1
Re: [PATCH V3 2/6] drm/panel: nv3051d: Hold panel in reset for unprepare
On 11/15/2023 4:17 PM, Chris Morgan wrote:
From: Chris Morgan
Improve the panel's ability to restore from suspend by holding the
panel in suspend after unprepare.
Fixes: b1d39f0f4264 ("drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel")
Signed-off-by: Chris Morgan
Thanks!
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/panel/panel-newvision-nv3051d.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index 79de6c886292..c44c6945662f 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -261,6 +261,8 @@ static int panel_nv3051d_unprepare(struct drm_panel *panel)
usleep_range(1, 15000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->vdd);
return 0;
--
2.34.1
[PATCH V3 2/6] drm/panel: nv3051d: Hold panel in reset for unprepare
From: Chris Morgan
Improve the panel's ability to restore from suspend by holding the
panel in suspend after unprepare.
Fixes: b1d39f0f4264 ("drm/panel: Add NewVision NV3051D MIPI-DSI LCD panel")
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-newvision-nv3051d.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index 79de6c886292..c44c6945662f 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -261,6 +261,8 @@ static int panel_nv3051d_unprepare(struct drm_panel *panel)
usleep_range(1, 15000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->vdd);
return 0;
--
2.34.1
[PATCH V3 5/6] arm64: dts: rockchip: Update powkiddy, rgb30 include to rk2023 DTSI
From: Chris Morgan
The Powkiddy RGB30 device is similar to the Anbernic RGxx3 series,
however there are several differences which require deleting nodes in
order to properly define the hardware. This was deemed unacceptable
for the RK2023, so instead create a common include file for the
Powkiddy RGB30 and the Powkiddy RK2023. The only notable difference
between these Powkiddy devices are the panel in use, the device
name, and the PLL_VPLL frequency necessary to support the different
panels.
Since the RK2023 was released on the market first, name the common
include file after it.
Signed-off-by: Chris Morgan
---
.../dts/rockchip/rk3566-powkiddy-rgb30.dts| 154 +--
.../dts/rockchip/rk3566-powkiddy-rk2023.dtsi | 875 ++
2 files changed, 891 insertions(+), 138 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
index 1ead3c5c24b3..0ac64f043b80 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
@@ -5,67 +5,11 @@
#include
#include
#include
-#include "rk3566-anbernic-rg353x.dtsi"
+#include "rk3566-powkiddy-rk2023.dtsi"
/ {
model = "RGB30";
compatible = "powkiddy,rgb30", "rockchip,rk3566";
-
- aliases {
- mmc1 =
- mmc2 =
- mmc3 =
- };
-
- battery: battery {
- compatible = "simple-battery";
- charge-full-design-microamp-hours = <3151000>;
- charge-term-current-microamp = <30>;
- constant-charge-current-max-microamp = <200>;
- constant-charge-voltage-max-microvolt = <425>;
- factory-internal-resistance-micro-ohms = <117000>;
- voltage-max-design-microvolt = <4172000>;
- voltage-min-design-microvolt = <340>;
-
- ocv-capacity-celsius = <20>;
- ocv-capacity-table-0 = <4172000 100>, <4092000 95>, <4035000
90>, <399 85>,
- <3939000 80>, <3895000 75>, <3852000
70>, <3807000 65>,
- <3762000 60>, <3713000 55>, <3672000
50>, <3647000 45>,
- <3629000 40>, <3613000 35>, <3598000
30>, <3578000 25>,
- <355 20>, <3519000 15>, <3479000
10>, <3438000 5>,
- <340 0>;
- };
-
- /*
-* Channels reversed for speakers. Headphones automatically switch via
hardware when
-* detected with no ability to control output in software. Headphones
appear to be mono
-* (each output channel receives all audio). No microphone support on
3.5mm jack.
-*/
- sound {
- compatible = "simple-audio-card";
- simple-audio-card,name = "rk817_ext";
- simple-audio-card,format = "i2s";
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,widgets =
- "Headphone", "Headphones";
- simple-audio-card,routing =
- "Headphones", "HPOL",
- "Headphones", "HPOR";
-
- simple-audio-card,codec {
- sound-dai = <>;
- };
-
- simple-audio-card,cpu {
- sound-dai = <_8ch>;
- };
- };
-};
-
-/delete-node/ _keys;
-
- {
- /delete-property/ stdout-path;
};
{
@@ -75,87 +19,21 @@ {
<2>, <29250>;
};
-_keys_control {
- button-r1 {
- gpios = < RK_PB3 GPIO_ACTIVE_LOW>;
- label = "TR";
- linux,code = ;
- };
-
- button-r2 {
- gpios = < RK_PB4 GPIO_ACTIVE_LOW>;
- label = "TR2";
- linux,code = ;
- };
-};
-
-/delete-node/ &{/i2c@fdd4/regulator@40};
-
- {
- vdd_cpu: regulator@1c {
- compatible = "tcs,tcs4525";
- reg = <0x1c>;
- fcs,suspend-voltage-selector = <1>;
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <712500>;
- regulator-max-microvolt = <139>;
- regulator-name = "vdd_cpu";
- regulator-ramp-delay = <2300>;
- vin-supply = <_sys>;
- regulator-state-mem {
- regulator-off-in-suspend;
+ {
+ panel: panel@0 {
+ compatible = "powkiddy,rgb30-panel";
+ reg = <0>;
+ backlight = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_rst>;
+ reset-gpios = < RK_PA0 GPIO_ACTIVE_LOW>;
+ vcc-supply = <_lcd0_n>;
+
[PATCH V3 6/6] dt-bindings: arm: rockchip: Add Powkiddy RK2023
From: Chris Morgan
Add support for the Powkiddy RK2023. The Powkiddy RK2023 is a handheld
gaming device with a 3.5 inch screen powered by the Rockchip RK3566
SoC. The device looks physically different from the Powkiddy RGB30,
but is functionally identical except for the panel.
Signed-off-by: Chris Morgan
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3566-powkiddy-rk2023.dts | 38 +++
2 files changed, 39 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index a18f33bf0c0e..f969618da352 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rk2023.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-radxa-cm3-io.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
new file mode 100644
index ..ba32d0793dca
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3566-powkiddy-rk2023.dtsi"
+
+/ {
+ model = "RK2023";
+ compatible = "powkiddy,rk2023", "rockchip,rk3566";
+};
+
+ {
+ assigned-clocks = < CLK_RTC_32K>, < PLL_GPLL>,
+ < PLL_PPLL>, < PLL_VPLL>;
+ assigned-clock-rates = <32768>, <12>,
+ <2>, <11520>;
+};
+
+ {
+ panel: panel@0 {
+ compatible = "powkiddy,rk2023-panel", "newvision,nv3051d";
+ reg = <0>;
+ backlight = <>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_rst>;
+ reset-gpios = < RK_PA0 GPIO_ACTIVE_LOW>;
+ vdd-supply = <_lcd0_n>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+};
--
2.34.1
[PATCH V3 4/6] dt-bindings: arm: rockchip: Add Powkiddy RK2023
From: Chris Morgan The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC. Group the Powkiddy RK3566 based devices together as they are both extremely similar. Signed-off-by: Chris Morgan Acked-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/rockchip.yaml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5f7c6c4aad8f..5b015c4ed775 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -674,9 +674,11 @@ properties: - const: pine64,soquartz - const: rockchip,rk3566 - - description: Powkiddy RGB30 + - description: Powkiddy RK3566 Handheld Gaming Console items: - - const: powkiddy,rgb30 + - enum: + - powkiddy,rgb30 + - powkiddy,rk2023 - const: rockchip,rk3566 - description: Radxa Compute Module 3(CM3) -- 2.34.1
[PATCH V3 3/6] nv3051d: Add Powkiddy RK2023 Panel Support
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of these panels are identical in
size (70x57) it is possible future panels may not be.
Tested on my RG351V, RG353P, RG353V, and RK2023.
Signed-off-by: Chris Morgan
---
.../gpu/drm/panel/panel-newvision-nv3051d.c | 55 +++
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index c44c6945662f..94d89ffd596b 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_flags;
+ u32 mode_flags;
};
struct panel_nv3051d {
@@ -387,15 +388,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
- /*
-* The panel in the RG351V is identical to the 353P, except it
-* requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-*/
- if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
- dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = ctx->panel_info->mode_flags;
drm_panel_init(>panel, >dev, _nv3051d_funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -483,16 +476,56 @@ static const struct drm_display_mode
nv3051d_rgxx3_modes[] = {
},
};
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+ {
+ .hdisplay = 640,
+ .hsync_start= 640 + 40,
+ .hsync_end = 640 + 40 + 2,
+ .htotal = 640 + 40 + 2 + 80,
+ .vdisplay = 480,
+ .vsync_start= 480 + 18,
+ .vsync_end = 480 + 18 + 2,
+ .vtotal = 480 + 18 + 2 + 4,
+ .clock = 24150,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ },
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
.display_modes = nv3051d_rgxx3_modes,
.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
.width_mm = 70,
.height_mm = 57,
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+ .display_modes = nv3051d_rgxx3_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+ .display_modes = nv3051d_rk2023_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
};
static const struct of_device_id newvision_nv3051d_of_match[] = {
- { .compatible = "newvision,nv3051d", .data = _rgxx3_info },
+ { .compatible = "anbernic,rg351v-panel", .data = _rg351v_info },
+ { .compatible = "anbernic,rg353p-panel", .data = _rg353p_info },
+ { .compatible = "powkiddy,rk2023-panel", .data = _rk2023_info },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
--
2.34.1
[PATCH V3 1/6] dt-bindings: display: panel: Update NewVision NV3051D compatibles
From: Chris Morgan Update the NewVision NV3051D compatible strings by adding a new panel, the powkiddy,rk2023-panel, and removing another entry, the anbernic,rg353v-panel. The rk2023-panel is similar to the rg353p-panel but has slightly different timings so it needs a new string. The rg353v-panel is duplicate to the rg353p-panel, so remove it. No current devices use it and changes to the driver mean it is no longer valid as a compatible string. Signed-off-by: Chris Morgan --- .../devicetree/bindings/display/panel/newvision,nv3051d.yaml| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml index cce775a87f87..7a634fbc465e 100644 --- a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml +++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml @@ -21,7 +21,7 @@ properties: - enum: - anbernic,rg351v-panel - anbernic,rg353p-panel - - anbernic,rg353v-panel + - powkiddy,rk2023-panel - const: newvision,nv3051d reg: true -- 2.34.1
[PATCH V3 0/6] rockchip: Add Powkiddy RK2023
From: Chris Morgan Add support for the Powkiddy RK2023, which is extremely similar to existing Powkiddy RGB30 device. Changes since V2: - Split "hold panel in reset" to a separate patch for the NV3051D. - Changed replaced common include to a new Powkiddy specific include to better reflect the similarity of these two devices (and so as to not have to delete so many nodes). Changes since V1: - Necessary clock changes have been accepted to mainline, so removed from this series. https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=f1db0865b4628d5e2e85347350c077a71f0629d2 - Combined Powkiddy RK3566 devices in devicetree documentation. Dropped ack from binding as this change is vastly different than the previous update. - Updated panel driver to hold panel in reset status after unprepare. Chris Morgan (6): dt-bindings: display: panel: Update NewVision NV3051D compatibles drm/panel: nv3051d: Hold panel in reset for unprepare nv3051d: Add Powkiddy RK2023 Panel Support dt-bindings: arm: rockchip: Add Powkiddy RK2023 arm64: dts: rockchip: Update powkiddy,rgb30 include to rk2023 DTSI dt-bindings: arm: rockchip: Add Powkiddy RK2023 .../devicetree/bindings/arm/rockchip.yaml | 6 +- .../display/panel/newvision,nv3051d.yaml | 2 +- arch/arm64/boot/dts/rockchip/Makefile | 1 + .../dts/rockchip/rk3566-powkiddy-rgb30.dts| 154 +-- .../dts/rockchip/rk3566-powkiddy-rk2023.dts | 38 + .../dts/rockchip/rk3566-powkiddy-rk2023.dtsi | 875 ++ .../gpu/drm/panel/panel-newvision-nv3051d.c | 57 +- 7 files changed, 981 insertions(+), 152 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rk2023.dtsi -- 2.34.1
Re: [PATCH v2 8/8] dma-buf: heaps: secure_heap: Add normal CMA heap
You should drop this patch completely.
On Sat, Nov 11, 2023 at 3:18 AM Yong Wu wrote:
>
> Add a normal CMA heap which use the standard cma allocate.
>
> Signed-off-by: Yong Wu
> ---
> Hi Vijay and Jaskaran,
>
> For this heap,
> 1) It uses sec_heap_buf_ops currently. I guess we cann't use the
> cma_heap_buf_ops. since if it is secure buffer, some operations such
> as mmap should not be allowed.
> 2) I didn't add how to protect/secure the buffer.
>
> Please feel free to change to meet your requirements.
> Thanks.
> ---
> drivers/dma-buf/heaps/secure_heap.c | 38 -
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> index f8b84fd16288..8989ad5d03e9 100644
> --- a/drivers/dma-buf/heaps/secure_heap.c
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -43,6 +43,8 @@ enum secure_buffer_tee_cmd { /* PARAM NUM always is 4. */
> };
>
> enum secure_memory_type {
> + /* CMA for the secure memory, Use the normal cma ops to alloc/free. */
> + SECURE_MEMORY_TYPE_CMA = 0,
> /*
> * MediaTek static chunk memory carved out for TrustZone. The memory
> * management is inside the TEE.
> @@ -65,6 +67,7 @@ struct secure_buffer {
> * a value got from TEE.
> */
> u32 sec_handle;
> + struct page *cma_page;
> };
>
> #define TEE_MEM_COMMAND_ID_BASE_MTK0x1
> @@ -287,6 +290,33 @@ const struct secure_heap_prv_data mtk_sec_mem_data = {
> .unsecure_the_memory= secure_heap_tee_unsecure_memory,
> };
>
> +static int cma_secure_memory_allocate(struct secure_heap *sec_heap,
> + struct secure_buffer *sec_buf)
> +{
> + if (!sec_heap->cma)
> + return -EINVAL;
> +
> + sec_buf->cma_page = cma_alloc(sec_heap->cma, sec_buf->size >>
> PAGE_SHIFT,
> + get_order(PAGE_SIZE), false);
> + if (!sec_buf->cma_page)
> + return -ENOMEM;
> +
> + memset(page_address(sec_buf->cma_page), 0, sec_buf->size);
> + return 0;
> +}
> +
> +static void cma_secure_memory_free(struct secure_heap *sec_heap,
> + struct secure_buffer *sec_buf)
> +{
> + cma_release(sec_heap->cma, sec_buf->cma_page, sec_buf->size >>
> PAGE_SHIFT);
> +}
> +
> +const struct secure_heap_prv_data cma_sec_mem_data = {
> + .memory_alloc = cma_secure_memory_allocate,
> + .memory_free= cma_secure_memory_free,
> + /* TODO : secure the buffer. */
> +};
> +
> static int secure_heap_secure_memory_allocate(struct secure_heap *sec_heap,
> struct secure_buffer *sec_buf)
> {
> @@ -496,6 +526,11 @@ static const struct dma_heap_ops sec_heap_ops = {
> };
>
> static struct secure_heap secure_heaps[] = {
> + {
> + .name = "secure_cma",
> + .mem_type = SECURE_MEMORY_TYPE_CMA,
> + .data = _sec_mem_data,
> + },
> {
> .name = "secure_mtk_cm",
> .mem_type = SECURE_MEMORY_TYPE_MTK_CM_TZ,
> @@ -522,7 +557,8 @@ static int __init secure_cma_init(struct reserved_mem
> *rmem)
> }
>
> for (i = 0; i < ARRAY_SIZE(secure_heaps); i++, sec_heap++) {
> - if (sec_heap->mem_type != SECURE_MEMORY_TYPE_MTK_CM_CMA)
> + if (sec_heap->mem_type != SECURE_MEMORY_TYPE_MTK_CM_CMA &&
> + sec_heap->mem_type != SECURE_MEMORY_TYPE_CMA)
> continue;
>
> sec_heap->cma = sec_cma;
> --
> 2.25.1
>
Re: [PATCH v2 7/8] dma_buf: heaps: secure_heap: Add a new MediaTek CMA heap
Most of the things in this patch should go in the MTK specific
implementation (except for the secure_heap_init changes). Especially
the RESERVEDMEM_OF_DECLARE.
On Sat, Nov 11, 2023 at 3:18 AM Yong Wu wrote:
>
> Create a new MediaTek CMA heap from the CMA reserved buffer.
>
> In this heap, When the first allocating buffer, use cma_alloc to prepare
> whole the CMA range, then send its range to TEE to protect and manage.
> For the later allocating, we just adds the cma_used_size_mtk.
>
> This CMA flow may be different with the normal CMA heap of next patch.
> So I named the variable with _mtk suffix like cma_page_mtk/
> cma_used_size_mtk. This is also to distinguish it from the cma_page of
> the buffer structure in the next patch.
>
> When SVP done, cma_release will release the buffer, then kernel may
> reuse it.
>
> Meanwhile, this patch adds a "heap_init" pointer, while allows some heap
> initialization operations. This case also checks if the CMA range is
> ready.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/secure_heap.c | 124 +++-
> 1 file changed, 122 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> index 25cc95442c56..f8b84fd16288 100644
> --- a/drivers/dma-buf/heaps/secure_heap.c
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -4,11 +4,12 @@
> *
> * Copyright (C) 2023 MediaTek Inc.
> */
> -
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -25,6 +26,8 @@ enum secure_buffer_tee_cmd { /* PARAM NUM always is 4. */
> * [in] value[0].a: The buffer size.
> * value[0].b: alignment.
> * [in] value[1].a: enum secure_memory_type.
> +* [in] value[2].a: pa base in cma case.
> +* value[2].b: The buffer size in cma case.
> * [out] value[3].a: The secure handle.
> */
> TZCMD_SECMEM_ZALLOC = 0,
> @@ -45,6 +48,13 @@ enum secure_memory_type {
> * management is inside the TEE.
> */
> SECURE_MEMORY_TYPE_MTK_CM_TZ= 1,
> + /*
> +* MediaTek dynamic chunk memory carved out from CMA.
> +* In normal case, the CMA could be used in kernel; When SVP start,
> we will
> +* allocate whole this CMA and pass whole the CMA PA and size into
> TEE to
> +* protect it, then the detail memory management also is inside the
> TEE.
> +*/
> + SECURE_MEMORY_TYPE_MTK_CM_CMA = 2,
> };
>
> struct secure_buffer {
> @@ -70,6 +80,7 @@ struct secure_heap_prv_data {
> */
> const int tee_command_id_base;
>
> + int (*heap_init)(struct secure_heap *sec_heap);
> int (*memory_alloc)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> void(*memory_free)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
>
> @@ -86,6 +97,13 @@ struct secure_heap {
> u32 tee_session;
>
> const struct secure_heap_prv_data *data;
> +
> + struct cma *cma;
> + struct page *cma_page_mtk;
> + unsigned long cma_paddr;
> + unsigned long cma_size;
> + unsigned long cma_used_size_mtk;
> + struct mutexlock; /* lock for cma_used_size_mtk */
> };
>
> struct secure_heap_attachment {
> @@ -168,7 +186,10 @@ static int secure_heap_tee_secure_memory(struct
> secure_heap *sec_heap,
> params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> params[1].u.value.a = sec_heap->mem_type;
> params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> -
> + if (sec_heap->cma && sec_heap->mem_type ==
> SECURE_MEMORY_TYPE_MTK_CM_CMA) {
> + params[2].u.value.a = sec_heap->cma_paddr;
> + params[2].u.value.b = sec_heap->cma_size;
> + }
> params[3].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
> ret = secure_heap_tee_service_call(sec_heap->tee_ctx,
> sec_heap->tee_session,
>data->tee_command_id_base +
> TZCMD_SECMEM_ZALLOC,
> @@ -197,6 +218,66 @@ static void secure_heap_tee_unsecure_memory(struct
> secure_heap *sec_heap,
>sec_heap->name, sec_buf->sec_handle,
> params[1].u.value.a);
> }
>
> +static int mtk_secure_memory_cma_allocate(struct secure_heap *sec_heap,
> + struct secure_buffer *sec_buf)
> +{
> + /*
> +* Allocate CMA only when allocating buffer for the first time, and
> just
> +* increase cma_used_size_mtk at the other time.
> +*/
> + mutex_lock(_heap->lock);
> + if (sec_heap->cma_used_size_mtk)
> + goto add_size;
> +
> + mutex_unlock(_heap->lock);
> + sec_heap->cma_page_mtk = cma_alloc(sec_heap->cma, sec_heap->cma_size
> >>
Re: [PATCH v2 6/8] dt-bindings: reserved-memory: Add secure CMA reserved memory range
May I suggest the following for the device tree binding? (I'm not very
familiar w/ device trees, so apologies for any oversights, but trying
to process the feedback here and help move Mediatek along). This
should align with my other suggestions for having an MTK specific
portion to their secure heap implementation; which also means there
should be an MTK specific device tree binding.
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id:
http://devicetree.org/schemas/reserved-memory/mediatek,dynamic-secure-region.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mediatek Dynamic Reserved Region
description:
A memory region that can dynamically transition as a whole between
secure and non-secure states. This memory will be protected by OP-TEE
when allocations are active and unprotected otherwise.
maintainers:
- Yong Wu
allOf:
- $ref: reserved-memory.yaml
properties:
compatible:
const: mediatek,dynamic-secure-region
required:
- compatible
- reg
- reusable
unevaluatedProperties: false
examples:
- |
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
reserved-memory@8000 {
compatible = "mediatek,dynamic-secure-region";
reusable;
reg = <0x8000 0x1800>;
};
};
On Tue, Nov 14, 2023 at 5:18 AM Robin Murphy wrote:
>
> On 13/11/2023 6:37 am, Yong Wu (吴勇) wrote:
> [...]
> >>> +properties:
> >>> + compatible:
> >>> +const: secure_cma_region
> >>
> >> Still wrong compatible. Look at other bindings - there is nowhere
> >> underscore. Look at other reserved memory bindings especially.
> >>
> >> Also, CMA is a Linux thingy, so either not suitable for bindings at
> >> all,
> >> or you need Linux specific compatible. I don't quite get why do you
> >> evennot
> >> put CMA there - adding Linux specific stuff will get obvious
> >> pushback...
> >
> > Thanks. I will change to: secure-region. Is this ok?
>
> No, the previous discussion went off in entirely the wrong direction. To
> reiterate, the point of the binding is not to describe the expected
> usage of the thing nor the general concept of the thing, but to describe
> the actual thing itself. There are any number of different ways software
> may interact with a "secure region", so that is meaningless as a
> compatible. It needs to describe *this* secure memory interface offered
> by *this* TEE, so that software knows that to use it requires making
> those particular SiP calls with that particular UUID etc.
>
> Thanks,
> Robin.
Re: [PATCH v2 4/8] dma-buf: heaps: secure_heap: Add tee memory service call
On Sat, Nov 11, 2023 at 3:17 AM Yong Wu wrote:
>
> Add TEE service call. In the case of MediaTek, secure memory management is
> located within the TEE. The kernel just needs to tell TEE what size it
> needs and the TEE will return a "security handle" to kernel.
>
> To be consistent with the cma heap later, we put the tee ops into the ops
> of secure_the_memory.
>
> It seems that secure_heap_tee_service_call could be a more general
> interface, but it could be a new topic.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/secure_heap.c | 97 +
> 1 file changed, 97 insertions(+)
>
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> index 2a037fc54004..05062c14e7c7 100644
> --- a/drivers/dma-buf/heaps/secure_heap.c
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -17,6 +17,27 @@
>
> #define TEE_PARAM_NUM 4
>
> +enum secure_buffer_tee_cmd { /* PARAM NUM always is 4. */
> + /*
> +* TZCMD_SECMEM_ZALLOC: Allocate the zeroed secure memory from TEE.
> +*
> +* [in] value[0].a: The buffer size.
> +* value[0].b: alignment.
> +* [in] value[1].a: enum secure_memory_type.
> +* [out] value[3].a: The secure handle.
> +*/
> + TZCMD_SECMEM_ZALLOC = 0,
> +
> + /*
> +* TZCMD_SECMEM_FREE: Free secure memory.
> +*
> +* [in] value[0].a: The secure handle of this buffer, It's
> value[3].a of
> +* TZCMD_SECMEM_ZALLOC.
> +* [out] value[1].a: return value, 0 means successful, otherwise fail.
> +*/
> + TZCMD_SECMEM_FREE = 1,
> +};
> +
This should go in the MTK specific implementation.
> enum secure_memory_type {
> /*
> * MediaTek static chunk memory carved out for TrustZone. The memory
> @@ -28,13 +49,25 @@ enum secure_memory_type {
> struct secure_buffer {
> struct dma_heap *heap;
> size_t size;
> + /*
> +* The secure handle is a reference to a buffer within the TEE, this
> is
> +* a value got from TEE.
> +*/
> + u32 sec_handle;
> };
Change this to a u64 and rename it to 'secure_address', it's up to the
specific implementation what that would actually mean.
>
> +#define TEE_MEM_COMMAND_ID_BASE_MTK0x1
> +
Move this into the MTK specific implementation.
> struct secure_heap;
>
> struct secure_heap_prv_data {
> const char *uuid;
> const int tee_impl_id;
> + /*
> +* Different TEEs may implement different commands, and this provides
> an opportunity
> +* for TEEs to use the same enum secure_buffer_tee_cmd.
> +*/
> + const int tee_command_id_base;
Remove this, it can be handled in the MTK specific implementation.
>
> int (*memory_alloc)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> void(*memory_free)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> @@ -98,10 +131,74 @@ static int secure_heap_tee_session_init(struct
> secure_heap *sec_heap)
> return ret;
> }
>
> +static int
> +secure_heap_tee_service_call(struct tee_context *tee_ctx, u32 session,
> +unsigned int command, struct tee_param *params)
> +{
> + struct tee_ioctl_invoke_arg arg = {0};
> + int ret;
> +
> + arg.num_params = TEE_PARAM_NUM;
> + arg.session = session;
> + arg.func = command;
> +
> + ret = tee_client_invoke_func(tee_ctx, , params);
> + if (ret < 0 || arg.ret) {
> + pr_err("%s: cmd %d ret %d:%x.\n", __func__, command, ret,
> arg.ret);
> + ret = -EOPNOTSUPP;
> + }
> + return ret;
> +}
> +
> +static int secure_heap_tee_secure_memory(struct secure_heap *sec_heap,
> +struct secure_buffer *sec_buf)
> +{
> + const struct secure_heap_prv_data *data = sec_heap->data;
> + struct tee_param params[TEE_PARAM_NUM] = {0};
> + int ret;
> +
> + params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> + params[0].u.value.a = sec_buf->size;
> + params[0].u.value.b = PAGE_SIZE;
> + params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> + params[1].u.value.a = sec_heap->mem_type;
> + params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> +
> + params[3].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
> + ret = secure_heap_tee_service_call(sec_heap->tee_ctx,
> sec_heap->tee_session,
> + data->tee_command_id_base +
> TZCMD_SECMEM_ZALLOC,
> + params);
> + if (ret)
> + return -ENOMEM;
> +
> + sec_buf->sec_handle = params[3].u.value.a;
> + return 0;
> +}
> +
> +static void
Re: [PATCH v2 3/8] dma-buf: heaps: secure_heap: Initialize tee session
Everything in this patch set should move into the MTK specific
implementation I suggested in patch 1 (secure_heap_mtk.c)
On Sat, Nov 11, 2023 at 3:17 AM Yong Wu wrote:
>
> The TEE probe later than dma-buf heap, and PROBE_DEDER doesn't work
> here since this is not a platform driver, therefore initialize the TEE
> context/session while we allocate the first secure buffer.
>
> Add our special UUID and tee type in the private data.
>
> If the uuid is zero, it means that it doesn't enter TEE to protect the
> buffer, there may be other ways to protect the buffer.
>
> All the MTK chrome projects use this UUID. The UUID is only used in the
> kernelspace while userspace never use it. The userspace could allocate the
> secure memory via the existing dma-buf ioctl.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/secure_heap.c | 75 +
> 1 file changed, 75 insertions(+)
>
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> index 87ac23072e9e..2a037fc54004 100644
> --- a/drivers/dma-buf/heaps/secure_heap.c
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -10,6 +10,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +
> +#define TZ_TA_MEM_UUID_MTK "4477588a-8476-11e2-ad15-e41f1390d676"
> +
> +#define TEE_PARAM_NUM 4
>
> enum secure_memory_type {
> /*
> @@ -27,6 +33,9 @@ struct secure_buffer {
> struct secure_heap;
>
> struct secure_heap_prv_data {
> + const char *uuid;
> + const int tee_impl_id;
> +
> int (*memory_alloc)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> void(*memory_free)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
>
> @@ -39,9 +48,62 @@ struct secure_heap {
> const char *name;
> const enum secure_memory_type mem_type;
>
> + struct tee_context *tee_ctx;
> + u32 tee_session;
> +
> const struct secure_heap_prv_data *data;
> };
>
> +static int tee_ctx_match(struct tee_ioctl_version_data *ver, const void
> *data)
> +{
> + const struct secure_heap_prv_data *d = data;
> +
> + return ver->impl_id == d->tee_impl_id;
> +}
> +
> +static int secure_heap_tee_session_init(struct secure_heap *sec_heap)
> +{
> + struct tee_param t_param[TEE_PARAM_NUM] = {0};
> + struct tee_ioctl_open_session_arg arg = {0};
> + const struct secure_heap_prv_data *data = sec_heap->data;
> + uuid_t ta_mem_uuid;
> + int ret;
> +
> + sec_heap->tee_ctx = tee_client_open_context(NULL, tee_ctx_match,
> data, NULL);
> + if (IS_ERR(sec_heap->tee_ctx)) {
> + pr_err_once("%s: open context failed, ret=%ld\n",
> sec_heap->name,
> + PTR_ERR(sec_heap->tee_ctx));
> + return -ENODEV;
> + }
> +
> + arg.num_params = TEE_PARAM_NUM;
> + arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
> + ret = uuid_parse(data->uuid, _mem_uuid);
> + if (ret)
> + goto close_context;
> + memcpy(, _mem_uuid.b, sizeof(ta_mem_uuid));
> +
> + ret = tee_client_open_session(sec_heap->tee_ctx, , t_param);
> + if (ret < 0 || arg.ret) {
> + pr_err_once("%s: open session failed, ret=%d:%d\n",
> + sec_heap->name, ret, arg.ret);
> + ret = -EINVAL;
> + goto close_context;
> + }
> + sec_heap->tee_session = arg.session;
> + return 0;
> +
> +close_context:
> + tee_client_close_context(sec_heap->tee_ctx);
> + return ret;
> +}
> +
> +/* The memory allocating is within the TEE. */
> +const struct secure_heap_prv_data mtk_sec_mem_data = {
> + .uuid = TZ_TA_MEM_UUID_MTK,
> + .tee_impl_id= TEE_IMPL_ID_OPTEE,
> +};
> +
> static int secure_heap_secure_memory_allocate(struct secure_heap *sec_heap,
> struct secure_buffer *sec_buf)
> {
> @@ -84,11 +146,23 @@ secure_heap_allocate(struct dma_heap *heap, unsigned
> long size,
> unsigned long fd_flags, unsigned long heap_flags)
> {
> struct secure_heap *sec_heap = dma_heap_get_drvdata(heap);
> + const struct secure_heap_prv_data *data = sec_heap->data;
> struct secure_buffer *sec_buf;
> DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> struct dma_buf *dmabuf;
> int ret;
>
> + /*
> +* If uuid is valid, It requires enter TEE to protect buffers. However
> +* TEE probe may be late. Initialize the secure session the first time
> +* we request the secure buffer.
> +*/
> + if (data->uuid && !sec_heap->tee_session) {
> + ret = secure_heap_tee_session_init(sec_heap);
> + if (ret)
> + return ERR_PTR(ret);
> +
Re: [PATCH v2 2/8] dma-buf: heaps: secure_heap: Add private heap ops
On Sat, Nov 11, 2023 at 3:16 AM Yong Wu wrote:
>
> For the secure memory, there are two steps:
> a) Allocate buffers in kernel side;
> b) Secure that buffer.
> Different heaps may have different buffer allocation methods and
> different memory protection methods. Here abstract the memory
> allocation and securing operations.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/secure_heap.c | 58 -
> 1 file changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> index a634051a0a67..87ac23072e9e 100644
> --- a/drivers/dma-buf/heaps/secure_heap.c
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -24,15 +24,66 @@ struct secure_buffer {
> size_t size;
> };
>
> +struct secure_heap;
> +
> +struct secure_heap_prv_data {
> + int (*memory_alloc)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> + void(*memory_free)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> +
> + /* Protect/unprotect the memory */
> + int (*secure_the_memory)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> + void(*unsecure_the_memory)(struct secure_heap *sec_heap, struct
> secure_buffer *sec_buf);
> +};
Move these into dma-heap-secure.h per the comments on the prior patch.
> +
> struct secure_heap {
> const char *name;
> const enum secure_memory_type mem_type;
> +
> + const struct secure_heap_prv_data *data;
> };
>
> +static int secure_heap_secure_memory_allocate(struct secure_heap *sec_heap,
> + struct secure_buffer *sec_buf)
> +{
> + const struct secure_heap_prv_data *data = sec_heap->data;
> + int ret;
> +
> + if (data->memory_alloc) {
> + ret = data->memory_alloc(sec_heap, sec_buf);
> + if (ret)
> + return ret;
> + }
You should probably always require that memory_alloc is defined
(secure_the_memory can be optional, as that may be part of the
allocation).
> +
> + if (data->secure_the_memory) {
> + ret = data->secure_the_memory(sec_heap, sec_buf);
> + if (ret)
> + goto sec_memory_free;
> + }
> + return 0;
> +
> +sec_memory_free:
> + if (data->memory_free)
> + data->memory_free(sec_heap, sec_buf);
You should probably always require that memory_free is defined.
> + return ret;
> +}
> +
> +static void secure_heap_secure_memory_free(struct secure_heap *sec_heap,
> + struct secure_buffer *sec_buf)
> +{
> + const struct secure_heap_prv_data *data = sec_heap->data;
> +
> + if (data->unsecure_the_memory)
> + data->unsecure_the_memory(sec_heap, sec_buf);
> +
> + if (data->memory_free)
> + data->memory_free(sec_heap, sec_buf);
You should probably always require that memory_free is defined.
> +}
> +
> static struct dma_buf *
> secure_heap_allocate(struct dma_heap *heap, unsigned long size,
> unsigned long fd_flags, unsigned long heap_flags)
> {
> + struct secure_heap *sec_heap = dma_heap_get_drvdata(heap);
> struct secure_buffer *sec_buf;
> DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> struct dma_buf *dmabuf;
> @@ -45,6 +96,9 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long
> size,
> sec_buf->size = ALIGN(size, PAGE_SIZE);
> sec_buf->heap = heap;
>
> + ret = secure_heap_secure_memory_allocate(sec_heap, sec_buf);
> + if (ret)
> + goto err_free_buf;
> exp_info.exp_name = dma_heap_get_name(heap);
> exp_info.size = sec_buf->size;
> exp_info.flags = fd_flags;
> @@ -53,11 +107,13 @@ secure_heap_allocate(struct dma_heap *heap, unsigned
> long size,
> dmabuf = dma_buf_export(_info);
> if (IS_ERR(dmabuf)) {
> ret = PTR_ERR(dmabuf);
> - goto err_free_buf;
> + goto err_free_sec_mem;
> }
>
> return dmabuf;
>
> +err_free_sec_mem:
> + secure_heap_secure_memory_free(sec_heap, sec_buf);
> err_free_buf:
> kfree(sec_buf);
> return ERR_PTR(ret);
> --
> 2.25.1
>
Re: [PATCH v2 1/8] dma-buf: heaps: Initialize a secure heap
On Sat, Nov 11, 2023 at 3:16 AM Yong Wu wrote:
>
> Initialize a secure heap. Currently just add a null heap, Prepare for
> the later patches.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/Kconfig | 7 +++
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/secure_heap.c | 98 +
> 3 files changed, 106 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/secure_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06c4226..e358bf711145 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -12,3 +12,10 @@ config DMABUF_HEAPS_CMA
> Choose this option to enable dma-buf CMA heap. This heap is backed
> by the Contiguous Memory Allocator (CMA). If your system has these
> regions, you should say Y here.
> +
> +config DMABUF_HEAPS_SECURE
> + bool "DMA-BUF Secure Heap"
> + depends on DMABUF_HEAPS && TEE
> + help
> + Choose this option to enable dma-buf secure heap. This heap is
> backed by
> + TEE client interfaces or CMA. If in doubt, say N.
Remove the mention of TEE and CMA from this.
You should probably add two KConfig options. One is for
DMABUF_HEAPS_SECURE which is for the framework for secure heaps. The
other one should be:
config MTK_DMABUF_HEAPS_SECURE
bool "Mediatek DMA-BUF Secure Heap"
depends on DMABUF_HEAPS_SECURE && TEE
help
Enables secure dma-buf heaps for Mediatek platforms.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 974467791032..b1ad9d1f2fbe 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_DMABUF_HEAPS_SECURE) += secure_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> new file mode 100644
> index ..a634051a0a67
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF secure heap exporter
> + *
> + * Copyright (C) 2023 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum secure_memory_type {
> + /*
> +* MediaTek static chunk memory carved out for TrustZone. The memory
> +* management is inside the TEE.
> +*/
> + SECURE_MEMORY_TYPE_MTK_CM_TZ= 1,
Mediatek specific code for secure dma heaps should go into a new file
(maybe secure_heap_mtk.c which the MTK_DMABUF_HEAPS_SECURE option
enables).
> +};
> +
> +struct secure_buffer {
> + struct dma_heap *heap;
> + size_t size;
> +};
> +
> +struct secure_heap {
> + const char *name;
> + const enum secure_memory_type mem_type;
secure_memory_type is going to be in the vendor specific
implementation, I don't think you need it in the framework.
> +};
You should probably move these to a file so
they can be shared by the framework and the specific implementation
(in this case vendor specific).
> +
> +static struct dma_buf *
> +secure_heap_allocate(struct dma_heap *heap, unsigned long size,
> +unsigned long fd_flags, unsigned long heap_flags)
> +{
> + struct secure_buffer *sec_buf;
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dmabuf;
> + int ret;
> +
> + sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
> + if (!sec_buf)
> + return ERR_PTR(-ENOMEM);
> +
> + sec_buf->size = ALIGN(size, PAGE_SIZE);
> + sec_buf->heap = heap;
> +
> + exp_info.exp_name = dma_heap_get_name(heap);
> + exp_info.size = sec_buf->size;
> + exp_info.flags = fd_flags;
> + exp_info.priv = sec_buf;
> +
> + dmabuf = dma_buf_export(_info);
> + if (IS_ERR(dmabuf)) {
> + ret = PTR_ERR(dmabuf);
> + goto err_free_buf;
> + }
> +
> + return dmabuf;
> +
> +err_free_buf:
> + kfree(sec_buf);
> + return ERR_PTR(ret);
> +}
> +
> +static const struct dma_heap_ops sec_heap_ops = {
> + .allocate = secure_heap_allocate,
> +};
> +
> +static struct secure_heap secure_heaps[] = {
> + {
> + .name = "secure_mtk_cm",
> + .mem_type = SECURE_MEMORY_TYPE_MTK_CM_TZ,
> + },
> +};
Move this to the vendor specific implementation.
> +
> +static int secure_heap_init(void)
> +{
> + struct secure_heap *sec_heap = secure_heaps;
> + struct dma_heap_export_info exp_info;
> + struct dma_heap *heap;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(secure_heaps); i++, sec_heap++) {
> + exp_info.name = sec_heap->name;
> +
Re: [PATCH] drm/msm/gpu: Move gpu devcore's to gpu device
On 11/15/2023 2:44 PM, Rob Clark wrote: From: Rob Clark The dpu devcore's are already associated with the dpu device. So we should associate the gpu devcore's with the gpu device, for easier classification. Signed-off-by: Rob Clark Reviewed-by: Abhinav Kumar
[PATCH] drm/msm/gpu: Move gpu devcore's to gpu device
From: Rob Clark The dpu devcore's are already associated with the dpu device. So we should associate the gpu devcore's with the gpu device, for easier classification. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_gpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index cfcb4317afdb..3fad5d58262f 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -292,8 +292,7 @@ static void msm_gpu_crashstate_capture(struct msm_gpu *gpu, /* Set the active crash state to be dumped on failure */ gpu->crashstate = state; - /* FIXME: Release the crashstate if this errors out? */ - dev_coredumpm(gpu->dev->dev, THIS_MODULE, gpu, 0, GFP_KERNEL, + dev_coredumpm(>pdev->dev, THIS_MODULE, gpu, 0, GFP_KERNEL, msm_gpu_devcoredump_read, msm_gpu_devcoredump_free); } #else -- 2.41.0
Re: [RFC] drm/tests: annotate intentional stack trace in drm_test_rect_calc_hscale()
On Mon, Nov 06, 2023 at 02:58:12PM +0100, mrip...@kernel.org wrote: > > But a similar thing is happening here where we have so many bogus > > warnings that we missed a real bug. > > IIRC, there was a similar discussion for lockdep issues. IMO, any > (unintended) warning should trigger a test failure. > > I guess that would require adding some intrumentation to __WARN somehow, > and also allowing tests to check whether a warning had been generated > during their execution for tests that want to trigger one. I think this is a good idea. I was looking at how lockdep prints warnings (see print_circular_bug_header()). It doesn't use WARN() it prints a bunch of pr_warn() statements and then a stack trace. We would have to have a increment the counter manually in that situation. I'm writing a script to parse a dmesg and collect Oopses. So now I know to look for WARN(), lockdep, and KASAN. What other bugs formats do we have? Probably someone like the syzbot devs have already has written a script like this? regards, dan carpenter
Re: [PATCH V2 2/4] nv3051d: Add Powkiddy RK2023 Panel Support
On 11/9/2023 1:50 PM, Chris Morgan wrote:
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds. Note that while all of these panels are identical in
size (70x57) it is possible future panels may not be.
Tested on my RG351V, RG353P, RG353V, and RK2023.
Signed-off-by: Chris Morgan
---
.../gpu/drm/panel/panel-newvision-nv3051d.c | 57 +++
1 file changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index 79de6c886292..94d89ffd596b 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_flags;
+ u32 mode_flags;
};
struct panel_nv3051d {
@@ -261,6 +262,8 @@ static int panel_nv3051d_unprepare(struct drm_panel *panel)
usleep_range(1, 15000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
Hi Chris,
Is this to address a suspend/resume issue similar to what was done here [1]?
If so, I think maybe this can go as a separate Fixes patch.
Thanks,
Jessica Zhang
[1] https://patchwork.freedesktop.org/patch/567670/?series=126479=1
regulator_disable(ctx->vdd);
return 0;
@@ -385,15 +388,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
- /*
-* The panel in the RG351V is identical to the 353P, except it
-* requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-*/
- if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
- dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = ctx->panel_info->mode_flags;
drm_panel_init(>panel, >dev, _nv3051d_funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -481,16 +476,56 @@ static const struct drm_display_mode
nv3051d_rgxx3_modes[] = {
},
};
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+ {
+ .hdisplay = 640,
+ .hsync_start= 640 + 40,
+ .hsync_end = 640 + 40 + 2,
+ .htotal = 640 + 40 + 2 + 80,
+ .vdisplay = 480,
+ .vsync_start= 480 + 18,
+ .vsync_end = 480 + 18 + 2,
+ .vtotal = 480 + 18 + 2 + 4,
+ .clock = 24150,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ },
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
.display_modes = nv3051d_rgxx3_modes,
.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
.width_mm = 70,
.height_mm = 57,
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+ .display_modes = nv3051d_rgxx3_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+ .display_modes = nv3051d_rk2023_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
};
static const struct of_device_id newvision_nv3051d_of_match[] = {
- { .compatible = "newvision,nv3051d", .data = _rgxx3_info },
+ { .compatible = "anbernic,rg351v-panel", .data = _rg351v_info },
+ { .compatible = "anbernic,rg353p-panel", .data = _rg353p_info },
+ { .compatible = "powkiddy,rk2023-panel", .data = _rk2023_info },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
--
2.34.1
Re: [PATCH 4/4] drm/panel-elida-kd35t133: Drop prepare/unprepare logic
On 11/15/2023 7:26 AM, Chris Morgan wrote:
From: Chris Morgan
Drop the prepare/unprepare logic, as this is now tracked elsewhere.
Additionally, the driver shutdown is also duplicate as it calls
drm_unprepare and drm_disable which are called anyway when
associated drivers are shutdown/removed.
Hi Chris,
In the commit message, can you mention that this [1] was the change that
made tracking the prepared flag common?
Also, it seems to me that this patch squashes 2 different changes
together. Maybe we can split this into 2 patches -- one to drop the
prepared flag checks and another to drop shutdown().
Thanks,
Jessica Zhang
[1] d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
drm_panel")
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 28
1 file changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index 29b4ee63d83b..00791ea81e90 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -43,7 +43,6 @@ struct kd35t133 {
struct regulator *vdd;
struct regulator *iovcc;
enum drm_panel_orientation orientation;
- bool prepared;
};
static inline struct kd35t133 *panel_to_kd35t133(struct drm_panel *panel)
@@ -91,9 +90,6 @@ static int kd35t133_unprepare(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
- if (!ctx->prepared)
- return 0;
-
ret = mipi_dsi_dcs_set_display_off(dsi);
if (ret < 0)
dev_err(ctx->dev, "failed to set display off: %d\n", ret);
@@ -109,8 +105,6 @@ static int kd35t133_unprepare(struct drm_panel *panel)
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vdd);
- ctx->prepared = false;
-
return 0;
}
@@ -120,9 +114,6 @@ static int kd35t133_prepare(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
- if (ctx->prepared)
- return 0;
-
dev_dbg(ctx->dev, "Resetting the panel\n");
ret = regulator_enable(ctx->vdd);
if (ret < 0) {
@@ -166,8 +157,6 @@ static int kd35t133_prepare(struct drm_panel *panel)
msleep(50);
- ctx->prepared = true;
-
return 0;
disable_iovcc:
@@ -296,27 +285,11 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
return 0;
}
-static void kd35t133_shutdown(struct mipi_dsi_device *dsi)
-{
- struct kd35t133 *ctx = mipi_dsi_get_drvdata(dsi);
- int ret;
-
- ret = drm_panel_unprepare(>panel);
- if (ret < 0)
- dev_err(>dev, "Failed to unprepare panel: %d\n", ret);
-
- ret = drm_panel_disable(>panel);
- if (ret < 0)
- dev_err(>dev, "Failed to disable panel: %d\n", ret);
-}
-
static void kd35t133_remove(struct mipi_dsi_device *dsi)
{
struct kd35t133 *ctx = mipi_dsi_get_drvdata(dsi);
int ret;
- kd35t133_shutdown(dsi);
-
ret = mipi_dsi_detach(dsi);
if (ret < 0)
dev_err(>dev, "Failed to detach from DSI host: %d\n", ret);
@@ -337,7 +310,6 @@ static struct mipi_dsi_driver kd35t133_driver = {
},
.probe = kd35t133_probe,
.remove = kd35t133_remove,
- .shutdown = kd35t133_shutdown,
};
module_mipi_dsi_driver(kd35t133_driver);
--
2.34.1
Re: [Nouveau] [PATCH] nouveau: don't fail driver load if no display hw present.
Le mer. 15 nov. 2023 à 15:40, a écrit :
>
> From: Dave Airlie
>
> If we get back ENODEV don't fail load. There are nvidia devices
> that don't have display blocks and the driver should work on those.
>
> Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/270
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index d8c92521226d9..f28f9a8574586 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -726,6 +726,11 @@ nouveau_display_create(struct drm_device *dev)
>
> if (nouveau_modeset != 2) {
> ret = nvif_disp_ctor(>client.device, "kmsDisp", 0,
> >disp);
> + /* no display hw */
> + if (ret == -ENODEV) {
> + ret = 0;
> + goto disp_create_err;
> + }
>
> if (!ret && (disp->disp.outp_mask || drm->vbios.dcb.entries))
> {
> nouveau_display_create_properties(dev);
> --
> 2.41.0
I have tested this patch on top of 6.7-rc1+ and this doesn't change
the situation on jetson-tx1 (gm20b)
Could it be that something else similar is missing on arm64 ?
Thanks
Re: [PATCH v2 0/8] dma-buf: heaps: Add secure heap
The main goal is for secure video playback, and to also enable other potential uses of this in the future. The 'secure dma-heap' will be used to allocate dma_buf objects that reference memory in the secure world that is inaccessible/unmappable by the non-secure (i.e. kernel/userspace) world. That memory will be used by the secure world to store secure information (i.e. decrypted media content). The dma_bufs allocated from the kernel will be passed to V4L2 for video decoding (as input and output). They will also be used by the drm system for rendering of the content. Hope that helps. Cheers, Jeff On Mon, Nov 13, 2023 at 3:38 AM Pavel Machek wrote: > > Hi! > > > This patchset adds three secure heaps: > > 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path). > >The buffer is reserved for the secure world after bootup and it is used > >for vcodec's ES/working buffer; > > 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is > >dynamically reserved for the secure world and will be got when we start > >playing secure videos, Once the security video playing is complete, the > >CMA will be released. This heap is used for the vcodec's frame buffer. > > 3) secure_cma: Use the kerne CMA ops as the allocation ops. > >currently it is a draft version for Vijay and Jaskaran. > > Is there high-level description of what the security goals here are, > somewhere? > > BR, > Pavel > -- > People of Russia, stop Putin before his war on Ukraine escalates.
Re: [PATCH 3/4] drm/panel-elida-kd35t133: drop drm_connector_set_orientation_from_panel
On 11/15/2023 7:26 AM, Chris Morgan wrote: From: Chris Morgan Stop calling drm_connector_set_orientation_from_panel() as its now called by the panel bridge directly when it is initialized. Signed-off-by: Chris Morgan Reviewed-by: Jessica Zhang --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c index f1fc4a26f447..29b4ee63d83b 100644 --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c @@ -211,11 +211,6 @@ static int kd35t133_get_modes(struct drm_panel *panel, connector->display_info.width_mm = mode->width_mm; connector->display_info.height_mm = mode->height_mm; drm_mode_probed_add(connector, mode); - /* -* TODO: Remove once all drm drivers call -* drm_connector_set_orientation_from_panel() -*/ - drm_connector_set_panel_orientation(connector, ctx->orientation); return 1; } -- 2.34.1
Re: [PATCH 2/4] drm/panel-elida-kd35t133: hold panel in reset for unprepare
On 11/15/2023 7:26 AM, Chris Morgan wrote:
From: Chris Morgan
For devices like the Anbernic RG351M and RG351P the panel is wired to
an always on regulator. When the device suspends and wakes up, there
are some slight artifacts on the screen that go away over time. If
instead we hold the panel in reset status after it is unprepared,
this does not happen.
Hi Chris,
LGTM, though if this is fixing something maybe we can add
Fixes: 5b6603360c12 ("drm/panel: add panel driver for Elida KD35T133
panels")
Signed-off-by: Chris Morgan
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index 6cd8536c09ff..f1fc4a26f447 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -104,6 +104,8 @@ static int kd35t133_unprepare(struct drm_panel *panel)
return ret;
}
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vdd);
--
2.34.1
Re: [PATCH 1/4] drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5
On 11/15/2023 7:26 AM, Chris Morgan wrote: From: Chris Morgan The comments at the top of the driver state the panel size incorrectly as 5.5" instead of 3.5". Signed-off-by: Chris Morgan Reviewed-by: Jessica Zhang --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c index e7be15b68102..6cd8536c09ff 100644 --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Elida kd35t133 5.5" MIPI-DSI panel driver + * Elida kd35t133 3.5" MIPI-DSI panel driver * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH * * based on -- 2.34.1
Re: [PATCH 1/2] drm/i915/guc: Don't double enable a context
On 11/9/2023 4:54 PM, john.c.harri...@intel.com wrote:
From: John Harrison
If a context is blocked, unblocked and subitted repeatedly in rapid
succession, the driver can end up trying to enable the context while
the previous enable request is still in flight. This can lead to much
confusion in the state tracking.
Prevent that by checking the pending enable flag before trying to
enable a context.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d37698bd6b91a..d399e4d238c10 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -720,7 +720,7 @@ static int __guc_add_request(struct intel_guc *guc, struct
i915_request *rq)
if (unlikely(context_blocked(ce) && !intel_context_is_parent(ce)))
goto out;
- enabled = context_enabled(ce) || context_blocked(ce);
+ enabled = context_enabled(ce) || context_blocked(ce) ||
context_pending_enable(ce);
if (!enabled) {
action[len++] = INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET;
Re: [PATCH v3 7/7] PCI: Exclude PCIe ports used for virtual links in pcie_bandwidth_available()
On 11/15/2023 11:04, Mario Limonciello wrote:
On 11/14/2023 21:23, Lazar, Lijo wrote:
On 11/15/2023 1:37 AM, Mario Limonciello wrote:
The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
behave as a PCIe Gen1 device. The actual performance of these ports is
controlled by the fabric implementation.
Callers for pcie_bandwidth_available() will always find the PCIe ports
used for tunneling as a limiting factor potentially leading to incorrect
performance decisions.
To prevent such problems check explicitly for ports that are marked as
virtual links or as thunderbolt controllers and skip them when looking
for bandwidth limitations of the hierarchy. If the only device connected
is a port used for tunneling then report that device.
Callers to pcie_bandwidth_available() could make this change on their
own as well but then they wouldn't be able to detect other potential
speed bottlenecks from the hierarchy without duplicating
pcie_bandwidth_available() logic.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925#note_2145860
Link: https://www.usb.org/document-library/usb4r-specification-v20
USB4 V2 with Errata and ECN through June 2023
Section 11.2.1
Signed-off-by: Mario Limonciello
---
v2->v3:
* Split from previous patch version
* Look for thunderbolt or virtual link
---
drivers/pci/pci.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0ff7883cc774..b1fb2258b211 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6269,11 +6269,20 @@ static u32 pcie_calc_bw_limits(struct pci_dev
*dev, u32 bw,
* limiting_dev, speed, and width pointers are supplied)
information about
* that point. The bandwidth returned is in Mb/s, i.e.,
megabits/second of
* raw bandwidth.
+ *
+ * This excludes the bandwidth calculation that has been returned
from a
+ * PCIe device that is used for transmitting tunneled PCIe traffic
over a virtual
+ * link part of larger hierarchy. Examples include Thunderbolt3 and
USB4 links.
+ * The calculation is excluded because the USB4 specification
specifies that the
+ * max speed returned from PCIe configuration registers for the
tunneling link is
+ * always PCI 1x 2.5 GT/s. When only tunneled devices are present,
the bandwidth
+ * returned is the bandwidth available from the first tunneled device.
*/
u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev
**limiting_dev,
enum pci_bus_speed *speed,
enum pcie_link_width *width)
{
+ struct pci_dev *vdev = NULL;
u32 bw = 0;
if (speed)
@@ -6282,10 +6291,20 @@ u32 pcie_bandwidth_available(struct pci_dev
*dev, struct pci_dev **limiting_dev,
*width = PCIE_LNK_WIDTH_UNKNOWN;
while (dev) {
+ if (dev->is_virtual_link || dev->is_thunderbolt) {
+ if (!vdev)
+ vdev = dev;
+ goto skip;
+ }
One problem with this is it *silently* ignores the bandwidth limiting
device - the bandwidth may not be really available if there are
virtual links in between. That is a change in behavior from the
messages shown in __pcie_print_link_status.
That's a good point. How about a matching behavioral change to
__pcie_print_link_status() where it looks at the entire hierarchy for
any links marked as virtual and prints a message along the lines of:
"This value may be further limited by virtual links".
I'll wait for some more feedback on the series before posting another
version, but I did put this together and this is a sample from dmesg of
the wording I'm planning on using for the next version:
31.504 Gb/s available PCIe bandwidth, this may be further limited by
conditions of virtual link :00:03.1
Thanks,
Lijo
bw = pcie_calc_bw_limits(dev, bw, limiting_dev, speed, width);
+skip:
dev = pci_upstream_bridge(dev);
}
+ /* If nothing "faster" found on hierarchy, limit to first
virtual link */
+ if (vdev && !bw)
+ bw = pcie_calc_bw_limits(vdev, bw, limiting_dev, speed, width);
+
return bw;
}
EXPORT_SYMBOL(pcie_bandwidth_available);
Re: [PATCH] drm/doc/rfc: SR-IOV support on the new Xe driver
On 15.11.2023 11:00, Tvrtko Ursulin wrote: > > On 14/11/2023 16:55, Michal Wajdeczko wrote: >> On 14.11.2023 13:37, Tvrtko Ursulin wrote: >>> On 10/11/2023 18:22, Michal Wajdeczko wrote: The Single Root I/O Virtualization (SR-IOV) extension to the PCI Express (PCIe) specification suite is supported starting from 12th generation of Intel Graphics processors. This RFC aims to explain how do we want to add support for SR-IOV to the new Xe driver and to propose related additions to the sysfs. Signed-off-by: Michal Wajdeczko Cc: Oded Gabbay Cc: Rodrigo Vivi Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Cc: Daniel Vetter --- Documentation/gpu/rfc/index.rst | 5 + Documentation/gpu/rfc/sysfs-driver-xe-sriov | 501 Documentation/gpu/rfc/xe_sriov.rst | 192 3 files changed, 698 insertions(+) create mode 100644 Documentation/gpu/rfc/sysfs-driver-xe-sriov create mode 100644 Documentation/gpu/rfc/xe_sriov.rst diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index e4f7b005138d..fc5bc447f30d 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -35,3 +35,8 @@ host such documentation: .. toctree:: xe.rst + +.. toctree:: + :maxdepth: 1 + + xe_sriov.rst diff --git a/Documentation/gpu/rfc/sysfs-driver-xe-sriov b/Documentation/gpu/rfc/sysfs-driver-xe-sriov new file mode 100644 index ..77748204dd83 --- /dev/null +++ b/Documentation/gpu/rfc/sysfs-driver-xe-sriov @@ -0,0 +1,501 @@ +.. Documentation/ABI/testing/sysfs-driver-xe-sriov +.. +.. Intel Xe driver ABI (SR-IOV extensions) +.. + The Single Root I/O Virtualization (SR-IOV) extension to + the PCI Express (PCIe) specification suite is supported + starting from 12th generation of Intel Graphics processors. + + This document describes Xe driver specific additions. + + For description of generic SR-IOV sysfs attributes see + "Documentation/ABI/testing/sysfs-bus-pci" document. + + /sys/bus/pci/drivers/xe/BDF/ + ├── sriov_auto_provisioning + │ ├── admin_mode + │ ├── enabled + │ ├── reset_defaults + │ ├── resources + │ │ ├── default_contexts_quota + │ │ ├── default_doorbells_quota + │ │ ├── default_ggtt_quota + │ │ └── default_lmem_quota + │ ├── scheduling + │ │ ├── default_exec_quantum_ms + │ │ └── default_preempt_timeout_us + │ └── monitoring + │ ├── default_cat_error_count + │ ├── default_doorbell_time_us + │ ├── default_engine_reset_count + │ ├── default_h2g_time_us + │ ├── default_irq_time_us + │ └── default_page_fault_count >>> >>> From the department of bike-shedding, one alternative could be to >>> have a >>> directory called defaults which avoids having to have the default_ >>> prefix on everything under it. >> >> like this ? >> >> /sys/bus/pci/drivers/xe/BDF/ >> ├── sriov_auto_provisioning >> │ ├── admin_mode >> │ ├── enabled >> │ └── defaults >> │ ├── resources >> │ │ ├── contexts_quota >> │ │ ├── doorbells_quota >> │ │ ├── ggtt_quota >> │ │ └── lmem_quota >> │ ├── scheduling >> │ │ ├── exec_quantum_ms >> │ │ └── preempt_timeout_us >> │ └── monitoring >> │ ├── cat_error_count >> │ ├── doorbell_time_us >> │ ├── engine_reset_count >> │ ├── h2g_time_us >> │ ├── irq_time_us >> │ └── page_fault_count > > Looks better to me but it may be just a matter of taste so I was just > roughly outlining an alternative. another proposal (to avoid clash with '.defaults' used elsewhere for different purposes): /sys/bus/pci/drivers/xe/BDF/ ├── sriov_auto_provisioning │ ├── admin_mode │ ├── enabled │ └── template │ ├── resources │ │ ├── guc_contexts_quota │ │ ├── guc_doorbells_quota │ │ ├── ggtt_quota │ │ └── lmem_quota │ ├── scheduling │ │ ├── guc_exec_quantum_ms │ │ └── guc_preempt_timeout_us │ └── monitoring │ ├── cat_error_count │ ├── engine_reset_count │ ├── guc_doorbell_time_us │ ├── guc_h2g_time_us │ ├── guc_irq_time_us │ └── page_fault_count > >>> + + /sys/bus/pci/drivers/xe/BDF/ + ├── sriov_extensions >>>
Re: [RFC PATCH] of/platform: Disable sysfb if a simple-framebuffer node is found
On Mon, Nov 13, 2023 at 2:53 AM Javier Martinez Canillas
wrote:
>
> Some DT platforms use EFI to boot and in this case the EFI Boot Services
> may register a EFI_GRAPHICS_OUTPUT_PROTOCOL handle, that will later be
> queried by the Linux EFI stub to fill the global struct screen_info data.
>
> The data is used by the Generic System Framebuffers (sysfb) framework to
> add a platform device with platform data about the system framebuffer.
>
> But if there is a "simple-framebuffer" node in the DT, the OF core will
> also do the same and add another device for the system framebuffer.
>
> This could lead for example, to two platform devices ("simple-framebuffer"
> and "efi-framebuffer") to be added and matched with their corresponding
> drivers. So both efifb and simpledrm will be probed, leading to following:
>
> [0.055752] efifb: framebuffer at 0xbd58dc000, using 16000k, total 16000k
> [0.055755] efifb: mode is 2560x1600x32, linelength=10240, pages=1
> [0.055758] efifb: scrolling: redraw
> [0.055759] efifb: Truecolor: size=2:10:10:10, shift=30:20:10:0
> ...
> [3.295896] simple-framebuffer bd58dc000.framebuffer: [drm] *ERROR*
> could not acquire memory range [??? 0x79f30a29ee40-0x2a501a7
> flags 0x0]: -16
> [3.298018] simple-framebuffer: probe of bd58dc000.framebuffer
> failed with error -16
>
> To prevent the issue, make the OF core to disable sysfb if there is a node
> with a "simple-framebuffer" compatible. That way only this device will be
> registered and sysfb would not attempt to register another one using the
> screen_info data even if this has been filled.
>
> This seems the correct thing to do in this case because:
>
> a) On a DT platform, the DTB is the single source of truth since is what
>describes the hardware topology. Even if EFI Boot Services are used to
>boot the machine.
This is the opposite of what we do for memory and memory reservations.
EFI is the source of truth for those.
This could also lead to an interesting scenario. As simple-framebuffer
can define its memory in a /reserved-memory node, but that is ignored
in EFI boot. Probably would work, but only because EFI probably
generates its memory map table from the /reserved-memory nodes.
Rob
Re: [PATCH v6 1/2] dt-bindings: backlight: mp3309c: remove two required properties
On Wed, Nov 15, 2023 at 04:29:01PM +0100, Flavio Suligoi wrote: > Signed-off-by: Flavio Suligoi You omitted my ack that I gave on the previous version. Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
RE: [Intel-gfx] [PATCH] drm/i915: Read a shadowed mmio register for ggtt flush
Hi Vinay, > -Original Message- > From: dri-devel On Behalf Of > Belgaumkar, Vinay > Sent: Thursday, November 9, 2023 5:02 PM > To: Ville Syrjälä > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Read a shadowed mmio register for > ggtt flush > > > On 11/9/2023 12:35 PM, Ville Syrjälä wrote: > > On Thu, Nov 09, 2023 at 12:01:26PM -0800, Belgaumkar, Vinay wrote: > >> On 11/9/2023 11:30 AM, Ville Syrjälä wrote: > >>> On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote: > We read RENDER_HEAD as a part of the flush. If GT is in > deeper sleep states, this could lead to read errors since we are > not using a forcewake. Safer to read a shadowed register instead. > >>> IIRC shadowing is only thing for writes, not reads. > >> Sure, but reading from a shadowed register does return the cached value > > Does it? I suppose that would make some sense, but I don't recall that > > ever being stated anywhere. At least before the shadow registers > > existed reads would just give you zeroes when not awake. > > > >> (even though we don't care about the vakue here). When GT is in deeper > >> sleep states, it is better to read a shadowed (cached) value instead of > >> trying to attempt an mmio register read without a force wake anyways. > > So you're saying reads from non-shadowed registers fails somehow > > when not awake? How exactly do they fail? And when reading from > > a shadowed register that failure never happens? > > We could hit problems like the one being addressed here - > https://patchwork.freedesktop.org/series/125356/. Reading from a > shadowed register will avoid any needless references(without a wake) to > the MMIO space. Shouldn't hurt to make this change for all gens IMO. The proposed usage looks accurate for the issue described. Reviewed-by: Radhakrishna Sripada --Radhakrishna(RK) Sripada > > Thanks, > > Vinay. > > > > >> Thanks, > >> > >> Vinay. > >> > Cc: John Harrison > Cc: Daniele Ceraolo Spurio > Signed-off-by: Vinay Belgaumkar > --- > drivers/gpu/drm/i915/gt/intel_gt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > index ed32bf5b1546..ea814ea5f700 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > @@ -451,7 +451,7 @@ void intel_gt_flush_ggtt_writes(struct intel_gt *gt) > > spin_lock_irqsave(>lock, flags); > intel_uncore_posting_read_fw(uncore, > - > RING_HEAD(RENDER_RING_BASE)); > + > RING_TAIL(RENDER_RING_BASE)); > spin_unlock_irqrestore(>lock, flags); > } > } > -- > 2.38.1
[PATCH 6.6 215/603] drm: bridge: for GENERIC_PHY_MIPI_DPHY also select GENERIC_PHY
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 96413b355a49fd684430a230479bd231d977894f ]
Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
might not be set. This causes Kconfig warnings and a build error.
WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY
Depends on [n]: GENERIC_PHY [=n]
Selected by [y]:
- DRM_NWL_MIPI_DSI [=y] && DRM_BRIDGE [=y] && DRM [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
- DRM_SAMSUNG_DSIM [=y] && DRM [=y] && DRM_BRIDGE [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
(drm/bridge/cadence/Kconfig was found by inspection.)
aarch64-linux-ld: drivers/gpu/drm/bridge/samsung-dsim.o: in function
`samsung_dsim_set_phy_ctrl':
drivers/gpu/drm/bridge/samsung-dsim.c:731: undefined reference to
`phy_mipi_dphy_get_default_config_for_hsclk'
Prevent these warnings and build error by also selecting GENERIC_PHY
whenever selecting GENERIC_PHY_MIPI_DPHY.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
Fixes: 171b3b1e0f8b ("drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY")
Signed-off-by: Randy Dunlap
Reported-by: Aleksandr Nogikh
Link: lore.kernel.org/r/20230803144227.2187749-1-nog...@google.com
Cc: Adam Ford
Cc: Maxime Ripard
Cc: Guido Günther
Cc: Robert Chiras
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Andrzej Hajda
Cc: Robert Foss
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Adam Ford
Tested-by: Aleksandr Nogikh
Reviewed-by: Guido Günther
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20230804030140.21395-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/Kconfig | 2 ++
drivers/gpu/drm/bridge/cadence/Kconfig | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 44a660a4bdbfc..ba82a1142adf7 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -181,6 +181,7 @@ config DRM_NWL_MIPI_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
select MULTIPLEXER
@@ -227,6 +228,7 @@ config DRM_SAMSUNG_DSIM
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
help
The Samsung MIPI DSIM bridge controller driver.
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index ec35215a20034..cced81633ddcd 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -4,6 +4,7 @@ config DRM_CDNS_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
depends on OF
help
--
2.42.0
Re: [PATCH v2] Remove custom dumb_map_offset implementation in msm driver
On Wed, 15 Nov 2023 at 20:46, Dipam Turkar wrote:
>
> They are not outdated, my bad. I went through the locks' code and saw that
> they have been updated. But they are probably not necessary here as most of
> the drivers do not use any form of locking in their implementations. The
> generic implementations drm_gem_dumb_map_offset() and
> drm_gem_ttm_dumb_map_offset() do not have any locking mechanisms either.
Excuse me, but this doesn't sound right to me. There are different
drivers with different implementations. So either we'd need a good
explanation of why it is not necessary, or this patch is NAKed.
>
> Thanks and regards
> Dipam Turkar
>
> On Wed, Nov 15, 2023 at 8:37 PM Dmitry Baryshkov
> wrote:
>>
>> On Wed, 15 Nov 2023 at 16:30, Dipam Turkar wrote:
>> >
>> > Make msm use drm_gem_create_map_offset() instead of its custom
>> > implementation for associating GEM object with a fake offset. Since,
>> > we already have this generic implementation, we don't need the custom
>> > implementation and it is better to standardize the code for GEM based
>> > drivers. This also removes the outdated locking leftovers.
>>
>> Why are they outdated?
>>
>> >
>> > Signed-off-by: Dipam Turkar
>> > ---
>> > drivers/gpu/drm/msm/msm_drv.c | 2 +-
>> > drivers/gpu/drm/msm/msm_gem.c | 21 -
>> > drivers/gpu/drm/msm/msm_gem.h | 2 --
>> > 3 files changed, 1 insertion(+), 24 deletions(-)
>> >
>> > Changes in v2:
>> > Modify commit message to include the absence of internal locking leftovers
>> > around allocating a fake offset in msm_gem_mmap_offset() in the generic
>> > implementation drm_gem_create_map_offset().
>> >
>> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>> > index a428951ee539..86a15992c717 100644
>> > --- a/drivers/gpu/drm/msm/msm_drv.c
>> > +++ b/drivers/gpu/drm/msm/msm_drv.c
>> > @@ -1085,7 +1085,7 @@ static const struct drm_driver msm_driver = {
>> > .open = msm_open,
>> > .postclose = msm_postclose,
>> > .dumb_create= msm_gem_dumb_create,
>> > - .dumb_map_offset= msm_gem_dumb_map_offset,
>> > + .dumb_map_offset= drm_gem_dumb_map_offset,
>> > .gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
>> > #ifdef CONFIG_DEBUG_FS
>> > .debugfs_init = msm_debugfs_init,
>> > diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
>> > index db1e748daa75..489694ef79cb 100644
>> > --- a/drivers/gpu/drm/msm/msm_gem.c
>> > +++ b/drivers/gpu/drm/msm/msm_gem.c
>> > @@ -671,27 +671,6 @@ int msm_gem_dumb_create(struct drm_file *file, struct
>> > drm_device *dev,
>> > MSM_BO_SCANOUT | MSM_BO_WC, >handle, "dumb");
>> > }
>> >
>> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
>> > - uint32_t handle, uint64_t *offset)
>> > -{
>> > - struct drm_gem_object *obj;
>> > - int ret = 0;
>> > -
>> > - /* GEM does all our handle to object mapping */
>> > - obj = drm_gem_object_lookup(file, handle);
>> > - if (obj == NULL) {
>> > - ret = -ENOENT;
>> > - goto fail;
>> > - }
>> > -
>> > - *offset = msm_gem_mmap_offset(obj);
>> > -
>> > - drm_gem_object_put(obj);
>> > -
>> > -fail:
>> > - return ret;
>> > -}
>> > -
>> > static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
>> > {
>> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
>> > diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
>> > index 8ddef5443140..dc74a0ef865d 100644
>> > --- a/drivers/gpu/drm/msm/msm_gem.h
>> > +++ b/drivers/gpu/drm/msm/msm_gem.h
>> > @@ -139,8 +139,6 @@ struct page **msm_gem_pin_pages(struct drm_gem_object
>> > *obj);
>> > void msm_gem_unpin_pages(struct drm_gem_object *obj);
>> > int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
>> > struct drm_mode_create_dumb *args);
>> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
>> > - uint32_t handle, uint64_t *offset);
>> > void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj);
>> > void *msm_gem_get_vaddr(struct drm_gem_object *obj);
>> > void *msm_gem_get_vaddr_active(struct drm_gem_object *obj);
>> > --
>> > 2.34.1
>> >
>>
>>
>> --
>> With best wishes
>> Dmitry
--
With best wishes
Dmitry
[PATCH 6.5 203/550] drm: bridge: for GENERIC_PHY_MIPI_DPHY also select GENERIC_PHY
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 96413b355a49fd684430a230479bd231d977894f ]
Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
might not be set. This causes Kconfig warnings and a build error.
WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY
Depends on [n]: GENERIC_PHY [=n]
Selected by [y]:
- DRM_NWL_MIPI_DSI [=y] && DRM_BRIDGE [=y] && DRM [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
- DRM_SAMSUNG_DSIM [=y] && DRM [=y] && DRM_BRIDGE [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
(drm/bridge/cadence/Kconfig was found by inspection.)
aarch64-linux-ld: drivers/gpu/drm/bridge/samsung-dsim.o: in function
`samsung_dsim_set_phy_ctrl':
drivers/gpu/drm/bridge/samsung-dsim.c:731: undefined reference to
`phy_mipi_dphy_get_default_config_for_hsclk'
Prevent these warnings and build error by also selecting GENERIC_PHY
whenever selecting GENERIC_PHY_MIPI_DPHY.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
Fixes: 171b3b1e0f8b ("drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY")
Signed-off-by: Randy Dunlap
Reported-by: Aleksandr Nogikh
Link: lore.kernel.org/r/20230803144227.2187749-1-nog...@google.com
Cc: Adam Ford
Cc: Maxime Ripard
Cc: Guido Günther
Cc: Robert Chiras
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Andrzej Hajda
Cc: Robert Foss
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Adam Ford
Tested-by: Aleksandr Nogikh
Reviewed-by: Guido Günther
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20230804030140.21395-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/Kconfig | 2 ++
drivers/gpu/drm/bridge/cadence/Kconfig | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 82c68b0424443..42d05a247511a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -181,6 +181,7 @@ config DRM_NWL_MIPI_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
select MULTIPLEXER
@@ -227,6 +228,7 @@ config DRM_SAMSUNG_DSIM
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
help
The Samsung MIPI DSIM bridge controller driver.
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index ec35215a20034..cced81633ddcd 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -4,6 +4,7 @@ config DRM_CDNS_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
depends on OF
help
--
2.42.0
Re: [PATCH] drm/i915/gsc: Mark internal GSC engine with reserved uabi class
On 11/15/2023 3:02 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
The GSC CS is not exposed to the user, so we skipped assigning a uabi
class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset makes the
GSC CS show up as the RCS in those logs.
Given that the engine is not exposed to the user, we can't add a new
case in the uabi enum, so we insted internally define a kernel
internal class as -1.
At the same time remove special handling for the name and complete
the uabi_classes array so internal class is automatically correctly
assigned.
Engine will show as 65535:0 other0 in the logs/traces which should
be unique enough.
Signed-off-by: Tvrtko Ursulin
Fixes: 194babe26bdc ("drm/i915/mtl: don't expose GSC command streamer to the
user")
Cc: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: Matt Roper
---
Daniele I borrowed most of your commit text as is, hope you don't mind but
I was lazy. See if you like this solution. It is also untested so lets see.
I'm ok with this approach. As you said the naming is unique so we can
easily identify the engine. I've tested this locally with a small change
(see below) and I see the expected values in the logs.
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 37 -
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 118164ddbb2e..7693ccfac1f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -41,12 +41,15 @@ void intel_engine_add_user(struct intel_engine_cs *engine)
llist_add(>uabi_llist, >i915->uabi_engines_llist);
}
+#define I915_NO_UABI_CLASS (-1)
I see the lkp is complaining about using this for comparison against a
u16. When I locally tried to reduce this to u16 my compiler also
complained that we're assigning it to a u8 in the uabi_classes array, so
I've just set I915_NO_UABI_CLASS directly to 255 and it all worked as
expected. With that fix, or an alternative change to work with all the
involved types:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
+
static const u8 uabi_classes[] = {
[RENDER_CLASS] = I915_ENGINE_CLASS_RENDER,
[COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
[VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
[COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
+ [OTHER_CLASS] = I915_NO_UABI_CLASS, /* Not exposed to users, no uabi
class. */
};
static int engine_cmp(void *priv, const struct list_head *A,
@@ -200,6 +203,7 @@ static void engine_rename(struct intel_engine_cs *engine,
const char *name, u16
void intel_engines_driver_register(struct drm_i915_private *i915)
{
+ u16 name_instance, other_instance = 0;
struct legacy_ring ring = {};
struct list_head *it, *next;
struct rb_node **p, *prev;
@@ -216,27 +220,28 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
if (intel_gt_has_unrecoverable_error(engine->gt))
continue; /* ignore incomplete engines */
- /*
-* We don't want to expose the GSC engine to the users, but we
-* still rename it so it is easier to identify in the debug logs
-*/
- if (engine->id == GSC0) {
- engine_rename(engine, "gsc", 0);
- continue;
- }
-
GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
engine->uabi_class = uabi_classes[engine->class];
+ if (engine->uabi_class == I915_NO_UABI_CLASS) {
+ name_instance = other_instance++;
+ } else {
+ GEM_BUG_ON(engine->uabi_class >=
+ ARRAY_SIZE(i915->engine_uabi_class_count));
+ name_instance =
+
i915->engine_uabi_class_count[engine->uabi_class]++;
+ }
+ engine->uabi_instance = name_instance;
- GEM_BUG_ON(engine->uabi_class >=
- ARRAY_SIZE(i915->engine_uabi_class_count));
- engine->uabi_instance =
- i915->engine_uabi_class_count[engine->uabi_class]++;
-
- /* Replace the internal name with the final user facing name */
+ /*
+* Replace the internal name with the final user and log facing
+* name.
+*/
engine_rename(engine,
intel_engine_class_repr(engine->class),
- engine->uabi_instance);
+ name_instance);
+
+ if (engine->uabi_class == I915_NO_UABI_CLASS)
+ continue;
Re: [PATCH v2] Remove custom dumb_map_offset implementation in msm driver
They are not outdated, my bad. I went through the locks' code and saw that
they have been updated. But they are probably not necessary here as most of
the drivers do not use any form of locking in their implementations. The
generic implementations drm_gem_dumb_map_offset() and
drm_gem_ttm_dumb_map_offset() do not have any locking mechanisms either.
Thanks and regards
Dipam Turkar
On Thu, Nov 16, 2023 at 12:16 AM Dipam Turkar wrote:
> They are not outdated, my bad. I went through the locks' code and saw that
> they have been updated. But they are probably not necessary here as most of
> the drivers do not use any form of locking in their implementations. The
> generic implementations drm_gem_dumb_map_offset() and
> drm_gem_ttm_dumb_map_offset() do not have any locking mechanisms either.
>
> Thanks and regards
> Dipam Turkar
>
> On Wed, Nov 15, 2023 at 8:37 PM Dmitry Baryshkov <
> dmitry.barysh...@linaro.org> wrote:
>
>> On Wed, 15 Nov 2023 at 16:30, Dipam Turkar wrote:
>> >
>> > Make msm use drm_gem_create_map_offset() instead of its custom
>> > implementation for associating GEM object with a fake offset. Since,
>> > we already have this generic implementation, we don't need the custom
>> > implementation and it is better to standardize the code for GEM based
>> > drivers. This also removes the outdated locking leftovers.
>>
>> Why are they outdated?
>>
>> >
>> > Signed-off-by: Dipam Turkar
>> > ---
>> > drivers/gpu/drm/msm/msm_drv.c | 2 +-
>> > drivers/gpu/drm/msm/msm_gem.c | 21 -
>> > drivers/gpu/drm/msm/msm_gem.h | 2 --
>> > 3 files changed, 1 insertion(+), 24 deletions(-)
>> >
>> > Changes in v2:
>> > Modify commit message to include the absence of internal locking
>> leftovers
>> > around allocating a fake offset in msm_gem_mmap_offset() in the generic
>> > implementation drm_gem_create_map_offset().
>> >
>> > diff --git a/drivers/gpu/drm/msm/msm_drv.c
>> b/drivers/gpu/drm/msm/msm_drv.c
>> > index a428951ee539..86a15992c717 100644
>> > --- a/drivers/gpu/drm/msm/msm_drv.c
>> > +++ b/drivers/gpu/drm/msm/msm_drv.c
>> > @@ -1085,7 +1085,7 @@ static const struct drm_driver msm_driver = {
>> > .open = msm_open,
>> > .postclose = msm_postclose,
>> > .dumb_create= msm_gem_dumb_create,
>> > - .dumb_map_offset= msm_gem_dumb_map_offset,
>> > + .dumb_map_offset= drm_gem_dumb_map_offset,
>> > .gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
>> > #ifdef CONFIG_DEBUG_FS
>> > .debugfs_init = msm_debugfs_init,
>> > diff --git a/drivers/gpu/drm/msm/msm_gem.c
>> b/drivers/gpu/drm/msm/msm_gem.c
>> > index db1e748daa75..489694ef79cb 100644
>> > --- a/drivers/gpu/drm/msm/msm_gem.c
>> > +++ b/drivers/gpu/drm/msm/msm_gem.c
>> > @@ -671,27 +671,6 @@ int msm_gem_dumb_create(struct drm_file *file,
>> struct drm_device *dev,
>> > MSM_BO_SCANOUT | MSM_BO_WC, >handle,
>> "dumb");
>> > }
>> >
>> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device
>> *dev,
>> > - uint32_t handle, uint64_t *offset)
>> > -{
>> > - struct drm_gem_object *obj;
>> > - int ret = 0;
>> > -
>> > - /* GEM does all our handle to object mapping */
>> > - obj = drm_gem_object_lookup(file, handle);
>> > - if (obj == NULL) {
>> > - ret = -ENOENT;
>> > - goto fail;
>> > - }
>> > -
>> > - *offset = msm_gem_mmap_offset(obj);
>> > -
>> > - drm_gem_object_put(obj);
>> > -
>> > -fail:
>> > - return ret;
>> > -}
>> > -
>> > static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
>> > {
>> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
>> > diff --git a/drivers/gpu/drm/msm/msm_gem.h
>> b/drivers/gpu/drm/msm/msm_gem.h
>> > index 8ddef5443140..dc74a0ef865d 100644
>> > --- a/drivers/gpu/drm/msm/msm_gem.h
>> > +++ b/drivers/gpu/drm/msm/msm_gem.h
>> > @@ -139,8 +139,6 @@ struct page **msm_gem_pin_pages(struct
>> drm_gem_object *obj);
>> > void msm_gem_unpin_pages(struct drm_gem_object *obj);
>> > int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
>> > struct drm_mode_create_dumb *args);
>> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device
>> *dev,
>> > - uint32_t handle, uint64_t *offset);
>> > void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj);
>> > void *msm_gem_get_vaddr(struct drm_gem_object *obj);
>> > void *msm_gem_get_vaddr_active(struct drm_gem_object *obj);
>> > --
>> > 2.34.1
>> >
>>
>>
>> --
>> With best wishes
>> Dmitry
>>
>
Re: [PATCH v2] Remove custom dumb_map_offset implementation in msm driver
They are not outdated, my bad. I went through the locks' code and saw that
they have been updated. But they are probably not necessary here as most of
the drivers do not use any form of locking in their implementations. The
generic implementations drm_gem_dumb_map_offset() and
drm_gem_ttm_dumb_map_offset() do not have any locking mechanisms either.
Thanks and regards
Dipam Turkar
On Wed, Nov 15, 2023 at 8:37 PM Dmitry Baryshkov <
dmitry.barysh...@linaro.org> wrote:
> On Wed, 15 Nov 2023 at 16:30, Dipam Turkar wrote:
> >
> > Make msm use drm_gem_create_map_offset() instead of its custom
> > implementation for associating GEM object with a fake offset. Since,
> > we already have this generic implementation, we don't need the custom
> > implementation and it is better to standardize the code for GEM based
> > drivers. This also removes the outdated locking leftovers.
>
> Why are they outdated?
>
> >
> > Signed-off-by: Dipam Turkar
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 2 +-
> > drivers/gpu/drm/msm/msm_gem.c | 21 -
> > drivers/gpu/drm/msm/msm_gem.h | 2 --
> > 3 files changed, 1 insertion(+), 24 deletions(-)
> >
> > Changes in v2:
> > Modify commit message to include the absence of internal locking
> leftovers
> > around allocating a fake offset in msm_gem_mmap_offset() in the generic
> > implementation drm_gem_create_map_offset().
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c
> b/drivers/gpu/drm/msm/msm_drv.c
> > index a428951ee539..86a15992c717 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -1085,7 +1085,7 @@ static const struct drm_driver msm_driver = {
> > .open = msm_open,
> > .postclose = msm_postclose,
> > .dumb_create= msm_gem_dumb_create,
> > - .dumb_map_offset= msm_gem_dumb_map_offset,
> > + .dumb_map_offset= drm_gem_dumb_map_offset,
> > .gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
> > #ifdef CONFIG_DEBUG_FS
> > .debugfs_init = msm_debugfs_init,
> > diff --git a/drivers/gpu/drm/msm/msm_gem.c
> b/drivers/gpu/drm/msm/msm_gem.c
> > index db1e748daa75..489694ef79cb 100644
> > --- a/drivers/gpu/drm/msm/msm_gem.c
> > +++ b/drivers/gpu/drm/msm/msm_gem.c
> > @@ -671,27 +671,6 @@ int msm_gem_dumb_create(struct drm_file *file,
> struct drm_device *dev,
> > MSM_BO_SCANOUT | MSM_BO_WC, >handle,
> "dumb");
> > }
> >
> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device
> *dev,
> > - uint32_t handle, uint64_t *offset)
> > -{
> > - struct drm_gem_object *obj;
> > - int ret = 0;
> > -
> > - /* GEM does all our handle to object mapping */
> > - obj = drm_gem_object_lookup(file, handle);
> > - if (obj == NULL) {
> > - ret = -ENOENT;
> > - goto fail;
> > - }
> > -
> > - *offset = msm_gem_mmap_offset(obj);
> > -
> > - drm_gem_object_put(obj);
> > -
> > -fail:
> > - return ret;
> > -}
> > -
> > static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
> > {
> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
> > diff --git a/drivers/gpu/drm/msm/msm_gem.h
> b/drivers/gpu/drm/msm/msm_gem.h
> > index 8ddef5443140..dc74a0ef865d 100644
> > --- a/drivers/gpu/drm/msm/msm_gem.h
> > +++ b/drivers/gpu/drm/msm/msm_gem.h
> > @@ -139,8 +139,6 @@ struct page **msm_gem_pin_pages(struct
> drm_gem_object *obj);
> > void msm_gem_unpin_pages(struct drm_gem_object *obj);
> > int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
> > struct drm_mode_create_dumb *args);
> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device
> *dev,
> > - uint32_t handle, uint64_t *offset);
> > void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj);
> > void *msm_gem_get_vaddr(struct drm_gem_object *obj);
> > void *msm_gem_get_vaddr_active(struct drm_gem_object *obj);
> > --
> > 2.34.1
> >
>
>
> --
> With best wishes
> Dmitry
>
Re: [PATCH] drm/msm/dpu: Add missing safe_lut_tbl in sc8280xp catalog
On 10/30/2023 4:23 PM, Bjorn Andersson wrote:
During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
typically take 1-2ms to complete. As expected this results in poor
performance, something that has been mitigated by proposing running the
iommu in non-strict mode (boot with iommu.strict=0).
This turns out to be related to the SAFE logic, and programming the QOS
SAFE values in the DPU (per suggestion from Rob and Doug) reduces the
TLB sync time to below 10us, which means significant less time spent
with interrupts disabled and a significant boost in throughput.
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Cc: sta...@vger.kernel.org
Suggested-by: Doug Anderson
Suggested-by: Rob Clark
Signed-off-by: Bjorn Andersson
---
Matches what we have in downstream DT, hence
Reviewed-by: Abhinav Kumar
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
index 1ccd1edd693c..4c0528794e7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h
@@ -406,6 +406,7 @@ static const struct dpu_perf_cfg sc8280xp_perf_data = {
.min_llcc_ib = 0,
.min_dram_ib = 80,
.danger_lut_tbl = {0xf, 0x, 0x0},
+ .safe_lut_tbl = {0xfe00, 0xfe00, 0x},
.qos_lut_tbl = {
{.nentry = ARRAY_SIZE(sc8180x_qos_linear),
.entries = sc8180x_qos_linear
---
base-commit: c503e3eec382ac708ee7adf874add37b77c5d312
change-id: 20231030-sc8280xp-dpu-safe-lut-9769027b8452
Best regards,
Re: [PATCH v4 12/32] drm/amd/display: add CRTC gamma TF driver-specific property
On 2023-10-05 13:15, Melissa Wen wrote:
> Add AMD pre-defined transfer function property to default DRM CRTC gamma
> to convert to wire encoding with or without a user gamma LUT. There is
> no post-blending regamma ROM for pre-defined TF. When setting Gamma TF
> (!= Identity) and LUT at the same time, the color module will combine
> the pre-defined TF and the custom LUT values into the LUT that's
> actually programmed.
>
> v2:
> - enable CRTC prop in the end of driver-specific prop sequence
> - define inverse EOTFs as supported regamma TFs
> - reword driver-specific function doc to remove shaper/3D LUT
>
> v3:
> - spell out TF+LUT behavior in the commit and comments (Harry)
>
> Co-developed-by: Joshua Ashton
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 7 ++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 8 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 7 ++
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 +++
> 4 files changed, 94 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index dee35d208493..071cc10bfd90 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -424,6 +424,13 @@ struct amdgpu_mode_info {
>* from a combination of pre-defined TF and the custom 1D LUT).
>*/
> struct drm_property *plane_blend_tf_property;
> + /* @regamma_tf_property: Transfer function for CRTC regamma
> + * (post-blending). Possible values are defined by `enum
> + * amdgpu_transfer_function`. There is no regamma ROM, but we can use
> + * AMD color modules to program LUT parameters from predefined TF (or
> + * from a combination of pre-defined TF and the custom 1D LUT).
> + */
> + struct drm_property *regamma_tf_property;
> };
>
> #define AMDGPU_MAX_BL_LEVEL 0xFF
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 1b96c742d747..c138457ff12e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -836,6 +836,14 @@ struct dm_crtc_state {
> struct dc_info_packet vrr_infopacket;
>
> int abm_level;
> +
> +/**
> + * @regamma_tf:
> + *
> + * Pre-defined transfer function for converting internal FB -> wire
> + * encoding.
> + */
> + enum amdgpu_transfer_function regamma_tf;
> };
>
> #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base)
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 82c554662faa..2ecfa0e886e8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -294,6 +294,13 @@ amdgpu_dm_create_color_properties(struct amdgpu_device
> *adev)
> return -ENOMEM;
> adev->mode_info.plane_blend_tf_property = prop;
>
> + prop = amdgpu_create_tf_property(adev_to_drm(adev),
> + "AMD_CRTC_REGAMMA_TF",
> + amdgpu_inv_eotf);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.regamma_tf_property = prop;
> +
> return 0;
> }
> #endif
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> index 440fc0869a34..d746f0aa0f11 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> @@ -253,6 +253,7 @@ static struct drm_crtc_state
> *dm_crtc_duplicate_state(struct drm_crtc *crtc)
> state->freesync_config = cur->freesync_config;
> state->cm_has_degamma = cur->cm_has_degamma;
> state->cm_is_degamma_srgb = cur->cm_is_degamma_srgb;
> + state->regamma_tf = cur->regamma_tf;
> state->crc_skip_count = cur->crc_skip_count;
> state->mpo_requested = cur->mpo_requested;
> /* TODO Duplicate dc_stream after objects are stream object is
> flattened */
> @@ -289,6 +290,70 @@ static int amdgpu_dm_crtc_late_register(struct drm_crtc
> *crtc)
> }
> #endif
>
> +#ifdef AMD_PRIVATE_COLOR
> +/**
> + * drm_crtc_additional_color_mgmt - enable additional color properties
> + * @crtc: DRM CRTC
> + *
> + * This function lets the driver enable post-blending CRTC regamma transfer
> + * function property in addition to DRM CRTC gamma LUT. Default value means
> + * linear transfer function, which is the default CRTC gamma LUT behaviour
> + * without this property.
> + */
> +static void
> +dm_crtc_additional_color_mgmt(struct drm_crtc *crtc)
> +{
> + struct amdgpu_device *adev = drm_to_adev(crtc->dev);
> +
> +
Re: [PATCH v4 11/32] drm/amd/display: add plane blend LUT and TF driver-specific properties
On 2023-10-05 13:15, Melissa Wen wrote:
> From: Joshua Ashton
>
> Blend 1D LUT or a pre-defined transfer function (TF) can be set to
> linearize content before blending, so that it's positioned just before
> blending planes in the AMD color mgmt pipeline, and after 3D LUT
> (non-linear space). Shaper and Blend LUTs are 1D LUTs that sandwich 3D
> LUT. Drivers should advertize blend properties according to HW caps.
>
> There is no blend ROM for pre-defined TF. When setting blend TF (!=
> Identity) and LUT at the same time, the color module will combine the
> pre-defined TF and the custom LUT values into the LUT that's actually
> programmed.
>
> v3:
> - spell out TF+LUT behavior in the commit and comments (Harry)
>
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 22
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 12 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 21 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 36 +++
> 4 files changed, 91 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index af70db4f6b4b..dee35d208493 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -402,6 +402,28 @@ struct amdgpu_mode_info {
>* entries for 3D LUT array is the 3D LUT size cubed;
>*/
> struct drm_property *plane_lut3d_size_property;
> + /**
> + * @plane_blend_lut_property: Plane property for output gamma before
> + * blending. Userspace set a blend LUT to convert colors after 3D LUT
> + * conversion. It works as a post-3DLUT 1D LUT. With shaper LUT, they
> + * are sandwiching 3D LUT with two 1D LUT. If plane_blend_tf_property
> + * != Identity TF, AMD color module will combine the user LUT values
> + * with pre-defined TF into the LUT parameters to be programmed.
> + */
> + struct drm_property *plane_blend_lut_property;
> + /**
> + * @plane_blend_lut_size_property: Plane property to define the max
> + * size of blend LUT as supported by the driver (read-only).
> + */
> + struct drm_property *plane_blend_lut_size_property;
> + /**
> + * @plane_blend_tf_property: Plane property to set a predefined
> + * transfer function for pre-blending blend/out_gamma (after applying
> + * 3D LUT) with or without LUT. There is no blend ROM, but we can use
> + * AMD color modules to program LUT parameters from predefined TF (or
> + * from a combination of pre-defined TF and the custom 1D LUT).
> + */
> + struct drm_property *plane_blend_tf_property;
> };
>
> #define AMDGPU_MAX_BL_LEVEL 0xFF
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 0e2a04a3caf3..1b96c742d747 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -800,6 +800,18 @@ struct dm_plane_state {
>* drm_color_lut.
>*/
> struct drm_property_blob *lut3d;
> + /**
> + * @blend_lut: blend lut lookup table blob. The blob (if not NULL) is an
> + * array of drm_color_lut.
> + */
> + struct drm_property_blob *blend_lut;
> + /**
> + * @blend_tf:
> + *
> + * Pre-defined transfer function for converting plane pixel data before
> + * applying blend LUT.
> + */
> + enum amdgpu_transfer_function blend_tf;
> };
>
> struct dm_crtc_state {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index d3c7f9a13a61..82c554662faa 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -273,6 +273,27 @@ amdgpu_dm_create_color_properties(struct amdgpu_device
> *adev)
> return -ENOMEM;
> adev->mode_info.plane_lut3d_size_property = prop;
>
> + prop = drm_property_create(adev_to_drm(adev),
> +DRM_MODE_PROP_BLOB,
> +"AMD_PLANE_BLEND_LUT", 0);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.plane_blend_lut_property = prop;
> +
> + prop = drm_property_create_range(adev_to_drm(adev),
> + DRM_MODE_PROP_IMMUTABLE,
> + "AMD_PLANE_BLEND_LUT_SIZE", 0,
> UINT_MAX);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.plane_blend_lut_size_property = prop;
> +
> + prop = amdgpu_create_tf_property(adev_to_drm(adev),
> + "AMD_PLANE_BLEND_TF",
> + amdgpu_eotf);
> + if (!prop)
> + return
Re: [PATCH v4 10/32] drm/amd/display: add plane shaper LUT and TF driver-specific properties
On 2023-10-05 13:15, Melissa Wen wrote:
> On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
> delinearizing and/or normalizing the color space before applying a 3D
> LUT. Add pre-defined transfer function to enable delinearizing content
> with or without shaper LUT, where AMD color module calculates the
> resulted shaper curve. We apply an inverse EOTF to go from linear
> values to encoded values. If we are already in a non-linear space and/or
> don't need to normalize values, we can bypass shaper LUT with a linear
> transfer function that is also the default TF value.
>
> There is no shaper ROM. When setting shaper TF (!= Identity) and LUT at
> the same time, the color module will combine the pre-defined TF and the
> custom LUT values into the LUT that's actually programmed.
>
> v2:
> - squash commits for shaper LUT and shaper TF
> - define inverse EOTF as supported shaper TFs
>
> v3:
> - spell out TF+LUT behavior in the commit and comments (Harry)
> - replace BT709 EOTF by inv OETF
>
> Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 21
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 11 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 29 +
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 32 +++
> 4 files changed, 93 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index f7adaa52c23f..af70db4f6b4b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -363,6 +363,27 @@ struct amdgpu_mode_info {
>* @plane_hdr_mult_property:
>*/
> struct drm_property *plane_hdr_mult_property;
> + /**
> + * @shaper_lut_property: Plane property to set pre-blending shaper LUT
> + * that converts color content before 3D LUT. If
> + * plane_shaper_tf_property != Identity TF, AMD color module will
> + * combine the user LUT values with pre-defined TF into the LUT
> + * parameters to be programmed.
> + */
> + struct drm_property *plane_shaper_lut_property;
> + /**
> + * @shaper_lut_size_property: Plane property for the size of
> + * pre-blending shaper LUT as supported by the driver (read-only).
> + */
> + struct drm_property *plane_shaper_lut_size_property;
> + /**
> + * @plane_shaper_tf_property: Plane property to set a predefined
> + * transfer function for pre-blending shaper (before applying 3D LUT)
> + * with or without LUT. There is no shaper ROM, but we can use AMD
> + * color modules to program LUT parameters from predefined TF (or
> + * from a combination of pre-defined TF and the custom 1D LUT).
> + */
> + struct drm_property *plane_shaper_tf_property;
> /**
>* @plane_lut3d_property: Plane property for color transformation using
>* a 3D LUT (pre-blending), a three-dimensional array where each
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 7a2350c62cf1..0e2a04a3caf3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -784,6 +784,17 @@ struct dm_plane_state {
>* TF is needed for any subsequent linear-to-non-linear transforms.
>*/
> __u64 hdr_mult;
> + /**
> + * @shaper_lut: shaper lookup table blob. The blob (if not NULL) is an
> + * array of drm_color_lut.
> + */
> + struct drm_property_blob *shaper_lut;
> + /**
> + * @shaper_tf:
> + *
> + * Predefined transfer function to delinearize color space.
> + */
> + enum amdgpu_transfer_function shaper_tf;
> /**
>* @lut3d: 3D lookup table blob. The blob (if not NULL) is an array of
>* drm_color_lut.
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 011f2f9ec890..d3c7f9a13a61 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -173,6 +173,14 @@ static const u32 amdgpu_eotf =
> BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA24_EOTF) |
> BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA26_EOTF);
>
> +static const u32 amdgpu_inv_eotf =
> + BIT(AMDGPU_TRANSFER_FUNCTION_SRGB_INV_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_BT709_OETF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_PQ_INV_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA22_INV_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA24_INV_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA26_INV_EOTF);
> +
> static struct drm_property *
> amdgpu_create_tf_property(struct drm_device *dev,
> const char *name,
> @@ -230,6 +238,27 @@ amdgpu_dm_create_color_properties(struct
Re: [PATCH v4 08/32] drm/amd/display: add plane HDR multiplier driver-specific property
On 2023-10-05 13:15, Melissa Wen wrote:
> From: Joshua Ashton
>
> Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
> transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
> least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
> nits for SDR content. So if you want, 203 nits for SDR content, pass in
> (203.0 / 80.0).
>
> v4:
> - comment about the PQ TF need for L-to-NL (from Harry's review)
>
> Signed-off-by: Joshua Ashton
> Co-developed-by: Melissa Wen
> Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 4
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 17 +
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 6 ++
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +
> 4 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 9b6fab86c6c3..62044d41da75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -359,6 +359,10 @@ struct amdgpu_mode_info {
>* to go from scanout/encoded values to linear values.
>*/
> struct drm_property *plane_degamma_tf_property;
> + /**
> + * @plane_hdr_mult_property:
> + */
> + struct drm_property *plane_hdr_mult_property;
> };
>
> #define AMDGPU_MAX_BL_LEVEL 0xFF
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index fc4f188d397e..bb2ce843369d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -55,6 +55,9 @@
> #define HDMI_AMD_VENDOR_SPECIFIC_DATA_BLOCK_IEEE_REGISTRATION_ID 0x1A
> #define AMD_VSDB_VERSION_3_FEATURECAP_REPLAYMODE 0x40
> #define HDMI_AMD_VENDOR_SPECIFIC_DATA_BLOCK_VERSION_3 0x3
> +
> +#define AMDGPU_HDR_MULT_DEFAULT (0x1LL)
> +
> /*
> #include "include/amdgpu_dal_power_if.h"
> #include "amdgpu_dm_irq.h"
> @@ -767,6 +770,20 @@ struct dm_plane_state {
>* linearize.
>*/
> enum amdgpu_transfer_function degamma_tf;
> + /**
> + * @hdr_mult:
> + *
> + * Multiplier to 'gain' the plane. When PQ is decoded using the fixed
> + * func transfer function to the internal FP16 fb, 1.0 -> 80 nits (on
> + * AMD at least). When sRGB is decoded, 1.0 -> 1.0, obviously.
> + * Therefore, 1.0 multiplier = 80 nits for SDR content. So if you
> + * want, 203 nits for SDR content, pass in (203.0 / 80.0). Format is
> + * S31.32 sign-magnitude.
> + *
> + * HDR multiplier can wide range beyond [0.0, 1.0]. This means that PQ
> + * TF is needed for any subsequent linear-to-non-linear transforms.
> + */
> + __u64 hdr_mult;
> };
>
> struct dm_crtc_state {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index d5dbd20a6766..caf49a044ab4 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -224,6 +224,12 @@ amdgpu_dm_create_color_properties(struct amdgpu_device
> *adev)
> return -ENOMEM;
> adev->mode_info.plane_degamma_tf_property = prop;
>
> + prop = drm_property_create_range(adev_to_drm(adev),
> + 0, "AMD_PLANE_HDR_MULT", 0, U64_MAX);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.plane_hdr_mult_property = prop;
> +
> return 0;
> }
> #endif
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 04af6db8cffd..ae64d4b73360 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -1337,6 +1337,7 @@ static void dm_drm_plane_reset(struct drm_plane *plane)
>
> __drm_atomic_helper_plane_reset(plane, _state->base);
> amdgpu_state->degamma_tf = AMDGPU_TRANSFER_FUNCTION_DEFAULT;
> + amdgpu_state->hdr_mult = AMDGPU_HDR_MULT_DEFAULT;
> }
>
> static struct drm_plane_state *
> @@ -1360,6 +1361,7 @@ dm_drm_plane_duplicate_state(struct drm_plane *plane)
> drm_property_blob_get(dm_plane_state->degamma_lut);
>
> dm_plane_state->degamma_tf = old_dm_plane_state->degamma_tf;
> + dm_plane_state->hdr_mult = old_dm_plane_state->hdr_mult;
>
> return _plane_state->base;
> }
> @@ -1456,6 +1458,10 @@ dm_atomic_plane_attach_color_mgmt_properties(struct
> amdgpu_display_manager *dm,
>
> dm->adev->mode_info.plane_degamma_tf_property,
> AMDGPU_TRANSFER_FUNCTION_DEFAULT);
> }
> + /* HDR MULT is always available */
>
Re: [PATCH v4 07/32] drm/amd/display: document AMDGPU pre-defined transfer functions
On 2023-10-05 13:15, Melissa Wen wrote:
> Brief documentation about pre-defined transfer function usage on AMD
> display driver and standardized EOTFs and inverse EOTFs.
>
> v3:
> - Document BT709 OETF (Pekka)
> - Fix description of sRGB and pure power funcs (Pekka)
>
> v4:
> - Add description of linear and non-linear forms (Harry)
>
> Co-developed-by: Harry Wentland
> Signed-off-by: Harry Wentland
> Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Harry
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 62 +++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index d03bdb010e8b..d5dbd20a6766 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -85,6 +85,68 @@ void amdgpu_dm_init_color_mod(void)
> }
>
> #ifdef AMD_PRIVATE_COLOR
> +/* Pre-defined Transfer Functions (TF)
> + *
> + * AMD driver supports pre-defined mathematical functions for transferring
> + * between encoded values and optical/linear space. Depending on HW color
> caps,
> + * ROMs and curves built by the AMD color module support these transforms.
> + *
> + * The driver-specific color implementation exposes properties for
> pre-blending
> + * degamma TF, shaper TF (before 3D LUT), and blend(dpp.ogam) TF and
> + * post-blending regamma (mpc.ogam) TF. However, only pre-blending degamma
> + * supports ROM curves. AMD color module uses pre-defined coefficients to
> build
> + * curves for the other blocks. What can be done by each color block is
> + * described by struct dpp_color_capsand struct mpc_color_caps.
> + *
> + * AMD driver-specific color API exposes the following pre-defined transfer
> + * functions:
> + *
> + * - Identity: linear/identity relationship between pixel value and
> + * luminance value;
> + * - Gamma 2.2, Gamma 2.4, Gamma 2.6: pure power functions;
> + * - sRGB: 2.4: The piece-wise transfer function from IEC 61966-2-1:1999;
> + * - BT.709: has a linear segment in the bottom part and then a power
> function
> + * with a 0.45 (~1/2.22) gamma for the rest of the range; standardized by
> + * ITU-R BT.709-6;
> + * - PQ (Perceptual Quantizer): used for HDR display, allows luminance range
> + * capability of 0 to 10,000 nits; standardized by SMPTE ST 2084.
> + *
> + * The AMD color model is designed with an assumption that SDR (sRGB, BT.709,
> + * Gamma 2.2, etc.) peak white maps (normalized to 1.0 FP) to 80 nits in the
> PQ
> + * system. This has the implication that PQ EOTF (non-linear to linear) maps
> to
> + * [0.0..125.0] where 125.0 = 10,000 nits / 80 nits.
> + *
> + * Non-linear and linear forms are described in the table below:
> + *
> + * ┌───┬─┬──┐
> + * │ │ Non-linear │ Linear │
> + * ├───┼─┼──┤
> + * │ sRGB │ UNORM or [0.0, 1.0] │ [0.0, 1.0] │
> + * ├───┼─┼──┤
> + * │ BT709 │ UNORM or [0.0, 1.0] │ [0.0, 1.0] │
> + * ├───┼─┼──┤
> + * │ Gamma 2.x │ UNORM or [0.0, 1.0] │ [0.0, 1.0] │
> + * ├───┼─┼──┤
> + * │PQ │ UNORM or FP16 CCCS* │ [0.0, 125.0] │
> + * ├───┼─┼──┤
> + * │ Identity │ UNORM or FP16 CCCS* │ [0.0, 1.0] or CCCS** │
> + * └───┴─┴──┘
> + * * CCCS: Windows canonical composition color space
> + * ** Respectively
> + *
> + * In the driver-specific API, color block names attached to TF properties
> + * suggest the intention regarding non-linear encoding pixel's luminance
> + * values. As some newer encodings don't use gamma curve, we make encoding
> and
> + * decoding explicit by defining an enum list of transfer functions supported
> + * in terms of EOTF and inverse EOTF, where:
> + *
> + * - EOTF (electro-optical transfer function): is the transfer function to go
> + * from the encoded value to an optical (linear) value. De-gamma functions
> + * traditionally do this.
> + * - Inverse EOTF (simply the inverse of the EOTF): is usually intended to go
> + * from an optical/linear space (which might have been used for blending)
> + * back to the encoded values. Gamma functions traditionally do this.
> + */
> static const char * const
> amdgpu_transfer_function_names[] = {
> [AMDGPU_TRANSFER_FUNCTION_DEFAULT] = "Default",
Re: [PATCH v4 06/32] drm/amd/display: explicitly define EOTF and inverse EOTF
On 2023-10-05 13:15, Melissa Wen wrote:
> Instead of relying on color block names to get the transfer function
> intention regarding encoding pixel's luminance, define supported
> Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that
> includes pure gamma or standardized transfer functions.
>
> v3:
> - squash linear and unity TFs to identity (Pekka)
> - define the right TFs for BT.709 (Pekka and Harry)
> - add comment about AMD TF coefficients
>
> Suggested-by: Harry Wentland
> Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 27 +---
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 67 ++-
> 2 files changed, 71 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 4c4cdf7fc6be..fc4f188d397e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -724,16 +724,27 @@ struct amdgpu_dm_wb_connector {
>
> extern const struct amdgpu_ip_block_version dm_ip_block;
>
> +/* enum amdgpu_transfer_function: pre-defined transfer function supported by
> AMD.
> + *
> + * It includes standardized transfer functions and pure power functions. The
> + * transfer function coefficients are available at
> modules/color/color_gamma.c
> + */
> enum amdgpu_transfer_function {
> AMDGPU_TRANSFER_FUNCTION_DEFAULT,
> - AMDGPU_TRANSFER_FUNCTION_SRGB,
> - AMDGPU_TRANSFER_FUNCTION_BT709,
> - AMDGPU_TRANSFER_FUNCTION_PQ,
> - AMDGPU_TRANSFER_FUNCTION_LINEAR,
> - AMDGPU_TRANSFER_FUNCTION_UNITY,
> - AMDGPU_TRANSFER_FUNCTION_GAMMA22,
> - AMDGPU_TRANSFER_FUNCTION_GAMMA24,
> - AMDGPU_TRANSFER_FUNCTION_GAMMA26,
> + AMDGPU_TRANSFER_FUNCTION_SRGB_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_BT709_INV_OETF,
> + AMDGPU_TRANSFER_FUNCTION_PQ_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_IDENTITY,
> + AMDGPU_TRANSFER_FUNCTION_GAMMA22_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_GAMMA24_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_GAMMA26_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_SRGB_INV_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_BT709_OETF,
> + AMDGPU_TRANSFER_FUNCTION_PQ_INV_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_GAMMA22_INV_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_GAMMA24_INV_EOTF,
> + AMDGPU_TRANSFER_FUNCTION_GAMMA26_INV_EOTF,
> +AMDGPU_TRANSFER_FUNCTION_COUNT
> };
>
> struct dm_plane_state {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 56ce008b9095..d03bdb010e8b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -85,18 +85,57 @@ void amdgpu_dm_init_color_mod(void)
> }
>
> #ifdef AMD_PRIVATE_COLOR
> -static const struct drm_prop_enum_list amdgpu_transfer_function_enum_list[]
> = {
> - { AMDGPU_TRANSFER_FUNCTION_DEFAULT, "Default" },
> - { AMDGPU_TRANSFER_FUNCTION_SRGB, "sRGB" },
> - { AMDGPU_TRANSFER_FUNCTION_BT709, "BT.709" },
> - { AMDGPU_TRANSFER_FUNCTION_PQ, "PQ (Perceptual Quantizer)" },
> - { AMDGPU_TRANSFER_FUNCTION_LINEAR, "Linear" },
> - { AMDGPU_TRANSFER_FUNCTION_UNITY, "Unity" },
> - { AMDGPU_TRANSFER_FUNCTION_GAMMA22, "Gamma 2.2" },
> - { AMDGPU_TRANSFER_FUNCTION_GAMMA24, "Gamma 2.4" },
> - { AMDGPU_TRANSFER_FUNCTION_GAMMA26, "Gamma 2.6" },
> +static const char * const
> +amdgpu_transfer_function_names[] = {
> + [AMDGPU_TRANSFER_FUNCTION_DEFAULT] = "Default",
> + [AMDGPU_TRANSFER_FUNCTION_IDENTITY] = "Identity",
> + [AMDGPU_TRANSFER_FUNCTION_SRGB_EOTF]= "sRGB EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_BT709_INV_OETF] = "BT.709 inv_OETF",
> + [AMDGPU_TRANSFER_FUNCTION_PQ_EOTF] = "PQ EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_GAMMA22_EOTF] = "Gamma 2.2 EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_GAMMA24_EOTF] = "Gamma 2.4 EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_GAMMA26_EOTF] = "Gamma 2.6 EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_SRGB_INV_EOTF]= "sRGB inv_EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_BT709_OETF] = "BT.709 OETF",
> + [AMDGPU_TRANSFER_FUNCTION_PQ_INV_EOTF] = "PQ inv_EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_GAMMA22_INV_EOTF] = "Gamma 2.2 inv_EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_GAMMA24_INV_EOTF] = "Gamma 2.4 inv_EOTF",
> + [AMDGPU_TRANSFER_FUNCTION_GAMMA26_INV_EOTF] = "Gamma 2.6 inv_EOTF",
> };
>
> +static const u32 amdgpu_eotf =
> + BIT(AMDGPU_TRANSFER_FUNCTION_SRGB_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_BT709_INV_OETF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_PQ_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA22_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA24_EOTF) |
> + BIT(AMDGPU_TRANSFER_FUNCTION_GAMMA26_EOTF);
> +
[PATCH v13 4/4] MAINTAINERS: Add maintainer for RZ DU drivers
Add my self as maintainer for RZ DU drivers. While at it, update the entries for common parts, rcar-du and shmobile. Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart --- v12->v13: * No change. v11->v12: * No change. v10->v11: * No change. v9->v10: * No change. v8->v9: * Added Rb tag from Laurent. * Updated entries for common parts(Makefile and Kconfig). v8: * New patch --- MAINTAINERS | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ec79843f842a..c20ed4e4a2cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7033,7 +7033,7 @@ F:drivers/gpu/host1x/ F: include/linux/host1x.h F: include/uapi/drm/tegra_drm.h -DRM DRIVERS FOR RENESAS +DRM DRIVERS FOR RENESAS RCAR AND SHMOBILE M: Laurent Pinchart M: Kieran Bingham L: dri-devel@lists.freedesktop.org @@ -7044,9 +7044,20 @@ F: Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml F: Documentation/devicetree/bindings/display/renesas,du.yaml -F: drivers/gpu/drm/renesas/ +F: drivers/gpu/drm/renesas/Kconfig +F: drivers/gpu/drm/renesas/Makefile +F: drivers/gpu/drm/renesas/rcar-du/ +F: drivers/gpu/drm/renesas/shmobile/ F: include/linux/platform_data/shmob_drm.h +DRM DRIVERS FOR RENESAS RZ +M: Biju Das +L: dri-devel@lists.freedesktop.org +L: linux-renesas-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml +F: drivers/gpu/drm/renesas/rz-du/ + DRM DRIVERS FOR ROCKCHIP M: Sandy Huang M: Heiko Stübner -- 2.25.1
[PATCH v13 3/4] drm: renesas: Add RZ/G2L DU Support
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support the blending of two picture layers and
raster operations (ROPs).
The DU module is connected to VSPD. Add RZ/G2L DU support for RZ/G2L
alike SoCs.
Signed-off-by: Biju Das
---
Ref:
https://lore.kernel.org/linux-renesas-soc/os0pr01mb5922717e4ccfe07f3c25fbc986...@os0pr01mb5922.jpnprd01.prod.outlook.com/#t
v12->v13:
* Dropped DU_MCR0_DPI_OE and unused macros.
* Dropped unneeded backward compatibility with old DTBs as it is new driver.
* Replaced "cells > 1"-> "cells != 1" in rzg2l_du_vsps_init().
* Fixed memory leak in rzg2l_du_vsps_init().
* Dropped drm_plane_create_{alpha,zpos,blend_mode}_property().
v11->v12:
* Replaced rzg2l_du_write() with writel().
v10->v11:
* Replaced CONFIG_DRM_RCAR_VSP->CONFIG_VIDEO_RENESAS_VSP1 for building
rzg2l_du_vsp driver.
* Dropped "rzg2l_du_regs.h" instead the relevant definitions defined in
.c file.
* Dropped setting ditr5 based on latest HW manual 1.3.0/1.4.0
* Updated the comment for auto clear.
* Replaced writel()->rzg2l_du_write() in rzg2l_du_start_stop().
* Dropped CRC related functions as it does not have DISCOM.
* Replaced the variable possible_crtcs->possible_outputs in
struct rzg2l_du_output_routing.
* Updated DMA_BIT_MASK from 40->32.
* Dropped unneeded struct drm_bridge from rzg2l_du_drv.h.
* Dropped colour keying support as it doesn't have planes.
* Added only RGB formats in rzg2l_du_format_infos.
* Dropped chroma planes from rzg2l_du_fb_create().
* Updated the comment for max_pitch in rzg2l_du_fb_create().
* Dropped possible_crtcs check in rzg2l_du_encoders_init().
* Dropped additional empty line from struct rzg2l_du_device.
v9->v10:
* Dropped ARM64 dependency from Kconfig.
* Sorted the configs alphabetically in Kconfig.
* Dropped DRM_RCAR_VSP config option and make DRM_RZG2L_DU depend on
VIDEO_RENESAS_VSP1.
* On rzg2l_du_crtc_set_display_timing() replaced the setting of parent
clk rate with dclk rate.
* Added rzg2l_du_write() wrapper function.
* Updated the comment atomic_begin->atomic_flush.
* Dropped .atomic_check and .atomic_begin callback
* Renamed __rzg2l_du_crtc_plane_atomic_check->__rzg2l_du_vsp_plane_atomic
_check and moved it to rzg2l_du_vsp.c
* Added struct clk in rzg2l_du_crtc.h
* Dropped the variables mmio_offset,index,vblank_lock,vblank_wait,
vblank_count from struct rzg2l_du_crtc.
* Replaced the macro to_rzg2l_crtc with static inline functions.
* Dropped the unneeded header files clk.h, io.h, mm.h, pm.h, slab.h,
wait.h and drm_managed.h from rzg2l_du_drv.c.
* Replaced DRM_INFO->drm_info
* Dropped the callbacks prime_handle_to_fd, prime_fd_to_handle and
gem_prime_mmap.
* Replaced the callback remove->remove_new.
* Dropped header file wait.h and added forward declarations struct clk and
rzg2l_du_device from rzg2l_du_drv.h.
* Dropped the dsi and dpad0_source variables from struct rzg2l_du_device.
* Replaced the macro to_rzg2l_encoder with static inline functions.
* Dropped header files dma-buf.h and wait.h from rzg2l_du_kms.c.
* Dropped struct sg_table and added the scatterlist.h header file in
rzg2l_du_vsp.h
* Added container_of.h header file, forward declarations struct device and
struct rzg2l_du_device in rzg2l_du_vsp.h.
v8->v9:
* Dropped reset_control_assert() from error patch for rzg2l_du_crtc_get() as
suggested by Philipp Zabel.
v7->v8:
* Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du
folder.
* Updated KConfig and Makefile.
v6->v7:
* Split DU lib and RZ/G2L du driver as separate patch series as
DU support added to more platforms based on RZ/G2L alike SoCs.
* Rebased to latest drm-tip.
* Added patch #2 for binding support for RZ/V2L DU
* Added patch #4 for driver support for RZ/V2L DU
* Added patch #5 for SoC DTSI support for RZ/G2L DU
* Added patch #6 for SoC DTSI support for RZ/V2L DU
* Added patch #7 for Enabling DU on SMARC EVK based on RZ/{G2L,V2L} SoCs.
* Added patch #8 for Enabling DU on SMARC EVK based on RZ/G2LC SoC.
---
drivers/gpu/drm/renesas/Kconfig | 1 +
drivers/gpu/drm/renesas/Makefile | 1 +
drivers/gpu/drm/renesas/rz-du/Kconfig | 12 +
drivers/gpu/drm/renesas/rz-du/Makefile| 8 +
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 431
drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h | 89
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c | 176 +++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h | 78 +++
.../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 72 +++
.../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h | 32 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c | 433 +
drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h | 43 ++
drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c | 460 ++
[PATCH v13 2/4] dt-bindings: display: renesas, rzg2l-du: Document RZ/V2L DU bindings
Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
SoC and therefore use RZ/G2L fallback to avoid any driver changes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
v12->v13:
* No change.
v11->v12:
* No change.
v10->v11:
* No change.
v9->v10:
* No change.
V8->v9:
* Added Rb tag from Laurent and Geert.
v7->v8:
* Fixed the typo vsp2->du
* Added Rb tag from Rob as the change is trivial.
v7:
* New patch.
---
.../devicetree/bindings/display/renesas,rzg2l-du.yaml| 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index c0ad194c538d..08e5b9478051 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -16,8 +16,13 @@ description: |
properties:
compatible:
-enum:
- - renesas,r9a07g044-du # RZ/G2{L,LC}
+oneOf:
+ - enum:
+ - renesas,r9a07g044-du # RZ/G2{L,LC}
+ - items:
+ - enum:
+ - renesas,r9a07g054-du# RZ/V2L
+ - const: renesas,r9a07g044-du # RZ/G2L fallback
reg:
maxItems: 1
--
2.25.1
[PATCH v13 1/4] dt-bindings: display: Document Renesas RZ/G2L DU bindings
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timings
− Selecting the polarity of output DCLK, HSYNC, VSYNC, and DE
− Supports Progressive
− Input data format (from VSPD): RGB888, RGB666
− Output data format: same as Input data format
− Supporting Full HD (1920 pixels x 1080 lines) for MIPI-DSI Output
− Supporting WXGA (1280 pixels x 800 lines) for Parallel Output
This patch documents the DU module found on RZ/G2L LCDC.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
---
v12->v13:
* No change.
v11->v12:
* Dropped quotes in ref handle for renesas,vsps property.
* Retained tags as it is trivial change.
v10->v11:
* No change
v9->v10:
* Added Rb tag from Laurent
* Updated the commit description.
* Updated description of the port by dropping the text "specified in
Documentation/devicetree/bindings/graph.txt."
* Dropped empty endpoint from example.
v8->v9:
* No change
v7->v8:
* No change
v6->v7:
* No change
v5->v6:
* No change.
v4->v5:
* Added Rb tag from Rob.
v3->v4:
* Changed compatible name from renesas,du-r9a07g044->renesas,r9a07g044-du
* started using same compatible for RZ/G2{L,LC}
v3: New patch
---
.../bindings/display/renesas,rzg2l-du.yaml| 121 ++
1 file changed, 121 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
new file mode 100644
index ..c0ad194c538d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/renesas,rzg2l-du.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas RZ/G2L Display Unit (DU)
+
+maintainers:
+ - Biju Das
+ - Laurent Pinchart
+
+description: |
+ These DT bindings describe the Display Unit embedded in the Renesas RZ/G2L
+ and RZ/V2L SoCs.
+
+properties:
+ compatible:
+enum:
+ - renesas,r9a07g044-du # RZ/G2{L,LC}
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Main clock
+ - description: Register access clock
+ - description: Video clock
+
+ clock-names:
+items:
+ - const: aclk
+ - const: pclk
+ - const: vclk
+
+ resets:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ The connections to the DU output video ports are modeled using the OF
+ graph bindings. The number of ports and their assignment are
+ model-dependent. Each port shall have a single endpoint.
+
+patternProperties:
+ "^port@[0-1]$":
+$ref: /schemas/graph.yaml#/properties/port
+unevaluatedProperties: false
+
+required:
+ - port@0
+
+unevaluatedProperties: false
+
+ renesas,vsps:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle to VSP instance that serves the DU channel
+- description: Channel index identifying the LIF instance in that VSP
+description:
+ A list of phandle and channel index tuples to the VSPs that handle the
+ memory interfaces for the DU channels.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - power-domains
+ - ports
+ - renesas,vsps
+
+additionalProperties: false
+
+examples:
+ # RZ/G2L DU
+ - |
+#include
+#include
+
+display@1089 {
+compatible = "renesas,r9a07g044-du";
+reg = <0x1089 0x1>;
+interrupts = ;
+clocks = < CPG_MOD R9A07G044_LCDC_CLK_A>,
+ < CPG_MOD R9A07G044_LCDC_CLK_P>,
+ < CPG_MOD R9A07G044_LCDC_CLK_D>;
+clock-names = "aclk", "pclk", "vclk";
+resets = < R9A07G044_LCDC_RESET_N>;
+power-domains = <>;
+
+renesas,vsps = < 0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+endpoint {
+remote-endpoint = <_in>;
+};
+};
+port@1 {
+reg = <1>;
+};
+};
+};
+
+...
--
2.25.1
[PATCH v13 0/4] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit support
This path series aims to add support for RZ/G2L DU DRM driver.
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video
signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
The output from DSI is connected to ADV7535.
Ref:
https://lore.kernel.org/linux-renesas-soc/os0pr01mb5922717e4ccfe07f3c25fbc986...@os0pr01mb5922.jpnprd01.prod.outlook.com/#t
This patch series is tested with [2]
[2] https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=742810
Test logs kmscube: [3]
v12->v13:
* Dropped DU_MCR0_DPI_OE and unused macros.
* Dropped unneeded backward compatibility with old DTBs as it is new driver.
* Replaced "cells > 1"-> "cells != 1" in rzg2l_du_vsps_init().
* Fixed memory leak in rzg2l_du_vsps_init().
* Dropped drm_plane_create_{alpha,zpos,blend_mode}_property().
v11->v12:
* Dropped quotes in ref handle for renesas,vsps property.
* Retained tags as it is trivial change.
* Replaced rzg2l_du_write()->writel().
v10->v11:
* Replaced CONFIG_DRM_RCAR_VSP->CONFIG_VIDEO_RENESAS_VSP1 for building
rzg2l_du_vsp driver.
* Dropped "rzg2l_du_regs.h" instead the relevant definitions defined in
.c file.
* Dropped setting ditr5 based on latest HW manual 1.3.0/1.4.0
* Updated the comment for auto clear.
* Replaced writel()->rzg2l_du_write() in rzg2l_du_start_stop().
* Dropped CRC related functions as it does not have DISCOM.
* Replaced the variable possible_crtcs->possible_outputs in
struct rzg2l_du_output_routing.
* Updated DMA_BIT_MASK from 40->32.
* Dropped unneeded struct drm_bridge from rzg2l_du_drv.h.
* Dropped colour keying support as it doesn't have planes.
* Added only RGB formats in rzg2l_du_format_infos.
* Dropped chroma planes from rzg2l_du_fb_create().
* Updated the comment for max_pitch in rzg2l_du_fb_create().
* Dropped possible_crtcs check in rzg2l_du_encoders_init().
* Dropped additional empty line from struct rzg2l_du_device.
v9->v10:
* patch#1 is mainlined, so dropped from this series.
* Added Rb tag from Laurent for the binding patch.
* Updated the commit description.
* Updated description of the port by dropping the text "specified in
Documentation/devicetree/bindings/graph.txt."
* Dropped empty endpoint from example.
* Dropped ARM64 dependency from Kconfig.
* Sorted the configs alphabetically in Kconfig.
* Dropped DRM_RCAR_VSP config option and make DRM_RZG2L_DU depend on
VIDEO_RENESAS_VSP1.
* On rzg2l_du_crtc_set_display_timing() replaced the setting of parent
clk rate with dclk rate.
* Added rzg2l_du_write() wrapper function.
* Updated the comment atomic_begin->atomic_flush.
* Dropped .atomic_check and .atomic_begin callback
* Renamed __rzg2l_du_crtc_plane_atomic_check->__rzg2l_du_vsp_plane_atomic
_check and moved it to rzg2l_du_vsp.c
* Added struct clk in rzg2l_du_crtc.h
* Dropped the variables mmio_offset,index,vblank_lock,vblank_wait,
vblank_count from struct rzg2l_du_crtc.
* Replaced the macro to_rzg2l_crtc with static inline functions.
* Dropped the unneeded header files clk.h, io.h, mm.h, pm.h, slab.h,
wait.h and drm_managed.h from rzg2l_du_drv.c.
* Replaced DRM_INFO->drm_info
* Dropped the callbacks prime_handle_to_fd, prime_fd_to_handle and
gem_prime_mmap.
* Replaced the callback remove->remove_new.
* Dropped header file wait.h and added forward declarations struct clk and
rzg2l_du_device from rzg2l_du_drv.h.
* Dropped the dsi and dpad0_source variables from struct rzg2l_du_device.
* Replaced the macro to_rzg2l_encoder with static inline functions.
* Dropped header files dma-buf.h and wait.h from rzg2l_du_kms.c.
* Dropped struct sg_table and added the scatterlist.h header file in
rzg2l_du_vsp.h
* Added container_of.h header file, forward declarations struct device and
struct rzg2l_du_device in rzg2l_du_vsp.h.
v8->v9:
* Added Rb tag from Laurent and Acked-by tag from Kieran for patch#1.
* Added Rb tag from Laurent and Geert for patch#3.
* Dropped reset_control_assert() from error patch for rzg2l_du_crtc_get() as
suggested by Philipp Zabel.
* Added Rb tag from Laurent oatch#5.
* Updated MAINTAINERS entries for common parts(Makefile and Kconfig).
v7->v8:
* Moved rcar-du and shmobile DRM drivers to renesas specific vendor directory.
* Fixed the typo vsp2->du in RZ/V2L DU bindings patch.
* Added Rb tag from Rob for RZ/V2L DU bindings patch.
* Dropped RCar du lib and created RZ/G2L DU DRM driver by creating rz_du
folder.
* Updated MAINTAINERS entries.
v6->v7:
* Split DU lib and RZ/G2L du driver as separate patch series as
DU support added to more platforms based on RZ/G2L alike SoCs.
* Rebased to latest drm-tip.
* Added patch #2 for binding support for RZ/V2L DU
* Added patch #4 for driver support for RZ/V2L DU
* Added patch #5 for SoC DTSI support for RZ/G2L DU
* Added patch #6 for SoC DTSI support for RZ/V2L DU
* Added patch #7 for Enabling DU on SMARC EVK
Re: [PATCH v2 2/2] drm/msm/dp: attach the DP subconnector property
On 11/15/2023 12:06 AM, Johan Hovold wrote:
On Wed, Oct 25, 2023 at 12:23:10PM +0300, Dmitry Baryshkov wrote:
While developing and testing the commit bfcc3d8f94f4 ("drm/msm/dp:
support setting the DP subconnector type") I had the patch [1] in my
tree. I haven't noticed that it was a dependency for the commit in
question. Mea culpa.
This also broke boot on the Lenovo ThinkPad X13s.
Would be nice to get this fixed ASAP so that further people don't have
to debug this known regression.
I will queue this patch for -fixes rightaway.
Since the patch has not landed yet (and even was not reviewed)
and since one of the bridges erroneously uses USB connector type instead
of DP, attach the property directly from the MSM DP driver.
This fixes the following oops on DP HPD event:
drm_object_property_set_value (drivers/gpu/drm/drm_mode_object.c:288)
dp_display_process_hpd_high (drivers/gpu/drm/msm/dp/dp_display.c:402)
dp_hpd_plug_handle.isra.0 (drivers/gpu/drm/msm/dp/dp_display.c:604)
hpd_event_thread (drivers/gpu/drm/msm/dp/dp_display.c:1110)
kthread (kernel/kthread.c:388)
ret_from_fork (arch/arm64/kernel/entry.S:858)
This only says where the oops happened, it doesn't necessarily in itself
indicate an oops at all or that in this case it's a NULL pointer
dereference.
On the X13s I'm seeing the NULL deref in a different path during boot,
and when this happens after a deferred probe (due to the panel lookup
mess) it hangs the machine, which makes it a bit of a pain to debug:
Unable to handle kernel NULL pointer dereference at virtual address
0060
...
CPU: 4 PID: 57 Comm: kworker/u16:1 Not tainted 6.7.0-rc1 #4
Hardware name: Qualcomm QRD, BIOS 6.0.220110.BOOT.MXF.1.1-00470-MAKENA-1
01/10/2022
...
Call trace:
drm_object_property_set_value+0x0/0x88 [drm]
dp_display_process_hpd_high+0xa0/0x14c [msm]
dp_hpd_plug_handle.constprop.0.isra.0+0x90/0x110 [msm]
dp_bridge_atomic_enable+0x184/0x21c [msm]
edp_bridge_atomic_enable+0x60/0x94 [msm]
drm_atomic_bridge_chain_enable+0x54/0xc8 [drm]
drm_atomic_helper_commit_modeset_enables+0x194/0x26c [drm_kms_helper]
msm_atomic_commit_tail+0x204/0x804 [msm]
commit_tail+0xa4/0x18c [drm_kms_helper]
drm_atomic_helper_commit+0x19c/0x1b0 [drm_kms_helper]
drm_atomic_commit+0xa4/0x104 [drm]
drm_client_modeset_commit_atomic+0x22c/0x298 [drm]
drm_client_modeset_commit_locked+0x60/0x1c0 [drm]
drm_client_modeset_commit+0x30/0x58 [drm]
__drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xfc [drm_kms_helper]
drm_fb_helper_set_par+0x30/0x4c [drm_kms_helper]
fbcon_init+0x224/0x49c
visual_init+0xb0/0x108
do_bind_con_driver.isra.0+0x19c/0x38c
do_take_over_console+0x140/0x1ec
do_fbcon_takeover+0x6c/0xe4
fbcon_fb_registered+0x180/0x1f0
register_framebuffer+0x19c/0x228
__drm_fb_helper_initial_config_and_unlock+0x2e8/0x4e8 [drm_kms_helper]
drm_fb_helper_initial_config+0x3c/0x4c [drm_kms_helper]
msm_fbdev_client_hotplug+0x84/0xcc [msm]
drm_client_register+0x5c/0xa0 [drm]
msm_fbdev_setup+0x94/0x148 [msm]
msm_drm_bind+0x3d0/0x42c [msm]
try_to_bring_up_aggregate_device+0x1ec/0x2f4
__component_add+0xa8/0x194
component_add+0x14/0x20
dp_display_probe+0x278/0x41c [msm]
[1] https://patchwork.freedesktop.org/patch/30/
Fixes: bfcc3d8f94f4 ("drm/msm/dp: support setting the DP subconnector type")
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Johan Hovold
Tested-by: Johan Hovold
Thanks !
Johan
Re: [PATCH 4/4] drm/msm/dsi: fix DSC for the bonded DSI case
On 2023-11-14 14:00:19, Jonathan Marek wrote:
> On 11/14/23 1:28 PM, Marijn Suijten wrote:
> > On what hardware have you been testing this? Dmitry and I have a stack of
> > patches to resolve support for Active CTL programming on newer hardware (DPU
> > 5.0+ IIRC), where a single CTL is responsible for programming multiple INTF
> > and
> > DSC blocks as used in bonded DSI.
> >
>
> I am also using DPU 6+ but I won't be posting patches for DPU to support
> this as I am not using the upstream DPU codebase.
Oh that is an odd situation! At least glad to hear we aren't completely
duplicating our efforts :)
> > On 2023-11-14 12:42:16, Jonathan Marek wrote:
> >> For the bonded DSI case, DSC pic_width and timing calculations should use
> >> the width of a single panel instead of the total combined width.
> >>
> >> Signed-off-by: Jonathan Marek
> >> ---
> >> drivers/gpu/drm/msm/dsi/dsi.h | 3 ++-
> >> drivers/gpu/drm/msm/dsi/dsi_host.c| 20 +++-
> >> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
> >> 3 files changed, 14 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> >> index 28379b1af63f..3a641e69447c 100644
> >> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> >> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> >> @@ -93,7 +93,8 @@ int msm_dsi_host_power_off(struct mipi_dsi_host *host);
> >> int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
> >> const struct drm_display_mode *mode);
> >> enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
> >> - const struct drm_display_mode
> >> *mode);
> >> + const struct drm_display_mode *mode,
> >> + bool is_bonded_dsi);
> >> unsigned long msm_dsi_host_get_mode_flags(struct mipi_dsi_host *host);
> >> int msm_dsi_host_register(struct mipi_dsi_host *host);
> >> void msm_dsi_host_unregister(struct mipi_dsi_host *host);
> >> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> >> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> >> index 7284346ab787..a6286eb9d006 100644
> >> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> >> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> >> @@ -938,8 +938,7 @@ static void dsi_timing_setup(struct msm_dsi_host
> >> *msm_host, bool is_bonded_dsi)
> >> mode->hdisplay, mode->vdisplay);
> >>return;
> >>}
> >> -
> >> - dsc->pic_width = mode->hdisplay;
> >> + dsc->pic_width = hdisplay;
> >
> > In my testing and debugging on CMDmode panels downstream this value/register
> > was always programmed to the _full_ width of the bonded panel. Is that
> > maybe
> > different for video mode?
> >
>
> downstream dual DSI panel timings are specified for a single panel
> ("qcom,mdss-dsi-panel-width" is for a single panel, not both panels)
_dual panels_? In my case I have a "single panel" that is driven by two
"bonded" DSI hosts, just to achieve enough bandwidth.
Indeed my downstream DTS has qcom,mdss-dsi-panel-width set to half the total
panel width, but I recall seeing the full width in the register dump. I'll scan
through my logs and see if I can back this up.
> >>dsc->pic_height = mode->vdisplay;
> >>DBG("Mode %dx%d\n", dsc->pic_width, dsc->pic_height);
> >>
> >> @@ -950,6 +949,11 @@ static void dsi_timing_setup(struct msm_dsi_host
> >> *msm_host, bool is_bonded_dsi)
> >>if (ret)
> >>return;
> >>
> >> + if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO)
> >> + dsi_update_dsc_timing(msm_host, false, hdisplay);
> >> + else
> >> + dsi_update_dsc_timing(msm_host, true, hdisplay);
Another thought: it's probably clearer to write:
bool is_cmd_mode = msm_host->mode_flags & MIPI_DSI_MODE_VIDEO;
dsi_update_dsc_timing(msm_host, is_cmd_mode, hdisplay);
> >> +
> >
> > Such cleanups (which appear unrelated) should probably be posted as separate
> > patches.
> >
> > - Marijn
> >
>
> Its not unrelated, dsi_update_dsc_timing call is moved up so it can use
> the single-panel "hdisplay" value before it gets adjusted for DSC.
This reply was mostly expected after not looking at the original code folded in
the diff, and pretty much solidifies my point: it's a hidden semantical change
that's not immediately obvious from reading the patch, and why I'd like to see
this split up in a few smaller patches.
> >>/* Divide the display by 3 but keep back/font porch and
> >> * pulse width same
> >> */
> >> @@ -966,9 +970,6 @@ static void dsi_timing_setup(struct msm_dsi_host
> >> *msm_host, bool is_bonded_dsi)
> >>}
> >>
> >>if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) {
> >> - if (msm_host->dsc)
> >> - dsi_update_dsc_timing(msm_host, false,
Re: [PATCH v4] Documentation/gpu: VM_BIND locking document
On 11/15/23 18:02, Danilo Krummrich wrote: On 11/15/23 17:04, Thomas Hellström wrote: Hi, Danilo, On Wed, 2023-11-15 at 16:11 +0100, Danilo Krummrich wrote: On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote: Add the first version of the VM_BIND locking document which is intended to be part of the xe driver upstreaming agreement. The document describes and discuss the locking used during exec- functions, evicton and for userptr gpu-vmas. Intention is to be using the same nomenclature as the drm-vm-bind-async.rst. Thanks for reviewing. I'll update the document accordingly except for the s/an rwsem/a rwsem/g, I think it's "an rwsem" similarly to "an r". I read it as "read-write-sem". Would you read it as "ar-double-u-sem" then I guess? Yes. :) /Thomas /Thomas
Re: [PATCH] drm/i915/gsc: Mark internal GSC engine with reserved uabi class
Hi Tvrtko,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next-fixes]
[also build test WARNING on drm-tip/drm-tip drm/drm-next
drm-exynos/exynos-drm-next drm-misc/drm-misc-next linus/master v6.7-rc1
next-20231115]
[cannot apply to drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Tvrtko-Ursulin/drm-i915-gsc-Mark-internal-GSC-engine-with-reserved-uabi-class/20231115-190507
base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20231115110216.267138-1-tvrtko.ursulin%40linux.intel.com
patch subject: [PATCH] drm/i915/gsc: Mark internal GSC engine with reserved
uabi class
config: x86_64-rhel-8.3-rust
(https://download.01.org/0day-ci/archive/20231116/202311160136.etoh3ghf-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20231116/202311160136.etoh3ghf-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202311160136.etoh3ghf-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gt/intel_engine_user.c:225:26: warning: result of
>> comparison of constant -1 with expression of type 'u16' (aka 'unsigned
>> short') is always false [-Wtautological-constant-out-of-range-compare]
if (engine->uabi_class == I915_NO_UABI_CLASS) {
~~ ^ ~~
drivers/gpu/drm/i915/gt/intel_engine_user.c:243:26: warning: result of
comparison of constant -1 with expression of type 'u16' (aka 'unsigned short')
is always false [-Wtautological-constant-out-of-range-compare]
if (engine->uabi_class == I915_NO_UABI_CLASS)
~~ ^ ~~
2 warnings generated.
vim +225 drivers/gpu/drm/i915/gt/intel_engine_user.c
203
204 void intel_engines_driver_register(struct drm_i915_private *i915)
205 {
206 u16 name_instance, other_instance = 0;
207 struct legacy_ring ring = {};
208 struct list_head *it, *next;
209 struct rb_node **p, *prev;
210 LIST_HEAD(engines);
211
212 sort_engines(i915, );
213
214 prev = NULL;
215 p = >uabi_engines.rb_node;
216 list_for_each_safe(it, next, ) {
217 struct intel_engine_cs *engine =
218 container_of(it, typeof(*engine), uabi_list);
219
220 if (intel_gt_has_unrecoverable_error(engine->gt))
221 continue; /* ignore incomplete engines */
222
223 GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
224 engine->uabi_class = uabi_classes[engine->class];
> 225 if (engine->uabi_class == I915_NO_UABI_CLASS) {
226 name_instance = other_instance++;
227 } else {
228 GEM_BUG_ON(engine->uabi_class >=
229
ARRAY_SIZE(i915->engine_uabi_class_count));
230 name_instance =
231
i915->engine_uabi_class_count[engine->uabi_class]++;
232 }
233 engine->uabi_instance = name_instance;
234
235 /*
236 * Replace the internal name with the final user and
log facing
237 * name.
238 */
239 engine_rename(engine,
240intel_engine_class_repr(engine->class),
241name_instance);
242
243 if (engine->uabi_class == I915_NO_UABI_CLASS)
244 continue;
245
246 rb_link_node(>uabi_node, prev, p);
247 rb_insert_color(>uabi_node,
>uabi_engines);
248
249 GEM_BUG_ON(intel_engine_lookup_user(i915,
250 engine->uabi_class,
251
engine->uabi_instance) != engine);
252
253 /* Fix up the mapping to match default
execbuf::user_map[] */
254 add_legacy_ring(, engin
Re: [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used for tunneling
On 11/15/2023 04:40, Mika Westerberg wrote: Hi Mario, On Tue, Nov 14, 2023 at 02:07:53PM -0600, Mario Limonciello wrote: USB4 routers support a feature called "PCIe tunneling". This allows PCIe traffic to be transmitted over USB4 fabric. PCIe root ports that are used in this fashion can be discovered by device specific data that specifies the USB4 router they are connected to. For the PCI core, the specific connection information doesn't matter, but it's interesting to know that this root port is used for tunneling traffic. This will allow other decisions to be made based upon it. Detect the `usb4-host-interface` _DSD and if it's found save it into a new `is_virtual_link` bit in `struct pci_device`. While this is fine for the "first" tunneled link, this does not take into account possible other "virtual" links that lead to the endpoint in question. Typically for eGPU it only makes sense to plug it directly to the host but say there is a USB4 hub (with PCIe tunneling capabilities) in the middle. Now the link from the hub to the eGPU that is also "virtual" is not marked as such and the bandwidth calculations may not get what is expected. Right; you mentioned the DVSEC available for hubs in this case. As I don't have one of these to validate it works properly I was thinking that should be a follow up. If you think it should be part of the same series I'll add it, but I'd ask if you can please check I did it right on one that reports the DVSEC? It should be possible to map the PCIe ports that go over USB4 links through router port operation "Get PCIe Downstream Entry Mapping" and for the Thunderbolt 3 there is the DROM entries (I believe Lukas has patches for this part already) but I guess it is outside of the scope of this series. Yeah I'd prefer to avoid the kitchen sink for the first pass and then we an add more cases to is_virtual_link later.
Re: [PATCH v3 7/7] PCI: Exclude PCIe ports used for virtual links in pcie_bandwidth_available()
On 11/14/2023 21:23, Lazar, Lijo wrote:
On 11/15/2023 1:37 AM, Mario Limonciello wrote:
The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
behave as a PCIe Gen1 device. The actual performance of these ports is
controlled by the fabric implementation.
Callers for pcie_bandwidth_available() will always find the PCIe ports
used for tunneling as a limiting factor potentially leading to incorrect
performance decisions.
To prevent such problems check explicitly for ports that are marked as
virtual links or as thunderbolt controllers and skip them when looking
for bandwidth limitations of the hierarchy. If the only device connected
is a port used for tunneling then report that device.
Callers to pcie_bandwidth_available() could make this change on their
own as well but then they wouldn't be able to detect other potential
speed bottlenecks from the hierarchy without duplicating
pcie_bandwidth_available() logic.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925#note_2145860
Link: https://www.usb.org/document-library/usb4r-specification-v20
USB4 V2 with Errata and ECN through June 2023
Section 11.2.1
Signed-off-by: Mario Limonciello
---
v2->v3:
* Split from previous patch version
* Look for thunderbolt or virtual link
---
drivers/pci/pci.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0ff7883cc774..b1fb2258b211 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6269,11 +6269,20 @@ static u32 pcie_calc_bw_limits(struct pci_dev
*dev, u32 bw,
* limiting_dev, speed, and width pointers are supplied) information
about
* that point. The bandwidth returned is in Mb/s, i.e.,
megabits/second of
* raw bandwidth.
+ *
+ * This excludes the bandwidth calculation that has been returned from a
+ * PCIe device that is used for transmitting tunneled PCIe traffic
over a virtual
+ * link part of larger hierarchy. Examples include Thunderbolt3 and
USB4 links.
+ * The calculation is excluded because the USB4 specification
specifies that the
+ * max speed returned from PCIe configuration registers for the
tunneling link is
+ * always PCI 1x 2.5 GT/s. When only tunneled devices are present,
the bandwidth
+ * returned is the bandwidth available from the first tunneled device.
*/
u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev
**limiting_dev,
enum pci_bus_speed *speed,
enum pcie_link_width *width)
{
+ struct pci_dev *vdev = NULL;
u32 bw = 0;
if (speed)
@@ -6282,10 +6291,20 @@ u32 pcie_bandwidth_available(struct pci_dev
*dev, struct pci_dev **limiting_dev,
*width = PCIE_LNK_WIDTH_UNKNOWN;
while (dev) {
+ if (dev->is_virtual_link || dev->is_thunderbolt) {
+ if (!vdev)
+ vdev = dev;
+ goto skip;
+ }
One problem with this is it *silently* ignores the bandwidth limiting
device - the bandwidth may not be really available if there are virtual
links in between. That is a change in behavior from the messages shown
in __pcie_print_link_status.
That's a good point. How about a matching behavioral change to
__pcie_print_link_status() where it looks at the entire hierarchy for
any links marked as virtual and prints a message along the lines of:
"This value may be further limited by virtual links".
Thanks,
Lijo
bw = pcie_calc_bw_limits(dev, bw, limiting_dev, speed, width);
+skip:
dev = pci_upstream_bridge(dev);
}
+ /* If nothing "faster" found on hierarchy, limit to first virtual
link */
+ if (vdev && !bw)
+ bw = pcie_calc_bw_limits(vdev, bw, limiting_dev, speed, width);
+
return bw;
}
EXPORT_SYMBOL(pcie_bandwidth_available);
Re: [PATCH v4] Documentation/gpu: VM_BIND locking document
On 11/15/23 17:04, Thomas Hellström wrote: Hi, Danilo, On Wed, 2023-11-15 at 16:11 +0100, Danilo Krummrich wrote: On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote: Add the first version of the VM_BIND locking document which is intended to be part of the xe driver upstreaming agreement. The document describes and discuss the locking used during exec- functions, evicton and for userptr gpu-vmas. Intention is to be using the same nomenclature as the drm-vm-bind-async.rst. Thanks for reviewing. I'll update the document accordingly except for the s/an rwsem/a rwsem/g, I think it's "an rwsem" similarly to "an r". I read it as "read-write-sem". Would you read it as "ar-double-u-sem" then I guess? /Thomas
[PATCH 09/10] accel/habanalabs: print error code when mapping fails
From: Dani Liberman
Failure to map is considered a non-trivial error and we need to notify
the user about it.
Signed-off-by: Dani Liberman
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/memory.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/accel/habanalabs/common/memory.c
b/drivers/accel/habanalabs/common/memory.c
index 0b8689fe0b64..3348ad12c237 100644
--- a/drivers/accel/habanalabs/common/memory.c
+++ b/drivers/accel/habanalabs/common/memory.c
@@ -955,8 +955,8 @@ static int map_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
(i + 1) == phys_pg_pack->npages);
if (rc) {
dev_err(hdev->dev,
- "map failed for handle %u, npages: %llu,
mapped: %llu",
- phys_pg_pack->handle, phys_pg_pack->npages,
+ "map failed (%d) for handle %u, npages: %llu,
mapped: %llu\n",
+ rc, phys_pg_pack->handle, phys_pg_pack->npages,
mapped_pg_cnt);
goto err;
}
@@ -1186,7 +1186,8 @@ static int map_device_va(struct hl_ctx *ctx, struct
hl_mem_in *args, u64 *device
rc = map_phys_pg_pack(ctx, ret_vaddr, phys_pg_pack);
if (rc) {
- dev_err(hdev->dev, "mapping page pack failed for handle %u\n",
handle);
+ dev_err(hdev->dev, "mapping page pack failed (%d) for handle
%u\n",
+ rc, handle);
mutex_unlock(>mmu_lock);
goto map_err;
}
--
2.34.1
[PATCH 07/10] accel/habanalabs: set hard reset flag if graceful reset is skipped
From: Tomer Tayar hl_device_cond_reset() might be called with the hard reset flag unset, because a compute reset upon device release as part of a graceful reset is valid. If the conditions for graceful reset are not met, hl_device_reset() will be called for an immediate reset. In this case a compute reset is not valid, so it will be replaced with a hard reset together with a debug message about it. This message might be confusing, as it implies that a compute reset was requested when it shouldn't. To prevent this confusion, set the hard reset flag in hl_device_cond_reset() if going to an immediate reset. Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/accel/habanalabs/common/device.c b/drivers/accel/habanalabs/common/device.c index 6bf5f1d0d005..a365791a9f5c 100644 --- a/drivers/accel/habanalabs/common/device.c +++ b/drivers/accel/habanalabs/common/device.c @@ -2040,7 +2040,7 @@ int hl_device_cond_reset(struct hl_device *hdev, u32 flags, u64 event_mask) if (ctx) hl_ctx_put(ctx); - return hl_device_reset(hdev, flags); + return hl_device_reset(hdev, flags | HL_DRV_RESET_HARD); } static void hl_notifier_event_send(struct hl_notifier_event *notifier_event, u64 event_mask) -- 2.34.1
[PATCH 10/10] accel/habanalabs: expose module id through sysfs
From: Dani Liberman
Module ID exposes the physical location of the device in the server,
from the pov of the devices in regard to how they are connected by
internal fabric.
This information is already exposed in our INFO ioctl, but there are
utilities and scripts running in data-center which are already
accessing sysfs for topology information and it is easier for them
to continue getting that information from sysfs instead of opening
a file descriptor.
Signed-off-by: Dani Liberman
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
Documentation/ABI/testing/sysfs-driver-habanalabs | 6 ++
drivers/accel/habanalabs/common/sysfs.c | 10 ++
2 files changed, 16 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs
b/Documentation/ABI/testing/sysfs-driver-habanalabs
index c63ca1ad500d..89fe3b09d4ad 100644
--- a/Documentation/ABI/testing/sysfs-driver-habanalabs
+++ b/Documentation/ABI/testing/sysfs-driver-habanalabs
@@ -149,6 +149,12 @@ Contact:ogab...@kernel.org
Description:Displays the current clock frequency, in Hz, of the MME compute
engine. This property is valid only for the Goya ASIC family
+What: /sys/class/accel/accel/device/module_id
+Date: Nov 2023
+KernelVersion: not yet upstreamed
+Contact:ogab...@kernel.org
+Description:Displays the device's module id
+
What: /sys/class/accel/accel/device/pci_addr
Date: Jan 2019
KernelVersion: 5.1
diff --git a/drivers/accel/habanalabs/common/sysfs.c
b/drivers/accel/habanalabs/common/sysfs.c
index 278606373055..8d2164691d81 100644
--- a/drivers/accel/habanalabs/common/sysfs.c
+++ b/drivers/accel/habanalabs/common/sysfs.c
@@ -386,6 +386,14 @@ static ssize_t security_enabled_show(struct device *dev,
return sprintf(buf, "%d\n", hdev->asic_prop.fw_security_enabled);
}
+static ssize_t module_id_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct hl_device *hdev = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n",
le32_to_cpu(hdev->asic_prop.cpucp_info.card_location));
+}
+
static DEVICE_ATTR_RO(armcp_kernel_ver);
static DEVICE_ATTR_RO(armcp_ver);
static DEVICE_ATTR_RO(cpld_ver);
@@ -405,6 +413,7 @@ static DEVICE_ATTR_RO(thermal_ver);
static DEVICE_ATTR_RO(uboot_ver);
static DEVICE_ATTR_RO(fw_os_ver);
static DEVICE_ATTR_RO(security_enabled);
+static DEVICE_ATTR_RO(module_id);
static struct bin_attribute bin_attr_eeprom = {
.attr = {.name = "eeprom", .mode = (0444)},
@@ -430,6 +439,7 @@ static struct attribute *hl_dev_attrs[] = {
_attr_uboot_ver.attr,
_attr_fw_os_ver.attr,
_attr_security_enabled.attr,
+ _attr_module_id.attr,
NULL,
};
--
2.34.1
[PATCH 08/10] accel/habanalabs/gaudi2: get the correct QM CQ info upon an error
From: Tomer Tayar
Upon a QM error, the address/size from both the CQ and the ARC_CQ are
printed, although the instruction that led to the error was received
from only one of them.
Moreover, in case of a QM undefined opcode, only one of these
address/size sets will be captured based on the value of ARC_CQ_PTR.
However, this value can be non-zero even if currently the CQ is used, in
case the CQ/ARC_CQ are alternately used.
Under the assumption of having a stop-on-error configuration, modify to
use CP_STS.CUR_CQ field to get the relevant CQ for the QM error.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 44 +--
.../include/gaudi2/asic_reg/gaudi2_regs.h | 1 +
2 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 5075f92d15cc..77c480725a84 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -7860,36 +7860,36 @@ static bool gaudi2_handle_ecc_event(struct hl_device
*hdev, u16 event_type,
static void handle_lower_qman_data_on_err(struct hl_device *hdev, u64
qman_base, u64 event_mask)
{
- u32 lo, hi, cq_ptr_size, arc_cq_ptr_size;
- u64 cq_ptr, arc_cq_ptr, cp_current_inst;
-
- lo = RREG32(qman_base + QM_CQ_PTR_LO_4_OFFSET);
- hi = RREG32(qman_base + QM_CQ_PTR_HI_4_OFFSET);
- cq_ptr = ((u64) hi) << 32 | lo;
- cq_ptr_size = RREG32(qman_base + QM_CQ_TSIZE_4_OFFSET);
-
- lo = RREG32(qman_base + QM_ARC_CQ_PTR_LO_OFFSET);
- hi = RREG32(qman_base + QM_ARC_CQ_PTR_HI_OFFSET);
- arc_cq_ptr = ((u64) hi) << 32 | lo;
- arc_cq_ptr_size = RREG32(qman_base + QM_ARC_CQ_TSIZE_OFFSET);
+ u32 lo, hi, cq_ptr_size, cp_sts;
+ u64 cq_ptr, cp_current_inst;
+ bool is_arc_cq;
+
+ cp_sts = RREG32(qman_base + QM_CP_STS_4_OFFSET);
+ is_arc_cq = FIELD_GET(PDMA0_QM_CP_STS_CUR_CQ_MASK, cp_sts); /* 0 -
legacy CQ, 1 - ARC_CQ */
+
+ if (is_arc_cq) {
+ lo = RREG32(qman_base + QM_ARC_CQ_PTR_LO_OFFSET);
+ hi = RREG32(qman_base + QM_ARC_CQ_PTR_HI_OFFSET);
+ cq_ptr = ((u64) hi) << 32 | lo;
+ cq_ptr_size = RREG32(qman_base + QM_ARC_CQ_TSIZE_OFFSET);
+ } else {
+ lo = RREG32(qman_base + QM_CQ_PTR_LO_4_OFFSET);
+ hi = RREG32(qman_base + QM_CQ_PTR_HI_4_OFFSET);
+ cq_ptr = ((u64) hi) << 32 | lo;
+ cq_ptr_size = RREG32(qman_base + QM_CQ_TSIZE_4_OFFSET);
+ }
lo = RREG32(qman_base + QM_CP_CURRENT_INST_LO_4_OFFSET);
hi = RREG32(qman_base + QM_CP_CURRENT_INST_HI_4_OFFSET);
cp_current_inst = ((u64) hi) << 32 | lo;
dev_info(hdev->dev,
- "LowerQM. CQ: {ptr %#llx, size %u}, ARC_CQ: {ptr %#llx, size
%u}, CP: {instruction %#llx}\n",
- cq_ptr, cq_ptr_size, arc_cq_ptr, arc_cq_ptr_size,
cp_current_inst);
+ "LowerQM. %sCQ: {ptr %#llx, size %u}, CP: {instruction
%#llx}\n",
+ is_arc_cq ? "ARC_" : "", cq_ptr, cq_ptr_size, cp_current_inst);
if (event_mask & HL_NOTIFIER_EVENT_UNDEFINED_OPCODE) {
- if (arc_cq_ptr) {
- hdev->captured_err_info.undef_opcode.cq_addr =
arc_cq_ptr;
- hdev->captured_err_info.undef_opcode.cq_size =
arc_cq_ptr_size;
- } else {
- hdev->captured_err_info.undef_opcode.cq_addr = cq_ptr;
- hdev->captured_err_info.undef_opcode.cq_size =
cq_ptr_size;
- }
-
+ hdev->captured_err_info.undef_opcode.cq_addr = cq_ptr;
+ hdev->captured_err_info.undef_opcode.cq_size = cq_ptr_size;
hdev->captured_err_info.undef_opcode.stream_id = QMAN_STREAMS;
}
}
diff --git a/drivers/accel/habanalabs/include/gaudi2/asic_reg/gaudi2_regs.h
b/drivers/accel/habanalabs/include/gaudi2/asic_reg/gaudi2_regs.h
index a08378d0802b..8018214a7b59 100644
--- a/drivers/accel/habanalabs/include/gaudi2/asic_reg/gaudi2_regs.h
+++ b/drivers/accel/habanalabs/include/gaudi2/asic_reg/gaudi2_regs.h
@@ -250,6 +250,7 @@
#define QM_ARC_CQ_PTR_HI_OFFSET(mmPDMA0_QM_ARC_CQ_PTR_HI -
mmPDMA0_QM_BASE)
#define QM_ARC_CQ_TSIZE_OFFSET (mmPDMA0_QM_ARC_CQ_TSIZE -
mmPDMA0_QM_BASE)
+#define QM_CP_STS_4_OFFSET (mmPDMA0_QM_CP_STS_4 - mmPDMA0_QM_BASE)
#define QM_CP_CURRENT_INST_LO_4_OFFSET (mmPDMA0_QM_CP_CURRENT_INST_LO_4 -
mmPDMA0_QM_BASE)
#define QM_CP_CURRENT_INST_HI_4_OFFSET (mmPDMA0_QM_CP_CURRENT_INST_HI_4 -
mmPDMA0_QM_BASE)
--
2.34.1
[PATCH 05/10] accel/habanalabs/gaudi2: fix undef opcode reporting
From: Dafna Hirschfeld
currently the undefined opcode event bit in set only for lower cp and
only if 'write_enable' is true. It should be set anyway and for all
streams in order to report that event to userspace.
Signed-off-by: Dafna Hirschfeld
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/gaudi2/gaudi2.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index b739078c2d87..5075f92d15cc 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -7929,21 +7929,19 @@ static int gaudi2_handle_qman_err_generic(struct
hl_device *hdev, u16 event_type
error_count++;
}
- if (i == QMAN_STREAMS && error_count) {
- /* check for undefined opcode */
- if (glbl_sts_val &
PDMA0_QM_GLBL_ERR_STS_CP_UNDEF_CMD_ERR_MASK &&
-
hdev->captured_err_info.undef_opcode.write_enable) {
+ /* check for undefined opcode */
+ if (glbl_sts_val & PDMA0_QM_GLBL_ERR_STS_CP_UNDEF_CMD_ERR_MASK)
{
+ *event_mask |= HL_NOTIFIER_EVENT_UNDEFINED_OPCODE;
+ if (hdev->captured_err_info.undef_opcode.write_enable) {
memset(>captured_err_info.undef_opcode, 0,
sizeof(hdev->captured_err_info.undef_opcode));
-
-
hdev->captured_err_info.undef_opcode.write_enable = false;
hdev->captured_err_info.undef_opcode.timestamp
= ktime_get();
hdev->captured_err_info.undef_opcode.engine_id =
gaudi2_queue_id_to_engine_id[qid_base];
- *event_mask |=
HL_NOTIFIER_EVENT_UNDEFINED_OPCODE;
}
- handle_lower_qman_data_on_err(hdev, qman_base,
*event_mask);
+ if (i == QMAN_STREAMS)
+ handle_lower_qman_data_on_err(hdev, qman_base,
*event_mask);
}
}
--
2.34.1
[PATCH 06/10] accel/habanalabs: remove 'get temperature' debug print
From: Ofir Bitton The print was added long back for a specific debug and can now be removed. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/hwmon.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/accel/habanalabs/common/hwmon.c b/drivers/accel/habanalabs/common/hwmon.c index 8598056216e7..1ee2ee07e9ed 100644 --- a/drivers/accel/habanalabs/common/hwmon.c +++ b/drivers/accel/habanalabs/common/hwmon.c @@ -578,10 +578,6 @@ int hl_get_temperature(struct hl_device *hdev, CPUCP_PKT_CTL_OPCODE_SHIFT); pkt.sensor_index = __cpu_to_le16(sensor_index); pkt.type = __cpu_to_le16(attr); - - dev_dbg(hdev->dev, "get temp, ctl 0x%x, sensor %d, type %d\n", - pkt.ctl, pkt.sensor_index, pkt.type); - rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) , sizeof(pkt), 0, ); -- 2.34.1
[PATCH 04/10] accel/habanalabs: fix EQ heartbeat mechanism
From: Farah Kassabri
Stop rescheduling another heartbeat check when EQ heartbeat check fails
as it generates confusing logs in dmesg that the heartbeat fails.
Signed-off-by: Farah Kassabri
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index d9447aeb3937..6bf5f1d0d005 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -1044,20 +1044,21 @@ static bool is_pci_link_healthy(struct hl_device *hdev)
return (vendor_id == PCI_VENDOR_ID_HABANALABS);
}
-static void hl_device_eq_heartbeat(struct hl_device *hdev)
+static int hl_device_eq_heartbeat_check(struct hl_device *hdev)
{
- u64 event_mask = HL_NOTIFIER_EVENT_DEVICE_RESET |
HL_NOTIFIER_EVENT_DEVICE_UNAVAILABLE;
struct asic_fixed_properties *prop = >asic_prop;
if (!prop->cpucp_info.eq_health_check_supported)
- return;
+ return 0;
if (hdev->eq_heartbeat_received) {
hdev->eq_heartbeat_received = false;
} else {
dev_err(hdev->dev, "EQ heartbeat event was not received!\n");
- hl_device_cond_reset(hdev, HL_DRV_RESET_HARD, event_mask);
+ return -EIO;
}
+
+ return 0;
}
static void hl_device_heartbeat(struct work_struct *work)
@@ -1074,10 +1075,9 @@ static void hl_device_heartbeat(struct work_struct *work)
/*
* For EQ health check need to check if driver received the heartbeat
eq event
* in order to validate the eq is working.
+* Only if both the EQ is healthy and we managed to send the next
heartbeat reschedule.
*/
- hl_device_eq_heartbeat(hdev);
-
- if (!hdev->asic_funcs->send_heartbeat(hdev))
+ if ((!hl_device_eq_heartbeat_check(hdev)) &&
(!hdev->asic_funcs->send_heartbeat(hdev)))
goto reschedule;
if (hl_device_operational(hdev, NULL))
--
2.34.1
[PATCH 03/10] accel/habanalabs: add support for Gaudi2C device
Gaudi2 with PCI revision ID with the value of '3' represents Gaudi2C
device and should be detected and initialized as Gaudi2.
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 3 +++
drivers/accel/habanalabs/common/habanalabs.h | 2 ++
drivers/accel/habanalabs/common/habanalabs_drv.c | 3 +++
drivers/accel/habanalabs/common/mmu/mmu.c| 1 +
drivers/accel/habanalabs/common/sysfs.c | 3 +++
drivers/accel/habanalabs/include/hw_ip/pci/pci_general.h | 1 +
6 files changed, 13 insertions(+)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index d95a981b2906..d9447aeb3937 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -853,6 +853,9 @@ static int device_early_init(struct hl_device *hdev)
gaudi2_set_asic_funcs(hdev);
strscpy(hdev->asic_name, "GAUDI2B", sizeof(hdev->asic_name));
break;
+ case ASIC_GAUDI2C:
+ gaudi2_set_asic_funcs(hdev);
+ strscpy(hdev->asic_name, "GAUDI2C", sizeof(hdev->asic_name));
break;
default:
dev_err(hdev->dev, "Unrecognized ASIC type %d\n",
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 5c69a482b8de..7b0209e5bad6 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -1262,6 +1262,7 @@ struct hl_dec {
* @ASIC_GAUDI_SEC: Gaudi secured device (HL-2000).
* @ASIC_GAUDI2: Gaudi2 device.
* @ASIC_GAUDI2B: Gaudi2B device.
+ * @ASIC_GAUDI2C: Gaudi2C device.
*/
enum hl_asic_type {
ASIC_INVALID,
@@ -1270,6 +1271,7 @@ enum hl_asic_type {
ASIC_GAUDI_SEC,
ASIC_GAUDI2,
ASIC_GAUDI2B,
+ ASIC_GAUDI2C,
};
struct hl_cs_parser;
diff --git a/drivers/accel/habanalabs/common/habanalabs_drv.c
b/drivers/accel/habanalabs/common/habanalabs_drv.c
index 35ae0ff347f5..e542fd40e16c 100644
--- a/drivers/accel/habanalabs/common/habanalabs_drv.c
+++ b/drivers/accel/habanalabs/common/habanalabs_drv.c
@@ -141,6 +141,9 @@ static enum hl_asic_type get_asic_type(struct hl_device
*hdev)
case REV_ID_B:
asic_type = ASIC_GAUDI2B;
break;
+ case REV_ID_C:
+ asic_type = ASIC_GAUDI2C;
+ break;
default:
break;
}
diff --git a/drivers/accel/habanalabs/common/mmu/mmu.c
b/drivers/accel/habanalabs/common/mmu/mmu.c
index b2145716c605..b654302a68fc 100644
--- a/drivers/accel/habanalabs/common/mmu/mmu.c
+++ b/drivers/accel/habanalabs/common/mmu/mmu.c
@@ -596,6 +596,7 @@ int hl_mmu_if_set_funcs(struct hl_device *hdev)
break;
case ASIC_GAUDI2:
case ASIC_GAUDI2B:
+ case ASIC_GAUDI2C:
/* MMUs in Gaudi2 are always host resident */
hl_mmu_v2_hr_set_funcs(hdev, >mmu_func[MMU_HR_PGT]);
break;
diff --git a/drivers/accel/habanalabs/common/sysfs.c
b/drivers/accel/habanalabs/common/sysfs.c
index 01f89f029355..278606373055 100644
--- a/drivers/accel/habanalabs/common/sysfs.c
+++ b/drivers/accel/habanalabs/common/sysfs.c
@@ -251,6 +251,9 @@ static ssize_t device_type_show(struct device *dev,
case ASIC_GAUDI2B:
str = "GAUDI2B";
break;
+ case ASIC_GAUDI2C:
+ str = "GAUDI2C";
+ break;
default:
dev_err(hdev->dev, "Unrecognized ASIC type %d\n",
hdev->asic_type);
diff --git a/drivers/accel/habanalabs/include/hw_ip/pci/pci_general.h
b/drivers/accel/habanalabs/include/hw_ip/pci/pci_general.h
index f5d497dc9bdc..4f951cada077 100644
--- a/drivers/accel/habanalabs/include/hw_ip/pci/pci_general.h
+++ b/drivers/accel/habanalabs/include/hw_ip/pci/pci_general.h
@@ -25,6 +25,7 @@ enum hl_revision_id {
REV_ID_INVALID = 0x00,
REV_ID_A= 0x01,
REV_ID_B= 0x02,
+ REV_ID_C= 0x03
};
#endif /* INCLUDE_PCI_GENERAL_H_ */
--
2.34.1
[PATCH 02/10] accel/habanalabs: add log when eq event is not received
From: Farah Kassabri
Add error log when no eq event is received from FW,
to cover a scenario when FW is stuck for some reason.
In such case driver will not receive neither the eq error interrupt
or the eq heartbeat event, and will just initiate a reset without
indication in the dmesg about the reason.
Signed-off-by: Farah Kassabri
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/device.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index 9711e8fc979d..d95a981b2906 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -1049,10 +1049,12 @@ static void hl_device_eq_heartbeat(struct hl_device
*hdev)
if (!prop->cpucp_info.eq_health_check_supported)
return;
- if (hdev->eq_heartbeat_received)
+ if (hdev->eq_heartbeat_received) {
hdev->eq_heartbeat_received = false;
- else
+ } else {
+ dev_err(hdev->dev, "EQ heartbeat event was not received!\n");
hl_device_cond_reset(hdev, HL_DRV_RESET_HARD, event_mask);
+ }
}
static void hl_device_heartbeat(struct work_struct *work)
--
2.34.1
[PATCH 01/10] accel/habanalabs/gaudi2: assume hard-reset by FW upon PCIe AXI drain
From: Tomer Tayar
When a PCIe AXI drain event happens, it is possible that the driver
cannot access the device through PCIe, and therefore cannot send a
hard-reset request to FW.
Starting from FW version 1.13, FW will initiate a hard-reset in such
a case without waiting for a reset request from the driver.
Signed-off-by: Tomer Tayar
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/accel/habanalabs/common/habanalabs.h | 8
drivers/accel/habanalabs/gaudi2/gaudi2.c | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/accel/habanalabs/common/habanalabs.h
b/drivers/accel/habanalabs/common/habanalabs.h
index 1655c101c705..5c69a482b8de 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -3594,6 +3594,14 @@ static inline bool hl_is_fw_sw_ver_below(struct
hl_device *hdev, u32 fw_sw_major
return false;
}
+static inline bool hl_is_fw_sw_ver_equal_or_greater(struct hl_device *hdev,
u32 fw_sw_major,
+ u32 fw_sw_minor)
+{
+ return (hdev->fw_sw_major_ver > fw_sw_major ||
+ (hdev->fw_sw_major_ver == fw_sw_major &&
+ hdev->fw_sw_minor_ver >= fw_sw_minor));
+}
+
/*
* Kernel module functions that can be accessed by entire module
*/
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 819660c684cf..b739078c2d87 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -10007,6 +10007,8 @@ static void gaudi2_handle_eqe(struct hl_device *hdev,
struct hl_eq_entry *eq_ent
error_count = gaudi2_handle_pcie_drain(hdev,
_entry->pcie_drain_ind_data);
reset_flags |= HL_DRV_RESET_FW_FATAL_ERR;
event_mask |= HL_NOTIFIER_EVENT_GENERAL_HW_ERR;
+ if (hl_is_fw_sw_ver_equal_or_greater(hdev, 1, 13))
+ is_critical = true;
break;
case GAUDI2_EVENT_PSOC59_RPM_ERROR_OR_DRAIN:
--
2.34.1
Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go
Hi Brenton, On 11/15/23 16:52, Brenton Simpson wrote: > Yes, thanks! > > That's the email attached to my public git work, so it should be the > one here as well. Ok, I've pushed this to drm-misc-fixes now, thank you for the patch. > Sorry for the hassle. Very new to sending PRs over email, and still > working through the kinks. Your initial submission was almost there. Just the weird thing with the + in the From: email-address. What also threw me off is that the From was: Normally the '+' + the part after it gets thrown away to get the canonical email address, so that would make your canonical email: where I now know it should be: . So next time you use a + address please do something like: I also guess you never got any of the replies addressed to since the mail server presumably has tried to deliver those to , but because your normal email was in the Cc things still worked out. Either way for future patches note that using "git send-email" is the advised way to submit kernel patches. Regards, Hans
Re: [PATCH v4] Documentation/gpu: VM_BIND locking document
Hi, Danilo, On Wed, 2023-11-15 at 16:11 +0100, Danilo Krummrich wrote: > On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote: > > Add the first version of the VM_BIND locking document which is > > intended to be part of the xe driver upstreaming agreement. > > > > The document describes and discuss the locking used during exec- > > functions, evicton and for userptr gpu-vmas. Intention is to be > > using the > > same nomenclature as the drm-vm-bind-async.rst. > > Thanks for reviewing. I'll update the document accordingly except for the s/an rwsem/a rwsem/g, I think it's "an rwsem" similarly to "an r". /Thomas
Re: [PATCH 1/3] kunit: Add a macro to wrap a deferred action function
On Wed, 15 Nov 2023 at 16:51, Maxime Ripard wrote: > > On Sat, 11 Nov 2023 04:08:26 +0800, David Gow wrote: > > KUnit's deferred action API accepts a void(*)(void *) function pointer > > which is called when the test is exited. However, we very frequently > > want to use existing functions which accept a single pointer, but which > > may not be of type void*. While this is probably dodgy enough to be on > > the wrong side of the C standard, it's been often used for similar > > > > [ ... ] > > Reviewed-by: Maxime Ripard Acked-by: Daniel Vetter for merging through kunit tree, since I guess that's the simplest way to land this. Cheers! -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 5/6] drm/vs: Add KMS crtc
On Wed, 15 Nov 2023 at 15:30, Keith Zhao wrote:
>
>
>
> On 2023/11/14 18:59, Dmitry Baryshkov wrote:
> > On Tue, 14 Nov 2023 at 12:42, Keith Zhao
> > wrote:
> >>
> >>
> >>
> >> On 2023/10/26 3:28, Dmitry Baryshkov wrote:
> >> > On 25/10/2023 13:39, Keith Zhao wrote:
> >> >> add 2 crtcs and 8 planes in vs-drm
> >> >>
> >> >> Signed-off-by: Keith Zhao
> >> >> ---
> >> >> drivers/gpu/drm/verisilicon/Makefile |8 +-
> >> >> drivers/gpu/drm/verisilicon/vs_crtc.c | 257
> >> >> drivers/gpu/drm/verisilicon/vs_crtc.h | 43 +
> >> >> drivers/gpu/drm/verisilicon/vs_dc.c| 1002
> >> >> drivers/gpu/drm/verisilicon/vs_dc.h| 80 +
> >> >> drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1959
> >> >> drivers/gpu/drm/verisilicon/vs_dc_hw.h | 492 ++
> >> >> drivers/gpu/drm/verisilicon/vs_drv.c |2 +
> >> >> drivers/gpu/drm/verisilicon/vs_plane.c | 526 +++
> >> >> drivers/gpu/drm/verisilicon/vs_plane.h | 58 +
> >> >> drivers/gpu/drm/verisilicon/vs_type.h | 69 +
> >> >> 11 files changed, 4494 insertions(+), 2 deletions(-)
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h
> >> >> create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h
> >> >>
> >> >> diff --git a/drivers/gpu/drm/verisilicon/Makefile
> >> >> b/drivers/gpu/drm/verisilicon/Makefile
> >> >> index 7d3be305b..1d48016ca 100644
> >> >> --- a/drivers/gpu/drm/verisilicon/Makefile
> >> >> +++ b/drivers/gpu/drm/verisilicon/Makefile
> >> >> @@ -1,7 +1,11 @@
> >> >> # SPDX-License-Identifier: GPL-2.0
> >> >>
> >> >> -vs_drm-objs := vs_drv.o \
> >> >> -vs_modeset.o
> >> >> +vs_drm-objs := vs_dc_hw.o \
> >> >> +vs_dc.o \
> >> >> +vs_crtc.o \
> >> >> +vs_drv.o \
> >> >> +vs_modeset.o \
> >> >> +vs_plane.o
> >> >>
> >> >> obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
> >> >>
> >> >> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
> >> >> b/drivers/gpu/drm/verisilicon/vs_crtc.c
> >> >> new file mode 100644
> >> >> index 0..8a658ea77
> >> >> --- /dev/null
> >> >> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
> >> >> @@ -0,0 +1,257 @@
> >> >> +// SPDX-License-Identifier: GPL-2.0
> >> >> +/*
> >> >> + * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
> >> >> + *
> >> >> + */
> >> >> +
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >> >> +
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >> >> +
> >> >> +#include "vs_crtc.h"
> >> >> +#include "vs_dc.h"
> >> >> +#include "vs_drv.h"
> >> >> +
> >> >> +static void vs_crtc_reset(struct drm_crtc *crtc)
> >> >> +{
> >> >> +struct vs_crtc_state *state;
> >> >> +
> >> >> +if (crtc->state) {
> >> >> +__drm_atomic_helper_crtc_destroy_state(crtc->state);
> >> >> +
> >> >> +state = to_vs_crtc_state(crtc->state);
> >> >> +kfree(state);
> >> >> +crtc->state = NULL;
> >> >> +}
> >> >
> >> > You can call your crtc_destroy_state function directly here.
> >> >
> >> >> +
> >> >> +state = kzalloc(sizeof(*state), GFP_KERNEL);
> >> >> +if (!state)
> >> >> +return;
> >> >> +
> >> >> +__drm_atomic_helper_crtc_reset(crtc, >base);
> >> >> +}
> >> >> +
> >> >> +static struct drm_crtc_state *
> >> >> +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
> >> >> +{
> >> >> +struct vs_crtc_state *ori_state;
> >> >
> >> > It might be a matter of taste, but it is usually old_state.
> >> >
> >> >> +struct vs_crtc_state *state;
> >> >> +
> >> >> +if (!crtc->state)
> >> >> +return NULL;
> >> >> +
> >> >> +ori_state = to_vs_crtc_state(crtc->state);
> >> >> +state = kzalloc(sizeof(*state), GFP_KERNEL);
> >> >> +if (!state)
> >> >> +return NULL;
> >> >> +
> >> >> +__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
> >> >> +
> >> >> +state->output_fmt = ori_state->output_fmt;
> >> >> +state->encoder_type = ori_state->encoder_type;
> >> >> +state->bpp = ori_state->bpp;
> >> >> +state->underflow = ori_state->underflow;
> >> >
> >> > Can you use kmemdup instead?
> >> >
> >> >> +
> >> >> +return >base;
> >> >> +}
> >> >> +
> >> >> +static void vs_crtc_atomic_destroy_state(struct drm_crtc *crtc,
> >> >> + struct drm_crtc_state *state)
> >> >> +{
> >> >> +__drm_atomic_helper_crtc_destroy_state(state);
> >> >> +
Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go
Yes, thanks!
That's the email attached to my public git work, so it should be the
one here as well.
Sorry for the hassle. Very new to sending PRs over email, and still
working through the kinks.
On Wed, Nov 15, 2023 at 7:51 AM Hans de Goede wrote:
>
> Hi,
>
> On 11/15/23 16:48, Brenton Simpson wrote:
> > Resending from the email address linked to my GitHub account.
>
> Ok, this doesn't really help. I'll just fix-up the author
> field of the original patch.
>
> Do understand correctly that both the author and the Signed-off-by
> should be set to:
>
> Brenton Simpson
>
> ?
>
> Regards,
>
> Hans
>
>
>
> >
> > -- >8 --
> >
> > The Legion Go has a 2560x1600 portrait screen, with the native "up" facing =
> > the right controller (90=C2=B0 CW from the rest of the device).
> >
> > Signed-off-by: Brenton Simpson
> > ---
> > drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/d=
> > rm/drm_panel_orientation_quirks.c
> > index d5c1529..3d92f66 100644
> > --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > @@ -336,6 +336,12 @@ static const struct dmi_system_id orientation_data[] =
> > =3D {
> > =09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> > =09=09},
> > =09=09.driver_data =3D (void *)_rightside_up,
> > +=09}, {=09/* Lenovo Legion Go 8APU1 */
> > +=09=09.matches =3D {
> > +=09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > +=09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Legion Go 8APU1"),
> > +=09=09},
> > +=09=09.driver_data =3D (void *)_leftside_up,
> > =09}, {=09/* Lenovo Yoga Book X90F / X90L */
> > =09=09.matches =3D {
> > =09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
> > --=20
> > 2.43.0.rc0.421.g78406f8d94-goog
> >
>
Re: [PATCH 1/3] kunit: Add a macro to wrap a deferred action function
On Sat, 11 Nov 2023 04:08:26 +0800, David Gow wrote: > KUnit's deferred action API accepts a void(*)(void *) function pointer > which is called when the test is exited. However, we very frequently > want to use existing functions which accept a single pointer, but which > may not be of type void*. While this is probably dodgy enough to be on > the wrong side of the C standard, it's been often used for similar > > [ ... ] Reviewed-by: Maxime Ripard Thanks! Maxime
Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go
Hi,
On 11/15/23 16:48, Brenton Simpson wrote:
> Resending from the email address linked to my GitHub account.
Ok, this doesn't really help. I'll just fix-up the author
field of the original patch.
Do understand correctly that both the author and the Signed-off-by
should be set to:
Brenton Simpson
?
Regards,
Hans
>
> -- >8 --
>
> The Legion Go has a 2560x1600 portrait screen, with the native "up" facing =
> the right controller (90=C2=B0 CW from the rest of the device).
>
> Signed-off-by: Brenton Simpson
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/d=
> rm/drm_panel_orientation_quirks.c
> index d5c1529..3d92f66 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -336,6 +336,12 @@ static const struct dmi_system_id orientation_data[] =
> =3D {
> =09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> =09=09},
> =09=09.driver_data =3D (void *)_rightside_up,
> +=09}, {=09/* Lenovo Legion Go 8APU1 */
> +=09=09.matches =3D {
> +=09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +=09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Legion Go 8APU1"),
> +=09=09},
> +=09=09.driver_data =3D (void *)_leftside_up,
> =09}, {=09/* Lenovo Yoga Book X90F / X90L */
> =09=09.matches =3D {
> =09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
> --=20
> 2.43.0.rc0.421.g78406f8d94-goog
>
Re: [PATCH 2/3] drm/tests: Use KUNIT_DEFINE_ACTION_WRAPPER()
Hi David, On Sat, Nov 11, 2023 at 04:08:27AM +0800, David Gow wrote: > In order to pass functions to kunit_add_action(), they need to be of the > kunit_action_t type. While casting the function pointer can work, it > will break control-flow integrity. > > drm_kunit_helpers already defines wrappers, but we now have a macro > which does this automatically. Using this greatly reduces the > boilerplate needed. > > Signed-off-by: David Gow > --- > > This patch should be a no-op, just moving to use a standard macro to > implement these wrappers rather than hand-coding them. > > Let me know if you'd prefer to take these in separately via the drm > trees, or if you're okay with having this whole series go via > kselftest/kunit. You can merge it through your tree with Acked-by: Maxime Ripard For the patches 2 and 3 Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go
Arg - the special characters got mangled. One last time.
-- >8 --
The Legion Go has a 2560x1600 portrait screen, with the native "up"
facing the right controller (90° CW from the rest of the device).
Signed-off-by: Brenton Simpson
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index d5c1529..3d92f66 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -336,6 +336,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
},
.driver_data = (void *)_rightside_up,
+ }, {/* Lenovo Legion Go 8APU1 */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Legion Go 8APU1"),
+ },
+ .driver_data = (void *)_leftside_up,
}, {/* Lenovo Yoga Book X90F / X90L */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
--
2.43.0.rc0.421.g78406f8d94-goog
On Wed, Nov 15, 2023 at 7:48 AM Brenton Simpson
wrote:
>
> Resending from the email address linked to my GitHub account.
>
> -- >8 --
>
> The Legion Go has a 2560x1600 portrait screen, with the native "up" facing =
> the right controller (90=C2=B0 CW from the rest of the device).
>
> Signed-off-by: Brenton Simpson
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/d=
> rm/drm_panel_orientation_quirks.c
> index d5c1529..3d92f66 100644
> --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -336,6 +336,12 @@ static const struct dmi_system_id orientation_data[] =
> =3D {
> =09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> =09=09},
> =09=09.driver_data =3D (void *)_rightside_up,
> +=09}, {=09/* Lenovo Legion Go 8APU1 */
> +=09=09.matches =3D {
> +=09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +=09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Legion Go 8APU1"),
> +=09=09},
> +=09=09.driver_data =3D (void *)_leftside_up,
> =09}, {=09/* Lenovo Yoga Book X90F / X90L */
> =09=09.matches =3D {
> =09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
> --=20
> 2.43.0.rc0.421.g78406f8d94-goog
Re: [PATCH] drm/panel-orientation-quirks: add Lenovo Legion Go
Resending from the email address linked to my GitHub account.
-- >8 --
The Legion Go has a 2560x1600 portrait screen, with the native "up" facing =
the right controller (90=C2=B0 CW from the rest of the device).
Signed-off-by: Brenton Simpson
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/d=
rm/drm_panel_orientation_quirks.c
index d5c1529..3d92f66 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -336,6 +336,12 @@ static const struct dmi_system_id orientation_data[] =
=3D {
=09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
=09=09},
=09=09.driver_data =3D (void *)_rightside_up,
+=09}, {=09/* Lenovo Legion Go 8APU1 */
+=09=09.matches =3D {
+=09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+=09=09 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Legion Go 8APU1"),
+=09=09},
+=09=09.driver_data =3D (void *)_leftside_up,
=09}, {=09/* Lenovo Yoga Book X90F / X90L */
=09=09.matches =3D {
=09=09 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
--=20
2.43.0.rc0.421.g78406f8d94-goog
[PATCH v6 2/2] backlight: mp3309c: Add support for MPS MP3309C
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For DT configuration details, please refer to:
- Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
The datasheet is available at:
- https://www.monolithicpower.com/en/mp3309c.html
Signed-off-by: Flavio Suligoi
---
MAINTAINERS | 7 +
drivers/video/backlight/Kconfig | 11 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/mp3309c.c | 443 ++
4 files changed, 462 insertions(+)
create mode 100644 drivers/video/backlight/mp3309c.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c9f868e13b6..d033c2a2d120 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14657,6 +14657,13 @@ S: Maintained
F: Documentation/driver-api/tty/moxa-smartio.rst
F: drivers/tty/mxser.*
+MP3309C BACKLIGHT DRIVER
+M: Flavio Suligoi
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
+F: drivers/video/backlight/mp3309c.c
+
MR800 AVERMEDIA USB FM RADIO DRIVER
M: Alexey Klimov
L: linux-me...@vger.kernel.org
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 51387b1ef012..1144a54a35c0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -402,6 +402,17 @@ config BACKLIGHT_LP8788
help
This supports TI LP8788 backlight driver.
+config BACKLIGHT_MP3309C
+ tristate "Backlight Driver for MPS MP3309C"
+ depends on I2C && PWM
+ select REGMAP_I2C
+ help
+ This supports MPS MP3309C backlight WLED driver in both PWM and
+ analog/I2C dimming modes.
+
+ To compile this driver as a module, choose M here: the module will
+ be called mp3309c.
+
config BACKLIGHT_PANDORA
tristate "Backlight driver for Pandora console"
depends on TWL4030_CORE
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index f72e1c3c59e9..1af583de665b 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_BACKLIGHT_LP855X)+= lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
obj-$(CONFIG_BACKLIGHT_MAX8925)+= max8925_bl.o
+obj-$(CONFIG_BACKLIGHT_MP3309C)+= mp3309c.o
obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
diff --git a/drivers/video/backlight/mp3309c.c
b/drivers/video/backlight/mp3309c.c
new file mode 100644
index ..3fe4469ef43f
--- /dev/null
+++ b/drivers/video/backlight/mp3309c.c
@@ -0,0 +1,443 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Driver for MPS MP3309C White LED driver with I2C interface
+ *
+ * This driver support both analog (by I2C commands) and PWM dimming control
+ * modes.
+ *
+ * Copyright (C) 2023 ASEM Srl
+ * Author: Flavio Suligoi
+ *
+ * Based on pwm_bl.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_I2C_0 0x00
+#define REG_I2C_1 0x01
+
+#define REG_I2C_0_EN 0x80
+#define REG_I2C_0_D0 0x40
+#define REG_I2C_0_D1 0x20
+#define REG_I2C_0_D2 0x10
+#define REG_I2C_0_D3 0x08
+#define REG_I2C_0_D4 0x04
+#define REG_I2C_0_RSRV10x02
+#define REG_I2C_0_RSRV20x01
+
+#define REG_I2C_1_RSRV10x80
+#define REG_I2C_1_DIMS 0x40
+#define REG_I2C_1_SYNC 0x20
+#define REG_I2C_1_OVP0 0x10
+#define REG_I2C_1_OVP1 0x08
+#define REG_I2C_1_VOS 0x04
+#define REG_I2C_1_LEDO 0x02
+#define REG_I2C_1_OTP 0x01
+
+#define ANALOG_I2C_NUM_LEVELS 32 /* 0..31 */
+#define ANALOG_I2C_REG_MASK0x7c
+
+#define MP3309C_PWM_DEFAULT_NUM_LEVELS 256 /* 0..255 */
+
+enum mp3309c_status_value {
+ FIRST_POWER_ON,
+ BACKLIGHT_OFF,
+ BACKLIGHT_ON,
+};
+
+enum mp3309c_dimming_mode_value {
+ DIMMING_PWM,
+ DIMMING_ANALOG_I2C,
+};
+
+struct mp3309c_platform_data {
+ unsigned int max_brightness;
+ unsigned int default_brightness;
+ unsigned int *levels;
+ u8 dimming_mode;
+ u8 over_voltage_protection;
+ bool sync_mode;
+ u8 status;
+};
+
+struct mp3309c_chip {
+ struct device *dev;
+ struct mp3309c_platform_data *pdata;
+ struct backlight_device *bl;
+ struct gpio_desc *enable_gpio;
+ struct regmap *regmap;
+ struct pwm_device *pwmd;
+};
+
+static const struct regmap_config mp3309c_regmap = {
+ .name = "mp3309c_regmap",
+ .reg_bits = 8,
+ .reg_stride = 1,
+ .val_bits = 8,
+
[PATCH v6 0/2] backlight: mp3309c: Add support for MPS MP3309C
This patchset (rebased on v6.7-rc1 kernel version): - updates the mps,mp3309c.yaml dt bindings file: - Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml - adds the related device driver to support the MPS MP3309C backlight chip. Note: about the first point, the mps,mp3309c.yaml file updating, there are no compatibility problems with the previous version, since the related device driver has not yet been included in any kernel. Only this dt-binding yaml file is already included in the current v6.7-rc1 kernel version. No developer may have used it. Flavio Suligoi (2): dt-bindings: backlight: mp3309c: remove two required properties backlight: mp3309c: Add support for MPS MP3309C .../bindings/leds/backlight/mps,mp3309c.yaml | 10 +- MAINTAINERS | 7 + drivers/video/backlight/Kconfig | 11 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/mp3309c.c | 443 ++ 5 files changed, 466 insertions(+), 6 deletions(-) create mode 100644 drivers/video/backlight/mp3309c.c -- 2.34.1
[PATCH v6 1/2] dt-bindings: backlight: mp3309c: remove two required properties
The two properties: - max-brightness - default brightness are not really required, so they can be removed from the "required" section. The "max-brightness" is no longer used in the current version of the driver (it was used only in the first version). The "default-brightness", if omitted in the DT, is managed by the device driver, using a default value. This value depends on the dimming mode used: - for the "analog mode", via I2C commands, this value is fixed by hardware (=31) - while in case of pwm mode the default used is the last value of the brightness-levels array. Also the brightness-levels array is not required: - in "analog mode", via I2C commands, the brightness-level array is fixed by hardware (0..31).; - in pwm dimming mode, the driver uses a default array of 0..255 and the "default-brightness" is the last one, which is "255" NOTE: there are no compatibility problems with the previous version, since the device driver has not yet been included in any kernel. Only this dt-binding yaml file is already included in the kernel repository. No developer may have used it. Other changes: - improve the backlight working mode description, in the "description" section - update the example, removing the "max-brightness" and introducing the "brightess-levels" property Signed-off-by: Flavio Suligoi --- .../bindings/leds/backlight/mps,mp3309c.yaml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml index 4191e33626f5..527a37368ed7 100644 --- a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml @@ -14,8 +14,8 @@ description: | programmable switching frequency to optimize efficiency. It supports two different dimming modes: - - analog mode, via I2C commands (default) - - PWM controlled mode. + - analog mode, via I2C commands, as default mode (32 dimming levels) + - PWM controlled mode (optional) The datasheet is available at: https://www.monolithicpower.com/en/mp3309c.html @@ -50,8 +50,6 @@ properties: required: - compatible - reg - - max-brightness - - default-brightness unevaluatedProperties: false @@ -66,8 +64,8 @@ examples: compatible = "mps,mp3309c"; reg = <0x17>; pwms = < 0 333 0>; /* 300 Hz --> (1/f) * 1*10^9 */ -max-brightness = <100>; -default-brightness = <80>; +brightness-levels = <0 4 8 16 32 64 128 255>; +default-brightness = <6>; mps,overvoltage-protection-microvolt = <2400>; }; }; -- 2.34.1
[PATCH 4/4] drm/panel-elida-kd35t133: Drop prepare/unprepare logic
From: Chris Morgan
Drop the prepare/unprepare logic, as this is now tracked elsewhere.
Additionally, the driver shutdown is also duplicate as it calls
drm_unprepare and drm_disable which are called anyway when
associated drivers are shutdown/removed.
Signed-off-by: Chris Morgan
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 28
1 file changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index 29b4ee63d83b..00791ea81e90 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -43,7 +43,6 @@ struct kd35t133 {
struct regulator *vdd;
struct regulator *iovcc;
enum drm_panel_orientation orientation;
- bool prepared;
};
static inline struct kd35t133 *panel_to_kd35t133(struct drm_panel *panel)
@@ -91,9 +90,6 @@ static int kd35t133_unprepare(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
- if (!ctx->prepared)
- return 0;
-
ret = mipi_dsi_dcs_set_display_off(dsi);
if (ret < 0)
dev_err(ctx->dev, "failed to set display off: %d\n", ret);
@@ -109,8 +105,6 @@ static int kd35t133_unprepare(struct drm_panel *panel)
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vdd);
- ctx->prepared = false;
-
return 0;
}
@@ -120,9 +114,6 @@ static int kd35t133_prepare(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
- if (ctx->prepared)
- return 0;
-
dev_dbg(ctx->dev, "Resetting the panel\n");
ret = regulator_enable(ctx->vdd);
if (ret < 0) {
@@ -166,8 +157,6 @@ static int kd35t133_prepare(struct drm_panel *panel)
msleep(50);
- ctx->prepared = true;
-
return 0;
disable_iovcc:
@@ -296,27 +285,11 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
return 0;
}
-static void kd35t133_shutdown(struct mipi_dsi_device *dsi)
-{
- struct kd35t133 *ctx = mipi_dsi_get_drvdata(dsi);
- int ret;
-
- ret = drm_panel_unprepare(>panel);
- if (ret < 0)
- dev_err(>dev, "Failed to unprepare panel: %d\n", ret);
-
- ret = drm_panel_disable(>panel);
- if (ret < 0)
- dev_err(>dev, "Failed to disable panel: %d\n", ret);
-}
-
static void kd35t133_remove(struct mipi_dsi_device *dsi)
{
struct kd35t133 *ctx = mipi_dsi_get_drvdata(dsi);
int ret;
- kd35t133_shutdown(dsi);
-
ret = mipi_dsi_detach(dsi);
if (ret < 0)
dev_err(>dev, "Failed to detach from DSI host: %d\n", ret);
@@ -337,7 +310,6 @@ static struct mipi_dsi_driver kd35t133_driver = {
},
.probe = kd35t133_probe,
.remove = kd35t133_remove,
- .shutdown = kd35t133_shutdown,
};
module_mipi_dsi_driver(kd35t133_driver);
--
2.34.1
[PATCH 2/4] drm/panel-elida-kd35t133: hold panel in reset for unprepare
From: Chris Morgan For devices like the Anbernic RG351M and RG351P the panel is wired to an always on regulator. When the device suspends and wakes up, there are some slight artifacts on the screen that go away over time. If instead we hold the panel in reset status after it is unprepared, this does not happen. Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c index 6cd8536c09ff..f1fc4a26f447 100644 --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c @@ -104,6 +104,8 @@ static int kd35t133_unprepare(struct drm_panel *panel) return ret; } + gpiod_set_value_cansleep(ctx->reset_gpio, 1); + regulator_disable(ctx->iovcc); regulator_disable(ctx->vdd); -- 2.34.1
[PATCH 3/4] drm/panel-elida-kd35t133: drop drm_connector_set_orientation_from_panel
From: Chris Morgan Stop calling drm_connector_set_orientation_from_panel() as its now called by the panel bridge directly when it is initialized. Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c index f1fc4a26f447..29b4ee63d83b 100644 --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c @@ -211,11 +211,6 @@ static int kd35t133_get_modes(struct drm_panel *panel, connector->display_info.width_mm = mode->width_mm; connector->display_info.height_mm = mode->height_mm; drm_mode_probed_add(connector, mode); - /* -* TODO: Remove once all drm drivers call -* drm_connector_set_orientation_from_panel() -*/ - drm_connector_set_panel_orientation(connector, ctx->orientation); return 1; } -- 2.34.1
[PATCH 0/4] Elida KD35T133 Panel Improvements
From: Chris Morgan Fix a few bugs and clean up no longer needed code on the Elida KD35T133 DSI panel, as used in devices such as the Odroid Go Advance and the Anbernic RG351M. Chris Morgan (4): drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5 drm/panel-elida-kd35t133: hold panel in reset for unprepare drm/panel-elida-kd35t133: drop drm_connector_set_orientation_from_panel drm/panel-elida-kd35t133: Drop prepare/unprepare logic drivers/gpu/drm/panel/panel-elida-kd35t133.c | 37 ++-- 1 file changed, 3 insertions(+), 34 deletions(-) -- 2.34.1
[PATCH 1/4] drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5
From: Chris Morgan The comments at the top of the driver state the panel size incorrectly as 5.5" instead of 3.5". Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c b/drivers/gpu/drm/panel/panel-elida-kd35t133.c index e7be15b68102..6cd8536c09ff 100644 --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Elida kd35t133 5.5" MIPI-DSI panel driver + * Elida kd35t133 3.5" MIPI-DSI panel driver * Copyright (C) 2020 Theobroma Systems Design und Consulting GmbH * * based on -- 2.34.1
Re: [PATCH 1/3] kunit: Add a macro to wrap a deferred action function
Hi David, On Sat, Nov 11, 2023 at 04:08:26AM +0800, David Gow wrote: > KUnit's deferred action API accepts a void(*)(void *) function pointer > which is called when the test is exited. However, we very frequently > want to use existing functions which accept a single pointer, but which > may not be of type void*. While this is probably dodgy enough to be on > the wrong side of the C standard, it's been often used for similar > callbacks, and gcc's -Wcast-function-type seems to ignore cases where > the only difference is the type of the argument, assuming it's > compatible (i.e., they're both pointers to data). > > However, clang 16 has introduced -Wcast-function-type-strict, which no > longer permits any deviation in function pointer type. This seems to be > because it'd break CFI, which validates the type of function calls. > > This rather ruins our attempts to cast functions to defer them, and > leaves us with a few options. The one we've chosen is to implement a > macro which will generate a wrapper function which accepts a void*, and > casts the argument to the appropriate type. > > For example, if you were trying to wrap: > void foo_close(struct foo *handle); > you could use: > KUNIT_DEFINE_ACTION_WRAPPER(kunit_action_foo_close, > foo_close, > struct foo *); > > This would create a new kunit_action_foo_close() function, of type > kunit_action_t, which could be passed into kunit_add_action() and > similar functions. > > In addition to defining this macro, update KUnit and its tests to use > it. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1750 > Signed-off-by: David Gow > --- > > This is a follow-up to the RFC here: > https://lore.kernel.org/linux-kselftest/20230915050125.3609689-1-david...@google.com/ > > There's no difference in the macro implementation, just an update to the > KUnit tests to use it. This version is intended to complement: > https://lore.kernel.org/all/20231106172557.2963-1...@opensource.cirrus.com/ > > There are also two follow-up patches in the series to use this macro in > various DRM tests. > > Hopefully this will solve any CFI issues that show up with KUnit. > > Thanks, > -- David > > --- Prior to this series, there is indeed a crash when running the KUnit tests with CONFIG_CFI_CLANG=y: $ tools/testing/kunit/kunit.py run \ --alltests \ --arch x86_64 \ --kconfig_add CONFIG_CFI_CLANG=y \ --make_options LLVM=1 \ --timeout 30 ... [08:06:03] [ERROR] Test: sysctl_test: missing subtest result line! [08:06:03] # module: sysctl_test [08:06:03] 1..10 [08:06:03] CFI failure at __kunit_action_free+0x18/0x20 (target: kfree+0x0/0x80; expected type: 0xe82c6923) [08:06:03] invalid opcode: [#1] PREEMPT NOPTI [08:06:03] CPU: 0 PID: 53 Comm: kunit_try_catch Tainted: G N 6.7.0-rc1-00019-gc42d9eeef8e5 #3 [08:06:03] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-14-g1e1da7a96300-prebuilt.qemu.org 04/01/2014 [08:06:03] RIP: 0010:__kunit_action_free+0x18/0x20 [08:06:03] Code: 00 00 b8 ae 55 f1 4d 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 4c 8b 5f 38 48 8b 7f 40 41 ba dd 96 d3 17 45 03 53 f1 74 02 <0f> 0b 2e e9 f0 b5 46 00 b8 fa f1 06 5e 90 90 90 90 90 90 90 90 90 [08:06:03] RSP: 0018:b0d2c00ebea0 EFLAGS: 0292 [08:06:03] RAX: 0001 RBX: 993d41949a80 RCX: 993d41949aa0 [08:06:03] RDX: 0282 RSI: 993d41949a80 RDI: 993d4186b6b0 [08:06:03] RBP: b0d2c0013ad8 R08: c9c84000 R09: 0400 [08:06:03] R10: f707d502 R11: 8f33aa40 R12: 993d418d2e00 [08:06:03] R13: 993d41a05600 R14: b0d2c0013cc0 R15: 993d41949ae0 [08:06:03] FS: () GS:90049000() knlGS: [08:06:03] CS: 0010 DS: ES: CR0: 80050033 [08:06:03] CR2: 993d55c01000 CR3: 1563e000 CR4: 06f0 [08:06:03] Call Trace: [08:06:03] [08:06:03] ? __die+0xd6/0x120 [08:06:03] ? die+0x5f/0xa0 [08:06:03] ? do_trap+0x9b/0x180 [08:06:03] ? __kunit_action_free+0x18/0x20 [08:06:03] ? __kunit_action_free+0x18/0x20 [08:06:03] ? handle_invalid_op+0x64/0x80 [08:06:03] ? __kunit_action_free+0x18/0x20 [08:06:03] ? exc_invalid_op+0x38/0x60 [08:06:03] ? asm_exc_invalid_op+0x1a/0x20 [08:06:03] ? __cfi_kfree+0x10/0x10 [08:06:03] ? __kunit_action_free+0x18/0x20 [08:06:03] kunit_remove_resource+0x8f/0xf0 [08:06:03] kunit_cleanup+0x60/0xe0 [08:06:03] kunit_generic_run_threadfn_adapter+0x24/0x30 [08:06:03] ? __cfi_kunit_generic_run_threadfn_adapter+0x10/0x10 [08:06:03] kthread+0xd9/0xf0 [08:06:03] ? __cfi_kthread+0x10/0x10 [08:06:03] ret_from_fork+0x43/0x50 [08:06:03] ? __cfi_kthread+0x10/0x10 [08:06:03] ret_from_fork_asm+0x1a/0x30 [08:06:03] [08:06:03] ---[ end trace ]--- [08:06:03] RIP: 0010:__kunit_action_free+0x18/0x20 ... With this series applied with
Re: [PATCH v4] Documentation/gpu: VM_BIND locking document
On Wed, Nov 15, 2023 at 01:49:37PM +0100, Thomas Hellström wrote: > Add the first version of the VM_BIND locking document which is > intended to be part of the xe driver upstreaming agreement. > > The document describes and discuss the locking used during exec- > functions, evicton and for userptr gpu-vmas. Intention is to be using the > same nomenclature as the drm-vm-bind-async.rst. > > v2: > - s/gvm/gpu_vm/g (Rodrigo Vivi) > - Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c > (Rodrigo Vivi) > - Adjust commit message accordingly. > - Add SPDX license header. > > v3: > - Large update to align with the drm_gpuvm manager locking > - Add "Efficient userptr gpu_vma exec function iteration" section > - Add "Locking at bind- and unbind time" section. > > v4: > - Fix tabs vs space errors by untabifying (Rodrigo Vivi) > - Minor style fixes and typos (Rodrigo Vivi) > - Clarify situations where stale GPU mappings are occurring and how > access through these mappings are blocked. (Rodrigo Vivi) > - Insert into the toctree in implementation_guidelines.rst > > Cc: Rodrigo Vivi > Signed-off-by: Thomas Hellström > --- > Documentation/gpu/drm-vm-bind-locking.rst | 503 ++ > .../gpu/implementation_guidelines.rst | 1 + > 2 files changed, 504 insertions(+) > create mode 100644 Documentation/gpu/drm-vm-bind-locking.rst > > diff --git a/Documentation/gpu/drm-vm-bind-locking.rst > b/Documentation/gpu/drm-vm-bind-locking.rst > new file mode 100644 > index ..bc701157cb34 > --- /dev/null > +++ b/Documentation/gpu/drm-vm-bind-locking.rst > @@ -0,0 +1,503 @@ > +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) > + > +=== > +VM_BIND locking > +=== > + > +This document attempts to describe what's needed to get VM_BIND locking > right, > +including the userptr mmu_notifier locking and it will also discuss some > +optimizations to get rid of the looping through of all userptr mappings and > +external / shared object mappings that is needed in the simplest > +implementation. It will also discuss some implications for faulting gpu_vms. I'd try to avoid switching to future tense. There are a few more places throughout the document. > + > +Nomenclature > + > + > +* ``Context``: GPU execution context. > +* ``gpu_vm``: Abstraction of a virtual GPU address space with > + meta-data. Typically one per client (DRM file-private), or one per > + context. > +* ``gpu_vma``: Abstraction of a GPU address range within a gpu_vm with > + associated meta-data. The backing storage of a gpu_vma can either be > + a GEM object or anonymous pages mapped also into the CPU > + address space for the process. > +* gpu_vm_bo: Abstracts the association of a GEM object and > + a VM. Note that if only one gpu_vma per vm and buffer object were > + allowed, the state stored with a gpu_vm_bo could just as well have > + been stored with the gpu_vma. For the purpose of this document, each > + GEM object maintains a list of gpu_vm_bos, and each gpu_vm_bo > + maintains a list of gpu_vmas. > +* ``userptr gpu_vma or just userptr``: A gpu_vma, whose backing store > + is anonymous pages as described above. > +* ``revalidating``: Revalidating a gpu_vma means making the latest version > + of the backing store resident and making sure the gpu_vma's > + page-table entries point to that backing store. > +* ``dma_fence``: A struct dma_fence that is similar to a struct completion > + and which tracks GPU activity. When the GPU activity is finished, > + the dma_fence signals. > +* ``dma_resv``: A struct dma_resv (a.k.a reservation object) that is used > + to track GPU activity in the form of multiple dma_fences on a > + gpu_vm or a GEM object. The dma_resv contains an array / list > + of dma_fences and a lock that needs to be held when adding > + additional dma_fences to the dma_resv. The lock is of a type that > + allows deadlock-safe locking of multiple dma_resvs in arbitrary order. > +* ``exec function``: An exec function is a function that revalidates all > + affected gpu_vmas, submits a GPU command batch and registers the > + dma_fence representing the GPU command's activity with all affected > + dma_resvs. For completeness, although not covered by this document, > + it's worth mentioning that an exec function may also be the > + revalidation worker that is used by some drivers in compute / > + long-running mode. > +* ``local object``: A GEM object which is local to a gpu_vm. Shared gem > + objects also share the gpu_vm's dma_resv. What about "a GEM object which is not shared across multiple VMs" or " a GEM object which is only mapped within a single VM"? Also That last sentence seems to belong to 'shared object' below. > +* ``shared object``: a.k.a external object: A GEM object which may be shared > + by multiple gpu_vms and whose backing storage may be shared with > + other drivers. > + > + > +Locks used and locking orders >
[PATCH] drm: rcar-du: Fix memory leak in rcar_du_vsps_init()
The rcar_du_vsps_init() doesn't free the np allocated by
of_parse_phandle_with_fixed_args() for the non-error case.
Fix memory leak for the non-error case.
Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP")
Signed-off-by: Biju Das
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
index 70d8ad065bfa..5cd54ea33313 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
@@ -747,8 +747,6 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
goto error;
}
- return 0;
-
error:
for (i = 0; i < ARRAY_SIZE(vsps); ++i)
of_node_put(vsps[i].np);
--
2.25.1
Re: [PATCH v2] Remove custom dumb_map_offset implementation in msm driver
On Wed, 15 Nov 2023 at 16:30, Dipam Turkar wrote:
>
> Make msm use drm_gem_create_map_offset() instead of its custom
> implementation for associating GEM object with a fake offset. Since,
> we already have this generic implementation, we don't need the custom
> implementation and it is better to standardize the code for GEM based
> drivers. This also removes the outdated locking leftovers.
Why are they outdated?
>
> Signed-off-by: Dipam Turkar
> ---
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 21 -
> drivers/gpu/drm/msm/msm_gem.h | 2 --
> 3 files changed, 1 insertion(+), 24 deletions(-)
>
> Changes in v2:
> Modify commit message to include the absence of internal locking leftovers
> around allocating a fake offset in msm_gem_mmap_offset() in the generic
> implementation drm_gem_create_map_offset().
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index a428951ee539..86a15992c717 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1085,7 +1085,7 @@ static const struct drm_driver msm_driver = {
> .open = msm_open,
> .postclose = msm_postclose,
> .dumb_create= msm_gem_dumb_create,
> - .dumb_map_offset= msm_gem_dumb_map_offset,
> + .dumb_map_offset= drm_gem_dumb_map_offset,
> .gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = msm_debugfs_init,
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index db1e748daa75..489694ef79cb 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -671,27 +671,6 @@ int msm_gem_dumb_create(struct drm_file *file, struct
> drm_device *dev,
> MSM_BO_SCANOUT | MSM_BO_WC, >handle, "dumb");
> }
>
> -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
> - uint32_t handle, uint64_t *offset)
> -{
> - struct drm_gem_object *obj;
> - int ret = 0;
> -
> - /* GEM does all our handle to object mapping */
> - obj = drm_gem_object_lookup(file, handle);
> - if (obj == NULL) {
> - ret = -ENOENT;
> - goto fail;
> - }
> -
> - *offset = msm_gem_mmap_offset(obj);
> -
> - drm_gem_object_put(obj);
> -
> -fail:
> - return ret;
> -}
> -
> static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
> {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index 8ddef5443140..dc74a0ef865d 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -139,8 +139,6 @@ struct page **msm_gem_pin_pages(struct drm_gem_object
> *obj);
> void msm_gem_unpin_pages(struct drm_gem_object *obj);
> int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
> struct drm_mode_create_dumb *args);
> -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
> - uint32_t handle, uint64_t *offset);
> void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj);
> void *msm_gem_get_vaddr(struct drm_gem_object *obj);
> void *msm_gem_get_vaddr_active(struct drm_gem_object *obj);
> --
> 2.34.1
>
--
With best wishes
Dmitry
Re: [PATCH v2 5/6] drm/vs: Add KMS crtc
On 2023/10/25 21:57, Maxime Ripard wrote:
> On Wed, Oct 25, 2023 at 06:39:56PM +0800, Keith Zhao wrote:
>> +static struct drm_crtc_state *
>> +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
>> +{
>> +struct vs_crtc_state *ori_state;
>> +struct vs_crtc_state *state;
>> +
>> +if (!crtc->state)
>> +return NULL;
>> +
>> +ori_state = to_vs_crtc_state(crtc->state);
>> +state = kzalloc(sizeof(*state), GFP_KERNEL);
>> +if (!state)
>> +return NULL;
>> +
>> +__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
>> +
>> +state->output_fmt = ori_state->output_fmt;
>
> That field is never set in your patch.
>
>> +state->encoder_type = ori_state->encoder_type;
>
> That isn't either, and it's not clear why you would need the
> encoder_type stored in the CRTC?
>
>> +state->bpp = ori_state->bpp;
>
> You seem to derive that from output_fmt, it doesn't need to be in the
> CRTC state.
>
>> +state->underflow = ori_state->underflow;
>
> Assuming you're setting this from the interrupt handler, it's unsafe,
> you shouldn't do that. What are you using it for?
I am going to use the crtc_debugfs function for printing.
crtc_debugfs will use it
But now I'd better delete it
>
>> +static const struct drm_prop_enum_list vs_sync_mode_enum_list[] = {
>> +{ VS_SINGLE_DC, "single dc mode" },
>> +{ VS_MULTI_DC_PRIMARY, "primary dc for multi dc mode" },
>> +{ VS_MULTI_DC_SECONDARY,"secondary dc for multi dc mode" },
>> +};
>
> Custom driver properties are a no-go:
> https://docs.kernel.org/gpu/drm-kms.html#requirements
>
> And
>
> https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements
>
>> +void vs_dc_enable(struct vs_dc *dc, struct drm_crtc *crtc)
>> +{
>> +struct vs_crtc_state *crtc_state = to_vs_crtc_state(crtc->state);
>> +struct drm_display_mode *mode = >state->adjusted_mode;
>> +struct dc_hw_display display;
>
> Why are you rolling your own structure here, if it's exactly equivalent
> to what drm_display_mode and the crtc_state provide?
My original intention was to make the hardware part purer. and
want to decouple hardware from drm struct.
so I define the own structure between drm and hardware.
Maybe doing this will make both the hardware and drm happy
>
>> +void vs_dc_commit(struct vs_dc *dc)
>> +{
>> +dc_hw_enable_shadow_register(>hw, false);
>> +
>> +dc_hw_commit(>hw);
>> +
>> +if (dc->first_frame)
>> +dc->first_frame = false;
>> +
>> +dc_hw_enable_shadow_register(>hw, true);
>> +}
>
> It's not clear to me what you're trying to do here, does the hardware
> have latched registers that are only updated during vblank?
>
>> +static int dc_bind(struct device *dev, struct device *master, void *data)
>> +{
>> +struct drm_device *drm_dev = data;
>> +struct vs_dc *dc = dev_get_drvdata(dev);
>> +struct device_node *port;
>> +struct vs_crtc *crtc;
>> +struct vs_dc_info *dc_info;
>> +struct vs_plane *plane;
>> +struct vs_plane_info *plane_info;
>> +int i, ret;
>> +u32 ctrc_mask = 0;
>> +
>> +if (!drm_dev || !dc) {
>> +dev_err(dev, "devices are not created.\n");
>> +return -ENODEV;
>> +}
>> +
>> +ret = dc_init(dev);
>> +if (ret < 0) {
>> +drm_err(drm_dev, "Failed to initialize DC hardware.\n");
>> +return ret;
>> +}
>> +
>> +port = of_get_child_by_name(dev->of_node, "port");
>> +if (!port) {
>> +drm_err(drm_dev, "no port node found\n");
>> +return -ENODEV;
>> +}
>> +of_node_put(port);
>> +
>> +dc_info = dc->hw.info;
>> +
>> +for (i = 0; i < dc_info->panel_num; i++) {
>> +crtc = vs_crtc_create(drm_dev, dc_info);
>> +if (!crtc) {
>> +drm_err(drm_dev, "Failed to create CRTC.\n");
>> +ret = -ENOMEM;
>> +return ret;
>> +}
>> +
>> +crtc->base.port = port;
>> +crtc->dev = dev;
>> +dc->crtc[i] = crtc;
>> +ctrc_mask |= drm_crtc_mask(>base);
>> +}
>> +
>> +for (i = 0; i < dc_info->plane_num; i++) {
>> +plane_info = (struct vs_plane_info *)_info->planes[i];
>> +
>> +if (!strcmp(plane_info->name, "Primary") ||
>> !strcmp(plane_info->name, "Cursor")) {
>> +plane = vs_plane_create(drm_dev, plane_info,
>> dc_info->layer_num,
>> +
>> drm_crtc_mask(>crtc[0]->base));
>> +} else if (!strcmp(plane_info->name, "Primary_1") ||
>> + !strcmp(plane_info->name, "Cursor_1")) {
>
> Please use an enum and an id there.
>
>> +static int vs_plane_atomic_set_property(struct drm_plane *plane,
>> +struct drm_plane_state *state,
>> +struct drm_property *property,
>> +
Re: [Nouveau] [PATCH] nouveau: don't fail driver load if no display hw present.
On Wed, 15 Nov 2023 at 05:54, Danilo Krummrich wrote:
>
> On 11/5/23 21:37, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > If we get back ENODEV don't fail load.
>
> Maybe worth to note why this is OK in this case, might not be obvious
> to future readers of the code.
Sent an updated version with that fixed.
>
> >
> > Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
>
> Maybe I'm missing something subtle here, but did you maybe pick the wrong
> commit here? At a first glance it looks like commit 073bde453635
> ("drm/nouveau/kms/nv50-: disable dcb parsing") introduced the issue.
>
Nope this commit causes the regression, as it powers off the display
core in devinit, which means later we don't detect it because GSP
doesn't power it back on.
Dave.
Re: [PATCH v1 2/3] dt-bindings: display: bridge: lt8912b: Add power supplies
On Wed, Nov 15, 2023 at 01:13:37PM +0100, Francesco Dolcini wrote: > From: Stefan Eichenberger > > Add Lontium lt8912b power supplies. > > Signed-off-by: Stefan Eichenberger > Signed-off-by: Francesco Dolcini Acked-by: Conor Dooley Cheers, Conor, > --- > .../display/bridge/lontium,lt8912b.yaml | 21 +++ > 1 file changed, 21 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > index f201ae4af4fb..2cef25215798 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > @@ -55,6 +55,27 @@ properties: >- port@0 >- port@1 > > + vcchdmipll-supply: > +description: A 1.8V supply that powers the HDMI PLL. > + > + vcchdmitx-supply: > +description: A 1.8V supply that powers the HDMI TX part. > + > + vcclvdspll-supply: > +description: A 1.8V supply that powers the LVDS PLL. > + > + vcclvdstx-supply: > +description: A 1.8V supply that powers the LVDS TX part. > + > + vccmipirx-supply: > +description: A 1.8V supply that powers the MIPI RX part. > + > + vccsysclk-supply: > +description: A 1.8V supply that powers the SYSCLK. > + > + vdd-supply: > +description: A 1.8V supply that powers the digital part. > + > required: >- compatible >- reg > -- > 2.25.1 > signature.asc Description: PGP signature
[PATCH] nouveau: don't fail driver load if no display hw present.
From: Dave Airlie
If we get back ENODEV don't fail load. There are nvidia devices
that don't have display blocks and the driver should work on those.
Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/270
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index d8c92521226d9..f28f9a8574586 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -726,6 +726,11 @@ nouveau_display_create(struct drm_device *dev)
if (nouveau_modeset != 2) {
ret = nvif_disp_ctor(>client.device, "kmsDisp", 0,
>disp);
+ /* no display hw */
+ if (ret == -ENODEV) {
+ ret = 0;
+ goto disp_create_err;
+ }
if (!ret && (disp->disp.outp_mask || drm->vbios.dcb.entries)) {
nouveau_display_create_properties(dev);
--
2.41.0
