Re: [PATCH v2 1/6] dt-bindings: arm: mediatek: mmsys: change compatible for MT8195
On 16/09/2022 04:34, Jason-JH Lin wrote:
> Hi Matthias,
>
> Thanks for the review.
>
> On Fri, 2022-09-16 at 00:05 +0200, Matthias Brugger wrote:
>>
>> On 15/09/2022 18:18, Jason-JH.Lin wrote:
>>> For previous MediaTek SoCs, such as MT8173, there are 2 display HW
>>> pipelines binding to 1 mmsys with the same power domain, the same
>>> clock driver and the same mediatek-drm driver.
>>>
>>> For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding
>>> to
>>> 2 different power domains, different clock drivers and different
>>> mediatek-drm drivers.
>>>
>>> Moreover, Hardware pipeline of VDOSYS0 has these components: COLOR,
>>> CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
>>> Quality)
>>> and they makes VDOSYS0 supports PQ function while they are not
>>> including in VDOSYS1.
>>>
>>> Hardware pipeline of VDOSYS1 has the component ETHDR (HDR related
>>> component). It makes VDOSYS1 supports the HDR function while it's
>>> not
>>> including in VDOSYS0.
>>>
>>> To summarize0:
>>> Only VDOSYS0 can support PQ adjustment.
>>> Only VDOSYS1 can support HDR adjustment.
>>>
>>> Therefore, we need to separate these two different mmsys hardwares
>>> to
>>> 2 different compatibles for MT8195.
>>>
>>> Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195
>>> SoC binding")
>>> Signed-off-by: Jason-JH.Lin
>>> Signed-off-by: Bo-Chen Chen
>>> ---
>>> .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml|
>>> 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
>>> l
>>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
>>> l
>>> index 6ad023eec193..0e267428eaa6 100644
>>> ---
>>> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
>>> l
>>> +++
>>> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
>>> l
>>> @@ -31,7 +31,7 @@ properties:
>>> - mediatek,mt8183-mmsys
>>> - mediatek,mt8186-mmsys
>>> - mediatek,mt8192-mmsys
>>> - - mediatek,mt8195-mmsys
>>> + - mediatek,mt8195-vdosys0
>>
>> Nack, we miss the fallback compatible, as I already said twice.
>>
>> Regards,
>> Matthias
>
> I'm sorry this happened again.
> I'll keep the compatible "mediatek,mt8195-mmsys" at next version.
>
> The patch "dt-bindings: arm: mediatek: mmsys: remove the unused
> compatible for mt8195" should be sent after accepting the vdosys1
> series, right?
I don't think there will be no such patch...
You need to add a bindings change which will accept device nodes like:
foo {
compatible = "mediatek,mt8195-vdosys0", "mediatek,mt8195-mmsys";
}
Example-schema shows how to do it.
Best regards,
Krzysztof
Re: [PATCH RESEND v3 1/9] dt-bindings: mediatek: modify item formatting for gamma
On 12/09/2022 02:29, Jason-JH.Lin wrote:
> From: "zheng-yan.chen"
>
> Since the items with only one const should be dedicated as enum,
> merge all such items into one enum item.
>
> Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block
> to individual yaml")
> Signed-off-by: zheng-yan.chen
> Signed-off-by: Jason-JH.Lin
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [PATCH RESEND v3 2/9] dt-bindings: mediatek: Add gamma compatible for mt8195
On 12/09/2022 02:29, Jason-JH.Lin wrote: > From: "zheng-yan.chen" > > mt8195 uses 10bit-to-12bit gamma-LUT, which is not compatible with > current 9bit-to-10bit gamma-LUT. > > This patch thus add constant compatible for mt8195, which means that > mt8195 should only use specified mt8195 gamma driver data. > > Also, delete related compatible from enum, to ensure that > mt8195 will not accidentally get others' gamma driver data and thus > cause fatal error. > > Signed-off-by: zheng-yan.chen > Signed-off-by: Jason-JH.Lin > Reviewed-by: AngeloGioacchino Del Regno > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] drm/bridge: ti-sn65dsi83: Add and use hs_rate and lp_rate
On 8/1/22 15:11, Marek Vasut wrote:
Fill in hs_rate and lp_rate to struct mipi_dsi_device for this bridge and
adjust DSI input frequency calculations such that they expect the DSI host
to configure HS clock according to hs_rate.
This is an optimization for the DSI burst mode case. In case the DSI device
supports DSI burst mode, it is recommended to operate the DSI interface at
the highest possible HS clock frequency which the DSI device supports. This
permits the DSI host to send as short as possible bursts of data on the DSI
link and keep the DSI data lanes in LP mode otherwise, which reduces power
consumption.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 14e7aa77e7584..b161f25c3a2f5 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -286,8 +286,7 @@ static u8 sn65dsi83_get_lvds_range(struct sn65dsi83 *ctx,
return (mode_clock - 12500) / 25000;
}
-static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx,
- const struct drm_display_mode *mode)
+static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx)
{
/*
* The encoding of the CHA_DSI_CLK_RANGE is as follows:
@@ -303,20 +302,20 @@ static u8 sn65dsi83_get_dsi_range(struct sn65dsi83 *ctx,
* DSI_CLK = mode clock * bpp / dsi_data_lanes / 2
* the 2 is there because the bus is DDR.
*/
- return DIV_ROUND_UP(clamp((unsigned int)mode->clock *
- mipi_dsi_pixel_format_to_bpp(ctx->dsi->format) /
- ctx->dsi->lanes / 2, 4U, 50U), 5000U);
+ return DIV_ROUND_UP(ctx->dsi->hs_rate, 500U);
}
-static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx)
+static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx,
+ const struct drm_display_mode *mode)
{
/* The divider is (DSI_CLK / LVDS_CLK) - 1, which really is: */
- unsigned int dsi_div = mipi_dsi_pixel_format_to_bpp(ctx->dsi->format);
+ unsigned int dsi_div;
+ int mode_clock = mode->clock;
- dsi_div /= ctx->dsi->lanes;
+ if (ctx->lvds_dual_link)
+ mode_clock /= 2;
- if (!ctx->lvds_dual_link)
- dsi_div /= 2;
+ dsi_div = (ctx->dsi->hs_rate / mode_clock) / 1000;
return dsi_div - 1;
}
@@ -397,9 +396,9 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
*bridge,
REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx, mode)) |
REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
regmap_write(ctx->regmap, REG_DSI_CLK,
-REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx,
mode)));
+
REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
regmap_write(ctx->regmap, REG_RC_DSI_CLK,
-
REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
+REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx,
mode)));
/* Set number of DSI lanes and LVDS link config. */
regmap_write(ctx->regmap, REG_DSI_LANE,
@@ -643,6 +642,8 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
dsi->lanes = dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
+ dsi->hs_rate = 5;
+ dsi->lp_rate = 1600;
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
+CC Maxime -- input would be helpful.
Re: [PATCH v3 0/3] KUnit tests for RGB888, XRGB2101010 and grayscale
Hi! On Sun, Aug 28, 2022 at 06:45:14PM +0200, José Expósito wrote: > Hello everyone, > > This series is a follow up on my work adding KUnit test to the XRGB > conversion functions. This time RGB888, XRGB2101010 and gray8 are added. > > Best wishes, > Jose > > v1 -> v2: > > Tested-by: Maíra Canal > Reviewed-by: David Gow > > v2 -> v3: > > Export symbol drm_fb_xrgb_to_xrgb2101010() This patchset is being in the mailing list for a while. Unless someone has a reason to not merge it, I'd like to push it next week. Thanks, Jose > José Expósito (3): > drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb888() > drm/format-helper: Add KUnit tests for > drm_fb_xrgb_to_xrgb2101010() > drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_gray8() > > drivers/gpu/drm/drm_format_helper.c | 1 + > .../gpu/drm/tests/drm_format_helper_test.c| 190 ++ > 2 files changed, 191 insertions(+) > > > base-commit: 61a9fa154d217c13eea90aa5bc635bc4b1fcb66e > -- > 2.25.1 >
Re: [PATCH v3 0/3] KUnit tests for RGB888, XRGB2101010 and grayscale
Hi Jose, On 9/18/22 10:22, José Expósito wrote: > Hi! > > On Sun, Aug 28, 2022 at 06:45:14PM +0200, José Expósito wrote: >> Hello everyone, >> >> This series is a follow up on my work adding KUnit test to the XRGB >> conversion functions. This time RGB888, XRGB2101010 and gray8 are added. >> >> Best wishes, >> Jose >> >> v1 -> v2: >> >> Tested-by: Maíra Canal >> Reviewed-by: David Gow >> >> v2 -> v3: >> >> Export symbol drm_fb_xrgb_to_xrgb2101010() > > This patchset is being in the mailing list for a while. Unless someone > has a reason to not merge it, I'd like to push it next week. I believe this patchset doesn't apply anymore due to this patch [1], that applied a naming convention for the DRM tests. Maybe you could send a v3 rebasing the patchset. [1] https://lore.kernel.org/dri-devel/20220911191756.203118-1-mairaca...@riseup.net/T/#mb794103c8e39cdb76734f4e22ce90806f11d99bc Best Regards, - Maíra Canal > > Thanks, > Jose > >> José Expósito (3): >> drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb888() >> drm/format-helper: Add KUnit tests for >> drm_fb_xrgb_to_xrgb2101010() >> drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_gray8() >> >> drivers/gpu/drm/drm_format_helper.c | 1 + >> .../gpu/drm/tests/drm_format_helper_test.c| 190 ++ >> 2 files changed, 191 insertions(+) >> >> >> base-commit: 61a9fa154d217c13eea90aa5bc635bc4b1fcb66e >> -- >> 2.25.1 >>
Re: [PATCH] drm/amdgpu: use dirty framebuffer helper
Hi, I recently experienced lock-ups that only responded to magic sysreq
reboots when the amdgpu module was loading on my pc (Athlon II X4 640 CPU,
with Radeon R7 250 - Cape Verde).
.config has:
CONFIG_DRM_AMDGPU=m
CONFIG_DRM_AMDGPU_SI=y
# CONFIG_DRM_AMDGPU_CIK is not set
# CONFIG_DRM_AMDGPU_USERPTR is not set
kernel command line has:
amdgpu.audio=1 amdgpu.si_support=1 radeon.si_support=0 page_owner=on \
amdgpu.gpu_recovery=1
Bisecting lead to:
commit 66f99628eb24409cb8feb5061f78283c8b65f820
Author: Hamza Mahfooz
Date: Tue Sep 6 15:01:49 2022 -0400
drm/amdgpu: use dirty framebuffer helper
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index c20922a5af9f..5b09c8f4fe95 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -496,6 +497,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
After doing a git bisect reset, git pull and reverting the patch above, I
rebuilt the kernel and am successfully running with the amdgpu module loaded
and using the Radeon R7 250 GPU.
I am happy to supply any further configuration details.
Arthur Marsh.
[PATCH 2/2] video: fbdev: uvesafb: convert snprintf to scnprintf
Coccinelle reports a warning WARNING: use scnprintf or sprintf Adding to that, there has also been some slow migration from snprintf to scnprintf This article explains the rationale for this change https: //lwn.net/Articles/69419/ Signed-off-by: Jules Irenge --- drivers/video/fbdev/uvesafb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c index 4df6772802d7..fd5d701106e1 100644 --- a/drivers/video/fbdev/uvesafb.c +++ b/drivers/video/fbdev/uvesafb.c @@ -1580,7 +1580,7 @@ static ssize_t uvesafb_show_vendor(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_vendor_name_ptr) - return snprintf(buf, PAGE_SIZE, "%s\n", (char *) + return scnprintf(buf, PAGE_SIZE, "%s\n", (char *) (&par->vbe_ib) + par->vbe_ib.oem_vendor_name_ptr); else return 0; @@ -1595,7 +1595,7 @@ static ssize_t uvesafb_show_product_name(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_product_name_ptr) - return snprintf(buf, PAGE_SIZE, "%s\n", (char *) + return scnprintf(buf, PAGE_SIZE, "%s\n", (char *) (&par->vbe_ib) + par->vbe_ib.oem_product_name_ptr); else return 0; @@ -1610,7 +1610,7 @@ static ssize_t uvesafb_show_product_rev(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_product_rev_ptr) - return snprintf(buf, PAGE_SIZE, "%s\n", (char *) + return scnprintf(buf, PAGE_SIZE, "%s\n", (char *) (&par->vbe_ib) + par->vbe_ib.oem_product_rev_ptr); else return 0; @@ -1625,7 +1625,7 @@ static ssize_t uvesafb_show_oem_string(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_string_ptr) - return snprintf(buf, PAGE_SIZE, "%s\n", + return scnprintf(buf, PAGE_SIZE, "%s\n", (char *)(&par->vbe_ib) + par->vbe_ib.oem_string_ptr); else return 0; @@ -1639,7 +1639,7 @@ static ssize_t uvesafb_show_nocrtc(struct device *dev, struct fb_info *info = dev_get_drvdata(dev); struct uvesafb_par *par = info->par; - return snprintf(buf, PAGE_SIZE, "%d\n", par->nocrtc); + return scnprintf(buf, PAGE_SIZE, "%d\n", par->nocrtc); } static ssize_t uvesafb_store_nocrtc(struct device *dev, -- 2.35.1
Re: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
I'll try using another mail client like Mutt later. :) Regards, Zheng Wang Greg KH 于2022年9月17日周六 17:07写道： > > On Fri, Sep 16, 2022 at 11:54:42PM +0800, Zheng Hacker wrote: > > >From afe79848cb74cc8e45ab426d13fa2394c87e0422 Mon Sep 17 00:00:00 2001 > > From: xmzyshypnc <1002992...@qq.com> > > Date: Fri, 16 Sep 2022 23:48:23 +0800 > > Subject: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry > > > > There is a double-free security bug in split_2MB_gtt_entry. > > > > Here is a calling chain : > > ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry. > > > > If intel_gvt_dma_map_guest_page failed, it will call > > ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and > > kfree(spt). But the caller does not notice that, and it will call > > ppgtt_free_spt again in error path. > > > > Fix this by only freeing spt in ppgtt_invalidate_spt in good case. > > > > Signed-off-by: Zheng Wang > > --- > > drivers/gpu/drm/i915/gvt/gtt.c | 16 +--- > > 1 file changed, 9 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c > > index ce0eb03709c3..550519f0acca 100644 > > --- a/drivers/gpu/drm/i915/gvt/gtt.c > > +++ b/drivers/gpu/drm/i915/gvt/gtt.c > > @@ -959,7 +959,7 @@ static inline int ppgtt_put_spt(struct > > intel_vgpu_ppgtt_spt *spt) > > return atomic_dec_return(&spt->refcount); > > } > > > > -static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt); > > +static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt, int > > is_error); > > > > static int ppgtt_invalidate_spt_by_shadow_entry(struct intel_vgpu *vgpu, > > struct intel_gvt_gtt_entry *e) > > @@ -995,7 +995,7 @@ static int > > ppgtt_invalidate_spt_by_shadow_entry(struct intel_vgpu *vgpu, > > Still line-wrapped and whitespace broken :( >
Re: [PATCH v3 0/5] drm/gma500: Backlight handling changes
On Sat, Sep 17, 2022 at 10:59 PM Hans de Goede wrote: > > Hi All, > > Here is a patch-series changing gma500's backlight handling to match > the changes done to the other major x86 GPU drivers in the just landed > backlight detection refactor patch series: > https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/ > > The main goal is here is to only register one backlight class device instead > of registering both "acpi_video0" and "psb-bl" backlight class devices; > in preparation for implementing the new backlight userspace-API from: > https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/ Hi Hans, Quite some time ago I wrote a backlight driver [1] for a MacBook to work around an issue in the i915 driver. My driver spoke directly to an external backlight driver chip. By doing so I could turn off the signal coming from the GPU and instead program my own PWM value directly. I remember it being a bit tricky to make my driver get priority over the i915 driver. Not sure what the actual issue was but I did get it to work properly in the end (perhaps with an xorg.conf change). I understand that this is a corner case but I'm just curious how/if this can be handled with the new API. Is it possible to kick out an existing non-acpi backlight driver if you know yours is better? [1] https://github.com/patjak/mba6x_bl > > Changes in v2: > - Add "Use backlight_get_brightness() to get the brightness" patch > > Changes in v3: > - Fix unused variable warnings when CONFIG_BACKLIGHT is not selected by > marking the 2 variables as __maybe_unused. This looks good to me. I don't have access to my DIM setup in a couple of days so please push these yourself if possible. For the entire series: Acked-by: Patrik Jakobsson > > Regards, > > Hans > > > Hans de Goede (5): > drm/gma500: Refactor backlight support (v2) > drm/gma500: Change registered backlight device type to raw/native > drm/gma500: Use backlight_get_brightness() to get the brightness > drm/gma500: Don't register backlight when another backlight should be > used > drm/gma500: Call acpi_video_register_backlight() > > drivers/gpu/drm/gma500/backlight.c | 102 +++ > drivers/gpu/drm/gma500/cdv_device.c | 50 ++- > drivers/gpu/drm/gma500/oaktrail_device.c | 65 ++- > drivers/gpu/drm/gma500/opregion.c| 6 +- > drivers/gpu/drm/gma500/psb_device.c | 73 +--- > drivers/gpu/drm/gma500/psb_drv.c | 15 +--- > drivers/gpu/drm/gma500/psb_drv.h | 13 +-- > 7 files changed, 97 insertions(+), 227 deletions(-) > > -- > 2.37.3 >
Re: [PATCH 0/6] drm/gma500: 1 fix + further cleanups
On Sat, Sep 17, 2022 at 2:31 PM Hans de Goede wrote: > > Hi Patrik, > > On 9/14/22 09:50, Patrik Jakobsson wrote: > > On Fri, Sep 9, 2022 at 1:56 PM Hans de Goede wrote: > >> > >> Hi Patrik, > >> > >> Here is another gma500 patch-series with one more bugfix and a bunch > >> of other cleanups of stuff which I noticed while doing the previous > >> set of bugfixes. > >> > > > > Hi Hans, nice cleanups! > > > > I'm rather busy at the moment so you can commit these yourself to > > drm-misc-next if you like. > > > > "drm/gma500: Wait longer for the GPU to power-down" can go through > > drm-misc-fixes if you prefer. It fixed the timeout message on two of > > my CDV machines but I never saw an actual problem from the timeouts. > > > > For the entire series: > > Acked-by: Patrik Jakobsson > > Thanks. > > I'm pushing these out to drm-misc-next now, but with some small > changes: > > 1. I have dropped the "drm/gma500: Wait longer for the GPU to power-down" > patch I'm still seeing timeouts even if I increase the wait time to > a full seconds. I believe that the actual issue is this line: > > dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT, > PSB_APMBA); > > sometimes failing. When the timeout happens I see apm_base is set to 0 and > reading apm_base + cmd / sts offset returns bogus values. Ugh, that is nasty. Debugging the punit is probably not easy. But the increased delay did remove the error on two of my 64-bit CDV systems. The 32-bit system never had an issue to begin with. I can also take a closer look at this. > > I have yet to have a successful boot where the timeout does not happen > since I have been poking at this (it seems success/fail wrt the timeout > is random). But I suspect that with a successful boot apm_base will not > be 0 and that the problem is there. To be continued... Do you still get working outputs when this happens? Perhaps we can work around it by simply not touching APM if apm_base is 0. > > > 2. For the "drm/gma500: Rewrite power management code" I noticed the > following error during further testing (for the actual backlight changes): > > [ 12.292509] gma500 :00:02.0: Unbalanced pm_runtime_enable! > > The problem is that pci_pm_init() which the PCI core runs for each > device already does: > > pm_runtime_forbid(&dev->dev); > pm_runtime_set_active(&dev->dev); > pm_runtime_enable(&dev->dev); > > So the pm_runtime_enable() call in "drm/gma500: Rewrite power management code" > was a second enable call and as such was not necessary. So I'm going to > squash in the following small fix while pushing this out: > > diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c > index 62d2cc1923f1..0080b692dc3e 100644 > --- a/drivers/gpu/drm/gma500/power.c > +++ b/drivers/gpu/drm/gma500/power.c > @@ -61,10 +61,11 @@ void gma_power_init(struct drm_device *dev) > * To fix this we need to call pm_runtime_get() once for each active > * pipe at boot and then put() / get() for each pipe disable / enable > * so that the device gets runtime suspended when no pipes are active. > +* Once this is in place the pm_runtime_get() below should be replaced > +* by a pm_runtime_allow() call to undo the pm_runtime_forbid() from > +* pci_pm_init(). > */ > pm_runtime_get(dev->dev); > - pm_runtime_set_active(dev->dev); /* Must be done before > pm_runtime_enable()! */ > - pm_runtime_enable(dev->dev); > > dev_priv->pm_initialized = true; > } > @@ -83,7 +83,6 @@ void gma_power_uninit(struct drm_device *dev) > if (!dev_priv->pm_initialized) > return; > > - pm_runtime_disable(dev->dev); > pm_runtime_put_noidle(dev->dev); > } > > > As you can see all the removed lines are already taken care of by the > PCI core, so this squashed in change really is a no-op (other then > that it silences the "Unbalanced pm_runtime_enable!" message). > > Regards, > > Hans > > > > > > > > > >> Regards, > >> > >> Hans > >> > >> > >> Hans de Goede (6): > >> drm/gma500: Wait longer for the GPU to power-down > >> drm/gma500: Remove runtime_allowed dead code in psb_unlocked_ioctl() > >> drm/gma500: Remove never set dev_priv->rpm_enabled flag > >> drm/gma500: Remove a couple of not useful function wrappers > >> drm/gma500: Rewrite power management code > >> drm/gma500: Remove unnecessary suspend/resume wrappers > >> > >> drivers/gpu/drm/gma500/cdv_device.c| 2 +- > >> drivers/gpu/drm/gma500/gma_display.c | 19 +-- > >> drivers/gpu/drm/gma500/gma_display.h | 2 - > >> drivers/gpu/drm/gma500/oaktrail_lvds.c | 1 - > >> drivers/gpu/drm/gma500/power.c | 156 + > >> drivers/gpu/drm/gma500/power.h | 18 --- > >> drivers/gpu/drm/gma500/psb_drv.c | 35 +- > >> drivers/gpu/drm/gma500/psb_drv.h | 7 +- > >> drivers/gpu/drm/gma500/psb_irq.c | 15 ++- > >> 9 files changed,
Re: [PATCH v3 0/5] drm/gma500: Backlight handling changes
Hi Hans, > > Changes in v3: > > - Fix unused variable warnings when CONFIG_BACKLIGHT is not selected by > > marking the 2 variables as __maybe_unused. > > This looks good to me. I don't have access to my DIM setup in a couple > of days so please push these yourself if possible. > > For the entire series: > Acked-by: Patrik Jakobsson I did not find time today - sorry. I you want to wait then I can take a look in the weekend - but not until then. Sam
Re: [PATCH v3 0/5] drm/gma500: Backlight handling changes
Hi Patrik,
On 9/18/22 20:22, Patrik Jakobsson wrote:
> On Sat, Sep 17, 2022 at 10:59 PM Hans de Goede wrote:
>>
>> Hi All,
>>
>> Here is a patch-series changing gma500's backlight handling to match
>> the changes done to the other major x86 GPU drivers in the just landed
>> backlight detection refactor patch series:
>> https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/
>>
>> The main goal is here is to only register one backlight class device instead
>> of registering both "acpi_video0" and "psb-bl" backlight class devices;
>> in preparation for implementing the new backlight userspace-API from:
>> https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/
>
> Hi Hans,
>
> Quite some time ago I wrote a backlight driver [1] for a MacBook to
> work around an issue in the i915 driver. My driver spoke directly to
> an external backlight driver chip. By doing so I could turn off the
> signal coming from the GPU and instead program my own PWM value
> directly. I remember it being a bit tricky to make my driver get
> priority over the i915 driver. Not sure what the actual issue was but
> I did get it to work properly in the end (perhaps with an xorg.conf
> change).
>
> I understand that this is a corner case but I'm just curious how/if
> this can be handled with the new API. Is it possible to kick out an
> existing non-acpi backlight driver if you know yours is better?
>
> [1] https://github.com/patjak/mba6x_bl
After the main refactoring series which is in linux-next now:
https://lore.kernel.org/all/20220825143726.269890-1-hdego...@redhat.com/
this should be possible, it should be easy even.
On x86/ACPI platforms the idea is that all backlight-drivers there
call acpi_video_get_backlight_type() which returns one of:
enum acpi_backlight_type {
acpi_backlight_none = 0,
acpi_backlight_video,
acpi_backlight_vendor,
acpi_backlight_native,
acpi_backlight_nvidia_wmi_ec,
acpi_backlight_apple_gmux,
};
(defined in include/acpi/video.h)
And then when acpi_video_get_backlight_type() returns a type which
does not match the driver which calls it, then that driver will
return without registering its backlight sysfs interface.
E.g. drivers/acpi/acpi_video.c does:
if (acpi_video_get_backlight_type() != acpi_backlight_video)
return 0;
before registering the /sys/class/backlight/acpi_video# interface(s).
And likewise the i915 driver now does:
if (!acpi_video_backlight_use_native())
return 0;
(Note native (GPU) backlight drivers use a special helper since that
helper also lets the video-detect code now that the GPU driver is
capable of doing native backlight control which is part of the heuristics
to pick which backlight control method to use).
So getting i915 out of the way now is as simple as making
acpi_video_get_backlight_type() return something else then
acpi_backlight_native which can be done through e.g. a DMI quirk.
The acpi_backlight_vendor type here is typically used by backlight code
in drivers like dell-laptop acer-wmi, asus-wmi, thinkpad_acpi, etc.
None of which I expect to load on your macbook.
So you could make your mba6x_bl have a:
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return 0;
Check to avoid registering. All backlight drivers used on x86/acpi
platforms should have such a check going forward so that
acpi_video_get_backlight_type() is the sole place in the kernel
which decides which backlight-control method actually gets registered.
And then pass: "acpi_backlight=vendor" on the kernel commandline to
switch from the default to your driver (and users can also use this
to switch back once you have made vendor the default on affected
macbooks).
If this works (which I expect it will) and once you have your driver
merged into the mainline kernel you can then add DMI based quirks to
drivers/acpi/video_detect.c to default to acpi_backlight=vendor on
these macbooks (I see that you already use DMI based auto-loading
in your driver).
So as you can hopefully see in linux-next with my refactoring in
place having another driver take over from the i915 driver should
be simple since there is a single point now
(acpi_video_get_backlight_type()) which controls which driver will
load and which ones will not load.
Regards,
Hans
p.s.
Note the above has nothing to do with the new userspace API for
backlight control. But sorting out there being multiple drivers
loaded/registered at the same time for a single panel/backlight
was a prerequisite for the new userspace API.
For the proposed new userspace API see:
https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86...@redhat.com/
>
>>
>> Changes in v2:
>> - Add "Use backlight_get_brightness() to get the brightness" patch
>>
>> Changes in v3:
>> - Fix unused variable warnings when CONFIG_BACKLIGHT is not selected by
>> marking the 2 variables
Re: [PATCH v3 0/5] drm/gma500: Backlight handling changes
Hi Sam, On 9/18/22 20:51, Sam Ravnborg wrote: > Hi Hans, > >>> Changes in v3: >>> - Fix unused variable warnings when CONFIG_BACKLIGHT is not selected by >>> marking the 2 variables as __maybe_unused. >> >> This looks good to me. I don't have access to my DIM setup in a couple >> of days so please push these yourself if possible. >> >> For the entire series: >> Acked-by: Patrik Jakobsson > > I did not find time today - sorry. No worries. > I you want to wait then I can take a look in the weekend - but not until > then. I just got an Ack from Patrik for these and I'm going to push them to drm-misc-next now. So another review is not necessary, thank you for the offer though! Regards, Hans
Re: [PATCH 0/6] drm/gma500: 1 fix + further cleanups
Hi Patrik,
On 9/18/22 20:45, Patrik Jakobsson wrote:
> On Sat, Sep 17, 2022 at 2:31 PM Hans de Goede wrote:
>>
>> Hi Patrik,
>>
>> On 9/14/22 09:50, Patrik Jakobsson wrote:
>>> On Fri, Sep 9, 2022 at 1:56 PM Hans de Goede wrote:
Hi Patrik,
Here is another gma500 patch-series with one more bugfix and a bunch
of other cleanups of stuff which I noticed while doing the previous
set of bugfixes.
>>>
>>> Hi Hans, nice cleanups!
>>>
>>> I'm rather busy at the moment so you can commit these yourself to
>>> drm-misc-next if you like.
>>>
>>> "drm/gma500: Wait longer for the GPU to power-down" can go through
>>> drm-misc-fixes if you prefer. It fixed the timeout message on two of
>>> my CDV machines but I never saw an actual problem from the timeouts.
>>>
>>> For the entire series:
>>> Acked-by: Patrik Jakobsson
>>
>> Thanks.
>>
>> I'm pushing these out to drm-misc-next now, but with some small
>> changes:
>>
>> 1. I have dropped the "drm/gma500: Wait longer for the GPU to power-down"
>> patch I'm still seeing timeouts even if I increase the wait time to
>> a full seconds. I believe that the actual issue is this line:
>>
>> dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
>> PSB_APMBA);
>>
>> sometimes failing. When the timeout happens I see apm_base is set to 0 and
>> reading apm_base + cmd / sts offset returns bogus values.
>
> Ugh, that is nasty. Debugging the punit is probably not easy. But the
> increased delay did remove the error on two of my 64-bit CDV systems.
It seemed to fix things on my 64 bit CDV system too, but it is really
hit and miss for me. I suspect that if you do a couple of full poweroff
+ boot again cycles it will be back some of the time for you too...
> The 32-bit system never had an issue to begin with. I can also take a
> closer look at this.
If you feel like verifying my dev_priv->apm_base = 0; theory that
would be great. Looking at the less hacky iosf-mbi access code from:
arch/x86/platform/intel/iosf_mbi.c
What might help is adding this:
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index 3065596257e9..70ce06ee3c1c 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -145,7 +145,7 @@ static int cdv_backlight_init(struct drm_device *dev)
static inline u32 CDV_MSG_READ32(int domain, uint port, uint offset)
{
- int mcr = (0x10<<24) | (port << 16) | (offset << 8);
+ int mcr = (0x10<<24) | (port << 16) | (offset << 8) | 0xF0;
uint32_t ret_val = 0;
struct pci_dev *pci_root = pci_get_domain_bus_and_slot(domain, 0, 0);
pci_write_config_dword(pci_root, 0xD0, mcr);
the gma500 cdv code already does this in the write path, but the:
arch/x86/platform/intel/iosf_mbi.c code does it both the write and read
paths.
Also we should probably just add the PCI root-bridge product-id to:
drivers/gpu/drm/gma500/cdv_device.c
and start using the iosf_mbi_read() / iosf_mbi_write() helpers from there.
>> I have yet to have a successful boot where the timeout does not happen
>> since I have been poking at this (it seems success/fail wrt the timeout
>> is random). But I suspect that with a successful boot apm_base will not
>> be 0 and that the problem is there. To be continued...
>
> Do you still get working outputs when this happens? Perhaps we can
> work around it by simply not touching APM if apm_base is 0.
The non working outputs thing is something weirdly timing related,
I have only seen this happen when the gma500_gfx module is not in
the initrd (so it gets loaded later). So I need to retry once we
have a proper fix for this, atm I am using the default Fedora config
of having the module inside the initrd.
Not doing random outl to IO address 0 and 0x04 seems like a good idea
regardless though :)
Regards,
Hans
>
>>
>>
>> 2. For the "drm/gma500: Rewrite power management code" I noticed the
>> following error during further testing (for the actual backlight changes):
>>
>> [ 12.292509] gma500 :00:02.0: Unbalanced pm_runtime_enable!
>>
>> The problem is that pci_pm_init() which the PCI core runs for each
>> device already does:
>>
>> pm_runtime_forbid(&dev->dev);
>> pm_runtime_set_active(&dev->dev);
>> pm_runtime_enable(&dev->dev);
>>
>> So the pm_runtime_enable() call in "drm/gma500: Rewrite power management
>> code"
>> was a second enable call and as such was not necessary. So I'm going to
>> squash in the following small fix while pushing this out:
>>
>> diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
>> index 62d2cc1923f1..0080b692dc3e 100644
>> --- a/drivers/gpu/drm/gma500/power.c
>> +++ b/drivers/gpu/drm/gma500/power.c
>> @@ -61,10 +61,11 @@ void gma_power_init(struct drm_device *dev)
>> * To fix this we need to call pm_runtime_get() once for each active
>> * pipe at boot and then put() / get() for each pipe disable / enable
>>
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
between commit:
41012d715d5d ("drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline
for stack usage")
from Linus' tree and commit:
a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
index 1cb858dd6ea0,b7fa003ffe06..
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
@@@ -6610,66 -6497,11 +6497,11 @@@ static double CalculateUrgentLatency
return ret;
}
-static void UseMinimumDCFCLK(
+static noinline_for_stack void UseMinimumDCFCLK(
struct display_mode_lib *mode_lib,
- int MaxInterDCNTileRepeaters,
+ struct vba_vars_st *v,
int MaxPrefetchMode,
- double FinalDRAMClockChangeLatency,
- double SREnterPlusExitTime,
- int ReturnBusWidth,
- int RoundTripPingLatencyCycles,
- int ReorderingBytes,
- int PixelChunkSizeInKByte,
- int MetaChunkSize,
- bool GPUVMEnable,
- int GPUVMMaxPageTableLevels,
- bool HostVMEnable,
- int NumberOfActivePlanes,
- double HostVMMinPageSize,
- int HostVMMaxNonCachedPageTableLevels,
- bool DynamicMetadataVMEnabled,
- enum immediate_flip_requirement ImmediateFlipRequirement,
- bool ProgressiveToInterlaceUnitInOPP,
- double
MaxAveragePercentOfIdealSDPPortBWDisplayCanUseInNormalSystemOperation,
- double
PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelMixedWithVMData,
- double
PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyVMDataOnly,
- double
PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelDataOnly,
- int VTotal[],
- int VActive[],
- int DynamicMetadataTransmittedBytes[],
- int DynamicMetadataLinesBeforeActiveRequired[],
- bool Interlace[],
- double RequiredDPPCLK[][2][DC__NUM_DPP__MAX],
- double RequiredDISPCLK[][2],
- double UrgLatency[],
- unsigned int NoOfDPP[][2][DC__NUM_DPP__MAX],
- double ProjectedDCFCLKDeepSleep[][2],
- double MaximumVStartup[][2][DC__NUM_DPP__MAX],
- double TotalVActivePixelBandwidth[][2],
- double TotalVActiveCursorBandwidth[][2],
- double TotalMetaRowBandwidth[][2],
- double TotalDPTERowBandwidth[][2],
- unsigned int TotalNumberOfActiveDPP[][2],
- unsigned int TotalNumberOfDCCActiveDPP[][2],
- int dpte_group_bytes[],
- double PrefetchLinesY[][2][DC__NUM_DPP__MAX],
- double PrefetchLinesC[][2][DC__NUM_DPP__MAX],
- unsigned int
swath_width_luma_ub_all_states[][2][DC__NUM_DPP__MAX],
- unsigned int
swath_width_chroma_ub_all_states[][2][DC__NUM_DPP__MAX],
- int BytePerPixelY[],
- int BytePerPixelC[],
- int HTotal[],
- double PixelClock[],
- double PDEAndMetaPTEBytesPerFrame[][2][DC__NUM_DPP__MAX],
- double DPTEBytesPerRow[][2][DC__NUM_DPP__MAX],
- double MetaRowBytes[][2][DC__NUM_DPP__MAX],
- bool DynamicMetadataEnable[],
- double VActivePixelBandwidth[][2][DC__NUM_DPP__MAX],
- double VActiveCursorBandwidth[][2][DC__NUM_DPP__MAX],
- double ReadBandwidthLuma[],
- double ReadBandwidthChroma[],
- double DCFCLKPerState[],
- double DCFCLKState[][2])
+ int ReorderingBytes)
{
double NormalEfficiency = 0;
double PTEEfficiency = 0;
pgpA7FjMmSM0N.pgp
Description: OpenPGP digital signature
[PATCH 0/3] drm/meson: fix use-after-free driver unload issues
This patch series tries to fix some use-after-free bugs I've observed with the help of KASAN in Amlogic's KMS DRM driver. The first patch in the series reorders the driver deinitialisation sequence so that devres won't deallocate things that are still expected to be around by a later call to drm_dev_put. The second patch adds a missing call to component_master_del inside a new driver's remove callback. The third patch makes sure some drm bridges added during driver initialisation are removed at module unload time, to make sure the global bridge list doesn't keep nodes to freed memory. All three patches have been tested on an Odroid N2+ plus SBC. Adrián Larumbe (3): drm/meson: reorder driver deinit sequence to fix use-after-free bug drm/meson: explicitly remove aggregate driver at module unload time drm/meson: remove drm bridges at aggregate driver unbind time drivers/gpu/drm/meson/meson_drv.c | 14 +- drivers/gpu/drm/meson/meson_drv.h | 7 +++ drivers/gpu/drm/meson/meson_encoder_cvbs.c | 7 +++ drivers/gpu/drm/meson/meson_encoder_cvbs.h | 1 + drivers/gpu/drm/meson/meson_encoder_hdmi.c | 7 +++ drivers/gpu/drm/meson/meson_encoder_hdmi.h | 1 + drivers/gpu/drm/meson/meson_venc.h | 15 +++ 7 files changed, 51 insertions(+), 1 deletion(-) -- 2.37.0
[PATCH 1/3] drm/meson: reorder driver deinit sequence to fix use-after-free bug
Unloading the driver triggers the following KASAN warning: [ +0.006275] = [ +0.29] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0 [ +0.26] Read of size 8 at addr 20c395e0 by task rmmod/2695 [ +0.19] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.13] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.08] Call trace: [ +0.07] dump_backtrace+0x1ec/0x280 [ +0.13] show_stack+0x24/0x80 [ +0.08] dump_stack_lvl+0x98/0xd4 [ +0.11] print_address_description.constprop.0+0x80/0x520 [ +0.11] print_report+0x128/0x260 [ +0.07] kasan_report+0xb8/0xfc [ +0.08] __asan_report_load8_noabort+0x3c/0x50 [ +0.10] __list_del_entry_valid+0xe0/0x1a0 [ +0.09] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.28] take_down_aggregate_device+0xb0/0x160 [ +0.16] component_del+0x18c/0x360 [ +0.09] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.15] platform_remove+0x64/0xb0 [ +0.09] device_remove+0xb8/0x154 [ +0.09] device_release_driver_internal+0x398/0x5b0 [ +0.09] driver_detach+0xac/0x1b0 [ +0.09] bus_remove_driver+0x158/0x29c [ +0.09] driver_unregister+0x70/0xb0 [ +0.08] platform_driver_unregister+0x20/0x2c [ +0.08] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.12] __do_sys_delete_module+0x288/0x400 [ +0.11] __arm64_sys_delete_module+0x5c/0x80 [ +0.09] invoke_syscall+0x74/0x260 [ +0.09] el0_svc_common.constprop.0+0xcc/0x260 [ +0.09] do_el0_svc+0x50/0x70 [ +0.07] el0_svc+0x68/0x1a0 [ +0.12] el0t_64_sync_handler+0x11c/0x150 [ +0.08] el0t_64_sync+0x18c/0x190 [ +0.18] Allocated by task 0: [ +0.07] (stack is not available) [ +0.11] Freed by task 2695: [ +0.08] kasan_save_stack+0x2c/0x5c [ +0.11] kasan_set_track+0x2c/0x40 [ +0.08] kasan_set_free_info+0x28/0x50 [ +0.09] kasan_slab_free+0x128/0x1d4 [ +0.08] __kasan_slab_free+0x18/0x24 [ +0.07] slab_free_freelist_hook+0x108/0x230 [ +0.11] kfree+0x110/0x35c [ +0.08] release_nodes+0xf0/0x16c [ +0.09] devres_release_group+0x180/0x270 [ +0.08] component_unbind+0x128/0x1e0 [ +0.10] component_unbind_all+0x1b8/0x264 [ +0.09] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.25] take_down_aggregate_device+0xb0/0x160 [ +0.09] component_del+0x18c/0x360 [ +0.09] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.12] platform_remove+0x64/0xb0 [ +0.08] device_remove+0xb8/0x154 [ +0.09] device_release_driver_internal+0x398/0x5b0 [ +0.09] driver_detach+0xac/0x1b0 [ +0.09] bus_remove_driver+0x158/0x29c [ +0.08] driver_unregister+0x70/0xb0 [ +0.08] platform_driver_unregister+0x20/0x2c [ +0.08] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.11] __do_sys_delete_module+0x288/0x400 [ +0.10] __arm64_sys_delete_module+0x5c/0x80 [ +0.08] invoke_syscall+0x74/0x260 [ +0.08] el0_svc_common.constprop.0+0xcc/0x260 [ +0.08] do_el0_svc+0x50/0x70 [ +0.07] el0_svc+0x68/0x1a0 [ +0.09] el0t_64_sync_handler+0x11c/0x150 [ +0.09] el0t_64_sync+0x18c/0x190 [ +0.14] The buggy address belongs to the object at 20c39000 which belongs to the cache kmalloc-4k of size 4096 [ +0.08] The buggy address is located 1504 bytes inside of 4096-byte region [20c39000, 20c3a000) [ +0.16] The buggy address belongs to the physical page: [ +0.09] page:fc830e00 refcount:1 mapcount:0 mapping: index:0x0 pfn:0x20c38 [ +0.13] head:fc830e00 order:3 compound_mapcount:0 compound_pincount:0 [ +0.08] flags: 0x0010200(slab|head|node=0|zone=0|lastcpupid=0x) [ +0.19] raw: 00010200 fcfd4808 fc126208 2e80 [ +0.09] raw: 00020002 0001 [ +0.08] page dumped because: kasan: bad access detected [ +0.11] Memory state around the buggy address: [ +0.08] 20c39480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.07] 20c39500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.07] >20c39580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.07]^ [ +0.07
[PATCH 3/3] drm/meson: remove drm bridges at aggregate driver unbind time
drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init were not manually removed at module unload time, which caused dangling references to freed memory to remain linked in the global bridge_list. When loading the driver modules back in, the same functions would again call drm_bridge_add, and when traversing the global bridge_list, would end up peeking into freed memory. Once again KASAN revealed the problem: [ +0.95] = [ +0.08] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120 [ +0.18] Read of size 8 at addr 3da291f0 by task modprobe/2483 [ +0.18] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.11] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.08] Call trace: [ +0.06] dump_backtrace+0x1ec/0x280 [ +0.12] show_stack+0x24/0x80 [ +0.08] dump_stack_lvl+0x98/0xd4 [ +0.11] print_address_description.constprop.0+0x80/0x520 [ +0.11] print_report+0x128/0x260 [ +0.08] kasan_report+0xb8/0xfc [ +0.08] __asan_report_load8_noabort+0x3c/0x50 [ +0.09] __list_add_valid+0x9c/0x120 [ +0.09] drm_bridge_add+0x6c/0x104 [drm] [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi] [ +0.22] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi] [ +0.14] component_bind+0x174/0x520 [ +0.12] component_bind_all+0x1a8/0x38c [ +0.10] meson_drv_bind_master+0x5e8/0xb74 [meson_drm] [ +0.32] meson_drv_bind+0x20/0x2c [meson_drm] [ +0.27] try_to_bring_up_aggregate_device+0x19c/0x390 [ +0.10] component_master_add_with_match+0x1c8/0x284 [ +0.09] meson_drv_probe+0x274/0x280 [meson_drm] [ +0.26] platform_probe+0xd0/0x220 [ +0.09] really_probe+0x3ac/0xa80 [ +0.09] __driver_probe_device+0x1f8/0x400 [ +0.09] driver_probe_device+0x68/0x1b0 [ +0.09] __driver_attach+0x20c/0x480 [ +0.08] bus_for_each_dev+0x114/0x1b0 [ +0.09] driver_attach+0x48/0x64 [ +0.08] bus_add_driver+0x390/0x564 [ +0.09] driver_register+0x1a8/0x3e4 [ +0.09] __platform_driver_register+0x6c/0x94 [ +0.08] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm] [ +0.27] do_one_initcall+0xc4/0x2b0 [ +0.11] do_init_module+0x154/0x570 [ +0.11] load_module+0x1a78/0x1ea4 [ +0.08] __do_sys_init_module+0x184/0x1cc [ +0.09] __arm64_sys_init_module+0x78/0xb0 [ +0.09] invoke_syscall+0x74/0x260 [ +0.09] el0_svc_common.constprop.0+0xcc/0x260 [ +0.08] do_el0_svc+0x50/0x70 [ +0.07] el0_svc+0x68/0x1a0 [ +0.12] el0t_64_sync_handler+0x11c/0x150 [ +0.08] el0t_64_sync+0x18c/0x190 [ +0.16] Allocated by task 879: [ +0.08] kasan_save_stack+0x2c/0x5c [ +0.11] __kasan_kmalloc+0x90/0xd0 [ +0.07] __kmalloc+0x278/0x4a0 [ +0.11] mpi_resize+0x13c/0x1d0 [ +0.11] mpi_powm+0xd24/0x1570 [ +0.09] rsa_enc+0x1a4/0x30c [ +0.09] pkcs1pad_verify+0x3f0/0x580 [ +0.09] public_key_verify_signature+0x7a8/0xba4 [ +0.10] public_key_verify_signature_2+0x40/0x60 [ +0.08] verify_signature+0xb4/0x114 [ +0.08] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574 [ +0.09] pkcs7_validate_trust+0xb8/0x15c [ +0.08] verify_pkcs7_message_sig+0xec/0x1b0 [ +0.12] verify_pkcs7_signature+0x78/0xac [ +0.07] mod_verify_sig+0x110/0x190 [ +0.09] module_sig_check+0x114/0x1e0 [ +0.09] load_module+0xa0/0x1ea4 [ +0.08] __do_sys_init_module+0x184/0x1cc [ +0.08] __arm64_sys_init_module+0x78/0xb0 [ +0.08] invoke_syscall+0x74/0x260 [ +0.09] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.08] do_el0_svc+0x50/0x70 [ +0.07] el0_svc+0x68/0x1a0 [ +0.09] el0t_64_sync_handler+0x11c/0x150 [ +0.09] el0t_64_sync+0x18c/0x190 [ +0.13] Freed by task 2422: [ +0.08] kasan_save_stack+0x2c/0x5c [ +0.09] kasan_set_track+0x2c/0x40 [ +0.07] kasan_set_free_info+0x28/0x50 [ +0.09] kasan_slab_free+0x128/0x1d4 [ +0.08] __kasan_slab_free+0x18/0x24 [ +0.07] slab_free_freelist_hook+0x108/0x230 [ +0.10] kfree+0x110/0x35c [ +0.08] release_nodes+0xf0/0x16c [ +0.09] devres_release_group+0x180/0x270 [ +0.08] take_down_aggregate_device+0xcc/0x160 [ +0.10] component_del+0x18c/0x360 [ +0.09] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.13] platform_remove+0x64/0xb0 [ +0.08] device_remove+0xb8/0x154 [ +0.09] device_release_driver_internal+0x398/0x5b0 [ +0.09] driver_detach+0xac/0x1b0 [ +0.09] bus_remove_driver+0x158/0x29c [ +0.08] driver_unregister+0x70/0xb0 [ +0.09] platform_driver_unregister+0x20/0x2c [ +0.07] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.12] __do_sys_delete_module+0x288/0x400 [ +0.09] __arm64_sys_delete_module+0x5c/0x80 [ +0.09] invoke_syscall+0x74/0x260 [ +0.08
[PATCH 2/3] drm/meson: explicitly remove aggregate driver at module unload time
Because component_master_del wasn't being called when unloading the meson_drm module, the aggregate device would linger forever in the global aggregate_devices list. That means when unloading and reloading the meson_dw_hdmi module, component_add would call into try_to_bring_up_aggregate_device and find the unbound meson_drm aggregate device. This would in turn dereference some of the aggregate_device's struct entries which point to memory automatically freed by the devres API when unbinding the aggregate device from meson_drv_unbind, and trigger an use-after-free bug: [ +0.14] = [ +0.07] BUG: KASAN: use-after-free in find_components+0x468/0x500 [ +0.17] Read of size 8 at addr 06731688 by task modprobe/2536 [ +0.18] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.10] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.08] Call trace: [ +0.05] dump_backtrace+0x1ec/0x280 [ +0.11] show_stack+0x24/0x80 [ +0.07] dump_stack_lvl+0x98/0xd4 [ +0.10] print_address_description.constprop.0+0x80/0x520 [ +0.11] print_report+0x128/0x260 [ +0.07] kasan_report+0xb8/0xfc [ +0.07] __asan_report_load8_noabort+0x3c/0x50 [ +0.09] find_components+0x468/0x500 [ +0.08] try_to_bring_up_aggregate_device+0x64/0x390 [ +0.09] __component_add+0x1dc/0x49c [ +0.09] component_add+0x20/0x30 [ +0.08] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi] [ +0.13] platform_probe+0xd0/0x220 [ +0.08] really_probe+0x3ac/0xa80 [ +0.08] __driver_probe_device+0x1f8/0x400 [ +0.08] driver_probe_device+0x68/0x1b0 [ +0.08] __driver_attach+0x20c/0x480 [ +0.09] bus_for_each_dev+0x114/0x1b0 [ +0.07] driver_attach+0x48/0x64 [ +0.09] bus_add_driver+0x390/0x564 [ +0.07] driver_register+0x1a8/0x3e4 [ +0.09] __platform_driver_register+0x6c/0x94 [ +0.07] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi] [ +0.14] do_one_initcall+0xc4/0x2b0 [ +0.08] do_init_module+0x154/0x570 [ +0.10] load_module+0x1a78/0x1ea4 [ +0.08] __do_sys_init_module+0x184/0x1cc [ +0.08] __arm64_sys_init_module+0x78/0xb0 [ +0.08] invoke_syscall+0x74/0x260 [ +0.08] el0_svc_common.constprop.0+0xcc/0x260 [ +0.09] do_el0_svc+0x50/0x70 [ +0.08] el0_svc+0x68/0x1a0 [ +0.09] el0t_64_sync_handler+0x11c/0x150 [ +0.09] el0t_64_sync+0x18c/0x190 [ +0.14] Allocated by task 902: [ +0.07] kasan_save_stack+0x2c/0x5c [ +0.09] __kasan_kmalloc+0x90/0xd0 [ +0.07] __kmalloc_node+0x240/0x580 [ +0.10] memcg_alloc_slab_cgroups+0xa4/0x1ac [ +0.10] memcg_slab_post_alloc_hook+0xbc/0x4c0 [ +0.08] kmem_cache_alloc_node+0x1d0/0x490 [ +0.09] __alloc_skb+0x1d4/0x310 [ +0.10] alloc_skb_with_frags+0x8c/0x620 [ +0.08] sock_alloc_send_pskb+0x5ac/0x6d0 [ +0.10] unix_dgram_sendmsg+0x2e0/0x12f0 [ +0.10] sock_sendmsg+0xcc/0x110 [ +0.07] sock_write_iter+0x1d0/0x304 [ +0.08] new_sync_write+0x364/0x460 [ +0.07] vfs_write+0x420/0x5ac [ +0.08] ksys_write+0x19c/0x1f0 [ +0.08] __arm64_sys_write+0x78/0xb0 [ +0.07] invoke_syscall+0x74/0x260 [ +0.08] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.09] do_el0_svc+0x50/0x70 [ +0.07] el0_svc+0x68/0x1a0 [ +0.08] el0t_64_sync_handler+0x11c/0x150 [ +0.08] el0t_64_sync+0x18c/0x190 [ +0.13] Freed by task 2509: [ +0.08] kasan_save_stack+0x2c/0x5c [ +0.07] kasan_set_track+0x2c/0x40 [ +0.08] kasan_set_free_info+0x28/0x50 [ +0.08] kasan_slab_free+0x128/0x1d4 [ +0.08] __kasan_slab_free+0x18/0x24 [ +0.07] slab_free_freelist_hook+0x108/0x230 [ +0.10] kfree+0x110/0x35c [ +0.08] release_nodes+0xf0/0x16c [ +0.08] devres_release_all+0xfc/0x180 [ +0.08] device_unbind_cleanup+0x24/0x164 [ +0.08] device_release_driver_internal+0x3e8/0x5b0 [ +0.10] driver_detach+0xac/0x1b0 [ +0.08] bus_remove_driver+0x158/0x29c [ +0.08] driver_unregister+0x70/0xb0 [ +0.09] platform_driver_unregister+0x20/0x2c [ +0.07] 0x83722d98 [ +0.12] __do_sys_delete_module+0x288/0x400 [ +0.09] __arm64_sys_delete_module+0x5c/0x80 [ +0.08] invoke_syscall+0x74/0x260 [ +0.08] el0_svc_common.constprop.0+0xcc/0x260 [ +0.08] do_el0_svc+0x50/0x70 [ +0.07] el0_svc+0x68/0x1a0 [ +0.08] el0t_64_sync_handler+0x11c/0x150 [ +0.09] el0t_64_sync+0x18c/0x190 [ +0.13] Last potentially related work creation: [ +0.07] kasan_save_stack+0x2c/0x5c [ +0.07] __kasan_record_aux_stack+0xb8/0xf0 [ +0.09] kasan_record_aux_stack_noalloc+0x14/0x20 [ +0.08] insert_work+0x54/0x290 [ +0.09] __queue_work+0x48c/0xd24 [ +0.08] queue_work_on+0x90/0x11c [ +0.08] call_usermodehelper_exec+0x188/0x404 [ +
Re: [PATCH v2 1/6] dt-bindings: arm: mediatek: mmsys: change compatible for MT8195
Hi Krzysztof,
Thanks for the reviews.
On Sun, 2022-09-18 at 10:31 +0100, Krzysztof Kozlowski wrote:
> On 16/09/2022 04:34, Jason-JH Lin wrote:
> > Hi Matthias,
> >
> > Thanks for the review.
> >
> > On Fri, 2022-09-16 at 00:05 +0200, Matthias Brugger wrote:
> > >
> > > On 15/09/2022 18:18, Jason-JH.Lin wrote:
> > > > For previous MediaTek SoCs, such as MT8173, there are 2 display
> > > > HW
> > > > pipelines binding to 1 mmsys with the same power domain, the
> > > > same
> > > > clock driver and the same mediatek-drm driver.
> > > >
> > > > For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines
> > > > binding
> > > > to
> > > > 2 different power domains, different clock drivers and
> > > > different
> > > > mediatek-drm drivers.
> > > >
> > > > Moreover, Hardware pipeline of VDOSYS0 has these components:
> > > > COLOR,
> > > > CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
> > > > Quality)
> > > > and they makes VDOSYS0 supports PQ function while they are not
> > > > including in VDOSYS1.
> > > >
> > > > Hardware pipeline of VDOSYS1 has the component ETHDR (HDR
> > > > related
> > > > component). It makes VDOSYS1 supports the HDR function while
> > > > it's
> > > > not
> > > > including in VDOSYS0.
> > > >
> > > > To summarize0:
> > > > Only VDOSYS0 can support PQ adjustment.
> > > > Only VDOSYS1 can support HDR adjustment.
> > > >
> > > > Therefore, we need to separate these two different mmsys
> > > > hardwares
> > > > to
> > > > 2 different compatibles for MT8195.
> > > >
> > > > Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add
> > > > mt8195
> > > > SoC binding")
> > > > Signed-off-by: Jason-JH.Lin
> > > > Signed-off-by: Bo-Chen Chen
> > > > ---
> > > >
> > > > .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> > > > |
> > > > 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > index 6ad023eec193..0e267428eaa6 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > +++
> > > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > @@ -31,7 +31,7 @@ properties:
> > > > - mediatek,mt8183-mmsys
> > > > - mediatek,mt8186-mmsys
> > > > - mediatek,mt8192-mmsys
> > > > - - mediatek,mt8195-mmsys
> > > > + - mediatek,mt8195-vdosys0
> > >
> > > Nack, we miss the fallback compatible, as I already said twice.
> > >
> > > Regards,
> > > Matthias
> >
> > I'm sorry this happened again.
> > I'll keep the compatible "mediatek,mt8195-mmsys" at next version.
> >
> > The patch "dt-bindings: arm: mediatek: mmsys: remove the unused
> > compatible for mt8195" should be sent after accepting the vdosys1
> > series, right?
>
> I don't think there will be no such patch...
>
> You need to add a bindings change which will accept device nodes
> like:
> foo {
> compatible = "mediatek,mt8195-vdosys0", "mediatek,mt8195-mmsys";
>
> }
>
> Example-schema shows how to do it.
OK, I got the point!
I'll fix it at the next version.
Thank you very much!
Regards,
Jason-JH.Lin
>
> Best regards,
> Krzysztof
--
Jason-JH Lin
Re: [PATCH] gpu: color: eliminate implicit conversion about enum type
gpu: color: fix enum-conversion compile warning
标题我记得不跟你所过让你改的
On 2022/9/19 9:44, Zeng Heng wrote:
> Fix below compile warning when open enum-conversion
> option check:
>
> drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:
> In function ‘apply_degamma_for_user_regamma’:
> drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1695:29:
> error: implicit conversion from ‘enum ’ to ‘enum
> dc_transfer_func_predefined’ [-Werror=enum-conversion]
> 1695 | build_coefficients(&coeff, true);
> | ^~~~
>
> As 'build_coefficients' definition, it needs enum
> 'dc_transfer_func_predefined' type acts as the
> second argument, instead of bool-type one.
>
> The numerical values of TRANSFER_FUNCTION_BT709 & true
> happen to be the same, so there is no change in
> behavior.
>
> Signed-off-by: Zeng Heng
> ---
> drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
> b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
> index 04f7656906ca..2f807d787c77 100644
> --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
> +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c
> @@ -1692,7 +1692,7 @@ static void apply_degamma_for_user_regamma(struct
> pwl_float_data_ex *rgb_regamma
> struct pwl_float_data_ex *rgb = rgb_regamma;
> const struct hw_x_point *coord_x = coordinates_x;
>
> - build_coefficients(&coeff, true);
> + build_coefficients(&coeff, TRANSFER_FUNCTION_BT709);
>
> i = 0;
> while (i != hw_points_num + 1) {
>
[PATCH] drm/amd/display: remove redundant CalculateTWait's
There are several copies of CalculateTwait.
Reduce to one instance and change local variable name to match common usage.
Signed-off-by: Tom Rix
---
.../dc/dml/dcn20/display_mode_vba_20.c| 16 +++---
.../dc/dml/dcn20/display_mode_vba_20v2.c | 21 ++-
.../dc/dml/dcn21/display_mode_vba_21.c| 19 +
.../dc/dml/dcn30/display_mode_vba_30.c| 18 +---
.../dc/dml/dcn31/display_mode_vba_31.c| 13 +---
.../dc/dml/dcn314/display_mode_vba_314.c | 13 +---
6 files changed, 14 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
index 6e9d7e2b5243..4ca080950924 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
@@ -153,10 +153,10 @@ static unsigned int CalculateVMAndRowBytes(
bool *PTEBufferSizeNotExceeded,
unsigned int *dpte_row_height,
unsigned int *meta_row_height);
-static double CalculateTWait(
+double CalculateTWait(
unsigned int PrefetchMode,
double DRAMClockChangeLatency,
- double UrgentLatencyPixelDataOnly,
+ double UrgentLatency,
double SREnterPlusExitTime);
static double CalculateRemoteSurfaceFlipDelay(
struct display_mode_lib *mode_lib,
@@ -2892,20 +2892,20 @@ static void dml20_DisplayPipeConfiguration(struct
display_mode_lib *mode_lib)
}
}
-static double CalculateTWait(
+double CalculateTWait(
unsigned int PrefetchMode,
double DRAMClockChangeLatency,
- double UrgentLatencyPixelDataOnly,
+ double UrgentLatency,
double SREnterPlusExitTime)
{
if (PrefetchMode == 0) {
return dml_max(
- DRAMClockChangeLatency +
UrgentLatencyPixelDataOnly,
- dml_max(SREnterPlusExitTime,
UrgentLatencyPixelDataOnly));
+ DRAMClockChangeLatency + UrgentLatency,
+ dml_max(SREnterPlusExitTime, UrgentLatency));
} else if (PrefetchMode == 1) {
- return dml_max(SREnterPlusExitTime, UrgentLatencyPixelDataOnly);
+ return dml_max(SREnterPlusExitTime, UrgentLatency);
} else {
- return UrgentLatencyPixelDataOnly;
+ return UrgentLatency;
}
}
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
index b02dda8ce70f..2b4dcae4e432 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
@@ -177,10 +177,10 @@ static unsigned int CalculateVMAndRowBytes(
bool *PTEBufferSizeNotExceeded,
unsigned int *dpte_row_height,
unsigned int *meta_row_height);
-static double CalculateTWait(
+double CalculateTWait(
unsigned int PrefetchMode,
double DRAMClockChangeLatency,
- double UrgentLatencyPixelDataOnly,
+ double UrgentLatency,
double SREnterPlusExitTime);
static double CalculateRemoteSurfaceFlipDelay(
struct display_mode_lib *mode_lib,
@@ -2967,23 +2967,6 @@ static void dml20v2_DisplayPipeConfiguration(struct
display_mode_lib *mode_lib)
}
}
-static double CalculateTWait(
- unsigned int PrefetchMode,
- double DRAMClockChangeLatency,
- double UrgentLatencyPixelDataOnly,
- double SREnterPlusExitTime)
-{
- if (PrefetchMode == 0) {
- return dml_max(
- DRAMClockChangeLatency +
UrgentLatencyPixelDataOnly,
- dml_max(SREnterPlusExitTime,
UrgentLatencyPixelDataOnly));
- } else if (PrefetchMode == 1) {
- return dml_max(SREnterPlusExitTime, UrgentLatencyPixelDataOnly);
- } else {
- return UrgentLatencyPixelDataOnly;
- }
-}
-
static double CalculateRemoteSurfaceFlipDelay(
struct display_mode_lib *mode_lib,
double VRatio,
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index 6be14f55c78d..a3ef3638d979 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -205,7 +205,7 @@ static unsigned int CalculateVMAndRowBytes(
unsigned int *DPDE0BytesFrame,
unsigned int *MetaPTEBytesFrame);
-static double CalculateTWait(
+double CalculateTWait(
Re: [PATCH] gpu: dc: fix enum conversion in display_mode_vba
On 2022/9/19 9:41, Zeng Heng wrote: > Fix below compile warning when open enum-conversion > option check (compiled with -Wenum-conversion): > > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c: > In function ‘dml20_ModeSupportAndSystemConfigurationFull’: > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3900:44: > error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’ > [-Werror=enum-conversion] > 3900 | locals->ODMCombineEnablePerState[i][k] = false; > |^ > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3904:46: > error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’ > [-Werror=enum-conversion] > 3904 | locals->ODMCombineEnablePerState[i][k] = true; > | ^ > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3907:46: > error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’ > [-Werror=enum-conversion] > 3907 | locals->ODMCombineEnablePerState[i][k] = true; > | ^ > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3960:45: > error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’ > [-Werror=enum-conversion] > 3960 | locals->ODMCombineEnablePerState[i][k] = false; > > Use the proper value from the right enumerated type, > dm_odm_combine_mode_disabled & dm_odm_combine_mode_2to1, > so there is no more implicit conversion. > > The numerical values of dm_odm_combine_mode_disabled > & false and dm_odm_combine_mode_2to1 & true > happen to be the same, so there is no change in > behavior. > LGTM
Re: drm/amdgpu: use dirty framebuffer helper
I have done a delayed load of amdgpu with the 6.0-rc6 kernel using: modprobe amdgpu si_support=1 and saved the dmesg output: [ 455.424263] udevd[414]: specified group 'sgx' unknown [ 455.514818] ACPI: bus type drm_connector registered [ 457.759316] [drm] amdgpu kernel modesetting enabled. [ 457.759491] amdgpu :01:00.0: vgaarb: deactivate vga console [ 457.760459] Console: switching to colour dummy device 80x25 [ 457.760689] [drm] initializing kernel modesetting (VERDE 0x1002:0x682B 0x1458:0x22CA 0x87). [ 457.760717] [drm] register mmio base: 0xFE8C [ 457.760720] [drm] register mmio size: 262144 [ 457.760872] [drm] add ip block number 0 [ 457.760887] [drm] add ip block number 1 [ 457.760890] [drm] add ip block number 2 [ 457.760893] [drm] add ip block number 3 [ 457.760896] [drm] add ip block number 4 [ 457.760898] [drm] add ip block number 5 [ 457.760901] [drm] add ip block number 6 [ 457.760903] [drm] add ip block number 7 [ 457.804366] [drm] BIOS signature incorrect 20 7 [ 457.804376] resource sanity check: requesting [mem 0x000c-0x000d], which spans more than PCI Bus :00 [mem 0x000d-0x000d window] [ 457.804383] caller pci_map_rom+0x68/0x1b0 mapping multiple BARs [ 457.804398] amdgpu :01:00.0: No more image in the PCI ROM [ 457.805746] amdgpu :01:00.0: amdgpu: Fetched VBIOS from ROM BAR [ 457.805752] amdgpu: ATOM BIOS: xxx-xxx-xxx [ 457.805775] amdgpu :01:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported [ 457.805781] amdgpu :01:00.0: amdgpu: PCIE atomic ops is not supported [ 457.806204] [drm] PCIE gen 2 link speeds already enabled [ 457.806632] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit [ 457.869590] amdgpu :01:00.0: amdgpu: VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) [ 457.869605] amdgpu :01:00.0: amdgpu: GART: 1024M 0x00FF - 0x00FF3FFF [ 457.869622] [drm] Detected VRAM RAM=2048M, BAR=256M [ 457.869625] [drm] RAM width 128bits DDR3 [ 457.869706] [drm] amdgpu: 2048M of VRAM memory ready [ 457.869710] [drm] amdgpu: 3979M of GTT memory ready. [ 457.869734] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 457.870061] amdgpu :01:00.0: amdgpu: PCIE GART of 1024M enabled (table at 0x00F400A0). [ 457.908024] [drm] Internal thermal controller with fan control [ 457.908045] [drm] amdgpu: dpm initialized [ 457.908126] [drm] AMDGPU Display Connectors [ 457.908128] [drm] Connector 0: [ 457.908131] [drm] HDMI-A-1 [ 457.908133] [drm] HPD1 [ 457.908135] [drm] DDC: 0x194c 0x194c 0x194d 0x194d 0x194e 0x194e 0x194f 0x194f [ 457.908139] [drm] Encoders: [ 457.908141] [drm] DFP1: INTERNAL_UNIPHY [ 457.908144] [drm] Connector 1: [ 457.908145] [drm] DVI-D-1 [ 457.908147] [drm] HPD2 [ 457.908149] [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [ 457.908153] [drm] Encoders: [ 457.908155] [drm] DFP2: INTERNAL_UNIPHY [ 457.908157] [drm] Connector 2: [ 457.908159] [drm] VGA-1 [ 457.908160] [drm] DDC: 0x1970 0x1970 0x1971 0x1971 0x1972 0x1972 0x1973 0x1973 [ 457.908164] [drm] Encoders: [ 457.908166] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 457.959506] [drm] Found UVD firmware Version: 64.0 Family ID: 13 [ 458.497761] [drm] UVD initialized successfully. [ 458.498549] amdgpu :01:00.0: amdgpu: SE 1, SH per SE 2, CU per SH 5, active_cu_number 8 [ 458.836681] [drm] Initialized amdgpu 3.48.0 20150101 for :01:00.0 on minor 0 [ 458.909127] fbcon: amdgpudrmfb (fb0) is primary device [ 458.936086] Console: switching to colour frame buffer device 240x67 [ 458.936126] BUG: kernel NULL pointer dereference, address: 0010 [ 458.936128] #PF: supervisor read access in kernel mode [ 458.936130] #PF: error_code(0x) - not-present page [ 458.936132] PGD 0 P4D 0 [ 458.936134] Oops: [#1] PREEMPT SMP NOPTI [ 458.936137] CPU: 3 PID: 81 Comm: kworker/3:1 Not tainted 6.0.0-rc6 #5144 [ 458.936140] Hardware name: System manufacturer System Product Name/M3A78 PRO, BIOS 170101/27/2011 [ 458.936141] Workqueue: events drm_fb_helper_damage_work [drm_kms_helper] [ 458.936162] RIP: 0010:drm_atomic_helper_dirtyfb+0x13c/0x240 [drm_kms_helper] [ 458.936176] Code: 05 c0 02 00 00 4c 8d 7a f8 48 39 c2 74 58 49 8b 74 24 48 4d 8d 77 20 4c 89 f7 e8 0f b5 f5 ff 85 c0 75 4b 49 8b 87 58 02 00 00 <48> 39 68 10 75 bf 4c 89 fe 4c 89 e7 e8 23 bf f5 ff 48 3d 00 f0 ff [ 458.936178] RSP: 0018:b75080db3da8 EFLAGS: 00010246 [ 458.936180] RAX: RBX: 9dbae32e2880 RCX: 003b [ 458.936181] RDX: b75080db3dd8 RSI: b75080db3dd8 RDI: 9dbad6329c48 [ 458.936182] RBP: 9dbae9b41100 R08: b75080db3dd8 R09: 9dbae33e01f8 [ 458.936184] R10: 9dbadf388028 R11: 0001 R12: 9dbad150e880 [ 458.936185] R13: 9dbaee0d9980 R14: 9dbad6329c20 R15: 9dbad6329c00 [ 458.936186] FS: 0
Re: [PATCH v2] drm: mediatek: Fix display vblank timeout when disable dsi
Hi CK,
We will test this fix on the mt8186/mt8183.
Maybe our fix is not necessary.
I appreciate your suggestion.
BRs,
Allen
On 9/18/22 12:32, Chun-Kuang Hu wrote:
> Hi, Allen:
>
> Allen-KH Cheng 於 2022年9月14日 週三 晚上10:00寫道：
>>
>> From: Xinlei Lee
>>
>> Dsi is turned off at bridge.disable, causing crtc to wait for vblank
>> timeout. It is necessary to add count protection to turn off dsi and
>> turn off at post_disable.
>
> If turn off dsi in post_disable(), you should turn on dsi in pre_enable().
>
> There is another patch fix this problem [1], do you have any comment
> on that patch?
>
> [1]
> http://lists.infradead.org/pipermail/linux-mediatek/2022-August/046713.html
>
> Regards,
> Chun-Kuang.
>
>>
>> Fixes: cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from
>> enable/disable and define new funcs")
>> Signed-off-by: Xinlei Lee
>> Co-developed-by: Allen-KH Cheng
>> Signed-off-by: Allen-KH Cheng
>> ---
>> Change in v1:
>> * Rebase to kernel/git/chunkuang.hu/linux.git, mediatek-drm-fixes
>> [Allen-KH Cheng ]
>> ---
>> ---
>> drivers/gpu/drm/mediatek/mtk_dsi.c | 15 ++-
>> 1 file changed, 6 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> index 5b624e0f5b0a..e30f4244c001 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> @@ -768,14 +768,6 @@ static void mtk_dsi_bridge_mode_set(struct drm_bridge
>> *bridge,
>> drm_display_mode_to_videomode(adjusted, &dsi->vm);
>> }
>>
>> -static void mtk_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
>> - struct drm_bridge_state
>> *old_bridge_state)
>> -{
>> - struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>> -
>> - mtk_output_dsi_disable(dsi);
>> -}
>> -
>> static void mtk_dsi_bridge_atomic_enable(struct drm_bridge *bridge,
>> struct drm_bridge_state
>> *old_bridge_state)
>> {
>> @@ -803,13 +795,15 @@ static void mtk_dsi_bridge_atomic_post_disable(struct
>> drm_bridge *bridge,
>> {
>> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>>
>> + if (dsi->refcount == 1)
>> + mtk_output_dsi_disable(dsi);
>> +
>> mtk_dsi_poweroff(dsi);
>> }
>>
>> static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
>> .attach = mtk_dsi_bridge_attach,
>> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
>> - .atomic_disable = mtk_dsi_bridge_atomic_disable,
>> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>> .atomic_enable = mtk_dsi_bridge_atomic_enable,
>> .atomic_pre_enable = mtk_dsi_bridge_atomic_pre_enable,
>> @@ -829,6 +823,9 @@ void mtk_dsi_ddp_stop(struct device *dev)
>> {
>> struct mtk_dsi *dsi = dev_get_drvdata(dev);
>>
>> + if (dsi->refcount == 1)
>> + mtk_output_dsi_disable(dsi);
>> +
>> mtk_dsi_poweroff(dsi);
>> }
>>
>> --
>> 2.18.0
>>
[PATCH] drm: bridge/dw-hdmi-ahb-audio: use strscpy() is more robust and safer
From: Minghao Chi The implementation of strscpy() is more robust and safer. That's now the recommended way to copy NUL terminated strings. Reported-by: Zeal Robot Signed-off-by: Minghao Chi --- drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c index 7d2ed0ed2fe2..4efb62bcdb63 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c @@ -542,8 +542,8 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev) if (ret < 0) return ret; - strlcpy(card->driver, DRIVER_NAME, sizeof(card->driver)); - strlcpy(card->shortname, "DW-HDMI", sizeof(card->shortname)); + strscpy(card->driver, DRIVER_NAME, sizeof(card->driver)); + strscpy(card->shortname, "DW-HDMI", sizeof(card->shortname)); snprintf(card->longname, sizeof(card->longname), "%s rev 0x%02x, irq %d", card->shortname, revision, data->irq); @@ -561,7 +561,7 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev) dw->pcm = pcm; pcm->private_data = dw; - strlcpy(pcm->name, DRIVER_NAME, sizeof(pcm->name)); + strscpy(pcm->name, DRIVER_NAME, sizeof(pcm->name)); snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &snd_dw_hdmi_ops); /* -- 2.25.1
Re: [PATCH v4 02/12] drm: bridge: Add Samsung DSIM bridge driver
Hi Jagan, On 16.09.2022 12:21, Jagan Teki wrote: > On Fri, Sep 16, 2022 at 1:58 PM Marek Szyprowski > wrote: >> On 14.09.2022 11:39, Jagan Teki wrote: >>> On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski >>> wrote: On 13.09.2022 19:29, Jagan Teki wrote: > On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski > wrote: >> On 06.09.2022 21:07, Jagan Teki wrote: >>> On Mon, Sep 5, 2022 at 4:54 PM Marek Szyprowski >>> wrote: On 02.09.2022 12:47, Marek Szyprowski wrote: > On 29.08.2022 20:40, Jagan Teki wrote: >> Samsung MIPI DSIM controller is common DSI IP that can be used in >> various >> SoCs like Exynos, i.MX8M Mini/Nano. >> >> In order to access this DSI controller between various platform SoCs, >> the ideal way to incorporate this in the drm stack is via the drm >> bridge >> driver. >> >> This patch is trying to differentiate platform-specific and bridge >> driver >> code and keep maintaining the exynos_drm_dsi.c code as >> platform-specific >> glue code and samsung-dsim.c as a common bridge driver code. >> >> - Exynos specific glue code is exynos specific te_irq, host_attach, >> and >>detach code along with conventional component_ops. >> >> - Samsung DSIM is a bridge driver which is common across all >> platforms and >>the respective platform-specific glue will initialize at the >> end >> of the >>probe. The platform-specific operations and other glue calls >> will >> invoke >>on associate code areas. >> >> v4: >> * include Inki Dae in MAINTAINERS >> * remove dsi_driver probe in exynos_drm_drv to support multi-arch >> build > This breaks Exynos DRM completely as the Exynos DRM driver is not able > to wait until the DSI driver is probed and registered as component. > > I will show how to rework this the way it is done in > drivers/gpu/drm/exynos/exynos_dp.c and > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c soon... I've finally had some time to implement such approach, see https://protect2.fireeye.com/v1/url?k=c5d024d9-a4ab8e4e-c5d1af96-74fe4860001d-625a8324a9797375&q=1&e=489b94d4-84fb-408e-b679-a8d27acf2930&u=https%3A%2F%2Fgithub.com%2Fmszyprow%2Flinux%2Ftree%2Fv6.0-dsi-v4-reworked If you want me to send the patches against your v4 patchset, let me know, but imho my changes are much more readable after squashing to the original patches. Now the driver is fully multi-arch safe and ready for further extensions. I've removed the weak functions, reworked the way the plat_data is used (dropped the patch related to it) and restored exynos-dsi driver as a part of the Exynos DRM drivers/subsystem. Feel free to resend the above as v5 after testing on your hardware. At least it properly works now on all Exynos boards I have, both compiled into the kernel or as modules. >>> Thanks. I've seen the repo added on top of Dave patches - does it mean >>> these depends on Dave changes as well? >> Yes and no. My rework doesn't change anything with this dependency. It >> comes from my patch "drm: exynos: dsi: Restore proper bridge chain >> order" already included in your series (patch #1). Without it exynos-dsi >> driver hacks the list of bridges to ensure the order of pre_enable calls >> needed for proper operation. This works somehow with DSI panels on my >> test systems, but it has been reported that it doesn't work with a bit >> more complex display pipelines. Only that patch depends on the Dave's >> patches. If you remove it, you would need to adjust the code in the >> exynos_drm_dsi.c and samsung-dsim.c respectively. imho it would be >> better to keep it and merge Dave's patches together with dsi changes, as >> they are the first real client of it. > I think the Dave patches especially "drm/bridge: Introduce > pre_enable_upstream_first to alter bridge init order" seems not 100% > relevant to this series as they affect bridge chain call flow > globally. Having a separate series for that makes sense to me. I'm > sending v5 by excluding those parts. If so then drop the "drm: exynos: dsi: Restore proper bridge chain order" patch and adjust code respectively in samsung-dsim.c. Without the Dave's patches, that one doesn't make sense. >>> Doesn't it break Exynos? >> No it won't. Lack of the "drm: exynos: dsi: Restore proper bridge chain >> order" patch doesn't change much against the current state of the driver. >> >> Here is my rework of your v4 patchset without the mentioned patch and >> Dave's patches: >> >> https://protect2
Re: [PATCH v3 0/3] KUnit tests for RGB888, XRGB2101010 and grayscale
On Sun, Sep 18, 2022 at 01:26:06PM -0300, Maíra Canal wrote: > Hi Jose, > > On 9/18/22 10:22, José Expósito wrote: > > Hi! > > > > On Sun, Aug 28, 2022 at 06:45:14PM +0200, José Expósito wrote: > >> Hello everyone, > >> > >> This series is a follow up on my work adding KUnit test to the XRGB > >> conversion functions. This time RGB888, XRGB2101010 and gray8 are added. > >> > >> Best wishes, > >> Jose > >> > >> v1 -> v2: > >> > >> Tested-by: Maíra Canal > >> Reviewed-by: David Gow > >> > >> v2 -> v3: > >> > >> Export symbol drm_fb_xrgb_to_xrgb2101010() > > > > This patchset is being in the mailing list for a while. Unless someone > > has a reason to not merge it, I'd like to push it next week. > > I believe this patchset doesn't apply anymore due to this patch [1], > that applied a naming convention for the DRM tests. Maybe you could send > a v3 rebasing the patchset. > > [1] > https://lore.kernel.org/dri-devel/20220911191756.203118-1-mairaca...@riseup.net/T/#mb794103c8e39cdb76734f4e22ce90806f11d99bc > > Best Regards, > - Maíra Canal Thanks for the heads up Maíra, I didn't noticed that you patches were already merged. I'll rebase on top of your work and send v4. Best wishes, Jose > > > > Thanks, > > Jose > > > >> José Expósito (3): > >> drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb888() > >> drm/format-helper: Add KUnit tests for > >> drm_fb_xrgb_to_xrgb2101010() > >> drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_gray8() > >> > >> drivers/gpu/drm/drm_format_helper.c | 1 + > >> .../gpu/drm/tests/drm_format_helper_test.c| 190 ++ > >> 2 files changed, 191 insertions(+) > >> > >> > >> base-commit: 61a9fa154d217c13eea90aa5bc635bc4b1fcb66e > >> -- > >> 2.25.1 > >>
[PATCH v2] virtio-gpu: fix shift wrapping bug in virtio_gpu_fence_event_create()
The ->ring_idx_mask variable is a u64 so static checkers, Smatch in
this case, complain if the BIT() is not also a u64.
drivers/gpu/drm/virtio/virtgpu_ioctl.c:50 virtio_gpu_fence_event_create()
warn: should '(1 << ring_idx)' be a 64 bit type?
Fixes: cd7f5ca33585 ("drm/virtio: implement context init: add
virtio_gpu_fence_event")
Signed-off-by: Dan Carpenter
---
v2: Style change. Use BIT_ULL().
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 3b1701607aae..5d05093014ac 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -47,7 +47,7 @@ static int virtio_gpu_fence_event_create(struct drm_device
*dev,
struct virtio_gpu_fence_event *e = NULL;
int ret;
- if (!(vfpriv->ring_idx_mask & (1 << ring_idx)))
+ if (!(vfpriv->ring_idx_mask & BIT_ULL(ring_idx)))
return 0;
e = kzalloc(sizeof(*e), GFP_KERNEL);
--
2.35.1
RE: [Intel-gfx] [PATCH] drm/i915/mtl: Add MTL forcewake support
Reviewed-by: Harish Chegondi
-Original Message-
From: Intel-gfx On Behalf Of Matt
Roper
Sent: Friday, September 9, 2022 5:17 PM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915/mtl: Add MTL forcewake support
MTL has separate forcewake tables for the primary/render GT and the media GT;
each GT's intel_uncore will use a separate forcewake table and should only
initialize the domains that are relevant to that GT. The GT ack register also
moves to a new location of (GSI base + 0xDFC) on this platform.
Note that although our uncore handlers take care of transparently redirecting
all register accesses in the media GT's GSI range to their new offset at
0x38, the forcewake ranges listed in the table should use the final,
post-translation offsets.
NOTE: There are two ranges in the media IP that have multicast registers where
the two register instances reside in different power wells (either VD0 or VD2).
We don't have an easy way to deal with this today (and in fact we don't even
access these register ranges in the driver today), so for now we just mark
those ranges as FORCEWAKE_ALL which will cause all of the media power wells to
be grabbed, ensuring proper operation. If we start reading/writing in those
ranges in the future, we can re-visit whether it's worth adding extra steering
complexity into our forcewake support.
Bspec: 67788, 67789, 52077
Cc: Radhakrishna Sripada
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/intel_uncore.c | 258 +-
drivers/gpu/drm/i915/intel_uncore.h | 2 +
drivers/gpu/drm/i915/selftests/intel_uncore.c | 4 +
4 files changed, 258 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..1cbb7226400b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -39,6 +39,9 @@
#define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0xd84)
#define FORCEWAKE_ACK_MEDIA_GEN9 _MMIO(0xd88)
+#define FORCEWAKE_ACK_GSC _MMIO(0xdf8)
+#define FORCEWAKE_ACK_GT_MTL _MMIO(0xdfc)
+
#define MCFG_MCR_SELECTOR _MMIO(0xfd0)
#define SF_MCR_SELECTOR_MMIO(0xfd8)
#define GEN8_MCR_SELECTOR _MMIO(0xfdc)
@@ -898,6 +901,8 @@
#define FORCEWAKE_MEDIA_VDBOX_GEN11(n) _MMIO(0xa540 + (n) * 4)
#define FORCEWAKE_MEDIA_VEBOX_GEN11(n) _MMIO(0xa560 + (n) * 4)
+#define FORCEWAKE_REQ_GSC _MMIO(0xa618)
+
#define CHV_POWER_SS0_SIG1 _MMIO(0xa720)
#define CHV_POWER_SS0_SIG2 _MMIO(0xa724)
#define CHV_POWER_SS1_SIG1 _MMIO(0xa728)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 5cd423c7b646..c058cdc6d8a0 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -104,6 +104,7 @@ static const char * const forcewake_domain_names[] = {
"vebox1",
"vebox2",
"vebox3",
+ "gsc",
};
const char *
@@ -888,10 +889,13 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
spin_unlock_irq(&uncore->lock);
}
-/* We give fast paths for the really cool registers */
+/*
+ * We give fast paths for the really cool registers. The second range
+includes
+ * media domains (and the GSC starting from Xe_LPM+) */
#define NEEDS_FORCE_WAKE(reg) ({ \
u32 __reg = (reg); \
- __reg < 0x4 || __reg >= GEN11_BSD_RING_BASE; \
+ __reg < 0x4 || __reg >= 0x116000; \
})
static int fw_range_cmp(u32 offset, const struct intel_forcewake_range *entry)
@@ -1131,6 +1135,45 @@ static const struct i915_range pvc_shadowed_regs[] = {
{ .start = 0x1F8510, .end = 0x1F8550 }, };
+static const struct i915_range mtl_shadowed_regs[] = {
+ { .start = 0x2030, .end = 0x2030 },
+ { .start = 0x2510, .end = 0x2550 },
+ { .start = 0xA008, .end = 0xA00C },
+ { .start = 0xA188, .end = 0xA188 },
+ { .start = 0xA278, .end = 0xA278 },
+ { .start = 0xA540, .end = 0xA56C },
+ { .start = 0xC050, .end = 0xC050 },
+ { .start = 0xC340, .end = 0xC340 },
+ { .start = 0xC4C8, .end = 0xC4C8 },
+ { .start = 0xC4E0, .end = 0xC4E0 },
+ { .start = 0xC600, .end = 0xC600 },
+ { .start = 0xC658, .end = 0xC658 },
+ { .start = 0xCFD4, .end = 0xCFDC },
+ { .start = 0x22030, .end = 0x22030 },
+ { .start = 0x22510, .end = 0x22550 }, };
+
+static const struct i915_range xelpmp_shadowed_regs[] = {
+ { .start = 0x1C0030, .end = 0x1C0030 },
+ { .start = 0x1C0510, .end = 0x1C0550 },
+ { .start = 0x1C8030, .end = 0x1C8030 },
+ { .sta
Re: [PATCH] drm/panfrost: Give name to anonymous coredump object union
Hi Steven,
On 13.09.2022 09:45, Steven Price wrote:
>On 12/09/2022 17:44, Adrián Larumbe wrote:
>> Building Mesa's Perfetto requires including the panfrost drm uAPI header in
>> C++ code, but the C++ compiler requires anonymous unions to have only
>> public non-static data members.
>>
>> Commit 730c2bf4ad39 ("drm/panfrost: Add support for devcoredump")
>> introduces one such union, breaking the Mesa build.
>>
>> Give it a name, and also rename pan_reg_hdr structure because it will
>> always be prefixed by the union name.
>>
>> Bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7195
>>
>> Signed-off-by: Adrián Larumbe
>Ouch! It's frustrating how C++ isn't quite a superset of C. However I
>think we can solve this with a simpler patch, I'd appreciate testing
>that this does indeed fix the build issues with Mesa with all supported
>compilers (I'm not so familiar with C++):
I just tested your changes on Mesa and they do fix the build.
>8<
>From 492714a7dff0710ac5b8b457bcfe9ae52b458565 Mon Sep 17 00:00:00 2001
>From: Steven Price
>Date: Tue, 13 Sep 2022 09:37:55 +0100
>Subject: [PATCH] drm/panfrost: Remove type name from internal structs
>
>The two structs internal to struct panfrost_dump_object_header were
>named, but sadly that is incompatible with C++, causing an error: "an
>anonymous union may only have public non-static data members".
>
>However nothing refers to struct pan_reg_hdr and struct pan_bomap_hdr
>and there's no need to export these definitions, so lets drop them. This
>fixes the C++ build error with the minimum change in userspace API.
>
>Bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7195
>Fixes: 730c2bf4ad39 ("drm/panfrost: Add support for devcoredump")
>Signed-off-by: Steven Price
>---
> include/uapi/drm/panfrost_drm.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/include/uapi/drm/panfrost_drm.h
>b/include/uapi/drm/panfrost_drm.h
>index eac87310b348..bd77254be121 100644
>--- a/include/uapi/drm/panfrost_drm.h
>+++ b/include/uapi/drm/panfrost_drm.h
>@@ -242,7 +242,7 @@ struct panfrost_dump_object_header {
> __le32 file_offset;
>
> union {
>- struct pan_reg_hdr {
>+ struct {
> __le64 jc;
> __le32 gpu_id;
> __le32 major;
>@@ -250,7 +250,7 @@ struct panfrost_dump_object_header {
> __le64 nbos;
> } reghdr;
>
>- struct pan_bomap_hdr {
>+ struct {
> __le32 valid;
> __le64 iova;
> __le32 data[2];
>--
>2.34.1
Re: [PATCH] drm/amdgpu: use dirty framebuffer helper
Hi
Am 06.09.22 um 21:57 schrieb Hamza Mahfooz:
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
drm_atomic_helper_dirtyfb() creates a new atomic commit for the
frambuffer's planes. Drivers can then updates these planes' output
(e.g., writeback to video memory). I thought that amdgpu simply scans
out from the framebuffer's memory regions in VRAM. So I'm curious why
this patch is necessary.
Best regards
Thomas
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index c20922a5af9f..5b09c8f4fe95 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -496,6 +497,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
