[PATCH] dt-bindings: display: mediatek: dsi: Add compatible for MediaTek MT8188
From: xinlei lee Add dt-binding documentation of dpi for MediaTek MT8188 SoC. Signed-off-by: xinlei lee --- Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml index b18d6a5..9f996f6 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml @@ -29,6 +29,7 @@ properties: - mediatek,mt8173-dsi - mediatek,mt8183-dsi - mediatek,mt8186-dsi + - mediatek,mt8188-dsi reg: maxItems: 1 -- 2.6.4
Re: [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
On Thu, 22 Sep 2022 19:51:45 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 22 Sep 2022 00:13:00 -0700, Gupta, Anshuman wrote:
> >
>
> Hi Anshuman,
>
> > > +static ssize_t
> > > +hwm_power1_max_interval_store(struct device *dev,
> > > + struct device_attribute *attr,
> > > + const char *buf, size_t count)
> > > +{
> > > + struct hwm_drvdata *ddat = dev_get_drvdata(dev);
> > > + struct i915_hwmon *hwmon = ddat->hwmon;
> > > + long val, max_win, ret;
> > > + u32 x, y, rxy, x_w = 2; /* 2 bits */
> > > + u64 tau4, r;
> > > +
> > > +#define PKG_MAX_WIN_DEFAULT 0x12ull
> > > +
> > > + ret = kstrtoul(buf, 0, );
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /*
> > > + * val must be < max in hwmon interface units. The steps below are
> > > + * explained in i915_power1_max_interval_show()
> > > + */
> > > + r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
> >
> > AFAIU we need to read r from PACKAGE_POWER_SKU reg untill unless it has
> > some known issue?
>
> The platform on which I tried had an incorrect value (that is why I didn't
> read it from PACKAGE_POWER_SKU) but let me investigate it some more for
> other platforms and get back.
I checked, the value is correct on DG1/DG2 which have a valid
PACKAGE_POWER_SKU (XEHPSDV does not have a valid
PACKAGE_POWER_SKU). Therefore the one line above should be replaced with
the code below:
if (i915_mmio_reg_valid(hwmon->rg.pkg_power_sku))
with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
r = intel_uncore_read64(ddat->uncore,
hwmon->rg.pkg_power_sku);
else
r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
> > > + x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
> > > + y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
> > > + tau4 = ((1 << x_w) | x) << y;
> > > + max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
> > > +
> > > + if (val > max_win)
> > > + return -EINVAL;
> > > +
> > > + /* val in hw units */
> > > + val = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_time, SF_TIME);
> > > + /* Convert to 1.x * power(2,y) */
> > > + if (!val)
> > > + return -EINVAL;
> > > + y = ilog2(val);
> > > + /* x = (val - (1 << y)) >> (y - 2); */
> > > + x = (val - (1ul << y)) << x_w >> y;
> > > +
> > > + rxy = REG_FIELD_PREP(PKG_PWR_LIM_1_TIME_X, x) |
> > > REG_FIELD_PREP(PKG_PWR_LIM_1_TIME_Y, y);
> > > +
> > > + hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit,
> > > + PKG_PWR_LIM_1_TIME, rxy);
> > > + return count;
> > > +}
> > > +
> > /snip
> > > if (IS_ERR(hwmon_dev)) {
> > > mutex_destroy(>hwmon_lock);
> > > i915->hwmon = NULL;
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 956e5298ef1e..68e7cc85dc53 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -1811,6 +1811,9 @@
> > >* *_PACKAGE_POWER_SKU - SKU power and timing parameters.
> > >*/
> > > #define PKG_PKG_TDP GENMASK_ULL(14, 0)
> > > +#define PKG_MAX_WINGENMASK_ULL(54, 48)
> > > +#define PKG_MAX_WIN_XGENMASK_ULL(54, 53)
> > > +#define PKG_MAX_WIN_YGENMASK_ULL(52, 48)
> > These GENMASK fields needs a reg definition.
>
> Yes this is the same _PACKAGE_POWER_SKU register so should get fixed when
> we add it in Patch 3.
Looks like PCU_PACKAGE_POWER_SKU for DG1/DG2 will need to be declared in
intel_mchbar_regs.h so these fields will need to also move there (in
Patch 3).
Thanks.
--
Ashutosh
Re: [PATCH v1] drivers/amd/kv_dpm: check the return value of amdgpu_kv_smc_bapm_enable
On 9/23/2022 1:36 AM, Li Zhong wrote:
Check the return value of amdgpu_kv_smc_bapm_enable() and log the error
when it fails.
Signed-off-by: Li Zhong
---
drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
index 8fd0782a2b20..d392256effe2 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
@@ -1384,13 +1384,16 @@ static int kv_dpm_enable(struct amdgpu_device *adev)
static void kv_dpm_disable(struct amdgpu_device *adev)
{
struct kv_power_info *pi = kv_get_pi(adev);
+ int err;
amdgpu_irq_put(adev, >pm.dpm.thermal.irq,
AMDGPU_THERMAL_IRQ_LOW_TO_HIGH);
amdgpu_irq_put(adev, >pm.dpm.thermal.irq,
AMDGPU_THERMAL_IRQ_HIGH_TO_LOW);
- amdgpu_kv_smc_bapm_enable(adev, false);
+ err = amdgpu_kv_smc_bapm_enable(adev, false);
+ if (ret)
+ DRM_ERROR("amdgpu_kv_smc_bapm_enable failed\n");
Return code is captured in 'err' and check is for ret' variable.
BTW, does this code compile?
Thanks,
Lijo
if (adev->asic_type == CHIP_MULLINS)
kv_enable_nb_dpm(adev, false);
Re: [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
On Thu, 22 Sep 2022 00:13:00 -0700, Gupta, Anshuman wrote:
>
Hi Anshuman,
> > +static ssize_t
> > +hwm_power1_max_interval_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count)
> > +{
> > + struct hwm_drvdata *ddat = dev_get_drvdata(dev);
> > + struct i915_hwmon *hwmon = ddat->hwmon;
> > + long val, max_win, ret;
> > + u32 x, y, rxy, x_w = 2; /* 2 bits */
> > + u64 tau4, r;
> > +
> > +#define PKG_MAX_WIN_DEFAULT 0x12ull
> > +
> > + ret = kstrtoul(buf, 0, );
> > + if (ret)
> > + return ret;
> > +
> > + /*
> > +* val must be < max in hwmon interface units. The steps below are
> > +* explained in i915_power1_max_interval_show()
> > +*/
> > + r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
>
> AFAIU we need to read r from PACKAGE_POWER_SKU reg untill unless it has
> some known issue?
The platform on which I tried had an incorrect value (that is why I didn't
read it from PACKAGE_POWER_SKU) but let me investigate it some more for
other platforms and get back.
> > + x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
> > + y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
> > + tau4 = ((1 << x_w) | x) << y;
> > + max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
> > +
> > + if (val > max_win)
> > + return -EINVAL;
> > +
> > + /* val in hw units */
> > + val = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_time, SF_TIME);
> > + /* Convert to 1.x * power(2,y) */
> > + if (!val)
> > + return -EINVAL;
> > + y = ilog2(val);
> > + /* x = (val - (1 << y)) >> (y - 2); */
> > + x = (val - (1ul << y)) << x_w >> y;
> > +
> > + rxy = REG_FIELD_PREP(PKG_PWR_LIM_1_TIME_X, x) |
> > REG_FIELD_PREP(PKG_PWR_LIM_1_TIME_Y, y);
> > +
> > + hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit,
> > + PKG_PWR_LIM_1_TIME, rxy);
> > + return count;
> > +}
> > +
> /snip
> > if (IS_ERR(hwmon_dev)) {
> > mutex_destroy(>hwmon_lock);
> > i915->hwmon = NULL;
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 956e5298ef1e..68e7cc85dc53 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1811,6 +1811,9 @@
> >* *_PACKAGE_POWER_SKU - SKU power and timing parameters.
> >*/
> > #define PKG_PKG_TDP GENMASK_ULL(14, 0)
> > +#define PKG_MAX_WIN GENMASK_ULL(54, 48)
> > +#define PKG_MAX_WIN_X GENMASK_ULL(54, 53)
> > +#define PKG_MAX_WIN_Y GENMASK_ULL(52, 48)
> These GENMASK fields needs a reg definition.
Yes this is the same _PACKAGE_POWER_SKU register so should get fixed when
we add it in Patch 3.
Thanks.
--
Ashutosh
Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
On Thu, 22 Sep 2022 00:08:46 -0700, Gupta, Anshuman wrote:
>
Hi Anshuman,
> On 9/21/2022 8:23 PM, Nilawar, Badal wrote:
> >
> > On 21-09-2022 17:15, Gupta, Anshuman wrote:
> >>
> >>> +static int
> >>> +hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int chan, long *val)
> >>> +{
> >>> + struct i915_hwmon *hwmon = ddat->hwmon;
> >>> +
> >>> + switch (attr) {
> >>> + case hwmon_power_max:
> >>> + *val = hwm_field_read_and_scale(ddat,
> >>> + hwmon->rg.pkg_rapl_limit,
> >>> + PKG_PWR_LIM_1,
> >>> + hwmon->scl_shift_power,
> >>> + SF_POWER);
> >>> + return 0;
> >>> + case hwmon_power_rated_max:
> >>> + *val = hwm_field_read_and_scale(ddat,
> >>> + hwmon->rg.pkg_power_sku,
> >>> + PKG_PKG_TDP,It seems a dead code,
> >>> pkg_power_sky register in initialized with
> >> INVALID_MMMIO_REG, why are we exposing this, unless i am missing
> >> something ?
> > Agree that for platforms considered in this series does not support
> > hwmon_power_rated_max. In fact hwm_power_is_visible will not allow to
> > create sysfs entry if pkg_power_sku is not supported. Considering future
> > dgfx platforms we didn't remove this entry. In future for supported
> > platforms we just need to assign valid register to pkg_power_sku.
>
> AFAIU PACKAGE_POWER_SKU reg is valid for both DG1 and DG2 from BSpec:51862
> So we need to define the register.
> See once more comment below,
Thanks for pointing out, I didn't know where to look for it. We will add
it. Thanks to Badal for locating the register too.
> >
> > Regards,
> > Badal
> >> Br,
> >> Anshuman.
> >>> + hwmon->scl_shift_power,
> >>> + SF_POWER);
> >>> + return 0;
> >>> + default:
> >>> + return -EOPNOTSUPP;
> >>> + }
> >>> +}
> >>> +
> >>> +static int
> /snip
> >>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >>> b/drivers/gpu/drm/i915/i915_reg.h
> >>> index 1a9bd829fc7e..55c35903adca 100644
> >>> --- a/drivers/gpu/drm/i915/i915_reg.h
> >>> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >>> @@ -1807,6 +1807,11 @@
> >>> #define POWER_LIMIT_1_MASK REG_BIT(10)
> >>> #define POWER_LIMIT_2_MASK REG_BIT(11)
> >>> +/*
> >>> + * *_PACKAGE_POWER_SKU - SKU power and timing parameters.
> >>> + */
> >>> +#define PKG_PKG_TDP GENMASK_ULL(14, 0)
> Define register above this definition, GENMASK should follow
> by a register.
Will do.
Thanks.
--
Ashutosh
[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216516 --- Comment #1 from kolAflash (kolafl...@kolahilft.de) --- Created attachment 301849 --> https://bugzilla.kernel.org/attachment.cgi?id=301849=edit kernel log: v5.18-rc7 and v5.18-rc7-1-g7123d39dc24d -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216516] New: s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216516 Bug ID: 216516 Summary: s2ram freezes screen (Ryzen-5650U incl. Radeon GPU) Product: Drivers Version: 2.5 Kernel Version: 6.0-rc6 Hardware: AMD OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: kolafl...@kolahilft.de Regression: No Beginning with this commit (regression) s2ram freezes the screen and I have to restart the XServer. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7123d39dc24dcd21ff23d75f46f926b15269b9da git describe: 5.18-rc7-1-g7123d39dc24d s2ram => systemctl start suspend.target Before v5.18-rc7 the system sometimes stays awake instead of entering S3 sleep. But in that case the system keeps running stable and the screen doesn't freeze. And on the second try the system then successfully enters S3. You can see this behaviour in the attached linux-v5.18-rc7.txt for 5.18.0-rc7-v5.18-rc7. This "stays awake" behaviour is probably a bug on it's own. (I may may open another bug report when this one is solved) Later on in the attached linux-v5.18-rc7.txt you'll see how 5.18.0-rc7-v5.18-rc7-1-g7123d39dc24d behaves when the screen is getting frozen. Reverting commit 7123d39dc on v5.19.10 or v6.0-rc7 makes the problem disappear. = System = Model: HP EliteBook 845 G8 (notebook) CPU+GPU: Ryzen 5650U incl. Radeon GPU OS: openSUSE-15.4 The HP EliteBook 845 G8 uses s0ix/s2idle by default. But I changed the ACPI BIOS settings to enable classic S3 s2ram. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 01/12] slab: Introduce kmalloc_size_roundup()
Thanks Hyeonggon for looping in me. On Thu, Sep 22, 2022 at 07:12:21PM +0800, Hyeonggon Yoo wrote: > On Wed, Sep 21, 2022 at 08:10:02PM -0700, Kees Cook wrote: > > In the effort to help the compiler reason about buffer sizes, the > > __alloc_size attribute was added to allocators. This improves the scope > > of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near > > future) CONFIG_FORTIFY_SOURCE. For most allocations, this works well, > > as the vast majority of callers are not expecting to use more memory > > than what they asked for. > > > > There is, however, one common exception to this: anticipatory resizing > > of kmalloc allocations. These cases all use ksize() to determine the > > actual bucket size of a given allocation (e.g. 128 when 126 was asked > > for). This comes in two styles in the kernel: > > > > 1) An allocation has been determined to be too small, and needs to be > >resized. Instead of the caller choosing its own next best size, it > >wants to minimize the number of calls to krealloc(), so it just uses > >ksize() plus some additional bytes, forcing the realloc into the next > >bucket size, from which it can learn how large it is now. For example: > > > > data = krealloc(data, ksize(data) + 1, gfp); > > data_len = ksize(data); > > > > 2) The minimum size of an allocation is calculated, but since it may > >grow in the future, just use all the space available in the chosen > >bucket immediately, to avoid needing to reallocate later. A good > >example of this is skbuff's allocators: > > > > data = kmalloc_reserve(size, gfp_mask, node, ); > > ... > > /* kmalloc(size) might give us more room than requested. > > * Put skb_shared_info exactly at the end of allocated zone, > > * to allow max possible filling before reallocation. > > */ > > osize = ksize(data); > > size = SKB_WITH_OVERHEAD(osize); > > > > In both cases, the "how large is the allocation?" question is answered > > _after_ the allocation, where the compiler hinting is not in an easy place > > to make the association any more. This mismatch between the compiler's > > view of the buffer length and the code's intention about how much it is > > going to actually use has already caused problems[1]. It is possible to > > fix this by reordering the use of the "actual size" information. > > > > We can serve the needs of users of ksize() and still have accurate buffer > > length hinting for the compiler by doing the bucket size calculation > > _before_ the allocation. Code can instead ask "how large an allocation > > would I get for a given size?". > > > > Introduce kmalloc_size_roundup(), to serve this function so we can start > > replacing the "anticipatory resizing" uses of ksize(). > > > > Cc-ing Feng Tang who may welcome this series ;) Indeed! This will help our work of extending slub redzone check, as we also ran into some trouble with ksize() users when extending the redzone support to this extra allocated space than requested size [1], and have to disable the redzone sanity for all ksize() users [2]. [1]. https://lore.kernel.org/lkml/20220719134503.ga56...@shbuild999.sh.intel.com/ [2]. https://lore.kernel.org/lkml/20220913065423.520159-5-feng.t...@intel.com/ Thanks, Feng > > [1] https://github.com/ClangBuiltLinux/linux/issues/1599 > > https://github.com/KSPP/linux/issues/183 > > > > Cc: Vlastimil Babka > > Cc: Pekka Enberg > > Cc: David Rientjes > > Cc: Joonsoo Kim > > Cc: Andrew Morton > > Cc: linux...@kvack.org > > Signed-off-by: Kees Cook > > ---
[GIT PULL] mediatek drm next for 6.1
Hi, Dave & Daniel: This includes: 1. Drop of_gpio header 2. Remove the unneeded result Regards, Chun-Kuang. The following changes since commit 568035b01cfb107af8d2e4bd2fb9aea22cf5b868: Linux 6.0-rc1 (2022-08-14 15:50:18 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-next-6.1 for you to fetch changes up to 9d3feb63339520462583a4c7ee5130046ab515ad: drm/mediatek: Remove the unneeded result (2022-08-26 07:34:49 +0800) Mediatek DRM Next for Linux 6.1 1. Drop of_gpio header 2. Remove the unneeded result Maíra Canal (1): drm/mediatek: Drop of_gpio header ye xingchen (1): drm/mediatek: Remove the unneeded result drivers/gpu/drm/mediatek/mtk_dpi.c | 1 - drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 + drivers/gpu/drm/mediatek/mtk_hdmi.c| 1 - 3 files changed, 1 insertion(+), 6 deletions(-)
[PATCH] drm/bridge: anx7625: Notify audio framework of connector status changes
We already have anx7625_audio_update_connector_status() to notify the
audio framework when HDMI is (dis)connected, but up until now this
function was only called during the callback setup. Add a call for it
to the HPD change handling logic.
A couple functions needed to be hoisted as part of this.
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 48 ---
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index b0ff1ecb80a5..da54d6a61e07 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1588,6 +1588,29 @@ static int anx7625_hpd_change_detect(struct anx7625_data
*ctx)
return 0;
}
+static void
+anx7625_audio_update_connector_status(struct anx7625_data *ctx,
+ enum drm_connector_status status)
+{
+ if (ctx->plugged_cb && ctx->codec_dev) {
+ ctx->plugged_cb(ctx->codec_dev,
+ status == connector_status_connected);
+ }
+}
+
+static enum drm_connector_status anx7625_sink_detect(struct anx7625_data *ctx)
+{
+ struct device *dev = >client->dev;
+
+ DRM_DEV_DEBUG_DRIVER(dev, "sink detect\n");
+
+ if (ctx->pdata.panel_bridge)
+ return connector_status_connected;
+
+ return ctx->hpd_status ? connector_status_connected :
+connector_status_disconnected;
+}
+
static void anx7625_work_func(struct work_struct *work)
{
int event;
@@ -1603,6 +1626,8 @@ static void anx7625_work_func(struct work_struct *work)
if (event < 0)
goto unlock;
+ anx7625_audio_update_connector_status(ctx, anx7625_sink_detect(ctx));
+
if (ctx->bridge_attached)
drm_helper_hpd_irq_event(ctx->bridge.dev);
@@ -1790,19 +1815,6 @@ static struct edid *anx7625_get_edid(struct anx7625_data
*ctx)
return (struct edid *)edid;
}
-static enum drm_connector_status anx7625_sink_detect(struct anx7625_data *ctx)
-{
- struct device *dev = >client->dev;
-
- DRM_DEV_DEBUG_DRIVER(dev, "sink detect\n");
-
- if (ctx->pdata.panel_bridge)
- return connector_status_connected;
-
- return ctx->hpd_status ? connector_status_connected :
-connector_status_disconnected;
-}
-
static int anx7625_audio_hw_params(struct device *dev, void *data,
struct hdmi_codec_daifmt *fmt,
struct hdmi_codec_params *params)
@@ -1951,16 +1963,6 @@ static int anx7625_hdmi_i2s_get_dai_id(struct
snd_soc_component *component,
return 0;
}
-static void
-anx7625_audio_update_connector_status(struct anx7625_data *ctx,
- enum drm_connector_status status)
-{
- if (ctx->plugged_cb && ctx->codec_dev) {
- ctx->plugged_cb(ctx->codec_dev,
- status == connector_status_connected);
- }
-}
-
static int anx7625_audio_hook_plugged_cb(struct device *dev, void *data,
hdmi_codec_plugged_cb fn,
struct device *codec_dev)
--
2.37.3
Re: [BUG] ls1046a: eDMA does not transfer data from I2C
On 9/20/22 7:05 PM, Sean Anderson wrote: > > > On 9/20/22 6:49 PM, Leo Li wrote: >> >> >>> -Original Message- >>> From: Sean Anderson >>> Sent: Tuesday, September 20, 2022 11:21 AM >>> To: Robin Murphy ; Oleksij Rempel >>> ; Pengutronix Kernel Team >>> ; linux-...@vger.kernel.org; linux-arm-kernel >>> ; Vinod Koul ; >>> dmaeng...@vger.kernel.org; Leo Li ; Laurentiu Tudor >>> >>> Cc: Linux Kernel Mailing List ; dri- >>> de...@lists.freedesktop.org; Christian König ; >>> linaro-mm-...@lists.linaro.org; Shawn Guo ; Sumit >>> Semwal ; Joy Zou ; linux- >>> me...@vger.kernel.org >>> Subject: Re: [BUG] ls1046a: eDMA does not transfer data from I2C >>> >>> >>> >>> On 9/20/22 11:44 AM, Sean Anderson wrote: >>> > >>> > >>> > On 9/20/22 11:24 AM, Sean Anderson wrote: >>> >> >>> >> >>> >> On 9/20/22 6:07 AM, Robin Murphy wrote: >>> >>> On 2022-09-19 23:24, Sean Anderson wrote: >>> Hi all, >>> >>> I discovered a bug in either imx_i2c or fsl-edma on the LS1046A >>> where no data is read in i2c_imx_dma_read except for the last two >>> bytes (which are not read using DMA). This is perhaps best >>> illustrated with the following example: >>> >>> # hexdump -C /sys/bus/nvmem/devices/0-00540/nvmem >>> [ 308.914884] i2c i2c-0: 00080938 0x00088938 >>> 0xf5401000 75401000 >>> [ 308.923529] src= 2180004 dst=f5401000 attr= 0 soff= 0 nbytes=1 >>> slast= 0 >>> [ 308.923529] citer= 7e biter= 7e doff= 1 dlast_sga= 0 >>> [ 308.923529] major_int=1 disable_req=1 enable_sg=0 [ 308.942113] >>> fsl-edma 2c0.edma: vchan 1b4371fc: txd >>> d9dd26c5[4]: submitted [ 308.974049] fsl-edma >>> 2c0.edma: txd d9dd26c5[4]: marked complete [ >>> 308.981339] i2c i2c-0: 00080938 = [2e 2e 2f 2e 2e 2f 2e 2e >>> 2f 64 65 76 69 63 65 73 2f 70 6c 61 74 66 6f 72 6d 2f 73 6f 63 2f 32 >>> 31 38 30 >>> 30 30 30 2e 69 32 63 2f 69 32 63 2d 30 2f 30 2d 30 30 35 34 2f 30 2d 30 30 >>> 35 34 >>> 30 00 00] [ 309.002226] i2c i2c-0: 75401000 = [2e 2e 2f 2e 2e 2f >>> 2e 2e 2f >>> 64 65 76 69 63 65 73 2f 70 6c 61 74 66 6f 72 6d 2f 73 6f 63 2f 32 31 38 30 >>> 30 30 30 >>> 2e 69 32 63 2f 69 32 63 2d 30 2f 30 2d 30 30 35 34 2f 30 2d 30 30 35 34 30 >>> 00 00] >>> [ 309.024649] i2c i2c-0: 000809380080 0x000889380080 >>> 0xf5401800 75401800 >>> [ 309.033270] src= 2180004 dst=f5401800 attr= 0 soff= 0 nbytes=1 >>> slast= 0 >>> [ 309.033270] citer= 7e biter= 7e doff= 1 dlast_sga= 0 >>> [ 309.033270] major_int=1 disable_req=1 enable_sg=0 [ 309.051633] >>> fsl-edma 2c0.edma: vchan 1b4371fc: txd >>> d9dd26c5[5]: submitted [ 309.083526] fsl-edma >>> 2c0.edma: txd d9dd26c5[5]: marked complete [ >>> 309.090807] i2c i2c-0: 000809380080 = [00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00] [ 309.111694] i2c i2c-0: >>> 75401800 = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00] >>> 2e 2e 2f 2e 2e 2f 2e 2e 2f 64 65 76 69 63 65 73 >>> |../../../devices| >>> 0010 2f 70 6c 61 74 66 6f 72 6d 2f 73 6f 63 2f 32 31 >>> |/platform/soc/21| >>> 0020 38 30 30 30 30 2e 69 32 63 2f 69 32 63 2d 30 2f >>> |8.i2c/i2c-0/| >>> 0030 30 2d 30 30 35 34 2f 30 2d 30 30 35 34 30 00 00 >>> |0-0054/0-00540..| >>> 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> || >>> * >>> 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff >>> || >>> 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> || >>> * >>> 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 5b >>> |...[| >>> 0100 >>> >>> (patch with my debug prints appended below) >>> >>> Despite the DMA completing successfully, no data was copied into >>> the buffer, leaving the original (now junk) contents. I probed the >>> I2C bus with an oscilloscope, and I verified that the transfer did >>> indeed >>> occur. >>> The timing between submission and completion seems reasonable for >>> the bus speed (50 kHz for whatever reason). >>> >>> I had a look over the I2C driver, and nothing looked obviously >>> incorrect. If anyone has ideas on what to try, I'm more than willing. >>> >>> >>> >>> Is the DMA controller cache-coherent? I see the mainline LS1046A DT >>> doesn't have a "dma-coherent" property for it,
RE: [PATCH] drm/hyperv: Don't overwrite dirt_needed value set by host
From: Saurabh Sengar Sent: Monday, September 12, 2022 8:33 AM > > Existing code is causing a race condition where dirt_needed value is > already set by the host and gets overwritten with default value. Remove > this default setting of dirt_needed, to avoid overwriting the value > received in the channel callback set by vmbus_open. Removing this > setting also means the default value for dirt_needed is changed to false > as it's allocated by kzalloc which is similar to legacy hyperv_fb driver. > > Signed-off-by: Saurabh Sengar > --- > drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > index 4a8941fa0815..57d49a08b37f 100644 > --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > @@ -198,8 +198,6 @@ static int hyperv_vmbus_probe(struct hv_device *hdev, > if (ret) > drm_warn(dev, "Failed to update vram location.\n"); > > - hv->dirt_needed = true; > - > ret = hyperv_mode_config_init(hv); > if (ret) > goto err_vmbus_close; > -- > 2.31.1 Reviewed-by: Michael Kelley
[PATCH 6/7] drm/i915/guc: define media GT GuC send regs
The media GT shares the G-unit with the root GT, so a second set of
communication registers is required for the media GuC.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 14 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index bac06e3d6f2c..b0beab44b34c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -156,7 +156,8 @@ static void gen11_disable_guc_interrupts(struct intel_guc
*guc)
void intel_guc_init_early(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct drm_i915_private *i915 = gt->i915;
intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC);
intel_guc_ct_init_early(>ct);
@@ -168,12 +169,17 @@ void intel_guc_init_early(struct intel_guc *guc)
mutex_init(>send_mutex);
spin_lock_init(>irq_lock);
if (GRAPHICS_VER(i915) >= 11) {
- guc->notify_reg = GEN11_GUC_HOST_INTERRUPT;
guc->interrupts.reset = gen11_reset_guc_interrupts;
guc->interrupts.enable = gen11_enable_guc_interrupts;
guc->interrupts.disable = gen11_disable_guc_interrupts;
- guc->send_regs.base =
- i915_mmio_reg_offset(GEN11_SOFT_SCRATCH(0));
+ if (gt->type == GT_MEDIA) {
+ guc->notify_reg = MEDIA_GUC_HOST_INTERRUPT;
+ guc->send_regs.base =
i915_mmio_reg_offset(MEDIA_SOFT_SCRATCH(0));
+ } else {
+ guc->notify_reg = GEN11_GUC_HOST_INTERRUPT;
+ guc->send_regs.base =
i915_mmio_reg_offset(GEN11_SOFT_SCRATCH(0));
+ }
+
guc->send_regs.count = GEN11_SOFT_SCRATCH_COUNT;
} else {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
index a7092f711e9c..9915de32e894 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
@@ -36,6 +36,7 @@
#define SOFT_SCRATCH_COUNT 16
#define GEN11_SOFT_SCRATCH(n) _MMIO(0x190240 + (n) * 4)
+#define MEDIA_SOFT_SCRATCH(n) _MMIO(0x190310 + (n) * 4)
#define GEN11_SOFT_SCRATCH_COUNT 4
#define UOS_RSA_SCRATCH(i) _MMIO(0xc200 + (i) * 4)
@@ -101,6 +102,7 @@
#define GUC_SEND_INTERRUPT _MMIO(0xc4c8)
#define GUC_SEND_TRIGGER (1<<0)
#define GEN11_GUC_HOST_INTERRUPT _MMIO(0x1901f0)
+#define MEDIA_GUC_HOST_INTERRUPT _MMIO(0x190304)
#define GEN12_GUC_SEM_INTR_ENABLES _MMIO(0xc71c)
#define GUC_SEM_INTR_ROUTE_TO_GUCBIT(31)
--
2.37.3
[PATCH 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just check for that and it is easier to
instead check for the lack of VCS engines.
Based on code from Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
drivers/gpu/drm/i915/i915_drv.h| 9 ++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..d4e2b252f16c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -42,12 +42,33 @@
* HuC-specific commands.
*/
+static bool vcs_supported(struct intel_gt *gt)
+{
+ intel_engine_mask_t mask = gt->info.engine_mask;
+
+ /*
+* we can reach here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence fall back to the device info's
+* engine mask
+*/
+ if (!mask && gt_is_root(gt))
+ mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
+
+ return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
+}
+
void intel_huc_init_early(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
+ struct intel_gt *gt = huc_to_gt(huc);
intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC);
+ if (!vcs_supported(gt)) {
+ intel_uc_fw_change_status(>fw,
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+ return;
+ }
+
if (GRAPHICS_VER(i915) >= 11) {
huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
huc->status.mask = HUC_LOAD_SUCCESSFUL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 134fc1621821..8ca575202e5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,12 +777,15 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
#define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
-#define ENGINE_INSTANCES_MASK(gt, first, count) ({ \
+#define __ENGINE_INSTANCES_MASK(mask, first, count) ({ \
unsigned int first__ = (first); \
unsigned int count__ = (count); \
- ((gt)->info.engine_mask &
\
-GENMASK(first__ + count__ - 1, first__)) >> first__; \
+ ((mask) & GENMASK(first__ + count__ - 1, first__)) >> first__; \
})
+
+#define ENGINE_INSTANCES_MASK(gt, first, count) \
+ __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
+
#define RCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
#define BCS_MASK(gt) \
--
2.37.3
[PATCH 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.
From: Aravind Iddamsetty
With MTL standalone media architecture the wopcm layout has changed with
separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size
of WOPCM is 4MB with lower 2MB for SA Media and upper 2MB for GCD/GT.
+=+===> ++ <== WOPCM TOP
^ ^ ||
| | ||
|GCD| GCD RC6 Image|
|GuC|Power Context |
|WOPCM ||
|Size ++
| | | GCD GuC Image|
| | ||
| v ||
| +===> ++ <== SA Media GuC WOPCM Top
| ^ ||
| SA Media||
|GuC| SA Media RC6 Image |
| WOPCM |Power Context |
|Size ||
WOPCM | ++
| | ||
| | | SA Media GuC Image |
| v ||
| +===> ++ <== GuC WOPCM base
| | WOPCM RSVD |
| +--- + <== HuC Firmware Top
v | HuC FW|
+=> ++ <== WOPCM Base
Given that MTL has GuC deprivilege, the WOPCM registers are pre-locked
by the bios. Therefore, we can skip all the math for the partitioning
and just limit ourselves to sanity checking the values.
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 7 +--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 48 +++--
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h | 0
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 14 +++---
drivers/gpu/drm/i915/i915_driver.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 3 --
drivers/gpu/drm/i915/i915_gem.c | 5 ++-
11 files changed, 56 insertions(+), 32 deletions(-)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (86%)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..6ed4c745b226 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -129,7 +129,9 @@ gt-y += \
gt/intel_timeline.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
- gt/sysfs_engines.o
+ gt/sysfs_engines.o \
+ gt/intel_wopcm.o
+
# x86 intel-gtt module support
gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
# autogenerated null render state
@@ -183,8 +185,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
- i915_vma_resource.o \
- intel_wopcm.o
+ i915_vma_resource.o
# general-purpose microcontroller (GuC) support
i915-y += gt/uc/intel_uc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 30cf5c3369d9..605e1aa674d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -560,7 +560,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* why.
*/
ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
- intel_wopcm_guc_size(>vm.i915->wopcm));
+ intel_wopcm_guc_size(>vm.gt->wopcm));
ret = intel_vgt_balloon(ggtt);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b367cfff48d5..a95eb0b656d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -56,6 +56,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
intel_gt_pm_init_early(gt);
+ intel_wopcm_init_early(>wopcm);
intel_uc_init_early(>uc);
intel_rps_init_early(>rps);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f19c2de77ff6..c20a32d2700f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -30,6 +30,7 @@
#include "intel_migrate_types.h"
#include "intel_wakeref.h"
#include "pxp/intel_pxp_types.h"
+#include "intel_wopcm.h"
struct drm_i915_private;
struct i915_ggtt;
@@ -97,6 +98,7 @@ struct intel_gt {
struct intel_uc uc;
struct intel_gsc gsc;
+ struct intel_wopcm wopcm;
struct {
/* Serialize global tlb invalidations */
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/gt/intel_wopcm.c
similarity index 86%
[PATCH 4/7] drm/i915/guc: Add GuC deprivilege feature to MTL
From: Stuart Summers
MTL supports GuC deprivilege. Add the feature flag to this platform.
Signed-off-by: Stuart Summers
Cc: Radhakrishna Sripada
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..b1b720870da8 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1143,6 +1143,7 @@ static const struct intel_device_info mtl_info = {
.display.has_modular_fia = 1,
.extra_gt_list = xelpmp_extra_gt,
.has_flat_ccs = 0,
+ .has_guc_deprivilege = 1,
.has_snoop = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
--
2.37.3
[PATCH 2/7] drm/i915/uc: fetch uc firmwares for each GT
The FW binaries are independently loaded on each GT. On MTL, the memory is shared so we could potentially re-use a single allocation, but on discrete multi-gt platforms we are going to need independent copies, so it is easier to do the same on MTL as well, given that the amount of duplicated memory is relatively small (~500K). Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: Alan Previn --- drivers/gpu/drm/i915/i915_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 88df9a35e0fe..a5b192ac885c 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1140,7 +1140,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv) if (ret) return ret; - intel_uc_fetch_firmwares(_gt(dev_priv)->uc); + for_each_gt(gt, dev_priv, i) + intel_uc_fetch_firmwares(>uc); intel_wopcm_init(_priv->wopcm); ret = i915_init_ggtt(dev_priv); -- 2.37.3
[PATCH 3/7] drm/i915/uc: use different ggtt pin offsets for uc loads
Our current FW loading process is the same for all FWs:
- Pin FW to GGTT at the start of the ggtt->uc_fw node
- Load the FW
- Unpin
This worked because we didn't have a case where 2 FWs would be loaded on
the same GGTT at the same time. On MTL, however, this can happend if both
GTs are reset at the same time, so we can't pin everything in the same
spot and we need to use separate offset. For simplicity, instead of
calculating the exact required size, we reserve a 2MB slot for each fw.
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index b91ad4aede1f..d6ca772e9f4b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -666,16 +666,33 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
return err;
}
+/*
+ * The reserved GGTT space is ~18 MBs. All our blobs are well below 1MB, so for
+ * safety we reserve 2MB each.
+ */
+#define INTEL_UC_RSVD_GGTT_PER_FW SZ_2M
static u32 uc_fw_ggtt_offset(struct intel_uc_fw *uc_fw)
{
- struct i915_ggtt *ggtt = __uc_fw_to_gt(uc_fw)->ggtt;
+ struct intel_gt *gt = __uc_fw_to_gt(uc_fw);
+ struct i915_ggtt *ggtt = gt->ggtt;
struct drm_mm_node *node = >uc_fw;
+ u32 offset = uc_fw->type * INTEL_UC_RSVD_GGTT_PER_FW;
+
+ /*
+* To keep the math simple, we use 8MB for the root tile and 8MB for
+* the media one.
+*/
+ BUILD_BUG_ON(INTEL_UC_FW_NUM_TYPES * INTEL_UC_RSVD_GGTT_PER_FW > SZ_8M);
+ if (gt->type == GT_MEDIA)
+ offset += SZ_8M;
GEM_BUG_ON(!drm_mm_node_allocated(node));
GEM_BUG_ON(upper_32_bits(node->start));
GEM_BUG_ON(upper_32_bits(node->start + node->size - 1));
+ GEM_BUG_ON(offset + uc_fw->obj->base.size > node->size);
+ GEM_BUG_ON(uc_fw->obj->base.size > INTEL_UC_RSVD_GGTT_PER_FW);
- return lower_32_bits(node->start);
+ return lower_32_bits(node->start + offset);
}
static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
@@ -690,7 +707,6 @@ static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
dummy->bi.pages = obj->mm.pages;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
- GEM_BUG_ON(dummy->node_size > ggtt->uc_fw.size);
/* uc_fw->obj cache domains were not controlled across suspend */
if (i915_gem_object_has_struct_page(obj))
--
2.37.3
[PATCH 7/7] drm/i915/guc: handle interrupts from media GuC
The render and media GuCs share the same interrupt enable register, so
we can no longer disable interrupts when we disable communication for
one of the GuCs as this would impact the other GuC. Instead, we keep the
interrupts always enabled in HW and use a variable in the GuC structure
to determine if we want to service the received interrupts or not.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 21 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 29 ++---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5 -
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +--
5 files changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f26882fdc24c..e33ed9ae1439 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -17,6 +17,9 @@
static void guc_irq_handler(struct intel_guc *guc, u16 iir)
{
+ if (unlikely(!guc->interrupts.enabled))
+ return;
+
if (iir & GUC_INTR_GUC2HOST)
intel_guc_to_host_event_handler(guc);
}
@@ -249,6 +252,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
{
struct intel_uncore *uncore = gt->uncore;
u32 irqs = GT_RENDER_USER_INTERRUPT;
+ u32 guc_mask = intel_uc_wants_guc(>uc) ? GUC_INTR_GUC2HOST : 0;
const u32 gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
u32 dmask;
u32 smask;
@@ -299,6 +303,19 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
if (HAS_HECI_GSC(gt->i915))
intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_MASK,
~gsc_mask);
+ if (guc_mask) {
+ /* the enable bit is common for both GTs but the masks are
separate */
+ u32 mask = gt->type == GT_MEDIA ?
+ REG_FIELD_PREP(ENGINE0_MASK, guc_mask) :
+ REG_FIELD_PREP(ENGINE1_MASK, guc_mask);
+
+ intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE,
+ REG_FIELD_PREP(ENGINE1_MASK, guc_mask));
+
+ /* we might not be the first GT to write this reg */
+ intel_uncore_rmw(uncore, GEN12_GUC_MGUC_INTR_MASK, mask, 0);
+ }
+
/*
* RPS interrupts will get enabled/disabled on demand when RPS itself
* is enabled/disabled.
@@ -307,10 +324,6 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
gt->pm_imr = ~gt->pm_ier;
intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
-
- /* Same thing for GuC interrupts */
- intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
- intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK, ~0);
}
void gen5_gt_irq_handler(struct intel_gt *gt, u32 gt_iir)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 1cbb7226400b..792809e49680 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1519,6 +1519,7 @@
#define GEN11_CSME (31)
#define GEN11_GUNIT (28)
#define GEN11_GUC(25)
+#define GEN12_GUCM (24)
#define GEN11_WDPERF (20)
#define GEN11_KCR(19)
#define GEN11_GTPM (16)
@@ -1573,6 +1574,7 @@
#define GEN11_VECS0_VECS1_INTR_MASK_MMIO(0x1900d0)
#define GEN12_VECS2_VECS3_INTR_MASK_MMIO(0x1900d4)
#define GEN11_GUC_SG_INTR_MASK _MMIO(0x1900e8)
+#define GEN12_GUC_MGUC_INTR_MASK _MMIO(0x1900e8) /* MTL+ */
#define GEN11_GPM_WGBOXPERF_INTR_MASK _MMIO(0x1900ec)
#define GEN11_CRYPTO_RSVD_INTR_MASK_MMIO(0x1900f0)
#define GEN11_GUNIT_CSME_INTR_MASK _MMIO(0x1900f4)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index b0beab44b34c..ab0263d8e1cf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -98,6 +98,8 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
gt->pm_guc_events);
gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
spin_unlock_irq(gt->irq_lock);
+
+ guc->interrupts.enabled = true;
}
static void gen9_disable_guc_interrupts(struct intel_guc *guc)
@@ -105,6 +107,7 @@ static void gen9_disable_guc_interrupts(struct intel_guc
*guc)
struct intel_gt *gt = guc_to_gt(guc);
assert_rpm_wakelock_held(>i915->runtime_pm);
+ guc->interrupts.enabled = false;
spin_lock_irq(gt->irq_lock);
@@ -116,39 +119,39 @@ static void
[PATCH 0/7] drm/i915: prepare for uC loading on MTL
The introduction of the media GT brings a few changes for GuC/HuC. The
main difference between the 2 GTs is that only the media one has the
HuC, while both have the GuC. Also, the fact that both GTs use the same
G-unit and GGTT means we now have parallel interrupt/communication
paths. Lastly, WOPCM is divided between the two GTs, with each having
their own private chunk.
Cc: Matt Roper
Cc: John Harrison
Cc: Alan Previn
Cc: Aravind Iddamsetty
Cc: Radhakrishna Sripada
Aravind Iddamsetty (1):
drm/i915/mtl: Handle wopcm per-GT and limit calculations.
Daniele Ceraolo Spurio (5):
drm/i915/huc: only load HuC on GTs that have VCS engines
drm/i915/uc: fetch uc firmwares for each GT
drm/i915/uc: use different ggtt pin offsets for uc loads
drm/i915/guc: define media GT GuC send regs
drm/i915/guc: handle interrupts from media GuC
Stuart Summers (1):
drm/i915/guc: Add GuC deprivilege feature to MTL
drivers/gpu/drm/i915/Makefile | 7 +--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 21 +++--
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 48 +++--
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h | 0
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 43 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 12 --
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 36
drivers/gpu/drm/i915/i915_driver.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 12 +++---
drivers/gpu/drm/i915/i915_gem.c | 6 ++-
drivers/gpu/drm/i915/i915_pci.c | 1 +
18 files changed, 161 insertions(+), 62 deletions(-)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (86%)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)
--
2.37.3
Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup()
On Thu, Sep 22, 2022 at 11:05:47PM +0200, Vlastimil Babka wrote: > On 9/22/22 17:55, Kees Cook wrote: > > On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote: > > [...] > > > So when this patch set is about to clean up this use case it should > > > probably > > > also take care to remove ksize() or at least limit it so that it won't be > > > used for this use case in the future. > > > > Yeah, my goal would be to eliminate ksize(), and it seems possible if > > other cases are satisfied with tracking their allocation sizes directly. > > I think we could leave ksize() to determine the size without a need for > external tracking, but from now on forbid callers from using that hint to > overflow the allocation size they actually requested? Once we remove the > kasan/kfence hooks in ksize() that make the current kinds of usage possible, > we should be able to catch any offenders of the new semantics that would > appear? That's correct. I spent the morning working my way through the rest of the ksize() users I didn't clean up yesterday, and in several places I just swapped in __ksize(). But that wouldn't even be needed if we just removed the kasan unpoisoning from ksize(), etc. I am tempted to leave it __ksize(), though, just to reinforce that it's not supposed to be used "normally". What do you think? -- Kees Cook
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Enable compute scheduling on DG2
On Thu, Sep 22, 2022 at 01:12:09PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
DG2 has issues. To work around one of these the GuC must schedule
apps in an exclusive manner across both RCS and CCS. That is, if a
context from app X is running on RCS then all CCS engines must sit
idle even if there are contexts from apps Y, Z, ... waiting to run. A
certain OS favours RCS to the total starvation of CCS. Linux does not.
Hence the GuC now has a scheduling policy setting to control this
abitration.
Signed-off-by: John Harrison
lgtm,
Reviewed-by: Umesh Nerlige Ramappa
Regards,
Umesh
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 9 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 22 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 93 +++
4 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 29ef8afc8c2e4..f359bef046e0b 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -117,6 +117,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
INTEL_GUC_ACTION_GLOBAL_SCHED_POLICY_CHANGE = 0x506,
+ INTEL_GUC_ACTION_UPDATE_SCHEDULING_POLICIES_KLV = 0x509,
INTEL_GUC_ACTION_SCHED_CONTEXT = 0x1000,
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET = 0x1001,
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
index 4a59478c3b5c4..58012edd4eb0e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
@@ -81,10 +81,17 @@
#define GUC_KLV_SELF_CFG_G2H_CTB_SIZE_KEY 0x0907
#define GUC_KLV_SELF_CFG_G2H_CTB_SIZE_LEN 1u
+/*
+ * Global scheduling policy update keys.
+ */
+enum {
+ GUC_SCHEDULING_POLICIES_KLV_ID_RENDER_COMPUTE_YIELD = 0x1001,
+};
+
/*
* Per context scheduling policy update keys.
*/
-enum {
+enum {
GUC_CONTEXT_POLICIES_KLV_ID_EXECUTION_QUANTUM =
0x2001,
GUC_CONTEXT_POLICIES_KLV_ID_PREEMPTION_TIMEOUT =
0x2002,
GUC_CONTEXT_POLICIES_KLV_ID_SCHEDULING_PRIORITY =
0x2003,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 323b055e5db97..e7a7fb450f442 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -290,6 +290,25 @@ struct guc_update_context_policy {
struct guc_klv_generic_dw_t klv[GUC_CONTEXT_POLICIES_KLV_NUM_IDS];
} __packed;
+/* Format of the UPDATE_SCHEDULING_POLICIES H2G data packet */
+struct guc_update_scheduling_policy_header {
+ u32 action;
+} __packed;
+
+/*
+ * Can't dynmically allocate memory for the scheduling policy KLV because
+ * it will be sent from within the reset path. Need a fixed size lump on
+ * the stack instead :(.
+ *
+ * Currently, there is only one KLV defined, which has 1 word of KL + 2 words
of V.
+ */
+#define MAX_SCHEDULING_POLICY_SIZE 3
+
+struct guc_update_scheduling_policy {
+ struct guc_update_scheduling_policy_header header;
+ u32 data[MAX_SCHEDULING_POLICY_SIZE];
+} __packed;
+
#define GUC_POWER_UNSPECIFIED 0
#define GUC_POWER_D01
#define GUC_POWER_D12
@@ -298,6 +317,9 @@ struct guc_update_context_policy {
/* Scheduling policy settings */
+#define GLOBAL_SCHEDULE_POLICY_RC_YIELD_DURATION 100 /* in ms */
+#define GLOBAL_SCHEDULE_POLICY_RC_YIELD_RATIO 50 /* in percent */
+
#define GLOBAL_POLICY_MAX_NUM_WI 15
/* Don't reset an engine upon preemption failure */
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 22ba66e48a9b0..f09f530198f4d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4177,6 +4177,98 @@ int intel_guc_submission_setup(struct intel_engine_cs
*engine)
return 0;
}
+struct scheduling_policy {
+ /* internal data */
+ u32 max_words, num_words;
+ u32 count;
+ /* API data */
+ struct guc_update_scheduling_policy h2g;
+};
+
+static u32 __guc_scheduling_policy_action_size(struct scheduling_policy
*policy)
+{
+ u32 *start = (void *)>h2g;
+ u32 *end = policy->h2g.data + policy->num_words;
+ size_t delta = end - start;
+
+ return delta;
+}
+
+static struct scheduling_policy *__guc_scheduling_policy_start_klv(struct
scheduling_policy *policy)
+{
+ policy->h2g.header.action =
INTEL_GUC_ACTION_UPDATE_SCHEDULING_POLICIES_KLV;
+ policy->max_words = ARRAY_SIZE(policy->h2g.data);
+ policy->num_words = 0;
+
[PATCH] drm/i915: Remove unused function parameter
The function parameter 'exclude' in funciton
i915_sw_fence_await_reservation() is not used.
Remove it.
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 5 ++---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence.c | 1 -
drivers/gpu/drm/i915/i915_sw_fence.h | 1 -
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index aaa6708256d5..ecb8d71d36c0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -1005,7 +1005,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
*/
if (intel_crtc_needs_modeset(crtc_state)) {
ret =
i915_sw_fence_await_reservation(>commit_ready,
-
old_obj->base.resv, NULL,
+
old_obj->base.resv,
false, 0,
GFP_KERNEL);
if (ret < 0)
@@ -1039,8 +1039,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
struct dma_fence *fence;
ret = i915_sw_fence_await_reservation(>commit_ready,
- obj->base.resv, NULL,
- false,
+ obj->base.resv, false,
i915_fence_timeout(dev_priv),
GFP_KERNEL);
if (ret < 0)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index 0512afdd20d8..b3b398fe689c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -113,7 +113,7 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object
*obj,
clflush = clflush_work_create(obj);
if (clflush) {
i915_sw_fence_await_reservation(>base.chain,
- obj->base.resv, NULL, true,
+ obj->base.resv, true,
i915_fence_timeout(i915),
I915_FENCE_GFP);
dma_resv_add_fence(obj->base.resv, >base.dma,
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 6fc0d1b89690..cc2a8821d22a 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -571,7 +571,6 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
- const struct dma_fence_ops *exclude,
bool write,
unsigned long timeout,
gfp_t gfp)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h
b/drivers/gpu/drm/i915/i915_sw_fence.h
index 619fc5a22f0c..f752bfc7c6e1 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -91,7 +91,6 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence *fence,
int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
- const struct dma_fence_ops *exclude,
bool write,
unsigned long timeout,
gfp_t gfp);
--
2.21.0.rc0.32.g243a4c7e27
Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup()
On 9/22/22 17:55, Kees Cook wrote: > On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote: >> Am 22.09.22 um 05:10 schrieb Kees Cook: >> > Hi, >> > >> > This series fixes up the cases where callers of ksize() use it to >> > opportunistically grow their buffer sizes, which can run afoul of the >> > __alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE >> > use to perform dynamic buffer bounds checking. >> >> Good cleanup, but one question: What other use cases we have for ksize() >> except the opportunistically growth of buffers? > > The remaining cases all seem to be using it as a "do we need to resize > yet?" check, where they don't actually track the allocation size > themselves and want to just depend on the slab cache to answer it. This > is most clearly seen in the igp code: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_main.c?h=v6.0-rc6#n1204 > > My "solution" there kind of side-steps it, and leaves ksize() as-is: > https://lore.kernel.org/linux-hardening/20220922031013.2150682-8-keesc...@chromium.org/ > > The more correct solution would be to add per-v_idx size tracking, > similar to the other changes I sent: > https://lore.kernel.org/linux-hardening/20220922031013.2150682-11-keesc...@chromium.org/ > > I wonder if perhaps I should just migrate some of this code to using > something like struct membuf. > >> Off hand I can't see any. >> >> So when this patch set is about to clean up this use case it should probably >> also take care to remove ksize() or at least limit it so that it won't be >> used for this use case in the future. > > Yeah, my goal would be to eliminate ksize(), and it seems possible if > other cases are satisfied with tracking their allocation sizes directly. I think we could leave ksize() to determine the size without a need for external tracking, but from now on forbid callers from using that hint to overflow the allocation size they actually requested? Once we remove the kasan/kfence hooks in ksize() that make the current kinds of usage possible, we should be able to catch any offenders of the new semantics that would appear? > -Kees >
Re: [PATCH v2 08/33] drm/connector: Rename drm_mode_create_tv_properties
For nouveau:
Reviewed-by: Lyude Paul
On Thu, 2022-09-22 at 16:25 +0200, Maxime Ripard wrote:
> drm_mode_create_tv_properties(), among other things, will create the
> "mode" property that stores the analog TV mode that connector is
> supposed to output.
>
> However, that property is getting deprecated, so let's rename that
> function to mention it's deprecated. We'll introduce a new variant of
> that function creating the property superseeding it in a later patch.
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 17a5913cefe3..4e4fbc9e0049 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1600,7 +1600,7 @@
> EXPORT_SYMBOL(drm_connector_attach_tv_margin_properties);
> * Called by a driver's HDMI connector initialization routine, this function
> * creates the TV margin properties for a given device. No need to call this
> * function for an SDTV connector, it's already called from
> - * drm_mode_create_tv_properties().
> + * drm_mode_create_tv_properties_legacy().
> *
> * Returns:
> * 0 on success or a negative error code on failure.
> @@ -1635,7 +1635,7 @@ int drm_mode_create_tv_margin_properties(struct
> drm_device *dev)
> EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>
> /**
> - * drm_mode_create_tv_properties - create TV specific connector properties
> + * drm_mode_create_tv_properties_legacy - create TV specific connector
> properties
> * @dev: DRM device
> * @num_modes: number of different TV formats (modes) supported
> * @modes: array of pointers to strings containing name of each format
> @@ -1648,9 +1648,9 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> * Returns:
> * 0 on success or a negative error code on failure.
> */
> -int drm_mode_create_tv_properties(struct drm_device *dev,
> - unsigned int num_modes,
> - const char * const modes[])
> +int drm_mode_create_tv_properties_legacy(struct drm_device *dev,
> + unsigned int num_modes,
> + const char * const modes[])
> {
> struct drm_property *tv_selector;
> struct drm_property *tv_subconnector;
> @@ -1733,7 +1733,7 @@ int drm_mode_create_tv_properties(struct drm_device
> *dev,
> nomem:
> return -ENOMEM;
> }
> -EXPORT_SYMBOL(drm_mode_create_tv_properties);
> +EXPORT_SYMBOL(drm_mode_create_tv_properties_legacy);
>
> /**
> * drm_mode_create_scaling_mode_property - create scaling mode property
> diff --git a/drivers/gpu/drm/gud/gud_connector.c
> b/drivers/gpu/drm/gud/gud_connector.c
> index 86e992b2108b..034e78360d4f 100644
> --- a/drivers/gpu/drm/gud/gud_connector.c
> +++ b/drivers/gpu/drm/gud/gud_connector.c
> @@ -400,7 +400,7 @@ static int gud_connector_add_tv_mode(struct gud_device
> *gdrm, struct drm_connect
> for (i = 0; i < num_modes; i++)
> modes[i] = [i * GUD_CONNECTOR_TV_MODE_NAME_LEN];
>
> - ret = drm_mode_create_tv_properties(connector->dev, num_modes, modes);
> + ret = drm_mode_create_tv_properties_legacy(connector->dev, num_modes,
> modes);
> free:
> kfree(buf);
> if (ret < 0)
> @@ -539,7 +539,7 @@ static int gud_connector_add_properties(struct gud_device
> *gdrm, struct gud_conn
> fallthrough;
> case GUD_PROPERTY_TV_HUE:
> /* This is a no-op if already added. */
> - ret = drm_mode_create_tv_properties(drm, 0, NULL);
> + ret = drm_mode_create_tv_properties_legacy(drm, 0,
> NULL);
> if (ret)
> goto out;
> break;
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c
> b/drivers/gpu/drm/i2c/ch7006_drv.c
> index d29b63fd6178..506f6f932518 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -250,7 +250,7 @@ static int ch7006_encoder_create_resources(struct
> drm_encoder *encoder,
> struct drm_device *dev = encoder->dev;
> struct drm_mode_config *conf = >mode_config;
>
> - drm_mode_create_tv_properties(dev, NUM_TV_NORMS, ch7006_tv_norm_names);
> + drm_mode_create_tv_properties_legacy(dev, NUM_TV_NORMS,
> ch7006_tv_norm_names);
>
> priv->scale_property = drm_property_create_range(dev, 0, "scale", 0, 2);
> if (!priv->scale_property)
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index abaf9ded942d..5e88da8185ee 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -1984,7 +1984,7 @@ intel_tv_init(struct drm_i915_private *dev_priv)
>
> tv_format_names[i] = tv_modes[i].name;
> }
> - drm_mode_create_tv_properties(dev, i, tv_format_names);
> + drm_mode_create_tv_properties_legacy(dev, i,
Re: [PATCH v2 06/33] drm/connector: Rename legacy TV property
nouveau changes:
Reviewed-by: Lyude Paul
On Thu, 2022-09-22 at 16:25 +0200, Maxime Ripard wrote:
> The current tv_mode has driver-specific values that don't allow to
> easily share code using it, either at the userspace or kernel level.
>
> Since we're going to introduce a new, generic, property that fit the
> same purpose, let's rename this one to legacy_tv_mode to make it
> obvious we should move away from it.
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index c06d0639d552..7f2b9a07fbdf 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -698,8 +698,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->tv.margins.top = val;
> } else if (property == config->tv_bottom_margin_property) {
> state->tv.margins.bottom = val;
> - } else if (property == config->tv_mode_property) {
> - state->tv.mode = val;
> + } else if (property == config->legacy_tv_mode_property) {
> + state->tv.legacy_mode = val;
> } else if (property == config->tv_brightness_property) {
> state->tv.brightness = val;
> } else if (property == config->tv_contrast_property) {
> @@ -808,8 +808,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->tv.margins.top;
> } else if (property == config->tv_bottom_margin_property) {
> *val = state->tv.margins.bottom;
> - } else if (property == config->tv_mode_property) {
> - *val = state->tv.mode;
> + } else if (property == config->legacy_tv_mode_property) {
> + *val = state->tv.legacy_mode;
> } else if (property == config->tv_brightness_property) {
> *val = state->tv.brightness;
> } else if (property == config->tv_contrast_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index e3142c8142b3..ede6025638d7 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1686,14 +1686,14 @@ int drm_mode_create_tv_properties(struct drm_device
> *dev,
> if (drm_mode_create_tv_margin_properties(dev))
> goto nomem;
>
> - dev->mode_config.tv_mode_property =
> + dev->mode_config.legacy_tv_mode_property =
> drm_property_create(dev, DRM_MODE_PROP_ENUM,
> "mode", num_modes);
> - if (!dev->mode_config.tv_mode_property)
> + if (!dev->mode_config.legacy_tv_mode_property)
> goto nomem;
>
> for (i = 0; i < num_modes; i++)
> - drm_property_add_enum(dev->mode_config.tv_mode_property,
> + drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
> i, modes[i]);
>
> dev->mode_config.tv_brightness_property =
> diff --git a/drivers/gpu/drm/gud/gud_connector.c
> b/drivers/gpu/drm/gud/gud_connector.c
> index fa636206f232..86e992b2108b 100644
> --- a/drivers/gpu/drm/gud/gud_connector.c
> +++ b/drivers/gpu/drm/gud/gud_connector.c
> @@ -303,7 +303,7 @@ static int gud_connector_atomic_check(struct
> drm_connector *connector,
> old_state->tv.margins.right != new_state->tv.margins.right ||
> old_state->tv.margins.top != new_state->tv.margins.top ||
> old_state->tv.margins.bottom != new_state->tv.margins.bottom ||
> - old_state->tv.mode != new_state->tv.mode ||
> + old_state->tv.legacy_mode != new_state->tv.legacy_mode ||
> old_state->tv.brightness != new_state->tv.brightness ||
> old_state->tv.contrast != new_state->tv.contrast ||
> old_state->tv.flicker_reduction != new_state->tv.flicker_reduction
> ||
> @@ -424,7 +424,7 @@ gud_connector_property_lookup(struct drm_connector
> *connector, u16 prop)
> case GUD_PROPERTY_TV_BOTTOM_MARGIN:
> return config->tv_bottom_margin_property;
> case GUD_PROPERTY_TV_MODE:
> - return config->tv_mode_property;
> + return config->legacy_tv_mode_property;
> case GUD_PROPERTY_TV_BRIGHTNESS:
> return config->tv_brightness_property;
> case GUD_PROPERTY_TV_CONTRAST:
> @@ -454,7 +454,7 @@ static unsigned int *gud_connector_tv_state_val(u16 prop,
> struct drm_tv_connecto
> case GUD_PROPERTY_TV_BOTTOM_MARGIN:
> return >margins.bottom;
> case GUD_PROPERTY_TV_MODE:
> - return >mode;
> + return >legacy_mode;
> case GUD_PROPERTY_TV_BRIGHTNESS:
> return >brightness;
> case GUD_PROPERTY_TV_CONTRAST:
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c
> b/drivers/gpu/drm/i2c/ch7006_drv.c
> index b91e48d2190d..d29b63fd6178 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -264,7 +264,7 @@ static int
[PATCH] drm: Remove redundant assignments to variable count
The variable count is assigned a value but it is never read. The
assignment is redundant and can be removed.
Cleans up two clang scan build warnings:
warning: Value stored to 'count' is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_crtc_helper.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 457448cc60f7..2467df7a7a95 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -632,7 +632,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
}
/* a) traverse passed in connector list and get encoders for them */
- count = 0;
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
const struct drm_connector_helper_funcs *connector_funcs =
@@ -678,7 +677,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
goto fail;
}
- count = 0;
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
if (!connector->encoder)
--
2.37.1
[PATCH 1/1] drm/i915/guc: Enable compute scheduling on DG2
From: John Harrison
DG2 has issues. To work around one of these the GuC must schedule
apps in an exclusive manner across both RCS and CCS. That is, if a
context from app X is running on RCS then all CCS engines must sit
idle even if there are contexts from apps Y, Z, ... waiting to run. A
certain OS favours RCS to the total starvation of CCS. Linux does not.
Hence the GuC now has a scheduling policy setting to control this
abitration.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 9 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 22 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 93 +++
4 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 29ef8afc8c2e4..f359bef046e0b 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -117,6 +117,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
INTEL_GUC_ACTION_GLOBAL_SCHED_POLICY_CHANGE = 0x506,
+ INTEL_GUC_ACTION_UPDATE_SCHEDULING_POLICIES_KLV = 0x509,
INTEL_GUC_ACTION_SCHED_CONTEXT = 0x1000,
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET = 0x1001,
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
index 4a59478c3b5c4..58012edd4eb0e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
@@ -81,10 +81,17 @@
#define GUC_KLV_SELF_CFG_G2H_CTB_SIZE_KEY 0x0907
#define GUC_KLV_SELF_CFG_G2H_CTB_SIZE_LEN 1u
+/*
+ * Global scheduling policy update keys.
+ */
+enum {
+ GUC_SCHEDULING_POLICIES_KLV_ID_RENDER_COMPUTE_YIELD = 0x1001,
+};
+
/*
* Per context scheduling policy update keys.
*/
-enum {
+enum {
GUC_CONTEXT_POLICIES_KLV_ID_EXECUTION_QUANTUM =
0x2001,
GUC_CONTEXT_POLICIES_KLV_ID_PREEMPTION_TIMEOUT =
0x2002,
GUC_CONTEXT_POLICIES_KLV_ID_SCHEDULING_PRIORITY =
0x2003,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 323b055e5db97..e7a7fb450f442 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -290,6 +290,25 @@ struct guc_update_context_policy {
struct guc_klv_generic_dw_t klv[GUC_CONTEXT_POLICIES_KLV_NUM_IDS];
} __packed;
+/* Format of the UPDATE_SCHEDULING_POLICIES H2G data packet */
+struct guc_update_scheduling_policy_header {
+ u32 action;
+} __packed;
+
+/*
+ * Can't dynmically allocate memory for the scheduling policy KLV because
+ * it will be sent from within the reset path. Need a fixed size lump on
+ * the stack instead :(.
+ *
+ * Currently, there is only one KLV defined, which has 1 word of KL + 2 words
of V.
+ */
+#define MAX_SCHEDULING_POLICY_SIZE 3
+
+struct guc_update_scheduling_policy {
+ struct guc_update_scheduling_policy_header header;
+ u32 data[MAX_SCHEDULING_POLICY_SIZE];
+} __packed;
+
#define GUC_POWER_UNSPECIFIED 0
#define GUC_POWER_D0 1
#define GUC_POWER_D1 2
@@ -298,6 +317,9 @@ struct guc_update_context_policy {
/* Scheduling policy settings */
+#define GLOBAL_SCHEDULE_POLICY_RC_YIELD_DURATION 100 /* in ms */
+#define GLOBAL_SCHEDULE_POLICY_RC_YIELD_RATIO 50 /* in percent */
+
#define GLOBAL_POLICY_MAX_NUM_WI 15
/* Don't reset an engine upon preemption failure */
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 22ba66e48a9b0..f09f530198f4d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4177,6 +4177,98 @@ int intel_guc_submission_setup(struct intel_engine_cs
*engine)
return 0;
}
+struct scheduling_policy {
+ /* internal data */
+ u32 max_words, num_words;
+ u32 count;
+ /* API data */
+ struct guc_update_scheduling_policy h2g;
+};
+
+static u32 __guc_scheduling_policy_action_size(struct scheduling_policy
*policy)
+{
+ u32 *start = (void *)>h2g;
+ u32 *end = policy->h2g.data + policy->num_words;
+ size_t delta = end - start;
+
+ return delta;
+}
+
+static struct scheduling_policy *__guc_scheduling_policy_start_klv(struct
scheduling_policy *policy)
+{
+ policy->h2g.header.action =
INTEL_GUC_ACTION_UPDATE_SCHEDULING_POLICIES_KLV;
+ policy->max_words = ARRAY_SIZE(policy->h2g.data);
+ policy->num_words = 0;
+ policy->count = 0;
+
+ return policy;
+}
+
+static void __guc_scheduling_policy_add_klv(struct scheduling_policy
[PATCH 0/1] DG2 fix for CCS starvation
From: John Harrison Enable CCS/RCS arbitration scheduling in GuC to prevent CCS starvation on DG2. Signed-off-by: John Harrison John Harrison (1): drm/i915/guc: Enable compute scheduling on DG2 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 9 +- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 22 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 93 +++ 4 files changed, 124 insertions(+), 1 deletion(-) -- 2.37.3
Re: [PATCH v2 06/10] drm/msm/dp: fix aux-bus EP lifetime
On 9/13/2022 5:36 AM, Doug Anderson wrote:
Hi,
On Tue, Sep 13, 2022 at 9:58 AM Johan Hovold wrote:
Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.
This can lead resource leaks or failure to bind the aggregate device
when binding is later retried and a second attempt to allocate the
resources is made.
For the DP aux-bus, an attempt to populate the bus a second time will
simply fail ("DP AUX EP device already populated").
Fix this by tying the lifetime of the EP device to the DRM device rather
than DP controller platform device.
Fixes: c3bf8e21b38a ("drm/msm/dp: Add eDP support via aux_bus")
Cc: sta...@vger.kernel.org # 5.19
Signed-off-by: Johan Hovold
---
drivers/gpu/drm/msm/dp/dp_display.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
This seems fine to me as a short term fix until we get the DP AUX
populating moved to probe.
Reviewed-by: Douglas Anderson
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
Re: [Freedreno] [PATCH v2 01/10] drm/msm: fix use-after-free on probe deferral
On 9/13/2022 1:53 AM, Johan Hovold wrote:
The bridge counter was never reset when tearing down the DRM device so
that stale pointers to deallocated structures would be accessed on the
next tear down (e.g. after a second late bind deferral).
Given enough bridges and a few probe deferrals this could currently also
lead to data beyond the bridge array being corrupted.
Fixes: d28ea556267c ("drm/msm: properly add and remove internal bridges")
Fixes: a3376e3ec81c ("drm/msm: convert to drm_bridge")
Cc: sta...@vger.kernel.org # 3.12
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/msm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 391d86b54ded..d254fe2507ec 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -241,6 +241,7 @@ static int msm_drm_uninit(struct device *dev)
for (i = 0; i < priv->num_bridges; i++)
drm_bridge_remove(priv->bridges[i]);
+ priv->num_bridges = 0;
pm_runtime_get_sync(dev);
msm_irq_uninstall(ddev);
Re: [Freedreno] [PATCH v2 10/10] drm/msm/dsi: drop modeset sanity checks
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Drop the overly defensive modeset sanity checks of function parameters
which have already been checked or used by the callers.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dsi/dsi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 8a95c744972a..31fdee2052be 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -211,14 +211,9 @@ void __exit msm_dsi_unregister(void)
int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
struct drm_encoder *encoder)
{
- struct msm_drm_private *priv;
+ struct msm_drm_private *priv = dev->dev_private;
int ret;
- if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))
- return -EINVAL;
-
- priv = dev->dev_private;
-
if (priv->num_bridges == ARRAY_SIZE(priv->bridges)) {
DRM_DEV_ERROR(dev->dev, "too many bridges\n");
return -ENOSPC;
Re: [PATCH v2 09/10] drm/msm/dp: drop modeset sanity checks
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Drop the overly defensive modeset sanity checks of function parameters
which have already been checked or used by the callers.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 808a516e84c5..33daec11f813 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1607,15 +1607,10 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
struct drm_encoder *encoder)
{
- struct msm_drm_private *priv;
+ struct msm_drm_private *priv = dev->dev_private;
struct dp_display_private *dp_priv;
int ret;
- if (WARN_ON(!encoder) || WARN_ON(!dp_display) || WARN_ON(!dev))
- return -EINVAL;
-
- priv = dev->dev_private;
-
if (priv->num_bridges == ARRAY_SIZE(priv->bridges)) {
DRM_DEV_ERROR(dev->dev, "too many bridges\n");
return -ENOSPC;
Re: [Freedreno] [PATCH v2 07/10] drm/msm/dp: fix bridge lifetime
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.
This can lead resource leaks or failure to bind the aggregate device
when binding is later retried and a second attempt to allocate the
resources is made.
For the DP bridges, previously allocated bridges will leak on probe
deferral.
Fix this by amending the DP parser interface and tying the lifetime of
the bridge device to the DRM device rather than DP platform device.
Fixes: c3bf8e21b38a ("drm/msm/dp: Add eDP support via aux_bus")
Cc: sta...@vger.kernel.org # 5.19
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
drivers/gpu/drm/msm/dp/dp_parser.c | 6 +++---
drivers/gpu/drm/msm/dp/dp_parser.h | 5 +++--
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 4b0a2d4bb61e..808a516e84c5 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1586,7 +1586,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
* For DisplayPort interfaces external bridges are optional, so
* silently ignore an error if one is not present (-ENODEV).
*/
- rc = dp_parser_find_next_bridge(dp_priv->parser);
+ rc = devm_dp_parser_find_next_bridge(dp->drm_dev->dev, dp_priv->parser);
if (!dp->is_edp && rc == -ENODEV)
return 0;
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
index dd732215d55b..dcbe893d66d7 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -240,12 +240,12 @@ static int dp_parser_clock(struct dp_parser *parser)
return 0;
}
-int dp_parser_find_next_bridge(struct dp_parser *parser)
+int devm_dp_parser_find_next_bridge(struct device *dev, struct dp_parser
*parser)
{
- struct device *dev = >pdev->dev;
+ struct platform_device *pdev = parser->pdev;
struct drm_bridge *bridge;
- bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ bridge = devm_drm_of_get_bridge(dev, pdev->dev.of_node, 1, 0);
if (IS_ERR(bridge))
return PTR_ERR(bridge);
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a82bf1a..d30ab773db46 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -138,8 +138,9 @@ struct dp_parser {
struct dp_parser *dp_parser_get(struct platform_device *pdev);
/**
- * dp_parser_find_next_bridge() - find an additional bridge to DP
+ * devm_dp_parser_find_next_bridge() - find an additional bridge to DP
*
+ * @dev: device to tie bridge lifetime to
* @parser: dp_parser data from client
*
* This function is used to find any additional bridge attached to
@@ -147,6 +148,6 @@ struct dp_parser *dp_parser_get(struct platform_device
*pdev);
*
* Return: 0 if able to get the bridge, otherwise negative errno for failure.
*/
-int dp_parser_find_next_bridge(struct dp_parser *parser);
+int devm_dp_parser_find_next_bridge(struct device *dev, struct dp_parser
*parser);
#endif
Re: [PATCH v2 08/10] drm/msm/hdmi: fix IRQ lifetime
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.
This is specifically true for the HDMI IRQ, which will otherwise remain
requested so that the next bind attempt fails when requesting the IRQ a
second time.
Fix this by tying the device-managed lifetime of the HDMI IRQ to the DRM
device so that it is released when bind fails.
Fixes: 067fef372c73 ("drm/msm/hdmi: refactor bind/init")
Cc: sta...@vger.kernel.org # 3.19
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index a0ed6aa8e4e1..f28fb21e3891 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -344,7 +344,7 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi,
goto fail;
}
- ret = devm_request_irq(>dev, hdmi->irq,
+ ret = devm_request_irq(dev->dev, hdmi->irq,
msm_hdmi_irq, IRQF_TRIGGER_HIGH,
"hdmi_isr", hdmi);
if (ret < 0) {
Re: [PATCH v2 04/10] drm/msm/hdmi: fix memory corruption with too many bridges
On 13/09/2022 11:53, Johan Hovold wrote:
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Fixes: a3376e3ec81c ("drm/msm: convert to drm_bridge")
Cc: sta...@vger.kernel.org # 3.12
Signed-off-by: Johan Hovold
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 5 +
1 file changed, 5 insertions(+)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v2 03/10] drm/msm/dsi: fix memory corruption with too many bridges
On 13/09/2022 11:53, Johan Hovold wrote:
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: sta...@vger.kernel.org # 4.1
Signed-off-by: Johan Hovold
---
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++
1 file changed, 6 insertions(+)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v2 02/10] drm/msm/dp: fix memory corruption with too many bridges
On 13/09/2022 11:53, Johan Hovold wrote:
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Fixes: 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable and
disable")
Cc: sta...@vger.kernel.org # 5.17
Signed-off-by: Johan Hovold
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [Freedreno] [PATCH v2 05/10] drm/msm/dp: fix IRQ lifetime
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Device-managed resources allocated post component bind must be tied to
the lifetime of the aggregate DRM device or they will not necessarily be
released when binding of the aggregate device is deferred.
This is specifically true for the DP IRQ, which will otherwise remain
requested so that the next bind attempt fails when requesting the IRQ a
second time.
Since commit c3bf8e21b38a ("drm/msm/dp: Add eDP support via aux_bus")
this can happen when the aux-bus panel driver has not yet been loaded so
that probe is deferred.
Fix this by tying the device-managed lifetime of the DP IRQ to the DRM
device so that it is released when bind fails.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Cc: sta...@vger.kernel.org # 5.10
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index fbe950edaefe..ba557328710a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1258,7 +1258,7 @@ int dp_display_request_irq(struct msm_dp *dp_display)
return -EINVAL;
}
- rc = devm_request_irq(>pdev->dev, dp->irq,
+ rc = devm_request_irq(dp_display->drm_dev->dev, dp->irq,
dp_display_irq_handler,
IRQF_TRIGGER_HIGH, "dp_display_isr", dp);
if (rc < 0) {
Re: [Freedreno] [PATCH v2 04/10] drm/msm/hdmi: fix memory corruption with too many bridges
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Fixes: a3376e3ec81c ("drm/msm: convert to drm_bridge")
Cc: sta...@vger.kernel.org # 3.12
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 93fe61b86967..a0ed6aa8e4e1 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -300,6 +300,11 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi,
struct platform_device *pdev = hdmi->pdev;
int ret;
+ if (priv->num_bridges == ARRAY_SIZE(priv->bridges)) {
+ DRM_DEV_ERROR(dev->dev, "too many bridges\n");
+ return -ENOSPC;
+ }
+
hdmi->dev = dev;
hdmi->encoder = encoder;
Re: [PATCH v2 03/10] drm/msm/dsi: fix memory corruption with too many bridges
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: sta...@vger.kernel.org # 4.1
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 39bbabb5daf6..8a95c744972a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -218,6 +218,12 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
return -EINVAL;
priv = dev->dev_private;
+
+ if (priv->num_bridges == ARRAY_SIZE(priv->bridges)) {
+ DRM_DEV_ERROR(dev->dev, "too many bridges\n");
+ return -ENOSPC;
+ }
+
msm_dsi->dev = dev;
ret = msm_dsi_host_modeset_init(msm_dsi->host, dev);
Re: [Freedreno] [PATCH v2 02/10] drm/msm/dp: fix memory corruption with too many bridges
On 9/13/2022 1:53 AM, Johan Hovold wrote:
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Fixes: 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable and
disable")
Cc: sta...@vger.kernel.org # 5.17
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 3e284fed8d30..fbe950edaefe 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1604,6 +1604,12 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
struct drm_device *dev,
return -EINVAL;
priv = dev->dev_private;
+
+ if (priv->num_bridges == ARRAY_SIZE(priv->bridges)) {
+ DRM_DEV_ERROR(dev->dev, "too many bridges\n");
+ return -ENOSPC;
+ }
+
dp_display->drm_dev = dev;
dp_priv = container_of(dp_display, struct dp_display_private, dp_display);
[PATCH] drm/i915: Fix CFI violations in gt_sysfs
When booting with clang's kernel control flow integrity series [1],
there are numerous violations when accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
$ grep . *
id:0
punit_req_freq_mhz:350
rc6_enable:1
rc6_residency_ms:214934
rps_act_freq_mhz:1300
rps_boost_freq_mhz:1300
rps_cur_freq_mhz:350
rps_max_freq_mhz:1300
rps_min_freq_mhz:350
rps_RP0_freq_mhz:1300
rps_RP1_freq_mhz:350
rps_RPn_freq_mhz:350
throttle_reason_pl1:0
throttle_reason_pl2:0
throttle_reason_pl4:0
throttle_reason_prochot:0
throttle_reason_ratl:0
throttle_reason_status:0
throttle_reason_thermal:0
throttle_reason_vr_tdc:0
throttle_reason_vr_thermalert:0
$ sudo dmesg &| grep "CFI failure at"
[ 214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target:
id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
[ 214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target:
punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
[ 214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target:
act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target:
boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target:
cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target:
max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target:
min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target:
RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.
The ultimate issue is that these sysfs functions are expecting to be
called via dev_attr_show() but they may also be called via
kobj_attr_show(), as certain files are created under two different
kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
hence the warnings above. When accessing the gt_ files under
/sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
sysfs functions, there are no violations, meaning the functions are
being called with the proper type.
To make everything work properly, adjust certain functions to match the
type of the ->show() and ->store() members in 'struct kobj_attribute'.
Add a macro to generate functions for that can be called via both
dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
called through both kobject locations without violating kCFI and adjust
the attribute groups to account for this.
[1]: https://lore.kernel.org/20220908215504.3686827-1-samitolva...@google.com/
Link: https://github.com/ClangBuiltLinux/linux/issues/1716
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c| 15 +-
drivers/gpu/drm/i915/gt/intel_gt_sysfs.h| 2 +-
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 462 +---
3 files
Re: [Freedreno] [PATCH v2 01/10] drm/msm: fix use-after-free on probe deferral
On 9/13/2022 1:53 AM, Johan Hovold wrote:
The bridge counter was never reset when tearing down the DRM device so
that stale pointers to deallocated structures would be accessed on the
next tear down (e.g. after a second late bind deferral).
Given enough bridges and a few probe deferrals this could currently also
lead to data beyond the bridge array being corrupted.
Fixes: d28ea556267c ("drm/msm: properly add and remove internal bridges")
Fixes: a3376e3ec81c ("drm/msm: convert to drm_bridge")
Cc: sta...@vger.kernel.org # 3.12
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Johan Hovold
Tested-by: Kuogee Hsieh
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/msm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 391d86b54ded..d254fe2507ec 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -241,6 +241,7 @@ static int msm_drm_uninit(struct device *dev)
for (i = 0; i < priv->num_bridges; i++)
drm_bridge_remove(priv->bridges[i]);
+ priv->num_bridges = 0;
pm_runtime_get_sync(dev);
msm_irq_uninstall(ddev);
Re: [PATCH 02/12] skbuff: Proactively round up to kmalloc bucket size
On Wed, 21 Sep 2022 20:10:03 -0700 Kees Cook wrote: > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 974e7138..4fe4c7544c1d 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -427,14 +427,15 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t > gfp_mask, >*/ > size = SKB_DATA_ALIGN(size); > size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); > - data = kmalloc_reserve(size, gfp_mask, node, ); > - if (unlikely(!data)) > - goto nodata; > - /* kmalloc(size) might give us more room than requested. > + /* kmalloc(size) might give us more room than requested, so > + * allocate the true bucket size up front. >* Put skb_shared_info exactly at the end of allocated zone, >* to allow max possible filling before reallocation. >*/ > - osize = ksize(data); > + osize = kmalloc_size_roundup(size); > + data = kmalloc_reserve(osize, gfp_mask, node, ); > + if (unlikely(!data)) > + goto nodata; > size = SKB_WITH_OVERHEAD(osize); > prefetchw(data + size); I'd rename osize here to alloc_size for consistency but one could argue either way :) Acked-by: Jakub Kicinski
Re: [PATCH v1 01/17] dt-bindings: clk: mediatek: Add MT8195 DPI clocks
On Thu, Sep 22, 2022 at 02:51:00PM +0200, Krzysztof Kozlowski wrote: > Thanks for explanation! Probably your patches are perfectly fine and > should apply, although I must admit diffstat is often useful. Krzysztof: The patches should indeed apply without problems and there's a fix for the missing diffstat already in place. Best regards, Konstantin
Re: [PATCH v1 1/4] drm/msm/mdp5: stop overriding drvdata
Hi Dmitry,
On Montag, 20. Juni 2022 23:30:51 CEST Dmitry Baryshkov wrote:
> The rest of the code expects that master's device drvdata is the
> struct msm_drm_private instance. Do not override the mdp5's drvdata.
>
> Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components")
> Signed-off-by: Dmitry Baryshkov
In search of a fix for a problem on msm8974/msm8226 crashing during shutdown
I tried applying this patch.
On top of 6.0-rc6 with some of my patches incl. adding display support to
msm8226 which generally works fine without this patch, plus only this patch on
top.
Unfortunately it seems display isn't probing anymore and I'm getting a null
pointer dereference in dmesg as seen below.
Hope that's helpful so you can fix that ;)
Regards
Luca
[2.616083] platform fd922800.dsi: Fixing up cyclic dependency with
fd900100.mdp
[2.636031] msm_mdp fd900100.mdp: No interconnect support may cause display
underflows!
[2.638435] [drm] using 32m VRAM carveout
[2.646026] msm_mdp fd900100.mdp: [drm:msm_drm_bind [msm]] VRAM:
1c10->1e10
[2.647055] msm_mdp fd900100.mdp: bound fd922800.dsi (ops dsi_ops [msm])
[2.654642] 8<--- cut here ---
[2.662750] Unable to handle kernel NULL pointer dereference at virtual
address 04d8
[2.664358] [04d8] *pgd=
[2.672610] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[2.676106] Modules linked in: msm gpu_sched qnoc_msm8974 icc_smd_rpm
[2.681403] CPU: 0 PID: 108 Comm: kworker/u2:5 Not tainted
6.0.0-rc6-00034-g3b2cf6d374af #217
[2.687746] Hardware name: Generic DT based system
[2.696242] Workqueue: events_unbound deferred_probe_work_func
[2.700931] PC is at mdp5_runtime_resume+0x30/0x168 [msm]
[2.706747] LR is at mdp5_runtime_resume+0x30/0x168 [msm]
[2.712217] pc : []lr : []psr: 6013
[2.717598] sp : d0a49a48 ip : bf0c0370 fp : c196d094
[2.723671] r10: c036a9dc r9 : c2bfabc0 r8 :
[2.728880] r7 : c3079c94 r6 : c196d010 r5 : c08fab08 r4 :
[2.734092] r3 : c2bfabc0 r2 : r1 : r0 : 0002
[2.740691] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[2.747204] Control: 10c5387d Table: 1307006a DAC: 0051
[2.754403] Register r0 information: non-paged memory
[2.760129] Register r1 information: NULL pointer
[2.765163] Register r2 information: NULL pointer
[2.769850] Register r3 information: slab task_struct start c2bfabc0 pointer
offset 0
[2.774550] Register r4 information: NULL pointer
[2.782350] Register r5 information: non-slab/vmalloc memory
[2.787041] Register r6 information: slab kmalloc-1k start c196d000 pointer
offset 16 size 1024
[2.792781] Register r7 information: slab kmalloc-1k start c3079c00 pointer
offset 148 size 1024
[2.801201] Register r8 information: NULL pointer
[2.810216] Register r9 information: slab task_struct start c2bfabc0 pointer
offset 0
[2.814827] Register r10 information: non-slab/vmalloc memory
[2.822631] Register r11 information: slab kmalloc-1k start c196d000 pointer
offset 148 size 1024
[2.828371] Register r12 information: 242-page vmalloc region starting at
0xbf025000 allocated at load_module+0x9a4/0x1f44
[2.837233] Process kworker/u2:5 (pid: 108, stack limit = 0x(ptrval))
[2.848155] Stack: (0xd0a49a48 to 0xd0a4a000)
[2.854665] 9a40: c3079c10 c08fab08 c196d010 c08fd82c
c3079c10 c08fab08
[2.859020] 9a60: c196d010 0004 d0a49a9c c2bfabc0 c036a9dc c08fd9a8
c3079c10 c08fab08
[2.867179] 9a80: c196d010 c08fd0f8 c3079c10 0bebc200
ffadf800
[2.875339] 9aa0: 8807ce68 a6e11243 d0940100 6013 0004 c3079c94
c307e840 c3079c10
[2.883499] 9ac0: c3079c10 0001 c152654c c08fd484 c306b040 c3079c00
c11d4314 bf044ab8
[2.891658] 9ae0: c3079c10 d0a49b34 c3207900 0018 c3080400 c3080400
c0dd2950
[2.899818] 9b00: d0a49b14 a6e11243 3f0c81c2 c0dd29d0 c1179a84 bf0c0710
c3219ec0 d0a49b34
[2.907977] 9b20: 0004 c0492c60 c0dd2d18 d0a49b48 c117985c
c307ea34 c3080400
[2.916137] 9b40: c3079c10 cbf5b000 a6e11243 0001 c307e840
c3080400
[2.924297] 9b60: c3079c10 cbf5b000 c307e840 0001 c152654c bf071b38
1e10
[2.932457] 9b80: a6e11243 0001 c307fc08 0001 c307fc08
c3079dc0 a113
[2.940617] 9ba0: c152654c a6e11243 c152654c c3202300 c3202300 c3207900
c1526568 c32078c0
[2.948776] 9bc0: 0018 0001 c152654c c08e6a70 0001 c3202300
c3207900
[2.956935] 9be0: c3202300 c1526560 bf0b81d4 c0e9531c
c1805800 c08e6d3c
[2.965096] 9c00: c307ec40 c307fc08 c307fc08 c1526570 bf096abc
c307fc00 c3203340
[2.973256] 9c20: c307fc08 c08e61a4 c0ea4380 d0a49c30 00ff 00ff
[2.981415] 9c40: 0001 a6e11243 c307fc08
c15264f4 c08eed68
[
Re: [PATCH 4/4] drm/bridge: lt8912b: clarify lvds output status
Le jeu. 22 sept. 2022 à 14:43, Philippe Schenker a écrit :
>
> From: Francesco Dolcini
>
> Add comments on the lt8912_write_lvds_config() config to document the
> current settings and to make it clear that this is a hardcoded
> configuration not relevant for the HDMI output (could be removed without
> affecting the HDMI port).
>
> No changes on the actual register writes.
>
> Signed-off-by: Francesco Dolcini
> Signed-off-by: Philippe Schenker
Acked-by: Adrien Grassein
> ---
>
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 26
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> index 5968f4af190b..3e870d45f881 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> @@ -165,24 +165,32 @@ static int lt8912_write_rxlogicres_config(struct lt8912
> *lt)
> return ret;
> };
>
> +/* enable LVDS output with some hardcoded configuration, not required for
> the HDMI output */
> static int lt8912_write_lvds_config(struct lt8912 *lt)
> {
> const struct reg_sequence seq[] = {
> + // lvds power up
> {0x44, 0x30},
> {0x51, 0x05},
> - {0x50, 0x24},
> - {0x51, 0x2d},
> - {0x52, 0x04},
> - {0x69, 0x0e},
> +
> + // core pll bypass
> + {0x50, 0x24}, // cp=50uA
> + {0x51, 0x2d}, // Pix_clk as reference, second order passive
> LPF PLL
> + {0x52, 0x04}, // loopdiv=0, use second-order PLL
> + {0x69, 0x0e}, // CP_PRESET_DIV_RATIO
> {0x69, 0x8e},
> {0x6a, 0x00},
> - {0x6c, 0xb8},
> + {0x6c, 0xb8}, // RGD_CP_SOFT_K_EN,RGD_CP_SOFT_K[13:8]
> {0x6b, 0x51},
> - {0x04, 0xfb},
> +
> + {0x04, 0xfb}, // core pll reset
> {0x04, 0xff},
> - {0x7f, 0x00},
> - {0xa8, 0x13},
> - {0x02, 0xf7},
> +
> + // scaler bypass
> + {0x7f, 0x00}, // disable scaler
> + {0xa8, 0x13}, // 0x13: JEIDA, 0x33: VESA
> +
> + {0x02, 0xf7}, // lvds pll reset
> {0x02, 0xff},
> {0x03, 0xcf},
> {0x03, 0xff},
> --
> 2.37.3
>
Re: [PATCH 3/4] drm/bridge: lt8912b: fix corrupted image output
Le jeu. 22 sept. 2022 à 14:43, Philippe Schenker a écrit :
>
> From: Francesco Dolcini
>
> Correct I2C address for the register list in lt8912_write_lvds_config(),
> these registers are on the first I2C address (0x48), the current
> function is just writing garbage to the wrong registers and this creates
> multiple issues (artifacts and output completely corrupted) on some HDMI
> displays.
>
> Correct I2C address comes from Lontium documentation and it is the one
> used on other out-of-tree LT8912B drivers [1].
>
> [1]
> https://github.com/boundarydevices/linux/blob/boundary-imx_5.10.x_2.0.0/drivers/video/lt8912.c#L296
>
> Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
> Signed-off-by: Francesco Dolcini
> Signed-off-by: Philippe Schenker
Acked-by: Adrien Grassein
> ---
>
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> index 6a4bb7422176..5968f4af190b 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> @@ -188,7 +188,7 @@ static int lt8912_write_lvds_config(struct lt8912 *lt)
> {0x03, 0xff},
> };
>
> - return regmap_multi_reg_write(lt->regmap[I2C_CEC_DSI], seq,
> ARRAY_SIZE(seq));
> + return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq,
> ARRAY_SIZE(seq));
> };
>
> static inline struct lt8912 *bridge_to_lt8912(struct drm_bridge *b)
> --
> 2.37.3
>
Re: [PATCH 2/4] drm/bridge: lt8912b: set hdmi or dvi mode
Le jeu. 22 sept. 2022 à 14:43, Philippe Schenker a écrit :
>
> From: Philippe Schenker
>
> The Lontium LT8912 does have a setting for DVI or HDMI. This patch reads
> from EDID what the display needs and sets it accordingly.
>
> Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
> Signed-off-by: Philippe Schenker
Acked-by: Adrien Grassein
> ---
>
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> index 0fd3472e767c..6a4bb7422176 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> @@ -323,6 +323,8 @@ static int lt8912_video_setup(struct lt8912 *lt)
> vsync_activehigh ? BIT(0) : 0);
> ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xab, BIT(1),
> hsync_activehigh ? BIT(1) : 0);
> + ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xb2, BIT(0),
> + lt->connector.display_info.is_hdmi ? BIT(0)
> : 0);
>
> return ret;
> }
> --
> 2.37.3
>
Re: [PATCH 1/4] drm/bridge: lt8912b: add vsync hsync
Le jeu. 22 sept. 2022 à 14:43, Philippe Schenker a écrit :
>
> From: Philippe Schenker
>
> Currently the bridge driver does not take care whether or not the display
> needs positive/negative vertical/horizontal syncs. Pass these two flags
> to the bridge from the EDID that was read out from the display.
>
> Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
> Signed-off-by: Philippe Schenker
Acked-by: Adrien Grassein
>
> ---
>
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> index 28bad30dc4e5..0fd3472e767c 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> @@ -268,7 +268,7 @@ static int lt8912_video_setup(struct lt8912 *lt)
> u32 hactive, h_total, hpw, hfp, hbp;
> u32 vactive, v_total, vpw, vfp, vbp;
> u8 settle = 0x08;
> - int ret;
> + int ret, hsync_activehigh, vsync_activehigh;
>
> if (!lt)
> return -EINVAL;
> @@ -278,12 +278,14 @@ static int lt8912_video_setup(struct lt8912 *lt)
> hpw = lt->mode.hsync_len;
> hbp = lt->mode.hback_porch;
> h_total = hactive + hfp + hpw + hbp;
> + hsync_activehigh = lt->mode.flags & DISPLAY_FLAGS_HSYNC_HIGH;
>
> vactive = lt->mode.vactive;
> vfp = lt->mode.vfront_porch;
> vpw = lt->mode.vsync_len;
> vbp = lt->mode.vback_porch;
> v_total = vactive + vfp + vpw + vbp;
> + vsync_activehigh = lt->mode.flags & DISPLAY_FLAGS_VSYNC_HIGH;
>
> if (vactive <= 600)
> settle = 0x04;
> @@ -317,6 +319,11 @@ static int lt8912_video_setup(struct lt8912 *lt)
> ret |= regmap_write(lt->regmap[I2C_CEC_DSI], 0x3e, hfp & 0xff);
> ret |= regmap_write(lt->regmap[I2C_CEC_DSI], 0x3f, hfp >> 8);
>
> + ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xab, BIT(0),
> + vsync_activehigh ? BIT(0) : 0);
> + ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xab, BIT(1),
> + hsync_activehigh ? BIT(1) : 0);
> +
> return ret;
> }
>
> --
> 2.37.3
>
[pull] drm/msm: drm-msm-next-2022-09-22 for v6.1
Hi Dave & Daniel, Here is the main drm/msm pull for v6.1, description below and in tag. The following changes since commit 1c23f9e627a7b412978b4e852793c5e3c3efc555: Linux 6.0-rc2 (2022-08-21 17:32:54 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2022-09-22 for you to fetch changes up to e8b595f7b058c7909e410f3e0736d95e8f909d01: drm/msm/hdmi: make hdmi_phy_8996 OF clk provider (2022-09-18 09:38:07 -0700) msm-next for v6.1 DPU: - simplified VBIF configuration - cleaned up CTL interfaces to accept indices rather than flush masks DSI: - removed unused msm_display_dsc_config struct - switch regulator calls to new bulk API - switched to use PANEL_BRIDGE for directly attached panels DSI PHY: - converted drivers to use parent_hws instead of parent_names DP: - cleaned up pixel_rate handling HDMI PHY: - turned hdmi-phy-8996 into OF clk provider core: - misc dt-bindings fixes - choose eDP as primary display if it's available - support getting interconnects from either the mdss or the mdp5/dpu device nodes gpu+gem: - Shrinker + LRU re-work: - adds a shared GEM LRU+shrinker helper and moves msm over to that - reduces lock contention between retire and submit by avoiding the need to acquire obj lock in retire path (and instead using resv seeing obj's busyness in the shrinker - fix reclaim vs submit issues - GEM fault injection for triggering userspace error paths - Map/unmap optimization - Improved robustness for a6xx GPU recovery Abhinav Kumar (1): drm/msm/dpu: populate wb or intf before reset_intf_cfg Akhil P Oommen (7): drm/msm: Remove unnecessary pm_runtime_get/put drm/msm: Take single rpm refcount on behalf of all submits drm/msm: Correct pm_runtime votes in recover worker drm/msm: Fix cx collapse issue during recovery drm/msm/a6xx: Ensure CX collapse during gpu recovery drm/msm/a6xx: Improve gpu recovery sequence drm/msm/a6xx: Handle GMU prepare-slumber hfi failure Bjorn Andersson (1): drm/msm/gpu: Drop qos request if devm_devfreq_add_device() fails Dmitry Baryshkov (25): drm/msm/dpu: use drm_dsc_config instead of msm_display_dsc_config drm/msm/dsi: use drm_dsc_config instead of msm_display_dsc_config dt-bindings: display/msm/gpu: allow specifying several IOMMU nodes dt-bindings: display/msm/gmu: account for different GMU variants dt-bindings: display/msm/mdp4: require 4 IOMMUs drm/msm: lookup the ICC paths in both mdp5/dpu and mdss devices drm/msm/dpu: index dpu_kms->hw_vbif using vbif_idx drm/msm/dpu: fix error handling around dpu_hw_vbif_init drm/msm/dpu: drop VBIF indices drm/msm/dpu: drop unused memory allocation drm/msm/dpu: drop unused variable from dpu_kms_mdp_snapshot() drm/msm/dpu: rip out master planes support drm/msm/dpu: do not limit the zpos property drm/msm/dpu: inline dpu_plane_get_ctl_flush drm/msm/dpu: get rid of cached flush_mask dt-bindings: msm/dp: mark vdda supplies as deprecated dt-bindings: msm/dp: add missing properties dt-bindings: msm/dp: handle DP vs eDP difference drm/msm/dsi: drop the hpd worker drm/mipi-dsi: pass DSC data through the struct mipi_dsi_device drm/msm/dsi: fetch DSC pps payload from struct mipi_dsi_device drm/panel: drop DSC pps pointer drm/msm/dsi: switch to DRM_PANEL_BRIDGE dt-bindings: phy: qcom, hdmi-phy-qmp: add clock-cells and XO clock drm/msm/hdmi: make hdmi_phy_8996 OF clk provider Douglas Anderson (6): drm/msm/dsi: Fix number of regulators for msm8996_dsi_cfg drm/msm/dsi: Fix number of regulators for SDM660 drm/msm/dsi: Don't set a load before disabling a regulator drm/msm/dsi: Use the new regulator bulk feature to specify the load drm/msm/dsi: Take advantage of devm_regulator_bulk_get_const() drm/msm/dsi: Improve dsi_phy_driver_probe() probe error handling Jason Wang (1): drm/msm/dpu: Fix comment typo Javier Martinez Canillas (1): drm/msm: Make .remove and .shutdown HW shutdown consistent Krzysztof Kozlowski (5): dt-bindings: display/msm: dpu-msm8998: add missing DPU opp-table dt-bindings: display/msm: dpu-qcm2290: add missing DPU opp-table dt-bindings: display/msm: dpu-sc7180: add missing DPU opp-table dt-bindings: display/msm: dpu-sc7280: add missing DPU opp-table dt-bindings: display/msm: dpu-sdm845: add missing DPU opp-table Kuogee Hsieh (3): drm/msm/dp: make eDP panel as the first connected connector drm/msm/dp: delete DP_RECOVERED_CLOCK_OUT_EN to fix tps4 drm/msm/dp: correct 1.62G link rate at dp_catalog_ctrl_config_msa() Marijn Suijten (8): drm/msm/dsi/phy: Reindent and reflow multiline function calls
Re: [PATCH 4/5] drm/msm/dpu: add support for SM8450
Hi Dmitry, I love your patch! Perhaps something to improve: [auto build test WARNING on next-20220921] [also build test WARNING on linus/master v6.0-rc6] [cannot apply to drm-misc/drm-misc-next v6.0-rc6 v6.0-rc5 v6.0-rc4] [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/Dmitry-Baryshkov/drm-msm-add-support-for-SM8450/20220922-193223 base:483fed3b5dc8ce3644c83d24240cf5756fb0993e config: s390-randconfig-r044-20220922 (https://download.01.org/0day-ci/archive/20220923/202209230114.2apdpcjg-...@intel.com/config) compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 791a7ae1ba3efd6bca96338e10ffde557ba83920) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://github.com/intel-lab-lkp/linux/commit/b25f303f8c65c2776a67e8c6ac66c379d74170ce git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Dmitry-Baryshkov/drm-msm-add-support-for-SM8450/20220922-193223 git checkout b25f303f8c65c2776a67e8c6ac66c379d74170ce # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=s390 SHELL=/bin/bash drivers/gpu/drm/msm/ If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:8: In file included from include/linux/of_address.h:7: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __raw_readb(PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro '__le16_to_cpu' #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x)) ^ include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16' #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x)) ^ In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:8: In file included from include/linux/of_address.h:7: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:35:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:115:54: note: expanded from macro '__swab32' #define __swab32(x) (__u32)__builtin_bswap32((__u32)(x)) ^ In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:8: In file included from include/linux/of_address.h:7: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writeb(value, PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writel((u32 __force)cpu_to_le32(value), PCI
Re: [PATCH v4 00/15] Tidy up vfio_device life cycle
On Wed, 21 Sep 2022 18:43:46 +0800 Kevin Tian wrote: > The idea is to let vfio core manage the vfio_device life cycle instead > of duplicating the logic cross drivers. Besides cleaner code in driver > side this also allows adding struct device to vfio_device as the first > step toward adding cdev uAPI in the future. Another benefit is that > user can now look at sysfs to decide whether a device is bound to > vfio [1], e.g.: > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > Though most drivers can fit the new model naturally: > > - vfio_alloc_device() to allocate and initialize vfio_device > - vfio_put_device() to release vfio_device > - dev_ops->init() for driver private initialization > - dev_ops->release() for driver private cleanup > > vfio-ccw is the only exception due to a life cycle mess that its private > structure mixes both parent and mdev info hence must be alloc/freed > outside of the life cycle of vfio device. > > Per prior discussions this won't be fixed in short term by IBM folks [2]. > > Instead of waiting this series introduces a few tricks to move forward: > > - vfio_init_device() to initialize a pre-allocated device structure; > > - require *EVERY* driver to implement @release and free vfio_device >inside. Then vfio-ccw can use a completion mechanism to delay the >free to css driver; > > The second trick is not a real burden to other drivers because they > all require a @release for private cleanup anyway. Later once the ccw > mess is fixed a simple cleanup can be done by moving free from @release > to vfio core. > > Thanks > Kevin > > [1] https://listman.redhat.com/archives/libvir-list/2022-August/233482.html > [2] > https://lore.kernel.org/all/0ee29bd6583f17f0ee4ec0769fa50e8ea6703623.ca...@linux.ibm.com/ > > v4: > - fix use-after-free issue in @release of mtty/mbochs and also change >mdpy/ap to free vfio-device as the last thing in @release (Alex) > - revert the rename from 'vfio' to 'vfio_group' in procfs (Alex) Applied to vfio next branch for v6.1. Thanks, Alex
Re: [PATCH 11/12] slab: Remove __malloc attribute from realloc functions
On Thu, Sep 22, 2022 at 5:56 PM Kees Cook wrote: > > I wasn't sure if this "composite macro" was sane there, especially since > it would be using __malloc before it was defined, etc. Would you prefer > I move it? Hmm... On one hand, they end up being attributes, so it could make sense to have them there (after all, the big advantage of that header is that there is no `#ifdef` nest like in others, and that it is only for attributes). On the other hand, you are right that the file so far is intended to be as simple as possible (`__always_inline` having an extra `inline` and `fallthrough` would be closest outliers), so if we do it, I would prefer to do so in an independent series that carries its own rationale. So I would leave the patch as it is here. Cheers, Miguel
Re: [Intel-gfx] [RFC v4 03/14] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
On Thu, Sep 22, 2022 at 05:18:28PM +0100, Matthew Auld wrote:
On 22/09/2022 09:09, Tvrtko Ursulin wrote:
On 21/09/2022 19:00, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 10:13:12AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 20 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..3b3ab4abb0a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,14 +11,24 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
I can't spot that you are adding any code which would need this?
I915_GTT_PAGE_SIZE_4K? It is in intel_gtt.h.
This include should have been added in a later patch for calling
i915_gem_vm_lookup(). But got added here while patch refactoring.
Will fix.
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region
**placements,
- unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of
the regions
+ * @placements: list of regions
+ * @n_placements: number of the placements
+ *
+ * Calculates the max of the min_page_size of a list of
placements passed in.
+ *
+ * Return: max of the min_page_size
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region
**placements,
+ unsigned int n_placements)
{
- u32 max_page_size = 0;
+ u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
for (i = 0; i < n_placements; i++) {
@@ -28,7 +38,6 @@ static u32 object_max_page_size(struct
intel_memory_region **placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
- GEM_BUG_ON(!max_page_size);
return max_page_size;
}
@@ -99,7 +108,8 @@ __i915_gem_object_create_user_ext(struct
drm_i915_private *i915, u64 size,
i915_gem_flush_free_objects(i915);
- size = round_up(size, object_max_page_size(placements,
n_placements));
+ size = round_up(size, i915_gem_object_max_page_size(placements,
+ n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
Because of the changes above this path is now unreachable. I
suppose it was meant to tell the user "you have supplied no
placements"? But then GEM_BUG_ON (which you remove) used to be
wrong.
Yah, looks like an existing problem. May be this "size == 0" check
should have been made before we do the round_up()? ie., check
input 'size'
paramter is not 0?
I think for now, I will remove this check as it was unreachable anyhow.
Hm that's true as well. i915_gem_create_ext_ioctl ensures at least
one placement and internal callers do as well.
To be safe, instead of removing maybe move to before "size = " and
change to "if (GEM_WARN_ON(n_placements == 0))"? Not sure.. Matt any
thoughts here given the changes in this patch?
The check is also to reject a zero sized object with args->size = 0,
i.e round_up(0, PAGE_SIZE) == 0. So for sure that is still needed
here.
Thanks Matt.
Yah, we could check for "size == 0" before we round_up, but doing it
after like here should be just fine. Will keep it as is.
Niranjana
Regards,
Tvrtko
Niranjana
Regards,
Tvrtko
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7317d4102955..8c97bddad921 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool
i915_gem_object_size_2big(u64 size)
}
void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region
**placements,
+ unsigned int n_placements);
void i915_objects_module_exit(void);
int i915_objects_module_init(void);
Re: [PATCH] drm/i915: Improve debug print in vm_fault_ttm
On 22/09/2022 13:09, Nirmoy Das wrote:
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..9619c0fe1025 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU accessible(err =
%pe)\n", err);
Yeah, looks useful. I think for that bug the object is just too large
for the mappable part of lmem, so this just gives -2big or similar on
small-bar systems. I presume that the test needs to be updated to
account for the cpu_size or so.
With the kernel test robot warning fixed:
Acked-by: Matthew Auld
I looked at the GEM_BUG_ON(rq->reserved_space > ring->space), and I
think the issue is maybe with emit_pte() using the ring->space to
manually figure out the number of dwords it can emit (instead of the
usual ring_begin()), which I guess works, but if we are unlucky and get
interrupted (like with a very well timed sigbus here), while waiting for
more ring space and end up bailing early, we might have trampled over
the reserved_space when submitting the request. I guess normally the
next ring_begin() would take care of the reserved_space, like when
constructing the actual copy packet.
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
Re: [RFC PATCH v3] media: mediatek: vcodec: support stateless AV1 decoder
Hi Xiaoyong.
Comments below (other code removed for brevity)
+/**
+ * struct vdec_av1_slice_slot - slot info need save in global instance
+ * @frame_info: frame info for each slot
+ * @timestamp: time stamp info
+ */
+struct vdec_av1_slice_slot {
+ struct vdec_av1_slice_frame_info frame_info[AV1_MAX_FRAME_BUF_COUNT];
+ u64 timestamp[AV1_MAX_FRAME_BUF_COUNT];
+};
nit: slot info that needs to be saved in the global instance
+static int vdec_av1_slice_get_qindex(struct
vdec_av1_slice_uncompressed_header *uh,
+int segmentation_id)
+{
+ struct vdec_av1_slice_seg *seg = >seg;
+ struct vdec_av1_slice_quantization *quant = >quant;
+ int data = 0, qindex = 0;
+
+ if (seg->segmentation_enabled &&
+ (seg->feature_enabled_mask[segmentation_id] & BIT(0))) {
+ data = seg->feature_data[segmentation_id][0];
Maybe you should replace the 0 above by SEG_LVL_ALT_Q to be more
explicit. Same goes for BIT(0).
+static void vdec_av1_slice_setup_lr(struct vdec_av1_slice_lr *lr,
+ struct v4l2_av1_loop_restoration *ctrl_lr)
+{
+ int i;
+
+ for (i = 0; i < V4L2_AV1_NUM_PLANES_MAX; i++) {
+ lr->frame_restoration_type[i] =
ctrl_lr->frame_restoration_type[i];
+ lr->loop_restoration_size[i] =
ctrl_lr->loop_restoration_size[i];
+ }
+ lr->use_lr = !!lr->frame_restoration_type[0];
+ lr->use_chroma_lr = !!lr->frame_restoration_type[1];
+}
From a first glance, this looks a bit divergent from the spec?
for ( i = 0; i < NumPlanes; i++ ) {
lr_type
FrameRestorationType[i] = Remap_Lr_Type[lr_type]
if ( FrameRestorationType[i] != RESTORE_NONE ) {
UsesLr = 1
if ( i > 0 ) {
usesChromaLr = 1
}
}
}
I will include these two variables in the next iteration of the uapi if
computing them in the driver is problematic.
+static void vdec_av1_slice_setup_lf(struct vdec_av1_slice_loop_filter *lf,
+ struct v4l2_av1_loop_filter *ctrl_lf)
+{
+ int i;
+
+ for (i = 0; i < 4; i++)
+ lf->loop_filter_level[i] = ctrl_lf->level[i];
+
+ for (i = 0; i < V4L2_AV1_TOTAL_REFS_PER_FRAME; i++)
+ lf->loop_filter_ref_deltas[i] = ctrl_lf->ref_deltas[i];
+
+ for (i = 0; i < 2; i++)
+ lf->loop_filter_mode_deltas[i] = ctrl_lf->mode_deltas[i];
+
+ lf->loop_filter_sharpness = ctrl_lf->sharpness;
+ lf->loop_filter_delta_enabled =
+ BIT_FLAG(ctrl_lf, V4L2_AV1_LOOP_FILTER_FLAG_DELTA_ENABLED);
+}
Maybe ARRAY_SIZE can be of use in the loop indices here?
+static void vdec_av1_slice_setup_cdef(struct vdec_av1_slice_cdef *cdef,
+ struct v4l2_av1_cdef *ctrl_cdef)
+{
+ int i;
+
+ cdef->cdef_damping = ctrl_cdef->damping_minus_3 + 3;
+ cdef->cdef_bits = ctrl_cdef->bits;
+
+ for (i = 0; i < V4L2_AV1_CDEF_MAX; i++) {
+ if (ctrl_cdef->y_sec_strength[i] == 4)
+ ctrl_cdef->y_sec_strength[i] -= 1;
+
+ if (ctrl_cdef->uv_sec_strength[i] == 4)
+ ctrl_cdef->uv_sec_strength[i] -= 1;
+
+ cdef->cdef_y_strength[i] = ctrl_cdef->y_pri_strength[i] << 2 |
+ ctrl_cdef->y_sec_strength[i];
+ cdef->cdef_uv_strength[i] = ctrl_cdef->uv_pri_strength[i] << 2 |
+ ctrl_cdef->uv_sec_strength[i];
+ }
+}
Maybe:
#define SECONDARY_FILTER_STRENGTH_NUM_BITS 2
+ cdef->cdef_y_strength[i] = ctrl_cdef->y_pri_strength[i] <<
SECONDARY_FILTER_STRENGTH_NUM_BITS |
+ ctrl_cdef->y_sec_strength[i];
+ cdef->cdef_uv_strength[i] = ctrl_cdef->uv_pri_strength[i] <<
SECONDARY_FILTER_STRENGTH_NUM_BITS |
+ ctrl_cdef->uv_sec_strength[i];
This should make it clearer.
+ sb_boundary_x_m1 =
+ (tile->mi_col_starts[tile_col + 1] - tile->mi_col_starts[tile_col] -
1) &
+ 0x3F;
+ sb_boundary_y_m1 =
+ (tile->mi_row_starts[tile_row + 1] - tile->mi_row_starts[tile_row] -
1) &
+ 0x1FF;
+
IIRC there's a preference for lower case hex values in the media subsystem.
+static void vdec_av1_slice_get_dpb_size(struct vdec_av1_slice_instance
*instance, u32 *dpb_sz)
+{
+ /* refer av1 specification */
+ *dpb_sz = 9;
+}
That's actually defined as 8 in the spec, i.e.:
NUM_REF_FRAMES 8 Number of frames that can be stored for future
reference.
It's helpful to indicate the section if you reference the specification,
as it makes it easier for the reviewer to cross check.
+ /* get buffer address from vb2buf */
+ for (i = 0; i < V4L2_AV1_REFS_PER_FRAME; i++) {
+ struct vdec_av1_slice_fb *vref = >ref[i];
+ int idx =
Re: [Intel-gfx] [PATCH] drm/i915: Improve debug print in vm_fault_ttm
Hi Nirmoy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Nirmoy-Das/drm-i915-Improve-debug-print-in-vm_fault_ttm/20220922-201041
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-defconfig
(https://download.01.org/0day-ci/archive/20220923/202209230001.og3h9emy-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-5) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/e1a426a9e14837ada7e883d20af7c9abdf59823c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Nirmoy-Das/drm-i915-Improve-debug-print-in-vm_fault_ttm/20220922-201041
git checkout e1a426a9e14837ada7e883d20af7c9abdf59823c
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/drm/drm_mm.h:51,
from include/drm/ttm/ttm_bo_driver.h:33,
from drivers/gpu/drm/i915/gem/i915_gem_ttm.c:8:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'vm_fault_ttm':
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1037:38: error: format '%p' expects
>> argument of type 'void *', but argument 4 has type 'int' [-Werror=format=]
1037 | drm_dbg(dev, "Unable to make resource CPU
accessible(err = %pe)\n", err);
|
^ ~~~
|
|
|
int
include/drm/drm_print.h:461:63: note: in definition of macro 'drm_dbg'
461 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
##__VA_ARGS__)
| ^~~
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1037:85: note: format string is
defined here
1037 | drm_dbg(dev, "Unable to make resource CPU
accessible(err = %pe)\n", err);
|
~^
|
|
|
void *
|
%d
cc1: all warnings being treated as errors
vim +1037 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
986
987 static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
988 {
989 struct vm_area_struct *area = vmf->vma;
990 struct ttm_buffer_object *bo = area->vm_private_data;
991 struct drm_device *dev = bo->base.dev;
992 struct drm_i915_gem_object *obj;
993 intel_wakeref_t wakeref = 0;
994 vm_fault_t ret;
995 int idx;
996
997 obj = i915_ttm_to_gem(bo);
998 if (!obj)
999 return VM_FAULT_SIGBUS;
1000
1001 /* Sanity check that we allow writing into this object */
1002 if (unlikely(i915_gem_object_is_readonly(obj) &&
1003 area->vm_flags & VM_WRITE))
1004 return VM_FAULT_SIGBUS;
1005
1006 ret = ttm_bo_vm_reserve(bo, vmf);
1007 if (ret)
1008 return ret;
1009
1010 if (obj->mm.madv != I915_MADV_WILLNEED) {
1011 dma_resv_unlock(bo->base.resv);
1012 return VM_FAULT_SIGBUS;
1013 }
1014
1015 if (i915_ttm_cpu_maps_iomem(bo->resource))
1016 wakeref =
intel_runtime_pm_get(_i915(obj->base.dev)->runtime_pm);
1017
1018 if (!i915_ttm_resource_mappable(bo->resource)) {
1019 int err = -ENODEV;
1020 int i;
1021
1022 for (i = 0; i < obj->mm.n_placements; i++) {
1023 struct intel_memory_region *mr =
obj->mm.placements[i];
1024 unsigned int flags;
1025
1026 if (!mr->io_size && mr->type !=
INTEL_MEMORY_SYSTEM)
1027 continue;
1028
1029 flags = obj->flags;
1030 flags &= ~I915_BO_ALLOC_GPU_ONLY;
1031 err = __i915_ttm_migrate(obj, mr, flags);
Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
Hi Marc, Am 22.09.22 um 16:54 schrieb Marc Kleine-Budde: Hello, I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64, using Debian's v5.19 kernel (Debian's v5.18 was working flawless). | [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] | [0.00] Linux version 5.19.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0 9-01) | [0.00] Machine model: Raspberry Pi 3 Model B+ | [3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11 As soon a the vc4 module is loaded the following warnings hits 4 times, then the machine stops. additionally to Maxime's reply, could you also please provide md5sum and filesize of your bcm2837-rpi-3-b-plus.dtb
Re: [Intel-gfx] [RFC v4 03/14] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
On 22/09/2022 09:09, Tvrtko Ursulin wrote:
On 21/09/2022 19:00, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 10:13:12AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 20 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..3b3ab4abb0a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,14 +11,24 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
I can't spot that you are adding any code which would need this?
I915_GTT_PAGE_SIZE_4K? It is in intel_gtt.h.
This include should have been added in a later patch for calling
i915_gem_vm_lookup(). But got added here while patch refactoring.
Will fix.
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region
**placements,
- unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the
regions
+ * @placements: list of regions
+ * @n_placements: number of the placements
+ *
+ * Calculates the max of the min_page_size of a list of placements
passed in.
+ *
+ * Return: max of the min_page_size
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region
**placements,
+ unsigned int n_placements)
{
- u32 max_page_size = 0;
+ u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
for (i = 0; i < n_placements; i++) {
@@ -28,7 +38,6 @@ static u32 object_max_page_size(struct
intel_memory_region **placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
- GEM_BUG_ON(!max_page_size);
return max_page_size;
}
@@ -99,7 +108,8 @@ __i915_gem_object_create_user_ext(struct
drm_i915_private *i915, u64 size,
i915_gem_flush_free_objects(i915);
- size = round_up(size, object_max_page_size(placements,
n_placements));
+ size = round_up(size, i915_gem_object_max_page_size(placements,
+ n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
Because of the changes above this path is now unreachable. I suppose
it was meant to tell the user "you have supplied no placements"? But
then GEM_BUG_ON (which you remove) used to be wrong.
Yah, looks like an existing problem. May be this "size == 0" check
should have been made before we do the round_up()? ie., check input
'size'
paramter is not 0?
I think for now, I will remove this check as it was unreachable anyhow.
Hm that's true as well. i915_gem_create_ext_ioctl ensures at least one
placement and internal callers do as well.
To be safe, instead of removing maybe move to before "size = " and
change to "if (GEM_WARN_ON(n_placements == 0))"? Not sure.. Matt any
thoughts here given the changes in this patch?
The check is also to reject a zero sized object with args->size = 0, i.e
round_up(0, PAGE_SIZE) == 0. So for sure that is still needed here.
Regards,
Tvrtko
Niranjana
Regards,
Tvrtko
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7317d4102955..8c97bddad921 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64
size)
}
void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region
**placements,
+ unsigned int n_placements);
void i915_objects_module_exit(void);
int i915_objects_module_init(void);
Re: [PATCH v4] drm/sched: Add FIFO sched policy to run queue v3
On 2022-09-22 11:03, Luben Tuikov wrote:
The title of this patch has "v3", but "v4" in the title prefix.
If you're using "-v" to git-format-patch, please remove the "v3" from the title.
Inlined:
On 2022-09-21 14:28, Andrey Grodzovsky wrote:
When many entities competing for same run queue on
the same scheduler When many entities have unacceptably long wait
time for some jobs waiting stuck in the run queue before being picked
up are observed (seen using GPUVis).
Use this as your opening:
"When many entities are competing for the same run queue on the same scheduler,
we observe an unusually long wait times and some jobs get starved. This has
been observed on GPUVis."
The issue is due to the Round Robin policy used by schedulers
to pick up the next entity's job queue for execution. Under stress
of many entities and long job queues within entity some
jobs could be stack for very long time in it's entity's
"stuck", not "stack".
queue before being popped from the queue and executed
while for other entities with smaller job queues a job
might execute earlier even though that job arrived later
then the job in the long queue.
Fix:
Add FIFO selection policy to entities in run queue, chose next entity
on run queue in such order that if job on one entity arrived
earlier then job on another entity the first job will start
executing earlier regardless of the length of the entity's job
queue.
v2:
Switch to rb tree structure for entities based on TS of
oldest job waiting in the job queue of an entity. Improves next
entity extraction to O(1). Entity TS update
O(log N) where N is the number of entities in the run-queue
Drop default option in module control parameter.
v3:
Various cosmetical fixes and minor refactoring of fifo update function. (Luben)
v4:
Switch drm_sched_rq_select_entity_fifo to in order search (Luben)
Signed-off-by: Andrey Grodzovsky
Tested-by: Li Yunxiang (Teddy)
---
drivers/gpu/drm/scheduler/sched_entity.c | 26 +-
drivers/gpu/drm/scheduler/sched_main.c | 107 ++-
include/drm/gpu_scheduler.h | 32 +++
3 files changed, 159 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 6b25b2f4f5a3..f3ffce3c9304 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -73,6 +73,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
entity->priority = priority;
entity->sched_list = num_sched_list > 1 ? sched_list : NULL;
entity->last_scheduled = NULL;
+ RB_CLEAR_NODE(>rb_tree_node);
if(num_sched_list)
entity->rq = _list[0]->sched_rq[entity->priority];
@@ -417,14 +418,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct
drm_sched_entity *entity)
sched_job = to_drm_sched_job(spsc_queue_peek(>job_queue));
if (!sched_job)
- return NULL;
+ goto skip;
while ((entity->dependency =
drm_sched_job_dependency(sched_job, entity))) {
trace_drm_sched_job_wait_dep(sched_job, entity->dependency);
- if (drm_sched_entity_add_dependency_cb(entity))
- return NULL;
+ if (drm_sched_entity_add_dependency_cb(entity)) {
+ sched_job = NULL;
+ goto skip;
+ }
}
/* skip jobs from entity that marked guilty */
@@ -443,6 +446,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct
drm_sched_entity *entity)
smp_wmb();
spsc_queue_pop(>job_queue);
+
+ /*
+* It's when head job is extracted we can access the next job (or empty)
+* queue and update the entity location in the min heap accordingly.
+*/
+skip:
+ if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
+ drm_sched_rq_update_fifo(entity,
+(sched_job ? sched_job->submit_ts :
ktime_get()));
+
return sched_job;
}
@@ -502,11 +515,13 @@ void drm_sched_entity_push_job(struct drm_sched_job *sched_job)
{
struct drm_sched_entity *entity = sched_job->entity;
bool first;
+ ktime_t ts = ktime_get();
trace_drm_sched_job(sched_job, entity);
atomic_inc(entity->rq->sched->score);
WRITE_ONCE(entity->last_user, current->group_leader);
first = spsc_queue_push(>job_queue, _job->queue_node);
+ sched_job->submit_ts = ts;
/* first job wakes up scheduler */
if (first) {
@@ -518,8 +533,13 @@ void drm_sched_entity_push_job(struct drm_sched_job
*sched_job)
DRM_ERROR("Trying to push to a killed entity\n");
return;
}
+
drm_sched_rq_add_entity(entity->rq, entity);
spin_unlock(>rq_lock);
+
+ if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
+
RE: [PATCH 2/5] drm/simpledrm: Use drm_atomic_get_new_plane_state()
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Zimmermann
>Sent: Thursday, September 22, 2022 9:10 AM
>To: javi...@redhat.com; airl...@linux.ie; dan...@ffwll.ch
>Cc: Thomas Zimmermann ; dri-
>de...@lists.freedesktop.org
>Subject: [PATCH 2/5] drm/simpledrm: Use
>drm_atomic_get_new_plane_state()
>
>Lookup the plane's state in atomic_update with the helper
>drm_atomic_get_new_plane_state(). Also rename the helpers'
>state arguments. No functional changes.
>
>Signed-off-by: Thomas Zimmermann
>---
> drivers/gpu/drm/tiny/simpledrm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/tiny/simpledrm.c
>b/drivers/gpu/drm/tiny/simpledrm.c
>index 51d01e34d5eb..14782a50f816 100644
>--- a/drivers/gpu/drm/tiny/simpledrm.c
>+++ b/drivers/gpu/drm/tiny/simpledrm.c
>@@ -470,10 +470,10 @@ static const uint64_t
>simpledrm_primary_plane_format_modifiers[] = {
> };
>
> static void simpledrm_primary_plane_helper_atomic_update(struct
>drm_plane *plane,
>- struct
>drm_atomic_state *old_state)
>+ struct
>drm_atomic_state *state)
> {
>- struct drm_plane_state *plane_state = plane->state;
>- struct drm_plane_state *old_plane_state =
>drm_atomic_get_old_plane_state(old_state, plane);
>+ struct drm_plane_state *plane_state =
>drm_atomic_get_new_plane_state(state, plane);
Going from plane->state to drm_atomic_get_new_plane_state seems like a slight
function change.
If this is the equivalent and the "right" way to do this, should the ->state
part of the data
structure be pruned?
The comment for drm_atomic_get_new_plane_state also says that it can return
NULL.
would plane->state be NULL in this case?
Thanks,
M
>+ struct drm_plane_state *old_plane_state =
>drm_atomic_get_old_plane_state(state, plane);
> struct drm_shadow_plane_state *shadow_plane_state =
> to_drm_shadow_plane_state(plane_state);
> struct drm_framebuffer *fb = plane_state->fb;
> struct drm_device *dev = plane->dev;
>@@ -503,7 +503,7 @@ static void
>simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
> }
>
> static void simpledrm_primary_plane_helper_atomic_disable(struct
>drm_plane *plane,
>-struct
>drm_atomic_state *old_state)
>+struct
>drm_atomic_state *state)
> {
> struct drm_device *dev = plane->dev;
> struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
>--
>2.37.3
Re: [PATCH 07/12] igb: Proactively round up to kmalloc bucket size
On Thu, Sep 22, 2022 at 03:56:54PM +, Ruhl, Michael J wrote: > >From: dri-devel On Behalf Of Kees > >Cook > [...] > >diff --git a/drivers/net/ethernet/intel/igb/igb_main.c > >b/drivers/net/ethernet/intel/igb/igb_main.c > >index 2796e81d2726..4d70ee5b0f79 100644 > >--- a/drivers/net/ethernet/intel/igb/igb_main.c > >+++ b/drivers/net/ethernet/intel/igb/igb_main.c > >@@ -1196,6 +1196,7 @@ static int igb_alloc_q_vector(struct igb_adapter > >*adapter, > > > > ring_count = txr_count + rxr_count; > > size = struct_size(q_vector, ring, ring_count); > >+size = kmalloc_size_roundup(size); > > why not: > > size = kmalloc_size_roundup(struct_size(q_vector, ring, ring_count)); > > ? Sure! I though it might be more readable split up. I will change it. :) -- Kees Cook
[PATCH -next 1/2] drm/rockchip: vop: fix PM usage counter unbalance in vop ops
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
We fix it by replacing it with the newest pm_runtime_resume_and_get
to keep usage counter balanced.
Fixes:5e570373c015b ("drm/rockchip: vop: Enable pm domain before vop_initial")
Fixes:604be85547ce4 ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Zhang Qilong
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c356de5dd220..fa1f4ee6d195 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -602,7 +602,7 @@ static int vop_enable(struct drm_crtc *crtc, struct
drm_crtc_state *old_state)
struct vop *vop = to_vop(crtc);
int ret, i;
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_and_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
@@ -1983,7 +1983,7 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
- ret = pm_runtime_get_sync(vop->dev);
+ ret = pm_runtime_resume_and_get(vop->dev);
if (ret < 0) {
DRM_DEV_ERROR(vop->dev, "failed to get pm runtime: %d\n", ret);
return ret;
--
2.25.1
[PATCH 0/4] drm/bridge: lt8912b: Fix corrupt display output due to wrong bridge config
From: Philippe Schenker This patch-set fixes the lt8912b driver that currently does not take care whether or not the attached display has postiive or negative syncs and or reports on EDID if it needs HDMI mode or DVI. This series addresses also an issue where the LVDS startup sequence was written to the wrong I2C address (the lt8912 has three). This caused writing into reserved registers and causing an unstable HDMI picture that manifests itself only sometimes and depending on the monitor with a flickering and a repeating of going black and coming up again. While at it move also some sensible comments to the sequence. Francesco Dolcini (2): drm/bridge: lt8912b: fix corrupted image output drm/bridge: lt8912b: clarify lvds output status Philippe Schenker (2): drm/bridge: lt8912b: add vsync hsync drm/bridge: lt8912b: set hdmi or dvi mode drivers/gpu/drm/bridge/lontium-lt8912b.c | 39 +--- 1 file changed, 28 insertions(+), 11 deletions(-) -- 2.37.3
[PATCH -next 2/2] drm/rockchip: fix PM usage counter unbalance in poweron
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
We fix it by replacing it with the newest pm_runtime_resume_and_get
to keep usage counter balanced.
Fixes:34cc0aa254560 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Fixes:cca1705c3d895 ("drm/rockchip: lvds: Add PX30 support")
Signed-off-by: Zhang Qilong
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 5a284332ec49..68f6ebb33460 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -152,7 +152,7 @@ static int rk3288_lvds_poweron(struct rockchip_lvds *lvds)
DRM_DEV_ERROR(lvds->dev, "failed to enable lvds pclk %d\n",
ret);
return ret;
}
- ret = pm_runtime_get_sync(lvds->dev);
+ ret = pm_runtime_resume_and_get(lvds->dev);
if (ret < 0) {
DRM_DEV_ERROR(lvds->dev, "failed to get pm runtime: %d\n", ret);
clk_disable(lvds->pclk);
@@ -336,16 +336,20 @@ static int px30_lvds_poweron(struct rockchip_lvds *lvds)
{
int ret;
- ret = pm_runtime_get_sync(lvds->dev);
+ ret = pm_runtime_resume_and_get(lvds->dev);
if (ret < 0) {
DRM_DEV_ERROR(lvds->dev, "failed to get pm runtime: %d\n", ret);
return ret;
}
/* Enable LVDS mode */
- return regmap_update_bits(lvds->grf, PX30_LVDS_GRF_PD_VO_CON1,
+ ret = regmap_update_bits(lvds->grf, PX30_LVDS_GRF_PD_VO_CON1,
PX30_LVDS_MODE_EN(1) | PX30_LVDS_P2S_EN(1),
PX30_LVDS_MODE_EN(1) | PX30_LVDS_P2S_EN(1));
+ if (ret)
+ pm_runtime_put(lvds->dev);
+
+ return ret;
}
static void px30_lvds_poweroff(struct rockchip_lvds *lvds)
--
2.25.1
[PATCH 3/4] drm/bridge: lt8912b: fix corrupted image output
From: Francesco Dolcini
Correct I2C address for the register list in lt8912_write_lvds_config(),
these registers are on the first I2C address (0x48), the current
function is just writing garbage to the wrong registers and this creates
multiple issues (artifacts and output completely corrupted) on some HDMI
displays.
Correct I2C address comes from Lontium documentation and it is the one
used on other out-of-tree LT8912B drivers [1].
[1]
https://github.com/boundarydevices/linux/blob/boundary-imx_5.10.x_2.0.0/drivers/video/lt8912.c#L296
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Signed-off-by: Francesco Dolcini
Signed-off-by: Philippe Schenker
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 6a4bb7422176..5968f4af190b 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -188,7 +188,7 @@ static int lt8912_write_lvds_config(struct lt8912 *lt)
{0x03, 0xff},
};
- return regmap_multi_reg_write(lt->regmap[I2C_CEC_DSI], seq,
ARRAY_SIZE(seq));
+ return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq,
ARRAY_SIZE(seq));
};
static inline struct lt8912 *bridge_to_lt8912(struct drm_bridge *b)
--
2.37.3
[PATCH 1/4] drm/bridge: lt8912b: add vsync hsync
From: Philippe Schenker
Currently the bridge driver does not take care whether or not the display
needs positive/negative vertical/horizontal syncs. Pass these two flags
to the bridge from the EDID that was read out from the display.
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Signed-off-by: Philippe Schenker
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 28bad30dc4e5..0fd3472e767c 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -268,7 +268,7 @@ static int lt8912_video_setup(struct lt8912 *lt)
u32 hactive, h_total, hpw, hfp, hbp;
u32 vactive, v_total, vpw, vfp, vbp;
u8 settle = 0x08;
- int ret;
+ int ret, hsync_activehigh, vsync_activehigh;
if (!lt)
return -EINVAL;
@@ -278,12 +278,14 @@ static int lt8912_video_setup(struct lt8912 *lt)
hpw = lt->mode.hsync_len;
hbp = lt->mode.hback_porch;
h_total = hactive + hfp + hpw + hbp;
+ hsync_activehigh = lt->mode.flags & DISPLAY_FLAGS_HSYNC_HIGH;
vactive = lt->mode.vactive;
vfp = lt->mode.vfront_porch;
vpw = lt->mode.vsync_len;
vbp = lt->mode.vback_porch;
v_total = vactive + vfp + vpw + vbp;
+ vsync_activehigh = lt->mode.flags & DISPLAY_FLAGS_VSYNC_HIGH;
if (vactive <= 600)
settle = 0x04;
@@ -317,6 +319,11 @@ static int lt8912_video_setup(struct lt8912 *lt)
ret |= regmap_write(lt->regmap[I2C_CEC_DSI], 0x3e, hfp & 0xff);
ret |= regmap_write(lt->regmap[I2C_CEC_DSI], 0x3f, hfp >> 8);
+ ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xab, BIT(0),
+ vsync_activehigh ? BIT(0) : 0);
+ ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xab, BIT(1),
+ hsync_activehigh ? BIT(1) : 0);
+
return ret;
}
--
2.37.3
[PATCH] gpu: host1x: use DEFINE_SHOW_ATTRIBUTE to simplify host1x_debug/host1x_debug_all
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code.
No functional change.
Signed-off-by: Liu Shixin
---
drivers/gpu/host1x/debug.c | 28 +++-
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
index 34c2e36d09e9..6649b04b7131 100644
--- a/drivers/gpu/host1x/debug.c
+++ b/drivers/gpu/host1x/debug.c
@@ -140,7 +140,7 @@ static void show_all(struct host1x *m, struct output *o,
bool show_fifo)
}
}
-static int host1x_debug_show_all(struct seq_file *s, void *unused)
+static int host1x_debug_all_show(struct seq_file *s, void *unused)
{
struct output o = {
.fn = write_to_seqfile,
@@ -151,6 +151,7 @@ static int host1x_debug_show_all(struct seq_file *s, void
*unused)
return 0;
}
+DEFINE_SHOW_ATTRIBUTE(host1x_debug_all);
static int host1x_debug_show(struct seq_file *s, void *unused)
{
@@ -163,30 +164,7 @@ static int host1x_debug_show(struct seq_file *s, void
*unused)
return 0;
}
-
-static int host1x_debug_open_all(struct inode *inode, struct file *file)
-{
- return single_open(file, host1x_debug_show_all, inode->i_private);
-}
-
-static const struct file_operations host1x_debug_all_fops = {
- .open = host1x_debug_open_all,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
-
-static int host1x_debug_open(struct inode *inode, struct file *file)
-{
- return single_open(file, host1x_debug_show, inode->i_private);
-}
-
-static const struct file_operations host1x_debug_fops = {
- .open = host1x_debug_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(host1x_debug);
static void host1x_debugfs_init(struct host1x *host1x)
{
--
2.25.1
[PATCH] drm/msm/dpu: use DEFINE_SHOW_ATTRIBUTE to simplify dpu_regset32
Use DEFINE_SHOW_ATTRIBUTE helper macro to simplify the code.
No functional change.
Signed-off-by: Liu Shixin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5e6e2626151e..f3660cd14f4f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -194,7 +194,7 @@ struct dpu_debugfs_regset32 {
struct dpu_kms *dpu_kms;
};
-static int _dpu_debugfs_show_regset32(struct seq_file *s, void *data)
+static int dpu_regset32_show(struct seq_file *s, void *data)
{
struct dpu_debugfs_regset32 *regset = s->private;
struct dpu_kms *dpu_kms = regset->dpu_kms;
@@ -227,19 +227,7 @@ static int _dpu_debugfs_show_regset32(struct seq_file *s,
void *data)
return 0;
}
-
-static int dpu_debugfs_open_regset32(struct inode *inode,
- struct file *file)
-{
- return single_open(file, _dpu_debugfs_show_regset32, inode->i_private);
-}
-
-static const struct file_operations dpu_fops_regset32 = {
- .open = dpu_debugfs_open_regset32,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(dpu_regset32);
void dpu_debugfs_create_regset32(const char *name, umode_t mode,
void *parent,
@@ -259,7 +247,7 @@ void dpu_debugfs_create_regset32(const char *name, umode_t
mode,
regset->blk_len = length;
regset->dpu_kms = dpu_kms;
- debugfs_create_file(name, mode, parent, regset, _fops_regset32);
+ debugfs_create_file(name, mode, parent, regset, _regset32_fops);
}
static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
--
2.25.1
[PATCH] dma-buf: Add __init annotation to module init func
Add missing __init annotation to module init func.
Signed-off-by: Xiu Jianfeng
---
drivers/dma-buf/heaps/cma_heap.c| 2 +-
drivers/dma-buf/heaps/system_heap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 28fb04eccdd0..62d0d0e8b10d 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -392,7 +392,7 @@ static int __add_cma_heap(struct cma *cma, void *data)
return 0;
}
-static int add_default_cma_heap(void)
+static int __init add_default_cma_heap(void)
{
struct cma *default_cma = dev_get_cma_area(NULL);
int ret = 0;
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index fcf836ba9c1f..cbe445bc5bab 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -422,7 +422,7 @@ static const struct dma_heap_ops system_heap_ops = {
.allocate = system_heap_allocate,
};
-static int system_heap_create(void)
+static int __init system_heap_create(void)
{
struct dma_heap_export_info exp_info;
--
2.17.1
[PATCH 2/4] drm/bridge: lt8912b: set hdmi or dvi mode
From: Philippe Schenker
The Lontium LT8912 does have a setting for DVI or HDMI. This patch reads
from EDID what the display needs and sets it accordingly.
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Signed-off-by: Philippe Schenker
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 0fd3472e767c..6a4bb7422176 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -323,6 +323,8 @@ static int lt8912_video_setup(struct lt8912 *lt)
vsync_activehigh ? BIT(0) : 0);
ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xab, BIT(1),
hsync_activehigh ? BIT(1) : 0);
+ ret |= regmap_update_bits(lt->regmap[I2C_MAIN], 0xb2, BIT(0),
+ lt->connector.display_info.is_hdmi ? BIT(0) :
0);
return ret;
}
--
2.37.3
[PATCH -next 0/2] fix PM usage counter unbalance
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with the newest pm_runtime_resume_and_get to keep usage counter balanced. Zhang Qilong (2): drm/rockchip: vop: fix PM usage counter unbalance in vop ops drm/rockchip: fix PM usage counter unbalance in poweron drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++-- drivers/gpu/drm/rockchip/rockchip_lvds.c| 10 +++--- 2 files changed, 9 insertions(+), 5 deletions(-) -- 2.25.1
[PATCH 4/4] drm/bridge: lt8912b: clarify lvds output status
From: Francesco Dolcini
Add comments on the lt8912_write_lvds_config() config to document the
current settings and to make it clear that this is a hardcoded
configuration not relevant for the HDMI output (could be removed without
affecting the HDMI port).
No changes on the actual register writes.
Signed-off-by: Francesco Dolcini
Signed-off-by: Philippe Schenker
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 26
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 5968f4af190b..3e870d45f881 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -165,24 +165,32 @@ static int lt8912_write_rxlogicres_config(struct lt8912
*lt)
return ret;
};
+/* enable LVDS output with some hardcoded configuration, not required for the
HDMI output */
static int lt8912_write_lvds_config(struct lt8912 *lt)
{
const struct reg_sequence seq[] = {
+ // lvds power up
{0x44, 0x30},
{0x51, 0x05},
- {0x50, 0x24},
- {0x51, 0x2d},
- {0x52, 0x04},
- {0x69, 0x0e},
+
+ // core pll bypass
+ {0x50, 0x24}, // cp=50uA
+ {0x51, 0x2d}, // Pix_clk as reference, second order passive LPF
PLL
+ {0x52, 0x04}, // loopdiv=0, use second-order PLL
+ {0x69, 0x0e}, // CP_PRESET_DIV_RATIO
{0x69, 0x8e},
{0x6a, 0x00},
- {0x6c, 0xb8},
+ {0x6c, 0xb8}, // RGD_CP_SOFT_K_EN,RGD_CP_SOFT_K[13:8]
{0x6b, 0x51},
- {0x04, 0xfb},
+
+ {0x04, 0xfb}, // core pll reset
{0x04, 0xff},
- {0x7f, 0x00},
- {0xa8, 0x13},
- {0x02, 0xf7},
+
+ // scaler bypass
+ {0x7f, 0x00}, // disable scaler
+ {0xa8, 0x13}, // 0x13: JEIDA, 0x33: VESA
+
+ {0x02, 0xf7}, // lvds pll reset
{0x02, 0xff},
{0x03, 0xcf},
{0x03, 0xff},
--
2.37.3
Re: [PATCH 03/12] net: ipa: Proactively round up to kmalloc bucket size
On Thu, Sep 22, 2022 at 08:45:19AM -0500, Alex Elder wrote:
> On 9/21/22 10:10 PM, Kees Cook wrote:
> > Instead of discovering the kmalloc bucket size _after_ allocation, round
> > up proactively so the allocation is explicitly made for the full size,
> > allowing the compiler to correctly reason about the resulting size of
> > the buffer through the existing __alloc_size() hint.
> >
> > Cc: Alex Elder
> > Cc: "David S. Miller"
> > Cc: Eric Dumazet
> > Cc: Jakub Kicinski
> > Cc: Paolo Abeni
> > Cc: net...@vger.kernel.org
> > Signed-off-by: Kees Cook
> > ---
> > drivers/net/ipa/gsi_trans.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ipa/gsi_trans.c b/drivers/net/ipa/gsi_trans.c
> > index 18e7e8c405be..cec968854dcf 100644
> > --- a/drivers/net/ipa/gsi_trans.c
> > +++ b/drivers/net/ipa/gsi_trans.c
> > @@ -89,6 +89,7 @@ int gsi_trans_pool_init(struct gsi_trans_pool *pool,
> > size_t size, u32 count,
> > u32 max_alloc)
> > {
> > void *virt;
> > + size_t allocate;
>
> I don't care about this but the reverse Christmas tree
> convention would put the "allocate" variable definition
> above "virt".
Oops, yes; thank you!
-Kees
--
Kees Cook
RE: [PATCH 07/12] igb: Proactively round up to kmalloc bucket size
>-Original Message- >From: dri-devel On Behalf Of >Kees Cook >Sent: Wednesday, September 21, 2022 11:10 PM >To: Vlastimil Babka >Cc: linux-wirel...@vger.kernel.org; Jacob Shin ; >l...@lists.linux.dev; dri-devel@lists.freedesktop.org; linux...@kvack.org; >Eric Dumazet ; Nguyen, Anthony L >; linux-harden...@vger.kernel.org; Sumit >Semwal ; d...@openvswitch.org; x...@kernel.org; >Brandeburg, Jesse ; intel-wired- >l...@lists.osuosl.org; David Rientjes ; Miguel Ojeda >; Yonghong Song ; Paolo Abeni >; linux-me...@vger.kernel.org; Marco Elver >; Kees Cook ; Josef Bacik >; linaro-mm-...@lists.linaro.org; Jakub Kicinski >; David Sterba ; Joonsoo Kim >; Alex Elder ; Greg Kroah- >Hartman ; Nick Desaulniers >; linux-ker...@vger.kernel.org; David S. Miller >; Pekka Enberg ; Daniel >Micay ; net...@vger.kernel.org; linux- >fsde...@vger.kernel.org; Andrew Morton ; >Christian König ; linux-bt...@vger.kernel.org >Subject: [PATCH 07/12] igb: Proactively round up to kmalloc bucket size > >Instead of having a mismatch between the requested allocation size and >the actual kmalloc bucket size, which is examined later via ksize(), >round up proactively so the allocation is explicitly made for the full >size, allowing the compiler to correctly reason about the resulting size >of the buffer through the existing __alloc_size() hint. > >Cc: Jesse Brandeburg >Cc: Tony Nguyen >Cc: "David S. Miller" >Cc: Eric Dumazet >Cc: Jakub Kicinski >Cc: Paolo Abeni >Cc: intel-wired-...@lists.osuosl.org >Cc: net...@vger.kernel.org >Signed-off-by: Kees Cook >--- > drivers/net/ethernet/intel/igb/igb_main.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/drivers/net/ethernet/intel/igb/igb_main.c >b/drivers/net/ethernet/intel/igb/igb_main.c >index 2796e81d2726..4d70ee5b0f79 100644 >--- a/drivers/net/ethernet/intel/igb/igb_main.c >+++ b/drivers/net/ethernet/intel/igb/igb_main.c >@@ -1196,6 +1196,7 @@ static int igb_alloc_q_vector(struct igb_adapter >*adapter, > > ring_count = txr_count + rxr_count; > size = struct_size(q_vector, ring, ring_count); >+ size = kmalloc_size_roundup(size); why not: size = kmalloc_size_roundup(struct_size(q_vector, ring, ring_count)); ? m > /* allocate q_vector and rings */ > q_vector = adapter->q_vector[v_idx]; >-- >2.34.1
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On 22-09-2022 19:26, Lucas De Marchi wrote:
> On Wed, Sep 21, 2022 at 12:00:38PM +0530, Iddamsetty, Aravind wrote:
>> replying here for earlier comments too.
>>
>> On 21-09-2022 01:35, Lucas De Marchi wrote:
>>> On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
> As an integrated GPU, MTL does not have local memory and
> HAS_LMEM() returns false. However the platform's stolen memory
> is presented via BAR2 (i.e., the BAR we traditionally consider
> to be the LMEM BAR) and should be managed by the driver the same
> way that local memory is on dgpu platforms (which includes
> setting the "lmem" bit on page table entries). We use the term
> "local stolen memory" to refer to this model.
>
> Cc: Matt Roper
> Cc: Lucas De Marchi
>
> Signed-off-by: CQ Tang
> Signed-off-by: Aravind Iddamsetty
> Original-author: CQ Tang
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> 3 files changed, 100 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index acc561c0f0aa..bad5250fb764 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct
> drm_i915_private *i915,
> mutex_unlock(>mm.stolen_lock);
> }
>
> +static bool is_dsm_invalid(struct drm_i915_private *i915, struct
> resource *dsm)
> +{
> + if (!HAS_BAR2_SMEM_STOLEN(i915)) {
I called a similar function as is_dsm_valid() in
https://patchwork.freedesktop.org/series/108620/
sounds weird with "invalid" and the double negation on return early
style.
>>
>> sure, will change it hope i can use that from your patch.
>
> that patch is now pushed, so now you can reuse it.
Thanks for the info and help.
Aravind.
>
> Lucas De Marchi
Re: [PATCH 11/12] slab: Remove __malloc attribute from realloc functions
On Thu, Sep 22, 2022 at 11:23:46AM +0200, Miguel Ojeda wrote: > On Thu, Sep 22, 2022 at 5:10 AM Kees Cook wrote: > > > > -#ifdef __alloc_size__ > > -# define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc > > -#else > > -# define __alloc_size(x, ...) __malloc > > -#endif > > +#define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc > > +#define __realloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) > > These look unconditional now, so we could move it to > `compiler_attributes.h` in a later patch (or an independent series). I wasn't sure if this "composite macro" was sane there, especially since it would be using __malloc before it was defined, etc. Would you prefer I move it? -- Kees Cook
Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup()
On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote: > Am 22.09.22 um 05:10 schrieb Kees Cook: > > Hi, > > > > This series fixes up the cases where callers of ksize() use it to > > opportunistically grow their buffer sizes, which can run afoul of the > > __alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE > > use to perform dynamic buffer bounds checking. > > Good cleanup, but one question: What other use cases we have for ksize() > except the opportunistically growth of buffers? The remaining cases all seem to be using it as a "do we need to resize yet?" check, where they don't actually track the allocation size themselves and want to just depend on the slab cache to answer it. This is most clearly seen in the igp code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_main.c?h=v6.0-rc6#n1204 My "solution" there kind of side-steps it, and leaves ksize() as-is: https://lore.kernel.org/linux-hardening/20220922031013.2150682-8-keesc...@chromium.org/ The more correct solution would be to add per-v_idx size tracking, similar to the other changes I sent: https://lore.kernel.org/linux-hardening/20220922031013.2150682-11-keesc...@chromium.org/ I wonder if perhaps I should just migrate some of this code to using something like struct membuf. > Off hand I can't see any. > > So when this patch set is about to clean up this use case it should probably > also take care to remove ksize() or at least limit it so that it won't be > used for this use case in the future. Yeah, my goal would be to eliminate ksize(), and it seems possible if other cases are satisfied with tracking their allocation sizes directly. -Kees -- Kees Cook
Re: [PATCH v2 1/7] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
On 22/09/2022 02:14, Bjorn Andersson wrote: > On Tue, Sep 20, 2022 at 09:09:13AM +0200, Krzysztof Kozlowski wrote: >> On 19/09/2022 23:18, Bjorn Andersson wrote: >>> On Sat, Sep 17, 2022 at 06:03:27PM +0100, Krzysztof Kozlowski wrote: On 16/09/2022 21:00, Bjorn Andersson wrote: > From: Bjorn Andersson > > Add compatibles for the DisplayPort and Embedded DisplayPort blocks in > Qualcomm SDM845 and SC8280XP platforms. > > Signed-off-by: Bjorn Andersson > Signed-off-by: Bjorn Andersson No need for quicinc SoB (unless you also take ownership). >>> >>> It's my understanding that both needs to be there. Bjorn @ Linaro >>> authored the patch and the author must certify its origin, but as the >>> submitter I must certify its origin. >> >> It's the same person. There are no two Bjorns (unless there are :) ), so >> you certify with old email. SoB chain is coming from people, not email >> addresses. >> > > IANAL, but I don't think it's the same person. I can't use my old > signature to certify the origin in a contribution today and I can't > claim authorship of something Linaro did. Fine with me. > >> And it is not only my understanding of SoB chain. >> https://lore.kernel.org/all/yukcbo5jatwry...@kroah.com/ >> > > Again, IANAL, but I think the situation is different given AMD and > Xilinx relationship. Hm, I am not sure how it is different. We might know or we might know the change of ownership. Maybe the change of owner came with copyrights, maybe not (someone else bought them). I don't know, there can be many cases here. I interpret Greg's point there as in SoB statement - the person, not email address, certifies. Anyway, this is not a blocker for the patch. Best regards, Krzysztof
Re: [PATCH v2 1/2] dt-bindings: display/panel: Add Sony Tama TD4353 JDI display panel
On 22/09/2022 17:16, Konrad Dybcio wrote: >> >> How about bringing them closer to common GPIOs: >> panel-reset-gpios >> ? >> >>> +description: Display panel reset pin >>> + >>> + treset-gpios: >> >> touch-reset-gpios >> > I can do that. I will however wait with resending in case somebody has > comments > on the .c driver. Sure, makes sense. Best regards, Krzysztof
Re: [PATCH v2 1/2] dt-bindings: display/panel: Add Sony Tama TD4353 JDI display panel
On 22.09.2022 17:11, Krzysztof Kozlowski wrote: > On 22/09/2022 15:58, Konrad Dybcio wrote: >> Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2 >> Compact smartphones. >> >> Signed-off-by: Konrad Dybcio > > Thank you for your patch. There is something to discuss/improve. > >> + >> + reg: true >> + >> + backlight: true >> + >> + vddio-supply: >> +description: VDDIO 1.8V supply >> + >> + vsp-supply: >> +description: Positive 5.5V supply >> + >> + vsn-supply: >> +description: Negative 5.5V supply >> + >> + preset-gpios: > > How about bringing them closer to common GPIOs: > panel-reset-gpios > ? > >> +description: Display panel reset pin >> + >> + treset-gpios: > > touch-reset-gpios > I can do that. I will however wait with resending in case somebody has comments on the .c driver. Konrad > > Best regards, > Krzysztof >
Re: [PATCH v2 1/2] dt-bindings: display/panel: Add Sony Tama TD4353 JDI display panel
On 22/09/2022 15:58, Konrad Dybcio wrote: > Add bindings for the display panel used on some Sony Xperia XZ2 and XZ2 > Compact smartphones. > > Signed-off-by: Konrad Dybcio Thank you for your patch. There is something to discuss/improve. > + > + reg: true > + > + backlight: true > + > + vddio-supply: > +description: VDDIO 1.8V supply > + > + vsp-supply: > +description: Positive 5.5V supply > + > + vsn-supply: > +description: Negative 5.5V supply > + > + preset-gpios: How about bringing them closer to common GPIOs: panel-reset-gpios ? > +description: Display panel reset pin > + > + treset-gpios: touch-reset-gpios Best regards, Krzysztof
Re: Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
Hi, On Thu, Sep 22, 2022 at 04:54:48PM +0200, Marc Kleine-Budde wrote: > Hello, > > I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64, > using Debian's v5.19 kernel (Debian's v5.18 was working flawless). > > | [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] > > > | [0.00] Linux version 5.19.0-1-arm64 > (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld > (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0 > 9-01) > > > | [0.00] Machine model: Raspberry Pi 3 Model B+ > | [3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from > 2022-03-24T13:21:11 > > As soon a the vc4 module is loaded the following warnings hits 4 > times, then the machine stops. > > | [ 66.839210] Console: switching to colour dummy device 80x25 > | [ 66.861282] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4]) > | [ 66.868418] [ cut here ] > | [ 66.873110] WARNING: CPU: 3 PID: 611 at > drivers/gpu/drm/vc4/vc4_hdmi_regs.h:456 vc4_hdmi_reset+0x3e8/0x540 [vc4] > | [ 66.883495] Modules linked in: vc4(+) ccm cpufreq_userspace > cpufreq_powersave cpufreq_ondemand cpufreq_conservative nls_ascii nls_cp437 > vfat fat ext4 mbcache jbd2 hci_uart btqca btrtl btbcm btintel btsdio > bluetooth bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) jitterentropy_rng > | videobuf2_vmalloc sha512_generic videobuf2_memops rt2800usb snd_soc_core > videobuf2_v4l2 rt2x00usb microchip videobuf2_common snd_bcm2835(C) rt2800lib > snd_pcm_dmaengine sha512_arm64 bridge videodev snd_pcm rt2x00lib snd_timer > aes_neon_bs lan78xx mc cec stp snd mac80211 aes_n > | eon_blk rc_core brcmfmac llc drm_display_helper soundcore drm_cma_helper > of_mdio cpufreq_dt drbg libarc4 fixed_phy drm_kms_helper brcmutil fwnode_mdio > libphy ansi_cprng cfg80211 vchiq(C) ecdh_generic raspberrypi_cpufreq ecc > bcm2835_rng crc16 bcm2835_thermal rng_core rfkill > | pwm_bcm2835 bcm2835_wdt leds_gpio fuse drm configfs lz4 lz4_compress zram > zsmalloc ip_tables x_tables autofs4 btrfs blake2b_generic xor xor_neon > raid6_pq zstd_compress libcrc32c > | [ 66.883758] crc32c_generic xxhash_generic dwc2 udc_core roles usbcore > sdhci_iproc sdhci_pltfm crct10dif_ce crct10dif_common usb_common sdhci > bcm2835 i2c_bcm2835 phy_generic > | [ 66.987722] CPU: 3 PID: 611 Comm: insmod Tainted: G C > 5.19.0-1-arm64 #1 Debian 5.19.6-1 > | [ 66.997253] Hardware name: Raspberry Pi 3 Model B+ (DT) > | [ 67.002549] pstate: 60c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > | [ 67.009610] pc : vc4_hdmi_reset+0x3e8/0x540 [vc4] > | [ 67.014426] lr : vc4_hdmi_reset+0x24/0x540 [vc4] > | [ 67.019153] sp : 8ab83660 > | [ 67.022510] x29: 8ab83660 x28: 055fd460 x27: > 09465080 > | [ 67.029753] x26: x25: 88fbe740 x24: > 89d582f0 > | [ 67.036995] x23: 0dabb000 x22: 05144000 x21: > 13dc7180 > | [ 67.044237] x20: x19: 09465080 x18: > > | [ 67.051479] x17: x16: x15: > 13dc7f14 > | [ 67.058721] x14: x13: 13dc7f10 x12: > 0101010101010101 > | [ 67.065963] x11: 0040 x10: f8858c10 x9 : > 8173ceb4 > | [ 67.073205] x8 : 0101010101010101 x7 : x6 : > 0b3ad140 > | [ 67.080447] x5 : 09465ca8 x4 : x3 : > 09465ca8 > | [ 67.087689] x2 : 0001 x1 : 0002 x0 : > 81753090 > | [ 67.094932] Call trace: > | [ 67.097407] vc4_hdmi_reset+0x3e8/0x540 [vc4] > | [ 67.101869] vc4_hdmi_runtime_resume+0x74/0x360 [vc4] > | [ 67.107036] vc4_hdmi_bind+0x218/0xa20 [vc4] > | [ 67.111407] component_bind_all+0x130/0x290 > | [ 67.115653] vc4_drm_bind+0x10c/0x2e0 [vc4] > | [ 67.119936] try_to_bring_up_aggregate_device+0x230/0x320 > | [ 67.125411] component_master_add_with_match+0xd4/0x11c > | [ 67.130710] vc4_platform_drm_probe+0xd0/0x110 [vc4] > | [ 67.135787] platform_probe+0x74/0xf0 > | [ 67.139501] really_probe+0x19c/0x3f0 > | [ 67.143213] __driver_probe_device+0x11c/0x190 > | [ 67.147719] driver_probe_device+0x44/0xf4 > | [ 67.151872] __driver_attach+0xd8/0x220 > | [ 67.155760] bus_for_each_dev+0x7c/0xe0 > | [ 67.159649] driver_attach+0x30/0x40 > | [ 67.163272] bus_add_driver+0x154/0x240 > | [ 67.167162] driver_register+0x84/0x140 > | [ 67.171051] __platform_driver_register+0x34/0x40 > | [ 67.175821] vc4_drm_register+0x5c/0x1000 [vc4]
Re: [PATCH v4] drm/sched: Add FIFO sched policy to run queue v3
The title of this patch has "v3", but "v4" in the title prefix.
If you're using "-v" to git-format-patch, please remove the "v3" from the title.
Inlined:
On 2022-09-21 14:28, Andrey Grodzovsky wrote:
> When many entities competing for same run queue on
> the same scheduler When many entities have unacceptably long wait
> time for some jobs waiting stuck in the run queue before being picked
> up are observed (seen using GPUVis).
Use this as your opening:
"When many entities are competing for the same run queue on the same scheduler,
we observe an unusually long wait times and some jobs get starved. This has
been observed on GPUVis."
> The issue is due to the Round Robin policy used by schedulers
> to pick up the next entity's job queue for execution. Under stress
> of many entities and long job queues within entity some
> jobs could be stack for very long time in it's entity's
"stuck", not "stack".
> queue before being popped from the queue and executed
> while for other entities with smaller job queues a job
> might execute earlier even though that job arrived later
> then the job in the long queue.
>
> Fix:
> Add FIFO selection policy to entities in run queue, chose next entity
> on run queue in such order that if job on one entity arrived
> earlier then job on another entity the first job will start
> executing earlier regardless of the length of the entity's job
> queue.
>
> v2:
> Switch to rb tree structure for entities based on TS of
> oldest job waiting in the job queue of an entity. Improves next
> entity extraction to O(1). Entity TS update
> O(log N) where N is the number of entities in the run-queue
>
> Drop default option in module control parameter.
>
> v3:
> Various cosmetical fixes and minor refactoring of fifo update function.
> (Luben)
>
> v4:
> Switch drm_sched_rq_select_entity_fifo to in order search (Luben)
>
> Signed-off-by: Andrey Grodzovsky
> Tested-by: Li Yunxiang (Teddy)
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 26 +-
> drivers/gpu/drm/scheduler/sched_main.c | 107 ++-
> include/drm/gpu_scheduler.h | 32 +++
> 3 files changed, 159 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index 6b25b2f4f5a3..f3ffce3c9304 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -73,6 +73,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
> entity->priority = priority;
> entity->sched_list = num_sched_list > 1 ? sched_list : NULL;
> entity->last_scheduled = NULL;
> + RB_CLEAR_NODE(>rb_tree_node);
>
> if(num_sched_list)
> entity->rq = _list[0]->sched_rq[entity->priority];
> @@ -417,14 +418,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct
> drm_sched_entity *entity)
>
> sched_job = to_drm_sched_job(spsc_queue_peek(>job_queue));
> if (!sched_job)
> - return NULL;
> + goto skip;
>
> while ((entity->dependency =
> drm_sched_job_dependency(sched_job, entity))) {
> trace_drm_sched_job_wait_dep(sched_job, entity->dependency);
>
> - if (drm_sched_entity_add_dependency_cb(entity))
> - return NULL;
> + if (drm_sched_entity_add_dependency_cb(entity)) {
> + sched_job = NULL;
> + goto skip;
> + }
> }
>
> /* skip jobs from entity that marked guilty */
> @@ -443,6 +446,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct
> drm_sched_entity *entity)
> smp_wmb();
>
> spsc_queue_pop(>job_queue);
> +
> + /*
> + * It's when head job is extracted we can access the next job (or empty)
> + * queue and update the entity location in the min heap accordingly.
> + */
> +skip:
> + if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
> + drm_sched_rq_update_fifo(entity,
> + (sched_job ? sched_job->submit_ts :
> ktime_get()));
> +
> return sched_job;
> }
>
> @@ -502,11 +515,13 @@ void drm_sched_entity_push_job(struct drm_sched_job
> *sched_job)
> {
> struct drm_sched_entity *entity = sched_job->entity;
> bool first;
> + ktime_t ts = ktime_get();
>
> trace_drm_sched_job(sched_job, entity);
> atomic_inc(entity->rq->sched->score);
> WRITE_ONCE(entity->last_user, current->group_leader);
> first = spsc_queue_push(>job_queue, _job->queue_node);
> + sched_job->submit_ts = ts;
>
> /* first job wakes up scheduler */
> if (first) {
> @@ -518,8 +533,13 @@ void drm_sched_entity_push_job(struct drm_sched_job
> *sched_job)
> DRM_ERROR("Trying to push to a killed entity\n");
> return;
> }
> +
>
Raspberry Pi 3 Model B+ hangs in vc4_hdmi_runtime_resume()
Hello, I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64, using Debian's v5.19 kernel (Debian's v5.18 was working flawless). | [0.00] Booting Linux on physical CPU 0x00 [0x410fd034] | [0.00] Linux version 5.19.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0 9-01) | [0.00] Machine model: Raspberry Pi 3 Model B+ | [3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11 As soon a the vc4 module is loaded the following warnings hits 4 times, then the machine stops. | [ 66.839210] Console: switching to colour dummy device 80x25 | [ 66.861282] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4]) | [ 66.868418] [ cut here ] | [ 66.873110] WARNING: CPU: 3 PID: 611 at drivers/gpu/drm/vc4/vc4_hdmi_regs.h:456 vc4_hdmi_reset+0x3e8/0x540 [vc4] | [ 66.883495] Modules linked in: vc4(+) ccm cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative nls_ascii nls_cp437 vfat fat ext4 mbcache jbd2 hci_uart btqca btrtl btbcm btintel btsdio bluetooth bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) jitterentropy_rng | videobuf2_vmalloc sha512_generic videobuf2_memops rt2800usb snd_soc_core videobuf2_v4l2 rt2x00usb microchip videobuf2_common snd_bcm2835(C) rt2800lib snd_pcm_dmaengine sha512_arm64 bridge videodev snd_pcm rt2x00lib snd_timer aes_neon_bs lan78xx mc cec stp snd mac80211 aes_n | eon_blk rc_core brcmfmac llc drm_display_helper soundcore drm_cma_helper of_mdio cpufreq_dt drbg libarc4 fixed_phy drm_kms_helper brcmutil fwnode_mdio libphy ansi_cprng cfg80211 vchiq(C) ecdh_generic raspberrypi_cpufreq ecc bcm2835_rng crc16 bcm2835_thermal rng_core rfkill | pwm_bcm2835 bcm2835_wdt leds_gpio fuse drm configfs lz4 lz4_compress zram zsmalloc ip_tables x_tables autofs4 btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress libcrc32c | [ 66.883758] crc32c_generic xxhash_generic dwc2 udc_core roles usbcore sdhci_iproc sdhci_pltfm crct10dif_ce crct10dif_common usb_common sdhci bcm2835 i2c_bcm2835 phy_generic | [ 66.987722] CPU: 3 PID: 611 Comm: insmod Tainted: G C 5.19.0-1-arm64 #1 Debian 5.19.6-1 | [ 66.997253] Hardware name: Raspberry Pi 3 Model B+ (DT) | [ 67.002549] pstate: 60c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | [ 67.009610] pc : vc4_hdmi_reset+0x3e8/0x540 [vc4] | [ 67.014426] lr : vc4_hdmi_reset+0x24/0x540 [vc4] | [ 67.019153] sp : 8ab83660 | [ 67.022510] x29: 8ab83660 x28: 055fd460 x27: 09465080 | [ 67.029753] x26: x25: 88fbe740 x24: 89d582f0 | [ 67.036995] x23: 0dabb000 x22: 05144000 x21: 13dc7180 | [ 67.044237] x20: x19: 09465080 x18: | [ 67.051479] x17: x16: x15: 13dc7f14 | [ 67.058721] x14: x13: 13dc7f10 x12: 0101010101010101 | [ 67.065963] x11: 0040 x10: f8858c10 x9 : 8173ceb4 | [ 67.073205] x8 : 0101010101010101 x7 : x6 : 0b3ad140 | [ 67.080447] x5 : 09465ca8 x4 : x3 : 09465ca8 | [ 67.087689] x2 : 0001 x1 : 0002 x0 : 81753090 | [ 67.094932] Call trace: | [ 67.097407] vc4_hdmi_reset+0x3e8/0x540 [vc4] | [ 67.101869] vc4_hdmi_runtime_resume+0x74/0x360 [vc4] | [ 67.107036] vc4_hdmi_bind+0x218/0xa20 [vc4] | [ 67.111407] component_bind_all+0x130/0x290 | [ 67.115653] vc4_drm_bind+0x10c/0x2e0 [vc4] | [ 67.119936] try_to_bring_up_aggregate_device+0x230/0x320 | [ 67.125411] component_master_add_with_match+0xd4/0x11c | [ 67.130710] vc4_platform_drm_probe+0xd0/0x110 [vc4] | [ 67.135787] platform_probe+0x74/0xf0 | [ 67.139501] really_probe+0x19c/0x3f0 | [ 67.143213] __driver_probe_device+0x11c/0x190 | [ 67.147719] driver_probe_device+0x44/0xf4 | [ 67.151872] __driver_attach+0xd8/0x220 | [ 67.155760] bus_for_each_dev+0x7c/0xe0 | [ 67.159649] driver_attach+0x30/0x40 | [ 67.163272] bus_add_driver+0x154/0x240 | [ 67.167162] driver_register+0x84/0x140 | [ 67.171051] __platform_driver_register+0x34/0x40 | [ 67.175821] vc4_drm_register+0x5c/0x1000 [vc4] | [ 67.180456] do_one_initcall+0x50/0x240 | [ 67.184347] do_init_module+0x50/0x1fc | [ 67.188150] load_module+0x1c5c/0x2060 | [ 67.191951] __do_sys_finit_module+0xac/0x130 | [ 67.196369] __arm64_sys_finit_module+0x2c/0x40 | [ 67.200964]
Re: [PATCH v2] drivers/amd/pm: check the return value of amdgpu_bo_kmap
Applied. Thanks!
On Thu, Sep 22, 2022 at 2:49 AM Christian König
wrote:
>
> Am 22.09.22 um 06:17 schrieb Li Zhong:
> > amdgpu_bo_kmap() returns error when fails to map buffer object. Add the
> > error check and propagate the error.
> >
> > Signed-off-by: Li Zhong
>
> We usually use "r" as return and error variables, but that's just a nit.
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > index 1eb4e613b27a..ec055858eb95 100644
> > --- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > +++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > @@ -1485,6 +1485,7 @@ static int pp_get_prv_buffer_details(void *handle,
> > void **addr, size_t *size)
> > {
> > struct pp_hwmgr *hwmgr = handle;
> > struct amdgpu_device *adev = hwmgr->adev;
> > + int err;
> >
> > if (!addr || !size)
> > return -EINVAL;
> > @@ -1492,7 +1493,9 @@ static int pp_get_prv_buffer_details(void *handle,
> > void **addr, size_t *size)
> > *addr = NULL;
> > *size = 0;
> > if (adev->pm.smu_prv_buffer) {
> > - amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
> > + err = amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
> > + if (err)
> > + return err;
> > *size = adev->pm.smu_prv_buffer_size;
> > }
> >
>
Re: [PATCH v2 00/33] drm: Analog TV Improvements
Hi, On Thu, Sep 22, 2022 at 04:25:17PM +0200, Maxime Ripard wrote: > Here's a series aiming at improving the command line named modes support, > and more importantly how we deal with all the analog TV variants. > > The named modes support were initially introduced to allow to specify the > analog TV mode to be used. > > However, this was causing multiple issues: > > * The mode name parsed on the command line was passed directly to the > driver, which had to figure out which mode it was suppose to match; > > * Figuring that out wasn't really easy, since the video= argument or what > the userspace might not even have a name in the first place, but > instead could have passed a mode with the same timings; > > * The fallback to matching on the timings was mostly working as long as > we were supporting one 525 lines (most likely NSTC) and one 625 lines > (PAL), but couldn't differentiate between two modes with the same > timings (NTSC vs PAL-M vs NSTC-J for example); > > * There was also some overlap with the tv mode property registered by > drm_mode_create_tv_properties(), but named modes weren't interacting > with that property at all. > > * Even though that property was generic, its possible values were > specific to each drivers, which made some generic support difficult. > > Thus, I chose to tackle in multiple steps: > > * A new TV mode property was introduced, with generic values, each driver > reporting through a bitmask what standard it supports to the userspace; > > * This option was added to the command line parsing code to be able to > specify it on the kernel command line, and new atomic_check and reset > helpers were created to integrate properly into atomic KMS; > > * The named mode parsing code is now creating a proper display mode for > the given named mode, and the TV standard will thus be part of the > connector state; > > * Two drivers were converted and tested for now (vc4 and sun4i), with > some backward compatibility code to translate the old TV mode to the > new TV mode; > > Unit tests were created along the way. > > One can switch from NTSC to PAL now using (on vc4) > > modetest -M vc4 -s 53:720x480i -w 53:'TV mode':1 # NTSC > modetest -M vc4 -s 53:720x576i -w 53:'TV mode':4 # PAL > > Let me know what you think, > Maxime > > To: David Airlie > To: Daniel Vetter > To: Maarten Lankhorst > To: Maxime Ripard > To: Thomas Zimmermann > To: Emma Anholt > To: Jani Nikula > To: Joonas Lahtinen > To: Rodrigo Vivi > To: Tvrtko Ursulin > To: Ben Skeggs > To: Karol Herbst > To: Lyude Paul > To: Chen-Yu Tsai > To: Jernej Skrabec > To: Samuel Holland > Cc: Geert Uytterhoeven > Cc: Mateusz Kwiatkowski > Cc: "Noralf Trønnes" > Cc: Dave Stevenson > Cc: Dom Cobley > Cc: Phil Elwell > Cc: > Cc: linux-ker...@vger.kernel.org > Cc: intel-...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-su...@lists.linux.dev > Cc: Hans de Goede > Signed-off-by: Maxime Ripard > > --- > Changes in v3: > - Applied some of the fixes to vc4 and sun4i > - Renamed the old TV mode property to legacy_mode > - Fixed a bunch of bisection errors > - Removed most of the redundant TV modes > - Added a new None TV mode to not fall back on NTSC by mistake > - Fixed the mode generation function to match better what is expected > - Added some logging to the mode generation function > - Split the improvements to the named mode parsing logic into separate patches > - Added more checks to the TV atomic_check helper > - Link to v2: > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v2-0-459522d65...@cerno.tech/ Sorry, this is obviously the v3... Maxime signature.asc Description: PGP signature
[PATCH v2 33/33] drm/sun4i: tv: Convert to the new TV mode property
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 74ff5ad6a8b9..833742cee745 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -140,23 +140,14 @@ struct resync_parameters {
struct tv_mode {
char*name;
+ unsigned inttv_mode;
+
u32 mode;
u32 chroma_freq;
u16 back_porch;
u16 front_porch;
- u16 line_number;
u16 vblank_level;
- u32 hdisplay;
- u16 hfront_porch;
- u16 hsync_len;
- u16 hback_porch;
-
- u32 vdisplay;
- u16 vfront_porch;
- u16 vsync_len;
- u16 vback_porch;
-
boolyc_en;
booldac3_en;
booldac_bit25_en;
@@ -212,7 +203,7 @@ static const struct resync_parameters pal_resync_parameters
= {
static const struct tv_mode tv_modes[] = {
{
- .name = "NTSC",
+ .tv_mode= DRM_MODE_TV_MODE_NTSC,
.mode = SUN4I_TVE_CFG0_RES_480i,
.chroma_freq= 0x21f07c1f,
.yc_en = true,
@@ -221,17 +212,6 @@ static const struct tv_mode tv_modes[] = {
.back_porch = 118,
.front_porch= 32,
- .line_number= 525,
-
- .hdisplay = 720,
- .hfront_porch = 18,
- .hsync_len = 2,
- .hback_porch= 118,
-
- .vdisplay = 480,
- .vfront_porch = 26,
- .vsync_len = 2,
- .vback_porch= 17,
.vblank_level = 240,
@@ -241,23 +221,12 @@ static const struct tv_mode tv_modes[] = {
.resync_params = _resync_parameters,
},
{
- .name = "PAL",
+ .tv_mode= DRM_MODE_TV_MODE_PAL,
.mode = SUN4I_TVE_CFG0_RES_576i,
.chroma_freq= 0x2a098acb,
.back_porch = 138,
.front_porch= 24,
- .line_number= 625,
-
- .hdisplay = 720,
- .hfront_porch = 3,
- .hsync_len = 2,
- .hback_porch= 139,
-
- .vdisplay = 576,
- .vfront_porch = 28,
- .vsync_len = 2,
- .vback_porch= 19,
.vblank_level = 252,
@@ -275,63 +244,21 @@ drm_encoder_to_sun4i_tv(struct drm_encoder *encoder)
encoder);
}
-/*
- * FIXME: If only the drm_display_mode private field was usable, this
- * could go away...
- *
- * So far, it doesn't seem to be preserved when the mode is passed by
- * to mode_set for some reason.
- */
-static const struct tv_mode *sun4i_tv_find_tv_by_mode(const struct
drm_display_mode *mode)
+static const struct tv_mode *
+sun4i_tv_find_tv_by_mode(unsigned int mode)
{
int i;
- /* First try to identify the mode by name */
for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
const struct tv_mode *tv_mode = _modes[i];
- DRM_DEBUG_DRIVER("Comparing mode %s vs %s",
-mode->name, tv_mode->name);
-
- if (!strcmp(mode->name, tv_mode->name))
- return tv_mode;
- }
-
- /* Then by number of lines */
- for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
- const struct tv_mode *tv_mode = _modes[i];
-
- DRM_DEBUG_DRIVER("Comparing mode %s vs %s (X: %d vs %d)",
-mode->name, tv_mode->name,
-mode->vdisplay, tv_mode->vdisplay);
-
- if (mode->vdisplay == tv_mode->vdisplay)
+ if (tv_mode->tv_mode == mode)
return tv_mode;
}
return NULL;
}
-static void sun4i_tv_mode_to_drm_mode(const struct tv_mode *tv_mode,
- struct drm_display_mode *mode)
-{
- DRM_DEBUG_DRIVER("Creating mode %s\n", mode->name);
-
- mode->type = DRM_MODE_TYPE_DRIVER;
- mode->clock = 13500;
- mode->flags = DRM_MODE_FLAG_INTERLACE;
-
- mode->hdisplay = tv_mode->hdisplay;
- mode->hsync_start = mode->hdisplay + tv_mode->hfront_porch;
- mode->hsync_end = mode->hsync_start + tv_mode->hsync_len;
- mode->htotal = mode->hsync_end + tv_mode->hback_porch;
-
- mode->vdisplay = tv_mode->vdisplay;
- mode->vsync_start = mode->vdisplay + tv_mode->vfront_porch;
- mode->vsync_end =
[PATCH v2 32/33] drm/vc4: vec: Add support for more analog TV standards
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
broadcasting, but sometimes used as a hack to play NTSC content in PAL
regions (e.g. on VCRs).
- PAL_N - PAL with alternative chroma subcarrier frequency,
3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
- PAL60 - 480i60 signal with PAL-style color at normal European PAL
frequency. Another non-standard, non-broadcast mode, used in similar
contexts as NTSC_443. Some displays support one but not the other.
- SECAM - French frequency-modulated analog color standard; also have
been broadcast in Eastern Europe and various parts of Africa and Asia.
Uses the same 576i50 timings as PAL.
Also added some comments explaining color subcarrier frequency
registers.
Signed-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index a9463364015b..0862462aa9e3 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -46,6 +46,7 @@
#define VEC_CONFIG0_YDEL(x)((x) << 26)
#define VEC_CONFIG0_CDEL_MASK GENMASK(25, 24)
#define VEC_CONFIG0_CDEL(x)((x) << 24)
+#define VEC_CONFIG0_SECAM_STD BIT(21)
#define VEC_CONFIG0_PBPR_FIL BIT(18)
#define VEC_CONFIG0_CHROMA_GAIN_MASK GENMASK(17, 16)
#define VEC_CONFIG0_CHROMA_GAIN_UNITY (0 << 16)
@@ -76,6 +77,27 @@
#define VEC_SOFT_RESET 0x10c
#define VEC_CLMP0_START0x144
#define VEC_CLMP0_END 0x148
+
+/*
+ * These set the color subcarrier frequency
+ * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
+ *
+ * VEC_FREQ1_0 contains the most significant 16-bit half-word,
+ * VEC_FREQ3_2 contains the least significant 16-bit half-word.
+ * 0x8000 seems to be equivalent to the pixel clock
+ * (which itself is the VEC clock divided by 8).
+ *
+ * Reference values (with the default pixel clock of 13.5 MHz):
+ *
+ * NTSC (3579545.[45] Hz) - 0x21F07C1F
+ * PAL (4433618.75 Hz) - 0x2A098ACB
+ * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
+ * PAL-N (3582056.25 Hz) - 0x21F69446
+ *
+ * NOTE: For SECAM, it is used as the Dr center frequency,
+ * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
+ * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
+ */
#define VEC_FREQ3_20x180
#define VEC_FREQ1_00x184
@@ -118,6 +140,14 @@
#define VEC_INTERRUPT_CONTROL 0x190
#define VEC_INTERRUPT_STATUS 0x194
+
+/*
+ * Db center frequency for SECAM; the clock for this is the same as for
+ * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
+ *
+ * This is specified as 425 Hz, which corresponds to 0x284BDA13.
+ * That is also the default value, so no need to set it explicitly.
+ */
#define VEC_FCW_SECAM_B0x198
#define VEC_SECAM_GAIN_VAL 0x19c
@@ -197,6 +227,10 @@ enum vc4_vec_tv_mode_id {
VC4_VEC_TV_MODE_NTSC_J,
VC4_VEC_TV_MODE_PAL,
VC4_VEC_TV_MODE_PAL_M,
+ VC4_VEC_TV_MODE_NTSC_443,
+ VC4_VEC_TV_MODE_PAL_60,
+ VC4_VEC_TV_MODE_PAL_N,
+ VC4_VEC_TV_MODE_SECAM,
};
struct vc4_vec_tv_mode {
@@ -239,6 +273,12 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
+ {
+ .mode = DRM_MODE_TV_MODE_NTSC_443,
+ .config0 = VEC_CONFIG0_NTSC_STD,
+ .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
+ .custom_freq = 0x2a098acb,
+ },
{
.mode = DRM_MODE_TV_MODE_NTSC_J,
.config0 = VEC_CONFIG0_NTSC_STD,
@@ -254,6 +294,17 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config0 = VEC_CONFIG0_PAL_M_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
+ {
+ .mode = DRM_MODE_TV_MODE_PAL_N,
+ .config0 = VEC_CONFIG0_PAL_N_STD,
+ .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+ },
+ {
+ .mode = DRM_MODE_TV_MODE_SECAM,
+ .config0 = VEC_CONFIG0_SECAM_STD,
+ .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+ .custom_freq = 0x29c71c72,
+ },
};
static inline const struct vc4_vec_tv_mode *
@@ -273,9 +324,13 @@ vc4_vec_tv_mode_lookup(unsigned int mode)
static const struct drm_prop_enum_list tv_mode_names[] = {
{ VC4_VEC_TV_MODE_NTSC, "NTSC", },
+ { VC4_VEC_TV_MODE_NTSC_443, "NTSC-443", },
{ VC4_VEC_TV_MODE_NTSC_J,
[PATCH v2 31/33] drm/vc4: vec: Convert to the new TV mode property
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 6828b79a1001..a9463364015b 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -172,6 +172,8 @@ struct vc4_vec {
struct clk *clock;
+ struct drm_property *legacy_tv_mode_property;
+
struct debugfs_regset32 regset;
};
@@ -184,6 +186,12 @@ encoder_to_vc4_vec(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_vec, encoder.base);
}
+static inline struct vc4_vec *
+connector_to_vc4_vec(struct drm_connector *connector)
+{
+ return container_of(connector, struct vc4_vec, connector);
+}
+
enum vc4_vec_tv_mode_id {
VC4_VEC_TV_MODE_NTSC,
VC4_VEC_TV_MODE_NTSC_J,
@@ -192,7 +200,7 @@ enum vc4_vec_tv_mode_id {
};
struct vc4_vec_tv_mode {
- const struct drm_display_mode *mode;
+ unsigned int mode;
u32 config0;
u32 config1;
u32 custom_freq;
@@ -225,43 +233,51 @@ static const struct debugfs_reg32 vec_regs[] = {
VC4_REG32(VEC_DAC_MISC),
};
-static const struct drm_display_mode ntsc_mode = {
- DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
-720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
-480, 480 + 7, 480 + 7 + 6, 525, 0,
-DRM_MODE_FLAG_INTERLACE)
-};
-
-static const struct drm_display_mode pal_mode = {
- DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
-720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
-576, 576 + 4, 576 + 4 + 6, 625, 0,
-DRM_MODE_FLAG_INTERLACE)
-};
-
static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
- [VC4_VEC_TV_MODE_NTSC] = {
- .mode = _mode,
+ {
+ .mode = DRM_MODE_TV_MODE_NTSC,
.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
- [VC4_VEC_TV_MODE_NTSC_J] = {
- .mode = _mode,
+ {
+ .mode = DRM_MODE_TV_MODE_NTSC_J,
.config0 = VEC_CONFIG0_NTSC_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
- [VC4_VEC_TV_MODE_PAL] = {
- .mode = _mode,
+ {
+ .mode = DRM_MODE_TV_MODE_PAL,
.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
- [VC4_VEC_TV_MODE_PAL_M] = {
- .mode = _mode,
+ {
+ .mode = DRM_MODE_TV_MODE_PAL_M,
.config0 = VEC_CONFIG0_PAL_M_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
};
+static inline const struct vc4_vec_tv_mode *
+vc4_vec_tv_mode_lookup(unsigned int mode)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) {
+ const struct vc4_vec_tv_mode *tv_mode = _vec_tv_modes[i];
+
+ if (tv_mode->mode == mode)
+ return tv_mode;
+ }
+
+ return NULL;
+}
+
+static const struct drm_prop_enum_list tv_mode_names[] = {
+ { VC4_VEC_TV_MODE_NTSC, "NTSC", },
+ { VC4_VEC_TV_MODE_NTSC_J, "NTSC-J", },
+ { VC4_VEC_TV_MODE_PAL, "PAL", },
+ { VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
+};
+
static enum drm_connector_status
vc4_vec_connector_detect(struct drm_connector *connector, bool force)
{
@@ -276,19 +292,99 @@ static void vc4_vec_connector_reset(struct drm_connector
*connector)
static int vc4_vec_connector_get_modes(struct drm_connector *connector)
{
- struct drm_connector_state *state = connector->state;
struct drm_display_mode *mode;
+ int count = 0;
- mode = drm_mode_duplicate(connector->dev,
- vc4_vec_tv_modes[state->tv.legacy_mode].mode);
+ mode = drm_mode_analog_ntsc_480i(connector->dev);
if (!mode) {
DRM_ERROR("Failed to create a new display mode\n");
return -ENOMEM;
}
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
+ count += 1;
- return 1;
+ mode = drm_mode_analog_pal_576i(connector->dev);
+ if (!mode) {
+ DRM_ERROR("Failed to create a new display mode\n");
+ return -ENOMEM;
+ }
+
+ drm_mode_probed_add(connector, mode);
+ count += 1;
+
+ return count;
+}
+
+static int
+vc4_vec_connector_set_property(struct drm_connector *connector,
+ struct drm_connector_state *state,
+ struct drm_property *property,
+ uint64_t val)
+{
+ struct vc4_vec *vec =
[PATCH v2 30/33] drm/vc4: vec: Check for VEC output constraints
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Signed-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index baa29067a1ff..6828b79a1001 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -453,6 +453,7 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ const struct drm_display_mode *mode = _state->adjusted_mode;
const struct vc4_vec_tv_mode *vec_mode;
vec_mode = _vec_tv_modes[conn_state->tv.legacy_mode];
@@ -461,6 +462,53 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder
*encoder,
!drm_mode_equal(vec_mode->mode, _state->adjusted_mode))
return -EINVAL;
+ if (mode->crtc_hdisplay % 4)
+ return -EINVAL;
+
+ if (!(mode->crtc_hsync_end - mode->crtc_hsync_start))
+ return -EINVAL;
+
+ switch (mode->vtotal) {
+ case 525:
+ if (mode->crtc_vtotal > 262)
+ return -EINVAL;
+
+ if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 253)
+ return -EINVAL;
+
+ if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
+ return -EINVAL;
+
+ if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
+ return -EINVAL;
+
+ if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 4)
+ return -EINVAL;
+
+ break;
+
+ case 625:
+ if (mode->crtc_vtotal > 312)
+ return -EINVAL;
+
+ if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 305)
+ return -EINVAL;
+
+ if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
+ return -EINVAL;
+
+ if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
+ return -EINVAL;
+
+ if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 2)
+ return -EINVAL;
+
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
return 0;
}
--
b4 0.10.0
[PATCH v2 29/33] drm/vc4: vec: Use TV Reset implementation
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 5ec3a12359b1..baa29067a1ff 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -268,6 +268,12 @@ vc4_vec_connector_detect(struct drm_connector *connector,
bool force)
return connector_status_unknown;
}
+static void vc4_vec_connector_reset(struct drm_connector *connector)
+{
+ drm_atomic_helper_connector_reset(connector);
+ drm_atomic_helper_connector_tv_reset(connector);
+}
+
static int vc4_vec_connector_get_modes(struct drm_connector *connector)
{
struct drm_connector_state *state = connector->state;
@@ -288,7 +294,7 @@ static int vc4_vec_connector_get_modes(struct drm_connector
*connector)
static const struct drm_connector_funcs vc4_vec_connector_funcs = {
.detect = vc4_vec_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
- .reset = drm_atomic_helper_connector_reset,
+ .reset = vc4_vec_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
--
b4 0.10.0
[PATCH v2 28/33] drm/vc4: vec: Fix definition of PAL-M mode
From: Mateusz Kwiatkowski
PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma
subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings.
This commit makes the driver actually use the proper VEC preset for this
mode instead of just changing PAL subcarrier frequency.
Signed-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index f31fef938f11..5ec3a12359b1 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -69,6 +69,7 @@
#define VEC_CONFIG0_STD_MASK GENMASK(1, 0)
#define VEC_CONFIG0_NTSC_STD 0
#define VEC_CONFIG0_PAL_BDGHI_STD 1
+#define VEC_CONFIG0_PAL_M_STD 2
#define VEC_CONFIG0_PAL_N_STD 3
#define VEC_SCHPH 0x108
@@ -255,10 +256,9 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
[VC4_VEC_TV_MODE_PAL_M] = {
- .mode = _mode,
- .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
- .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
- .custom_freq = 0x223b61d1,
+ .mode = _mode,
+ .config0 = VEC_CONFIG0_PAL_M_STD,
+ .config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
};
--
b4 0.10.0
[PATCH v2 25/33] drm/modes: Introduce more named modes
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 1ca1f82dfd12..6f315385bd02 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2271,7 +2271,9 @@ struct drm_named_mode {
static const struct drm_named_mode drm_named_modes[] = {
NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
DRM_MODE_TV_MODE_NTSC),
+ NAMED_MODE("NTSC-J", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
DRM_MODE_TV_MODE_NTSC_J),
NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE,
DRM_MODE_TV_MODE_PAL),
+ NAMED_MODE("PAL-M", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
DRM_MODE_TV_MODE_PAL_M),
};
static int drm_mode_parse_cmdline_named_mode(const char *name,
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 4380cf670fb4..521505753af9 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -140,6 +140,32 @@ static void drm_pick_cmdline_named_ntsc(struct kunit *test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
mode));
}
+static void drm_pick_cmdline_named_ntsc_j(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+ struct drm_device *drm = priv->drm;
+ struct drm_connector *connector = >connector;
+ struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+ struct drm_display_mode *mode;
+ const char *cmdline = "NTSC-J";
+ int ret;
+
+ KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+ connector,
+
cmdline_mode));
+
+ mutex_lock(>mode_config.mutex);
+ ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+ mutex_unlock(>mode_config.mutex);
+ KUNIT_ASSERT_GT(test, ret, 0);
+
+ mode = drm_connector_pick_cmdline_mode(connector);
+ KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+ KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
mode));
+}
+
static void drm_pick_cmdline_named_pal(struct kunit *test)
{
struct drm_client_modeset_test_priv *priv = test->priv;
@@ -166,10 +192,38 @@ static void drm_pick_cmdline_named_pal(struct kunit *test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_pal_576i(drm),
mode));
}
+static void drm_pick_cmdline_named_pal_m(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+ struct drm_device *drm = priv->drm;
+ struct drm_connector *connector = >connector;
+ struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+ struct drm_display_mode *mode;
+ const char *cmdline = "PAL-M";
+ int ret;
+
+ KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+ connector,
+
cmdline_mode));
+
+ mutex_lock(>mode_config.mutex);
+ ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+ mutex_unlock(>mode_config.mutex);
+ KUNIT_ASSERT_GT(test, ret, 0);
+
+ mode = drm_connector_pick_cmdline_mode(connector);
+ KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+ KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
mode));
+}
+
static struct kunit_case drm_pick_cmdline_tests[] = {
KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
KUNIT_CASE(drm_pick_cmdline_named_ntsc),
+ KUNIT_CASE(drm_pick_cmdline_named_ntsc_j),
KUNIT_CASE(drm_pick_cmdline_named_pal),
+ KUNIT_CASE(drm_pick_cmdline_named_pal_m),
{}
};
--
b4 0.10.0
[PATCH v2 26/33] drm/atomic-helper: Add a TV properties reset helper
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index dfb57217253b..0373c3dc824b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -481,6 +481,81 @@ void drm_atomic_helper_connector_tv_margins_reset(struct
drm_connector *connecto
}
EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
+/**
+ * drm_atomic_helper_connector_tv_reset - Resets Analog TV connector properties
+ * @connector: DRM connector
+ *
+ * Resets the analog TV properties attached to a connector
+ */
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_cmdline_mode *cmdline = >cmdline_mode;
+ struct drm_connector_state *state = connector->state;
+ struct drm_property *prop;
+ uint64_t val;
+
+ prop = dev->mode_config.tv_mode_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.mode = val;
+
+ if (cmdline->tv_mode)
+ state->tv.mode = cmdline->tv_mode;
+
+ prop = dev->mode_config.tv_select_subconnector_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.select_subconnector = val;
+
+ prop = dev->mode_config.tv_subconnector_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.subconnector = val;
+
+ prop = dev->mode_config.tv_brightness_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.brightness = val;
+
+ prop = dev->mode_config.tv_contrast_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.contrast = val;
+
+ prop = dev->mode_config.tv_flicker_reduction_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.flicker_reduction = val;
+
+ prop = dev->mode_config.tv_overscan_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.overscan = val;
+
+ prop = dev->mode_config.tv_saturation_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.saturation = val;
+
+ prop = dev->mode_config.tv_hue_property;
+ if (prop)
+ if (!drm_object_property_get_default_value(>base,
+ prop, ))
+ state->tv.hue = val;
+
+ drm_atomic_helper_connector_tv_margins_reset(connector);
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+
/**
* __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
* @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h
b/include/drm/drm_atomic_state_helper.h
index 192766656b88..c8fbce795ee7 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,6 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct
drm_connector_state *conn_
void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
struct drm_connector_state
*conn_state);
void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector
*connector);
void
__drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
--
b4 0.10.0
[PATCH v2 27/33] drm/atomic-helper: Add an analog TV atomic_check implementation
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created a bunch of new constraints that needs to
be shared across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 0373c3dc824b..e88c57a4f7be 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -556,6 +556,55 @@ void drm_atomic_helper_connector_tv_reset(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+/**
+ * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state
+ * @connector: DRM Connector
+ * @state: the DRM State object
+ *
+ * Checks the state object to see if the requested state is valid for an
+ * analog TV connector.
+ *
+ * Returns:
+ * Zero for success, a negative error code on error.
+ */
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_connector_state *new_conn_state =
+ drm_atomic_get_new_connector_state(state, connector);
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+
+ crtc = new_conn_state->crtc;
+ if (!crtc)
+ return 0;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (!crtc_state)
+ return -EINVAL;
+
+ if (old_conn_state->tv.mode != new_conn_state->tv.mode)
+ crtc_state->mode_changed = true;
+
+ if ((old_conn_state->tv.margins.left !=
new_conn_state->tv.margins.left) ||
+ (old_conn_state->tv.margins.right !=
new_conn_state->tv.margins.right) ||
+ (old_conn_state->tv.margins.top != new_conn_state->tv.margins.top)
||
+ (old_conn_state->tv.margins.bottom !=
new_conn_state->tv.margins.bottom) ||
+ (old_conn_state->tv.mode != new_conn_state->tv.mode) ||
+ (old_conn_state->tv.brightness != new_conn_state->tv.brightness) ||
+ (old_conn_state->tv.contrast != new_conn_state->tv.contrast) ||
+ (old_conn_state->tv.flicker_reduction !=
new_conn_state->tv.flicker_reduction) ||
+ (old_conn_state->tv.overscan != new_conn_state->tv.overscan) ||
+ (old_conn_state->tv.saturation != new_conn_state->tv.saturation) ||
+ (old_conn_state->tv.hue != new_conn_state->tv.hue))
+ crtc_state->connectors_changed = true;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
+
/**
* __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
* @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h
b/include/drm/drm_atomic_state_helper.h
index c8fbce795ee7..b9740edb2658 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -26,6 +26,7 @@
#include
+struct drm_atomic_state;
struct drm_bridge;
struct drm_bridge_state;
struct drm_crtc;
@@ -71,6 +72,8 @@ void __drm_atomic_helper_connector_reset(struct drm_connector
*connector,
struct drm_connector_state
*conn_state);
void drm_atomic_helper_connector_reset(struct drm_connector *connector);
void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+struct drm_atomic_state *state);
void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector
*connector);
void
__drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
--
b4 0.10.0
[PATCH v2 24/33] drm/modes: Properly generate a drm_display_mode from a named mode
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though, there's no real code to make that
translation and we rely on the drivers to guess which actual display mode
we meant.
Let's modify drm_mode_create_from_cmdline_mode() to properly generate the
drm_display_mode we mean when passing a named mode.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 23e665fd808e..1ca1f82dfd12 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2500,6 +2500,36 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
}
EXPORT_SYMBOL(drm_mode_parse_command_line_for_connector);
+static struct drm_display_mode *drm_named_mode(struct drm_device *dev,
+ struct drm_cmdline_mode *cmd)
+{
+ struct drm_display_mode *mode;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+ const struct drm_named_mode *named_mode = _named_modes[i];
+
+ if (strcmp(cmd->name, named_mode->name))
+ continue;
+
+ if (!named_mode->tv_mode)
+ continue;
+
+ mode = drm_analog_tv_mode(dev,
+ named_mode->tv_mode,
+ named_mode->pixel_clock_khz * 1000,
+ named_mode->xres,
+ named_mode->yres,
+ named_mode->flags &
DRM_MODE_FLAG_INTERLACE);
+ if (!mode)
+ return NULL;
+
+ return mode;
+ }
+
+ return NULL;
+}
+
/**
* drm_mode_create_from_cmdline_mode - convert a command line modeline into a
DRM display mode
* @dev: DRM device to create the new mode for
@@ -2517,7 +2547,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
if (cmd->xres == 0 || cmd->yres == 0)
return NULL;
- if (cmd->cvt)
+ if (strlen(cmd->name))
+ mode = drm_named_mode(dev, cmd);
+ else if (cmd->cvt)
mode = drm_cvt_mode(dev,
cmd->xres, cmd->yres,
cmd->refresh_specified ? cmd->refresh : 60,
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 46335de7bc6b..4380cf670fb4 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -26,6 +26,20 @@ static int drm_client_modeset_connector_get_modes(struct
drm_connector *connecto
count = drm_add_modes_noedid(connector, 1920, 1200);
+ mode = drm_mode_analog_ntsc_480i(connector->dev);
+ if (!mode)
+ return -ENOMEM;
+
+ drm_mode_probed_add(connector, mode);
+ count += 1;
+
+ mode = drm_mode_analog_pal_576i(connector->dev);
+ if (!mode)
+ return -ENOMEM;
+
+ drm_mode_probed_add(connector, mode);
+ count += 1;
+
return count;
}
@@ -58,6 +72,9 @@ static int drm_client_modeset_test_init(struct kunit *test)
return ret;
drm_connector_helper_add(>connector,
_client_modeset_connector_helper_funcs);
+ priv->connector.interlace_allowed = true;
+ priv->connector.doublescan_allowed = true;
+
return 0;
}
@@ -97,8 +114,62 @@ static void drm_pick_cmdline_res_1920_1080_60(struct kunit
*test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
}
+static void drm_pick_cmdline_named_ntsc(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+ struct drm_device *drm = priv->drm;
+ struct drm_connector *connector = >connector;
+ struct drm_cmdline_mode *cmdline_mode = >cmdline_mode;
+ struct drm_display_mode *mode;
+ const char *cmdline = "NTSC";
+ int ret;
+
+ KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+ connector,
+
cmdline_mode));
+
+ mutex_lock(>mode_config.mutex);
+ ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+ mutex_unlock(>mode_config.mutex);
+ KUNIT_ASSERT_GT(test, ret, 0);
+
+ mode = drm_connector_pick_cmdline_mode(connector);
+ KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+ KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm),
mode));
+}
+
+static void drm_pick_cmdline_named_pal(struct kunit *test)
[PATCH v2 23/33] drm/modes: Introduce the tv_mode property as a command-line option
Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.
Let's add some code to allow it, and some unit tests to exercise that code.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index eb3c4e596c67..23e665fd808e 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2133,6 +2133,29 @@ static int drm_mode_parse_panel_orientation(const char
*delim,
return 0;
}
+static int drm_mode_parse_tv_mode(const char *delim,
+ struct drm_cmdline_mode *mode)
+{
+ const char *value;
+ int ret;
+
+ if (*delim != '=')
+ return -EINVAL;
+
+ value = delim + 1;
+ delim = strchr(value, ',');
+ if (!delim)
+ delim = value + strlen(value);
+
+ ret = drm_get_tv_mode_from_name(value, delim - value);
+ if (ret < 0)
+ return ret;
+
+ mode->tv_mode = ret;
+
+ return 0;
+}
+
static int drm_mode_parse_cmdline_options(const char *str,
bool freestanding,
const struct drm_connector *connector,
@@ -2202,6 +2225,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
} else if (!strncmp(option, "panel_orientation", delim -
option)) {
if (drm_mode_parse_panel_orientation(delim, mode))
return -EINVAL;
+ } else if (!strncmp(option, "tv_mode", delim - option)) {
+ if (drm_mode_parse_tv_mode(delim, mode))
+ return -EINVAL;
} else {
return -EINVAL;
}
@@ -2230,20 +2256,22 @@ struct drm_named_mode {
unsigned int xres;
unsigned int yres;
unsigned int flags;
+ unsigned int tv_mode;
};
-#define NAMED_MODE(_name, _pclk, _x, _y, _flags) \
+#define NAMED_MODE(_name, _pclk, _x, _y, _flags, _mode)\
{ \
.name = _name, \
.pixel_clock_khz = _pclk, \
.xres = _x, \
.yres = _y, \
.flags = _flags,\
+ .tv_mode = _mode, \
}
static const struct drm_named_mode drm_named_modes[] = {
- NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE),
- NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE),
+ NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE,
DRM_MODE_TV_MODE_NTSC),
+ NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE,
DRM_MODE_TV_MODE_PAL),
};
static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2292,6 +2320,7 @@ static int drm_mode_parse_cmdline_named_mode(const char
*name,
cmdline_mode->xres = mode->xres;
cmdline_mode->yres = mode->yres;
cmdline_mode->interlace = !!(mode->flags &
DRM_MODE_FLAG_INTERLACE);
+ cmdline_mode->tv_mode = mode->tv_mode;
cmdline_mode->specified = true;
return 1;
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 09b806e27506..019ff5aa4f8d 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -927,6 +927,14 @@ static const struct drm_cmdline_invalid_test
drm_cmdline_invalid_tests[] = {
.name = "invalid_option",
.cmdline = "720x480,test=42",
},
+ {
+ .name = "invalid_tv_option",
+ .cmdline = "720x480i,tv_mode=invalid",
+ },
+ {
+ .name = "truncated_tv_option",
+ .cmdline = "720x480i,tv_mode=NTS",
+ },
};
static void drm_cmdline_invalid_desc(const struct drm_cmdline_invalid_test *t,
@@ -937,6 +945,64 @@ static void drm_cmdline_invalid_desc(const struct
drm_cmdline_invalid_test *t,
KUNIT_ARRAY_PARAM(drm_cmdline_invalid, drm_cmdline_invalid_tests,
drm_cmdline_invalid_desc);
+struct drm_cmdline_tv_option_test {
+ const char *name;
+ const char *cmdline;
+ struct drm_display_mode *(*mode_fn)(struct drm_device *dev);
+ enum drm_connector_tv_mode tv_mode;
+};
+
+static void drm_cmdline_test_tv_options(struct kunit *test)
+{
+ const struct drm_cmdline_tv_option_test *params = test->param_value;
+ const struct drm_display_mode *expected_mode = params->mode_fn(NULL);
+ struct drm_cmdline_mode mode = { };
+
+ KUNIT_EXPECT_TRUE(test,
