[Resend v4] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few nits (Doug, Dmitry)
- Restrict sub-block flush programming to dpu_hw_ctl file (Dmitry)
Changes in v2:
- Move the address offset to flush macro (Dmitry)
- Seperate ops for the sub block flush (Dmitry)
Changes in v3:
- Reuse the DPU_DSPP_xx enum instead of a new one (Dmitry)
Changes in v4:
- Use shorter version for unsigned int (Stephen)
Signed-off-by: Kalyan Thota
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 5 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 35 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++--
5 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 601d687..4170fbe 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -766,7 +766,7 @@ static void _dpu_crtc_setup_cp_blocks(struct drm_crtc *crtc)
/* stage config flush mask */
ctl->ops.update_pending_flush_dspp(ctl,
- mixer[i].hw_dspp->idx);
+ mixer[i].hw_dspp->idx, DPU_DSPP_PCC);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029f..0eecb2f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -65,7 +65,10 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
#define CTL_SC7280_MASK \
- (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) |
BIT(DPU_CTL_VM_CFG))
+ (BIT(DPU_CTL_ACTIVE_CFG) | \
+BIT(DPU_CTL_FETCH_ACTIVE) | \
+BIT(DPU_CTL_VM_CFG) | \
+BIT(DPU_CTL_DSPP_SUB_BLOCK_FLUSH))
#define MERGE_3D_SM8150_MASK (0)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 38aa38a..8148e91 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -161,10 +161,12 @@ enum {
* DSPP sub-blocks
* @DPU_DSPP_PCC Panel color correction block
* @DPU_DSPP_GC Gamma correction block
+ * @DPU_DSPP_IGC Inverse Gamma correction block
*/
enum {
DPU_DSPP_PCC = 0x1,
DPU_DSPP_GC,
+ DPU_DSPP_IGC,
DPU_DSPP_MAX
};
@@ -191,6 +193,7 @@ enum {
* @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
* @DPU_CTL_FETCH_ACTIVE: Active CTL for fetch HW (SSPPs)
* @DPU_CTL_VM_CFG:CTL config to support multiple VMs
+ * @DPU_CTL_DSPP_BLOCK_FLUSH: CTL config to support dspp sub-block flush
* @DPU_CTL_MAX
*/
enum {
@@ -198,6 +201,7 @@ enum {
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
DPU_CTL_VM_CFG,
+ DPU_CTL_DSPP_SUB_BLOCK_FLUSH,
DPU_CTL_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index a35ecb6..f26f484 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -33,6 +33,7 @@
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
+#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n - 1) * 4))
#define CTL_MIXER_BORDER_OUTBIT(24)
#define CTL_FLUSH_MASK_CTL BIT(17)
@@ -287,8 +288,9 @@ static void
dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
}
static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl *ctx,
- enum dpu_dspp dspp)
+ enum dpu_dspp dspp, u32 dspp_sub_blk)
{
+
switch (dspp) {
case DSPP_0:
ctx->pending_flush_mask |= BIT(13);
@@ -307,6 +309,31 @@ static void dpu_hw_ctl_update_pending_flush_dspp(struct
dpu_hw_ctl *ctx,
}
}
+static void dpu_hw_ctl_update_pending_flush_dspp_subblocks(
+ struct dpu_hw_ctl *ctx, enum dpu_dspp dspp, u32 dspp_sub_blk)
+{
+ u32 flushbits = 0, active;
+
+ switch (dspp_sub_blk) {
+ case DPU_DSPP_IGC:
+ flushbits = BIT(2);
+ break;
+ case DPU_DSPP_PCC:
+ flushbits = BIT(4);
+ break;
+ case DPU_DSPP_GC:
+ flushbits = BIT(5);
+ break;
+ default:
+ return;
+ }
+
+ active = DPU_REG_READ(>hw, CTL_DSPP_n_FLUSH(dspp));
+ DPU_REG_WRITE(>hw, CTL_DSPP_n_FLUSH(dspp), active | flushbits);
+
+
Re: [PATCH 10/12] iwlwifi: Track scan_cmd allocation size explicitly
On Thu, Sep 22, 2022 at 07:18:51AM +0300, Kalle Valo wrote: > Kees Cook writes: > > > In preparation for reducing the use of ksize(), explicitly track the > > size of scan_cmd allocations. This also allows for noticing if the scan > > size changes unexpectedly. Note that using ksize() was already incorrect > > here, in the sense that ksize() would not match the actual allocation > > size, which would trigger future run-time allocation bounds checking. > > (In other words, memset() may know how large scan_cmd was allocated for, > > but ksize() will return the upper bounds of the actually allocated memory, > > causing a run-time warning about an overflow.) > > > > Cc: Gregory Greenman > > Cc: Kalle Valo > > Cc: Johannes Berg > > Cc: linux-wirel...@vger.kernel.org > > Cc: net...@vger.kernel.org > > Signed-off-by: Kees Cook > > Via which tree is this iwlwifi patch going? Normally via wireless-next > or something else? This doesn't depend on the kmalloc_size_roundup() helper at all, so I would be happy for it to go via wireless-next if the patch seems reasonable. -- Kees Cook
Re: [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
On 9/22/2022 8:47 AM, Dixit, Ashutosh wrote: On Wed, 21 Sep 2022 08:07:15 -0700, Gupta, Anshuman wrote: Hi Anshuman, diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 55c35903adca..956e5298ef1e 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -6644,6 +6644,12 @@ #define DG1_PCODE_STATUS 0x7E #define DG1_UNCORE_GET_INIT_STATUS 0x0 #define DG1_UNCORE_INIT_STATUS_COMPLETE 0x1 +#define PCODE_POWER_SETUP0x7C +#define POWER_SETUP_SUBCOMMAND_READ_I1 0x4 +#define POWER_SETUP_SUBCOMMAND_WRITE_I10x5 +#definePOWER_SETUP_I1_WATTSREG_BIT(31) +#definePOWER_SETUP_I1_SHIFT6 /* 10.6 fixed point format */ Could please add some comment to explain, why POWER_SETUP_I1_SHIFT = 6, what is excatly 10.6 fixed point format ? With that. Reviewed-by: Anshuman Gupta 10.6 fixed point format means a 16 bit number is represented as x.y where x are the top 10 bits and y are the bottom 6 bits. The float value of this 16 bit number is (x + (y / 2^6)), so (x + (y / 64)). For example the number 0x8008 will have the value (1 * 2^9 + 8 / 2^6) == 512.125. Note that the hexadecimal number 0x8008 == 32776 and 512.125 == 32776 / 64 which is why POWER_SETUP_I1_SHIFT is 6 (2^6 == 64). Similarly, the 8.8 fixed point format is explained in gt/intel_gt_sysfs_pm.c. Do you think this needs a comment? I thought "10.6 fixed point format" is a sufficient hint (fixed point numbers are fairly well known). An even trickier data format is in the patch "drm/i915/hwmon: Expose power1_max_interval" in hwm_power1_max_interval_show() but I think I have a long comment there. Thanks for explaining this, i was unaware of fixed point representation. My RB can can be used without any change. Br, Anshuman. Thanks. -- Ashutosh
RE: [PATCH v3 15/15] vfio: Add struct device to vfio_device
> From: Jason Gunthorpe > Sent: Thursday, September 22, 2022 12:10 AM > > On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote: > > > From: Alex Williamson > > > Sent: Wednesday, September 21, 2022 4:27 AM > > > > > > On Fri, 9 Sep 2022 18:22:47 +0800 > > > Kevin Tian wrote: > > > > > > > From: Yi Liu > > > > > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > > > sysfs path of the parent, indicating the device is bound to a vfio > > > > driver, e.g.: > > > > > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > > > > > It is also a preparatory step toward adding cdev for supporting future > > > > device-oriented uAPI. > > > > > > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > > > > > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > > > > /proc/devices. > > > > > > What's the risk/reward here, is this just more aesthetically pleasing > > > symmetry vs 'vfio-dev'? The char major number to name association in > > > /proc/devices seems pretty obscure, but what due diligence have we > done > > > to make sure this doesn't break anyone? Thanks, > > > > I'm not sure whether the content of /proc/devices is considered as ABI. > > > > @Jason? > > Ah, I've forgotten why we got here - didn't we have a naming conflict > with the new stuff that is being introduced? No, we don't have. There is no new char dev introduced in this series. Later when device cdev is added a new device major will be allocated for 'vfio-dev'. It's at that time renaming existing 'vfio' to 'vfio-group' is probably clearer, which is what I understood from your earlier suggestion. > > ABI wise it is not a problem unless there is a real user, I'm not > aware of anything scanning /proc, that has been obsoleted by sysfs a > long time ago. > This is a good news.
[PATCH] drm/i915: Remove unused function parameter
The function parameter 'exclude' in funciton
i915_sw_fence_await_reservation() is not used.
Remove it.
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 v2] drivers/amd/pm: check the return value of amdgpu_bo_kmap
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: Li Zhong
> Sent: Thursday, September 22, 2022 12:18 PM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: jiapeng.ch...@linux.alibaba.com; Powell, Darren
> ; Chen, Guchun ;
> Limonciello, Mario ; Quan, Evan
> ; Lazar, Lijo ; dan...@ffwll.ch;
> airl...@linux.ie; Pan, Xinhui ; Koenig, Christian
> ; Deucher, Alexander
> ; Li Zhong
> Subject: [PATCH v2] drivers/amd/pm: check the return value of
> amdgpu_bo_kmap
>
> amdgpu_bo_kmap() returns error when fails to map buffer object. Add the
> error check and propagate the error.
>
> Signed-off-by: Li Zhong
> ---
> 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;
> }
>
> --
> 2.25.1
Re: [PATCH 10/12] iwlwifi: Track scan_cmd allocation size explicitly
Kees Cook writes: > In preparation for reducing the use of ksize(), explicitly track the > size of scan_cmd allocations. This also allows for noticing if the scan > size changes unexpectedly. Note that using ksize() was already incorrect > here, in the sense that ksize() would not match the actual allocation > size, which would trigger future run-time allocation bounds checking. > (In other words, memset() may know how large scan_cmd was allocated for, > but ksize() will return the upper bounds of the actually allocated memory, > causing a run-time warning about an overflow.) > > Cc: Gregory Greenman > Cc: Kalle Valo > Cc: Johannes Berg > Cc: linux-wirel...@vger.kernel.org > Cc: net...@vger.kernel.org > Signed-off-by: Kees Cook Via which tree is this iwlwifi patch going? Normally via wireless-next or something else? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
On Wed, 21 Sep 2022 08:07:15 -0700, Gupta, Anshuman wrote: > Hi Anshuman, > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > b/drivers/gpu/drm/i915/i915_reg.h > > index 55c35903adca..956e5298ef1e 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -6644,6 +6644,12 @@ > > #define DG1_PCODE_STATUS0x7E > > #define DG1_UNCORE_GET_INIT_STATUS0x0 > > #define DG1_UNCORE_INIT_STATUS_COMPLETE 0x1 > > +#define PCODE_POWER_SETUP0x7C > > +#define POWER_SETUP_SUBCOMMAND_READ_I1 0x4 > > +#define POWER_SETUP_SUBCOMMAND_WRITE_I10x5 > > +#definePOWER_SETUP_I1_WATTSREG_BIT(31) > > +#definePOWER_SETUP_I1_SHIFT6 /* 10.6 fixed > > point format */ > Could please add some comment to explain, why POWER_SETUP_I1_SHIFT = 6, > what is excatly 10.6 fixed point format ? > With that. > Reviewed-by: Anshuman Gupta 10.6 fixed point format means a 16 bit number is represented as x.y where x are the top 10 bits and y are the bottom 6 bits. The float value of this 16 bit number is (x + (y / 2^6)), so (x + (y / 64)). For example the number 0x8008 will have the value (1 * 2^9 + 8 / 2^6) == 512.125. Note that the hexadecimal number 0x8008 == 32776 and 512.125 == 32776 / 64 which is why POWER_SETUP_I1_SHIFT is 6 (2^6 == 64). Similarly, the 8.8 fixed point format is explained in gt/intel_gt_sysfs_pm.c. Do you think this needs a comment? I thought "10.6 fixed point format" is a sufficient hint (fixed point numbers are fairly well known). An even trickier data format is in the patch "drm/i915/hwmon: Expose power1_max_interval" in hwm_power1_max_interval_show() but I think I have a long comment there. Thanks. -- Ashutosh
[PATCH 08/12] openvswitch: 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: Pravin B Shelar
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Jakub Kicinski
Cc: Paolo Abeni
Cc: net...@vger.kernel.org
Cc: d...@openvswitch.org
Signed-off-by: Kees Cook
---
net/openvswitch/flow_netlink.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 4c09cf8a0ab2..11b2e2c94c7e 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2306,10 +2306,12 @@ int ovs_nla_put_mask(const struct sw_flow *flow, struct
sk_buff *skb)
static struct sw_flow_actions *nla_alloc_flow_actions(int size)
{
struct sw_flow_actions *sfa;
+ int alloc_size;
WARN_ON_ONCE(size > MAX_ACTIONS_BUFSIZE);
- sfa = kmalloc(sizeof(*sfa) + size, GFP_KERNEL);
+ alloc_size = kmalloc_size_roundup(sizeof(*sfa) + size);
+ sfa = kmalloc(alloc_size, GFP_KERNEL);
if (!sfa)
return ERR_PTR(-ENOMEM);
--
2.34.1
[PATCH 04/12] btrfs: send: Proactively round up to kmalloc bucket size
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: linux-bt...@vger.kernel.org
Signed-off-by: Kees Cook
---
fs/btrfs/send.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index e7671afcee4f..d40d65598e8f 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -435,6 +435,11 @@ static int fs_path_ensure_buf(struct fs_path *p, int len)
path_len = p->end - p->start;
old_buf_len = p->buf_len;
+ /*
+* Allocate to the next largest kmalloc bucket size, to let
+* the fast path happen most of the time.
+*/
+ len = kmalloc_size_roundup(len);
/*
* First time the inline_buf does not suffice
*/
@@ -448,11 +453,7 @@ static int fs_path_ensure_buf(struct fs_path *p, int len)
if (!tmp_buf)
return -ENOMEM;
p->buf = tmp_buf;
- /*
-* The real size of the buffer is bigger, this will let the fast path
-* happen most of the time
-*/
- p->buf_len = ksize(p->buf);
+ p->buf_len = len;
if (p->reversed) {
tmp_buf = p->buf + old_buf_len - path_len - 1;
--
2.34.1
[PATCH 12/12] slab: Restore __alloc_size attribute to __kmalloc_track_caller
With skbuff's post-allocation use of ksize() rearranged to use
kmalloc_size_round() prior to allocation, the compiler can correctly
reason about the size of these allocations. The prior mismatch had caused
buffer overflow mitigations to erroneously fire under CONFIG_UBSAN_BOUNDS,
requiring a partial revert of the __alloc_size attributes. Restore the
attribute that had been removed in commit 93dd04ab0b2b ("slab: remove
__alloc_size attribute from __kmalloc_track_caller").
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Signed-off-by: Kees Cook
---
include/linux/slab.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index ac3832b50dbb..dd50ed7207c9 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -693,7 +693,8 @@ static inline __alloc_size(1, 2) void *kcalloc(size_t n,
size_t size, gfp_t flag
* allocator where we care about the real place the memory allocation
* request comes from.
*/
-extern void *__kmalloc_track_caller(size_t size, gfp_t flags, unsigned long
caller);
+extern void *__kmalloc_track_caller(size_t size, gfp_t flags, unsigned long
caller)
+ __alloc_size(1);
#define kmalloc_track_caller(size, flags) \
__kmalloc_track_caller(size, flags, _RET_IP_)
--
2.34.1
[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); /* allocate q_vector and rings */ q_vector = adapter->q_vector[v_idx]; -- 2.34.1
[PATCH 05/12] dma-buf: Proactively round up to kmalloc bucket size
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: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Kees Cook
---
drivers/dma-buf/dma-resv.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 205acb2c744d..a20f6db99b8f 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -98,12 +98,17 @@ static void dma_resv_list_set(struct dma_resv_list *list,
static struct dma_resv_list *dma_resv_list_alloc(unsigned int max_fences)
{
struct dma_resv_list *list;
+ size_t size = struct_size(list, table, max_fences);
- list = kmalloc(struct_size(list, table, max_fences), GFP_KERNEL);
+ /* Round up to the next kmalloc bucket size. */
+ size = kmalloc_size_roundup(size);
+
+ list = kmalloc(size, GFP_KERNEL);
if (!list)
return NULL;
- list->max_fences = (ksize(list) - offsetof(typeof(*list), table)) /
+ /* Given the resulting bucket size, recalculated max_fences. */
+ list->max_fences = (size - offsetof(typeof(*list), table)) /
sizeof(*list->table);
return list;
--
2.34.1
[PATCH 03/12] net: ipa: Proactively round up to kmalloc bucket size
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;
if (!size)
return -EINVAL;
@@ -104,13 +105,15 @@ int gsi_trans_pool_init(struct gsi_trans_pool *pool,
size_t size, u32 count,
* If there aren't enough entries starting at the free index,
* we just allocate free entries from the beginning of the pool.
*/
- virt = kcalloc(count + max_alloc - 1, size, GFP_KERNEL);
+ allocate = size_mul(count + max_alloc - 1, size);
+ allocate = kmalloc_size_roundup(allocate);
+ virt = kzalloc(allocate, GFP_KERNEL);
if (!virt)
return -ENOMEM;
pool->base = virt;
/* If the allocator gave us any extra memory, use it */
- pool->count = ksize(pool->base) / size;
+ pool->count = allocate / size;
pool->free = 0;
pool->max_alloc = max_alloc;
pool->size = size;
--
2.34.1
[PATCH 09/12] x86/microcode/AMD: Track patch allocation size explicitly
In preparation for reducing the use of ksize(), record the actual
allocation size for later memcpy(). This avoids copying extra
(uninitialized!) bytes into the patch buffer when the requested allocation
size isn't exactly the size of a kmalloc bucket. Additionally fixes
potential future issues where runtime bounds checking will notice that
the buffer was allocated to a smaller value than returned by ksize().
Suggested-by: Daniel Micay
Link:
https://lore.kernel.org/lkml/ca+dvkq+bp7y7gmavhacjv9uf6ar-o4tet872h4q8rpypjjc...@mail.gmail.com/
Fixes: 757885e94a22 ("x86, microcode, amd: Early microcode patch loading
support for AMD")
Cc: Borislav Petkov
Cc: x...@kernel.org
Signed-off-by: Kees Cook
---
arch/x86/include/asm/microcode.h| 1 +
arch/x86/kernel/cpu/microcode/amd.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 0c3d3440fe27..aa675783412f 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -9,6 +9,7 @@
struct ucode_patch {
struct list_head plist;
void *data; /* Intel uses only this one */
+ unsigned int size;
u32 patch_id;
u16 equiv_cpu;
};
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 8b2fcdfa6d31..615bc6efa1dd 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -788,6 +788,7 @@ static int verify_and_add_patch(u8 family, u8 *fw, unsigned
int leftover,
kfree(patch);
return -EINVAL;
}
+ patch->size = *patch_size;
mc_hdr = (struct microcode_header_amd *)(fw + SECTION_HDR_SIZE);
proc_id = mc_hdr->processor_rev_id;
@@ -869,7 +870,7 @@ load_microcode_amd(bool save, u8 family, const u8 *data,
size_t size)
return ret;
memset(amd_ucode_patch, 0, PATCH_MAX_SIZE);
- memcpy(amd_ucode_patch, p->data, min_t(u32, ksize(p->data),
PATCH_MAX_SIZE));
+ memcpy(amd_ucode_patch, p->data, min_t(u32, p->size, PATCH_MAX_SIZE));
return ret;
}
--
2.34.1
[PATCH 02/12] skbuff: Proactively round up to kmalloc bucket size
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.
This will allow for kernels built with CONFIG_UBSAN_BOUNDS or the
coming dynamic bounds checking under CONFIG_FORTIFY_SOURCE to gain
back the __alloc_size() hints that were temporarily reverted in commit
93dd04ab0b2b ("slab: remove __alloc_size attribute from __kmalloc_track_caller")
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Jakub Kicinski
Cc: Paolo Abeni
Cc: net...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: Nick Desaulniers
Cc: David Rientjes
Cc: Vlastimil Babka
Signed-off-by: Kees Cook
---
net/core/skbuff.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
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);
@@ -1709,6 +1710,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int
ntail,
{
int i, osize = skb_end_offset(skb);
int size = osize + nhead + ntail;
+ int alloc_size;
long off;
u8 *data;
@@ -1722,11 +1724,11 @@ int pskb_expand_head(struct sk_buff *skb, int nhead,
int ntail,
if (skb_pfmemalloc(skb))
gfp_mask |= __GFP_MEMALLOC;
- data = kmalloc_reserve(size + SKB_DATA_ALIGN(sizeof(struct
skb_shared_info)),
- gfp_mask, NUMA_NO_NODE, NULL);
+ alloc_size = kmalloc_size_roundup(size + SKB_DATA_ALIGN(sizeof(struct
skb_shared_info)));
+ data = kmalloc_reserve(alloc_size, gfp_mask, NUMA_NO_NODE, NULL);
if (!data)
goto nodata;
- size = SKB_WITH_OVERHEAD(ksize(data));
+ size = SKB_WITH_OVERHEAD(alloc_size);
/* Copy only real data... and, alas, header. This should be
* optimized for the cases when header is void.
@@ -6063,19 +6065,19 @@ static int pskb_carve_inside_header(struct sk_buff
*skb, const u32 off,
int i;
int size = skb_end_offset(skb);
int new_hlen = headlen - off;
+ int alloc_size;
u8 *data;
size = SKB_DATA_ALIGN(size);
if (skb_pfmemalloc(skb))
gfp_mask |= __GFP_MEMALLOC;
- data = kmalloc_reserve(size +
- SKB_DATA_ALIGN(sizeof(struct skb_shared_info)),
- gfp_mask, NUMA_NO_NODE, NULL);
+ alloc_size = kmalloc_size_roundup(size + SKB_DATA_ALIGN(sizeof(struct
skb_shared_info)));
+ data = kmalloc_reserve(alloc_size, gfp_mask, NUMA_NO_NODE, NULL);
if (!data)
return -ENOMEM;
- size = SKB_WITH_OVERHEAD(ksize(data));
+ size = SKB_WITH_OVERHEAD(alloc_size);
/* Copy real data, and all frags */
skb_copy_from_linear_data_offset(skb, off, data, new_hlen);
@@ -6184,18 +6186,18 @@ static int pskb_carve_inside_nonlinear(struct sk_buff
*skb, const u32 off,
u8 *data;
const int nfrags = skb_shinfo(skb)->nr_frags;
struct skb_shared_info *shinfo;
+ int alloc_size;
size = SKB_DATA_ALIGN(size);
if (skb_pfmemalloc(skb))
gfp_mask |= __GFP_MEMALLOC;
- data = kmalloc_reserve(size +
- SKB_DATA_ALIGN(sizeof(struct skb_shared_info)),
- gfp_mask, NUMA_NO_NODE, NULL);
+ alloc_size = kmalloc_size_roundup(size + SKB_DATA_ALIGN(sizeof(struct
skb_shared_info)));
+ data = kmalloc_reserve(alloc_size, gfp_mask, NUMA_NO_NODE, NULL);
if (!data)
return -ENOMEM;
- size = SKB_WITH_OVERHEAD(ksize(data));
+ size = SKB_WITH_OVERHEAD(alloc_size);
memcpy((struct skb_shared_info *)(data + size),
skb_shinfo(skb), offsetof(struct skb_shared_info, frags[0]));
--
2.34.1
[PATCH 11/12] slab: Remove __malloc attribute from realloc functions
The __malloc attribute should not be applied to "realloc" functions, as
the returned pointer may alias the storage of the prior pointer. Instead
of splitting __malloc from __alloc_size, which would be a huge amount of
churn, just create __realloc_size for the few cases where it is needed.
Additionally removes the conditional test for __alloc_size__, which is
always defined now.
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: Nick Desaulniers
Cc: Hao Luo
Cc: Marco Elver
Cc: linux...@kvack.org
Signed-off-by: Kees Cook
---
include/linux/compiler_types.h | 13 +
include/linux/slab.h | 12 ++--
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 4f2a819fd60a..f141a6f6b9f6 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -271,15 +271,12 @@ struct ftrace_likely_data {
/*
* Any place that could be marked with the "alloc_size" attribute is also
- * a place to be marked with the "malloc" attribute. Do this as part of the
- * __alloc_size macro to avoid redundant attributes and to avoid missing a
- * __malloc marking.
+ * a place to be marked with the "malloc" attribute, except those that may
+ * be performing a _reallocation_, as that may alias the existing pointer.
+ * For these, use __realloc_size().
*/
-#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__)
#ifndef asm_volatile_goto
#define asm_volatile_goto(x...) asm goto(x)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 4fc41e4ed4a2..ac3832b50dbb 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -184,7 +184,7 @@ int kmem_cache_shrink(struct kmem_cache *s);
/*
* Common kmalloc functions provided by all allocators
*/
-void * __must_check krealloc(const void *objp, size_t new_size, gfp_t flags)
__alloc_size(2);
+void * __must_check krealloc(const void *objp, size_t new_size, gfp_t flags)
__realloc_size(2);
void kfree(const void *objp);
void kfree_sensitive(const void *objp);
size_t __ksize(const void *objp);
@@ -661,10 +661,10 @@ static inline __alloc_size(1, 2) void
*kmalloc_array(size_t n, size_t size, gfp_
* @new_size: new size of a single member of the array
* @flags: the type of memory to allocate (see kmalloc)
*/
-static inline __alloc_size(2, 3) void * __must_check krealloc_array(void *p,
- size_t
new_n,
- size_t
new_size,
- gfp_t flags)
+static inline __realloc_size(2, 3) void * __must_check krealloc_array(void *p,
+ size_t
new_n,
+ size_t
new_size,
+ gfp_t
flags)
{
size_t bytes;
@@ -788,7 +788,7 @@ static inline __alloc_size(1, 2) void *kvcalloc(size_t n,
size_t size, gfp_t fla
}
extern void *kvrealloc(const void *p, size_t oldsize, size_t newsize, gfp_t
flags)
- __alloc_size(3);
+ __realloc_size(3);
extern void kvfree(const void *addr);
extern void kvfree_sensitive(const void *addr, size_t len);
--
2.34.1
[PATCH 01/12] slab: Introduce kmalloc_size_roundup()
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(). [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 --- include/linux/slab.h | 31 +++ mm/slab_common.c | 17 + 2 files changed, 48 insertions(+) diff --git a/include/linux/slab.h b/include/linux/slab.h index 0fefdf528e0d..4fc41e4ed4a2 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -188,7 +188,21 @@ void * __must_check krealloc(const void *objp, size_t new_size, gfp_t flags) __a void kfree(const void *objp); void kfree_sensitive(const void *objp); size_t __ksize(const void *objp); + +/** + * ksize - Report actual allocation size of associated object + * + * @objp: Pointer returned from a prior kmalloc()-family allocation. + * + * This should not be used for writing beyond the originally requested + * allocation size. Either use krealloc() or round up the allocation size + * with kmalloc_size_roundup() prior to allocation. If this is used to + * access beyond the originally requested allocation size, UBSAN_BOUNDS + * and/or FORTIFY_SOURCE may trip, since they only know about the + * originally allocated size via the __alloc_size attribute. + */ size_t ksize(const void *objp); + #ifdef CONFIG_PRINTK bool kmem_valid_obj(void *object); void kmem_dump_obj(void *object); @@ -779,6 +793,23 @@ extern void kvfree(const void *addr); extern void kvfree_sensitive(const void *addr, size_t len); unsigned int kmem_cache_size(struct kmem_cache *s); + +/** + * kmalloc_size_roundup - Report allocation bucket size for the given size + * + * @size: Number of bytes to round up from. + * + * This returns the number of bytes that would be available in a kmalloc() + * allocation of @size bytes. For example, a 126 byte request would be + * rounded up to the next sized kmalloc bucket, 128 bytes. (This is strictly + * for the general-purpose kmalloc()-based allocations, and is not for the + * pre-sized kmem_cache_alloc()-based allocations.) + * + * Use this to kmalloc() the full bucket size ahead of time instead of using + * ksize() to query the size after an allocation. + */ +unsigned int kmalloc_size_roundup(size_t size); + void __init kmem_cache_init_late(void); #if defined(CONFIG_SMP) && defined(CONFIG_SLAB) diff --git a/mm/slab_common.c b/mm/slab_common.c index 17996649cfe3..132d91a0f8c7 100644 --- a/mm/slab_common.c +++
[PATCH 10/12] iwlwifi: Track scan_cmd allocation size explicitly
In preparation for reducing the use of ksize(), explicitly track the
size of scan_cmd allocations. This also allows for noticing if the scan
size changes unexpectedly. Note that using ksize() was already incorrect
here, in the sense that ksize() would not match the actual allocation
size, which would trigger future run-time allocation bounds checking.
(In other words, memset() may know how large scan_cmd was allocated for,
but ksize() will return the upper bounds of the actually allocated memory,
causing a run-time warning about an overflow.)
Cc: Gregory Greenman
Cc: Kalle Valo
Cc: Johannes Berg
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/net/wireless/intel/iwlwifi/dvm/dev.h | 1 +
drivers/net/wireless/intel/iwlwifi/dvm/scan.c | 10 --
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 ++-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 ++-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 6 +++---
5 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/dev.h
b/drivers/net/wireless/intel/iwlwifi/dvm/dev.h
index bbd574091201..1a9eadace188 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/dev.h
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/dev.h
@@ -696,6 +696,7 @@ struct iwl_priv {
/* Scan related variables */
unsigned long scan_start;
unsigned long scan_start_tsf;
+ size_t scan_cmd_size;
void *scan_cmd;
enum nl80211_band scan_band;
struct cfg80211_scan_request *scan_request;
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/scan.c
b/drivers/net/wireless/intel/iwlwifi/dvm/scan.c
index 2d38227dfdd2..a7e85c5c8c72 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/scan.c
@@ -626,7 +626,7 @@ static int iwlagn_request_scan(struct iwl_priv *priv,
struct ieee80211_vif *vif)
u8 active_chains;
u8 scan_tx_antennas = priv->nvm_data->valid_tx_ant;
int ret;
- int scan_cmd_size = sizeof(struct iwl_scan_cmd) +
+ size_t scan_cmd_size = sizeof(struct iwl_scan_cmd) +
MAX_SCAN_CHANNEL * sizeof(struct iwl_scan_channel) +
priv->fw->ucode_capa.max_probe_length;
const u8 *ssid = NULL;
@@ -649,9 +649,15 @@ static int iwlagn_request_scan(struct iwl_priv *priv,
struct ieee80211_vif *vif)
"fail to allocate memory for scan\n");
return -ENOMEM;
}
+ priv->scan_cmd_size = scan_cmd_size;
+ }
+ if (priv->scan_cmd_size < scan_cmd_size) {
+ IWL_DEBUG_SCAN(priv,
+ "memory needed for scan grew unexpectedly\n");
+ return -ENOMEM;
}
scan = priv->scan_cmd;
- memset(scan, 0, scan_cmd_size);
+ memset(scan, 0, priv->scan_cmd_size);
scan->quiet_plcp_th = IWL_PLCP_QUIET_THRESH;
scan->quiet_time = IWL_ACTIVE_QUIET_TIME;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index bf35e130c876..214b8a525cc6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -860,6 +860,7 @@ struct iwl_mvm {
/* Scan status, cmd (pre-allocated) and auxiliary station */
unsigned int scan_status;
+ size_t scan_cmd_size;
void *scan_cmd;
struct iwl_mcast_filter_cmd *mcast_filter_cmd;
/* For CDB this is low band scan type, for non-CDB - type. */
@@ -1705,7 +1706,7 @@ int iwl_mvm_update_quotas(struct iwl_mvm *mvm, bool
force_upload,
int iwl_mvm_reg_scan_start(struct iwl_mvm *mvm, struct ieee80211_vif *vif,
struct cfg80211_scan_request *req,
struct ieee80211_scan_ies *ies);
-int iwl_mvm_scan_size(struct iwl_mvm *mvm);
+size_t iwl_mvm_scan_size(struct iwl_mvm *mvm);
int iwl_mvm_scan_stop(struct iwl_mvm *mvm, int type, bool notify);
int iwl_mvm_max_scan_ie_len(struct iwl_mvm *mvm);
void iwl_mvm_report_scan_aborted(struct iwl_mvm *mvm);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
index db43c8a83a31..b9cbb18b0dcb 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
@@ -1065,7 +1065,7 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const
struct iwl_cfg *cfg,
static const u8 no_reclaim_cmds[] = {
TX_CMD,
};
- int scan_size;
+ size_t scan_size;
u32 min_backoff;
struct iwl_mvm_csme_conn_info *csme_conn_info __maybe_unused;
@@ -1299,6 +1299,7 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const
struct iwl_cfg *cfg,
mvm->scan_cmd = kmalloc(scan_size, GFP_KERNEL);
if (!mvm->scan_cmd)
goto out_free;
+ mvm->scan_cmd_size
[PATCH 06/12] coredump: Proactively round up to kmalloc bucket size
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: linux-fsde...@vger.kernel.org
Signed-off-by: Kees Cook
---
fs/coredump.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 9f4aae202109..0894b2c35d98 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -68,7 +68,10 @@ struct core_name {
static int expand_corename(struct core_name *cn, int size)
{
- char *corename = krealloc(cn->corename, size, GFP_KERNEL);
+ char *corename;
+
+ size = kmalloc_size_roundup(size);
+ corename = krealloc(cn->corename, size, GFP_KERNEL);
if (!corename)
return -ENOMEM;
@@ -76,7 +79,7 @@ static int expand_corename(struct core_name *cn, int size)
if (size > core_name_size) /* racy but harmless */
core_name_size = size;
- cn->size = ksize(corename);
+ cn->size = size;
cn->corename = corename;
return 0;
}
--
2.34.1
[PATCH 00/12] slab: Introduce kmalloc_size_roundup()
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. Quoting the first patch: 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(). [1] https://github.com/ClangBuiltLinux/linux/issues/1599 https://github.com/KSPP/linux/issues/183 --- And after adding kmalloc_size_roundup(), put it to use with the various ksize() callers, restore the previously removed __alloc_size hint, and fix the use of __malloc annotations. I tried to trim the CC list on this series since it got rather long. I kept all the suggested mailing lists, though. :) Thanks! -Kees Kees Cook (12): slab: Introduce kmalloc_size_roundup() skbuff: Proactively round up to kmalloc bucket size net: ipa: Proactively round up to kmalloc bucket size btrfs: send: Proactively round up to kmalloc bucket size dma-buf: Proactively round up to kmalloc bucket size coredump: Proactively round up to kmalloc bucket size igb: Proactively round up to kmalloc bucket size openvswitch: Proactively round up to kmalloc bucket size x86/microcode/AMD: Track patch allocation size explicitly iwlwifi: Track scan_cmd allocation size explicitly slab: Remove __malloc attribute from realloc functions slab: Restore __alloc_size attribute to __kmalloc_track_caller arch/x86/include/asm/microcode.h | 1 + arch/x86/kernel/cpu/microcode/amd.c | 3 +- drivers/dma-buf/dma-resv.c| 9 +++- drivers/net/ethernet/intel/igb/igb_main.c | 1 + drivers/net/ipa/gsi_trans.c | 7 ++- drivers/net/wireless/intel/iwlwifi/dvm/dev.h | 1 + drivers/net/wireless/intel/iwlwifi/dvm/scan.c | 10 +++- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +- drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 +- drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 6 +-- fs/btrfs/send.c | 11 +++-- fs/coredump.c | 7 ++- include/linux/compiler_types.h| 13 ++ include/linux/slab.h | 46 --- mm/slab_common.c | 17 +++ net/core/skbuff.c | 34 +++--- net/openvswitch/flow_netlink.c| 4 +- 17 files changed, 125 insertions(+), 51 deletions(-) -- 2.34.1
Re: [PATCH 01/18] phy: mediatek: add a new helper to update bitfield
On Wed, 2022-09-21 at 10:15 +0200, AngeloGioacchino Del Regno wrote:
> Il 20/09/22 11:00, Chunfeng Yun ha scritto:
> > Due to FIELD_PREP() macro can be used to prepare a bitfield value,
> > local ones can be remove; add the new helper to make bitfield
> > update
> > easier.
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > drivers/phy/mediatek/phy-mtk-io.h | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/phy/mediatek/phy-mtk-io.h
> > b/drivers/phy/mediatek/phy-mtk-io.h
> > index 500fcdab165d..a723d4afc9b4 100644
> > --- a/drivers/phy/mediatek/phy-mtk-io.h
> > +++ b/drivers/phy/mediatek/phy-mtk-io.h
> > @@ -8,6 +8,7 @@
> > #ifndef __PHY_MTK_H__
> > #define __PHY_MTK_H__
> >
> > +#include
> > #include
> >
> > static inline void mtk_phy_clear_bits(void __iomem *reg, u32
> > bits)
> > @@ -35,4 +36,10 @@ static inline void mtk_phy_update_bits(void
> > __iomem *reg, u32 mask, u32 val)
> > writel(tmp, reg);
> > }
> >
> > +/* field @mask should be constant and continuous */
>
> "Field @mask shall be [...]"
> ^
Ok, will modify it
>
> > +static inline void mtk_phy_update_field(void __iomem *reg, u32
> > mask, u32 val)
>
> ...so, (void __iomem *reg, const u32 mask, u32 val)
Maybe no need const, @mask will be checked it in compile time when
use FIELD_PREP(), means @mask is a constant value, but not a variable.
Thanks
>
> > +{
> > + mtk_phy_update_bits(reg, mask, FIELD_PREP(mask, val));
> > +}
> > +
> > #endif
>
>
RE: [PATCH v1] drivers:amdgpu: check the return value of amdgpu_bo_kmap
Perhaps you need to update the prefix of patch subject to 'drm/amd/pm: check
return value ...'.
With above addressed, it's: Acked-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Li Zhong
Sent: Thursday, September 22, 2022 9:27 AM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: jiapeng.ch...@linux.alibaba.com; Powell, Darren ;
Chen, Guchun ; Limonciello, Mario
; Quan, Evan ; Lazar, Lijo
; dan...@ffwll.ch; airl...@linux.ie; Pan, Xinhui
; Koenig, Christian ; Deucher,
Alexander ; Li Zhong
Subject: [PATCH v1] drivers:amdgpu: check the return value of amdgpu_bo_kmap
amdgpu_bo_kmap() returns error when fails to map buffer object. Add the error
check and propagate the error.
Signed-off-by: Li Zhong
---
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;
}
--
2.25.1
[PATCH] drm/ttm: clean the redundant assignment
Clean the redundant assignment of ttm->caching in ttm_tt_init_fields().
Signed-off-by: Chuansheng Liu
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index d505603930a7..e110db86c870 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -136,7 +136,6 @@ static void ttm_tt_init_fields(struct ttm_tt *ttm,
unsigned long extra_pages)
{
ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT) +
extra_pages;
- ttm->caching = ttm_cached;
ttm->page_flags = page_flags;
ttm->dma_address = NULL;
ttm->swap_storage = NULL;
--
2.25.0.rc2
[PATCH 2/2] drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()
Currently there is no protection against a user trying to set
an unsupported mode on DSI. Implement a check based on the opp
table whether the byte clock for the mode can be supported by
validating whether an opp table entry exists.
For devices which have not added opp table support yet, skip
this check otherwise it will break bootup on those devices.
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15
Reported-by: Rob Clark
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3a1417397283..87b518c42965 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -450,6 +450,29 @@ static enum drm_mode_status
dsi_mgr_bridge_mode_valid(struct drm_bridge *bridge,
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct mipi_dsi_host *host = msm_dsi->host;
+ struct platform_device *pdev = msm_dsi->pdev;
+ struct dev_pm_opp *opp;
+ struct opp_table *opp_tbl;
+ unsigned long byte_clk_rate;
+
+ byte_clk_rate = dsi_byte_clk_get_rate(host, IS_BONDED_DSI(), mode);
+
+ /*
+* first check if there is an opp table available for the calculated
+* byte clock and then check DSC related info. Some devices have not
+* added support for OPP table. Skip the check for those.
+*/
+ opp_tbl = dev_pm_opp_get_opp_table(>dev);
+ if (opp_tbl) {
+ opp = dev_pm_opp_find_freq_ceil(>dev, _clk_rate);
+ if (IS_ERR(opp)) {
+ pr_err("opp table not found for freq %lu err: %ld\n",
+ byte_clk_rate, PTR_ERR(opp));
+ return PTR_ERR(opp);
+ }
+ dev_pm_opp_put(opp);
+ dev_pm_opp_put_opp_table(opp_tbl);
+ }
return msm_dsi_host_check_dsc(host, mode);
}
--
2.7.4
[PATCH 1/2] drm/msm/dsi: add a helper method to compute the dsi byte clk
Re-arrange the dsi_calc_pclk method to two helpers, one to
compute the DSI byte clk and the other to compute the pclk.
This makes the separation of the two clean and also allows
clients to compute and use the dsi byte clk separately.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
drivers/gpu/drm/msm/dsi/dsi_host.c | 27 +++
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 2a96b4fe7839..60ba8e67f550 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -118,6 +118,8 @@ int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host *host, bool
is_bonded_dsi,
+ const struct drm_display_mode *mode);
int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 57a4c0fa614b..32b35d4ac1d3 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -569,9 +569,8 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
-static unsigned long dsi_get_pclk_rate(struct msm_dsi_host *msm_host, bool
is_bonded_dsi)
+static unsigned long dsi_get_pclk_rate(const struct drm_display_mode *mode,
bool is_bonded_dsi)
{
- struct drm_display_mode *mode = msm_host->mode;
unsigned long pclk_rate;
pclk_rate = mode->clock * 1000;
@@ -588,12 +587,18 @@ static unsigned long dsi_get_pclk_rate(struct
msm_dsi_host *msm_host, bool is_bo
return pclk_rate;
}
-static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
+unsigned long dsi_byte_clk_get_rate(struct mipi_dsi_host *host, bool
is_bonded_dsi,
+ const struct drm_display_mode *mode)
{
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
u8 lanes = msm_host->lanes;
u32 bpp = dsi_get_bpp(msm_host->format);
- unsigned long pclk_rate = dsi_get_pclk_rate(msm_host, is_bonded_dsi);
- u64 pclk_bpp = (u64)pclk_rate * bpp;
+ unsigned long pclk_rate;
+ u64 pclk_bpp;
+
+ pclk_rate = dsi_get_pclk_rate(mode, is_bonded_dsi);
+
+ pclk_bpp = (u64)pclk_rate * bpp;
if (lanes == 0) {
pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
@@ -606,8 +611,14 @@ static void dsi_calc_pclk(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
else
do_div(pclk_bpp, (8 * lanes));
- msm_host->pixel_clk_rate = pclk_rate;
- msm_host->byte_clk_rate = pclk_bpp;
+ return pclk_bpp;
+}
+
+static void dsi_calc_pclk(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
+{
+ msm_host->pixel_clk_rate = dsi_get_pclk_rate(msm_host->mode,
is_bonded_dsi);
+ msm_host->byte_clk_rate = dsi_byte_clk_get_rate(_host->base,
is_bonded_dsi,
+ msm_host->mode);
DBG("pclk=%lu, bclk=%lu", msm_host->pixel_clk_rate,
msm_host->byte_clk_rate);
@@ -635,7 +646,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
dsi_calc_pclk(msm_host, is_bonded_dsi);
- pclk_bpp = (u64)dsi_get_pclk_rate(msm_host, is_bonded_dsi) * bpp;
+ pclk_bpp = (u64)dsi_get_pclk_rate(msm_host->mode, is_bonded_dsi) * bpp;
do_div(pclk_bpp, 8);
msm_host->src_clk_rate = pclk_bpp;
--
2.7.4
Re: [PATCH v2 1/7] dt-bindings: msm/dp: Add SDM845 and SC8280XP compatibles
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. > 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. > > > > I'm not entirely sure what you mean about taking ownership, > > I meant you to be the author of the commit. > As mentioned above, I can't do that. Regards, Bjorn > > I am going > > to pursue getting these patches landed. But it wouldn't be correct for > > new me to claim I authored them. > > Yeah, that's true. > > > Best regards, > Krzysztof
[GIT PULL] mediatek drm fixes for 6.0
Hi, Dave & Daniel:
This includes:
1. dsi: Add atomic {destroy,duplicate}_state, reset callbacks
2. drm/mediatek: Fix wrong dither settings
3. dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
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-fixes-6.0
for you to fetch changes up to 90144dd8b0d137d9e78ef34b3c418e51a49299ad:
drm/mediatek: dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
(2022-09-22 07:31:43 +0800)
Mediatek DRM Fixes for Linux 6.0
1. dsi: Add atomic {destroy,duplicate}_state, reset callbacks
2. drm/mediatek: Fix wrong dither settings
3. dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
Allen-KH Cheng (1):
drm/mediatek: Fix wrong dither settings
AngeloGioacchino Del Regno (1):
drm/mediatek: dsi: Add atomic {destroy,duplicate}_state, reset callbacks
Nícolas F. R. A. Prado (1):
drm/mediatek: dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 24 +---
2 files changed, 14 insertions(+), 12 deletions(-)
Re: [PATCH 2/2] power: supply: Add Lenovo Yoga C630 EC driver
On Fri, Sep 16, 2022 at 12:53:42AM +0300, Dmitry Baryshkov wrote:
> On Fri, 16 Sept 2022 at 00:25, Bjorn Andersson wrote:
> >
> > On Tue, Sep 13, 2022 at 12:45:45PM +0200, Sebastian Reichel wrote:
> > > Hi,
> > >
> > > [+Cc Lee Jones, DRI devel]
> > >
> > > On Tue, Aug 09, 2022 at 10:05:00PM -0500, Bjorn Andersson wrote:
> > > > The Qualcomm Snapdragon-based Lenovo Yoga C630 has some sort of EC
> > > > providing AC-adapter and battery status, as well as USB Type-C altmode
> > > > notifications for Displayport operation.
> > > >
> > > > The Yoga C630 ships with Windows, where these operations primarily are
> > > > implemented in ACPI, but due to various issues with the hardware
> > > > representation therein it's not possible to run Linux on this
> > > > information. As such this is a best-effort re-implementation of these
> > > > operations, based on the register map expressed in ACPI and a fair
> > > > amount of trial and error.
> > > >
> > > > Signed-off-by: Bjorn Andersson
> > > > ---
> > > > [...]
> > > > + val = yoga_c630_ec_read8(ec, LENOVO_EC_BAT_ATTRIBUTES);
> > > > + if (val < 0)
> > > > + goto out_unlock;
> > > > + ec->unit_ma = val & LENOVO_EC_BAT_ATTR_UNIT_IS_MA;
> > > > + if (!ec->unit_ma)
> > > > + ec->scale = 1000;
> > > > + else
> > > > + ec->scale = 1;
> > >
> > > Since I'm not sure how much of information was gained by reverse
> > > engineering: Is this really milliamps vs microamps and not milliamps
> > > vs milliwatt? SBS batteries usually report either mA or mW.
> > >
> >
> > Unfortunately I don't know the answer to this.
> >
> > > > [...]
> > > > + case POWER_SUPPLY_PROP_SERIAL_NUMBER:
> > > > + val->strval = "05072018";
> > > > + break;
> > >
> > > why is this hardcoded? :)
> > >
> >
> > I don't know, but as Daniel suggests, it would make sense to just drop
> > it.
> >
> > > > [...]
> > > > + device_for_each_child_node(dev, fwnode) {
> > > > + ret = fwnode_property_read_u32(fwnode, "reg", );
> > > > + if (ret < 0)
> > > > + continue;
> > > > +
> > > > + /* Got multiple ports, but altmode is only possible on port
> > > > 1 */
> > > > + if (port != 1)
> > > > + continue;
> > > > +
> > > > + ec->bridge.funcs = _c630_ec_bridge_funcs;
> > > > + ec->bridge.of_node = to_of_node(fwnode);
> > > > + ec->bridge.ops = DRM_BRIDGE_OP_HPD;
> > > > + ec->bridge.type = DRM_MODE_CONNECTOR_USB;
> > > > +
> > > > + ret = devm_drm_bridge_add(dev, >bridge);
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to register drm bridge\n");
> > > > + fwnode_handle_put(fwnode);
> > > > + return ret;
> > > > + }
> > >
> > > I wonder if DRM people want to see this in drivers/gpu/drm/bridge.
> > > Maybe it's better to make this a MFD driver?
> > >
> >
> > I did consider it, but it adds a whole bunch of boiler plate code
> > without a lot of benefit.
> >
> > There are a few other cases where I think it would make sense to have
> > drm bridges outside of drivers/gpu/drm, such as
> > drivers/usb/typec/altmodes/ and drivers/platform/chrome/...
>
> What about a solution which might sound simpler than MFD: from your
> driver's probe() register a platform device which represents a drm
> bridge. Add drm_bridge driver for it into drivers/gpu/drm/bridges/.
>
That is indeed simpler
But then rather than just calling drm_bridge_hpd_notify(status) we need
a new custom interface for this driver to call the other drive when
status changes and we waste 840 bytes just to track another struct
platform_device.
Perhaps that could be made generic, so we'd have "proxy_drm_bridge"
driver for drivers who implements a HPD drm_bridge but don't want to
implement that outside drivers/gpu/drm.
But this is just based on the assumption that the "DRM people" require
drm_bridges to only live in drivers/gpu/drm/. It's all one kernel and
the API is well defined, so I don't think there's a concrete problem to
solve.
Regards,
Bjorn
[linux-next:master] BUILD REGRESSION 483fed3b5dc8ce3644c83d24240cf5756fb0993e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 483fed3b5dc8ce3644c83d24240cf5756fb0993e Add linux-next specific files for 20220921 Error/Warning reports: https://lore.kernel.org/linux-mm/202209042337.fqi69rlv-...@intel.com https://lore.kernel.org/linux-mm/202209060229.dvuyxjbv-...@intel.com https://lore.kernel.org/linux-mm/202209150141.wgbakqmx-...@intel.com https://lore.kernel.org/linux-mm/202209160607.se3qvgty-...@intel.com https://lore.kernel.org/linux-mm/202209200603.hpvoa8ii-...@intel.com https://lore.kernel.org/linux-mm/202209200949.vl3xruyd-...@intel.com https://lore.kernel.org/llvm/202209220009.8nypipst-...@intel.com https://lore.kernel.org/llvm/202209220019.yr2vuxhg-...@intel.com Error/Warning: (recently discovered and may have been fixed) ERROR: modpost: "devm_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_ioremap_resource" [drivers/dma/idma64.ko] undefined! ERROR: modpost: "devm_ioremap_resource" [drivers/dma/qcom/hdma.ko] undefined! ERROR: modpost: "devm_memremap" [drivers/misc/open-dice.ko] undefined! ERROR: modpost: "devm_memunmap" [drivers/misc/open-dice.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/char/xillybus/xillybus_of.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/clk/xilinx/clk-xlnx-clock-wizard.ko] undefined! ERROR: modpost: "ioremap" [drivers/tty/ipwireless/ipwireless.ko] undefined! ERROR: modpost: "iounmap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined! ERROR: modpost: "iounmap" [drivers/tty/ipwireless/ipwireless.ko] undefined! arch/arm64/kernel/alternative.c:199:6: warning: no previous prototype for 'apply_alternatives_vdso' [-Wmissing-prototypes] arch/arm64/kernel/alternative.c:295:14: warning: no previous prototype for 'alt_cb_patch_nops' [-Wmissing-prototypes] arch/ia64/kernel/sys_ia64.c:188:17: sparse: sparse: typename in expression arch/ia64/kernel/sys_ia64.c:188:31: sparse: sparse: Trying to use reserved word 'typeof' as identifier arch/ia64/kernel/sys_ia64.c:188:31: sparse: sparse: Trying to use reserved word 'void' as identifier arch/ia64/kernel/sys_ia64.c:189:60: sparse: sparse: invalid initializer arch/ia64/kernel/sys_ia64.c:190:17: sparse: sparse: Trying to use reserved word 'return' as identifier arch/parisc/lib/iomap.c:363:5: warning: no previous prototype for 'ioread64_lo_hi' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:373:5: warning: no previous prototype for 'ioread64_hi_lo' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:448:6: warning: no previous prototype for 'iowrite64_lo_hi' [-Wmissing-prototypes] arch/parisc/lib/iomap.c:454:6: warning: no previous prototype for 'iowrite64_hi_lo' [-Wmissing-prototypes] drivers/scsi/qla2xxx/qla_os.c:2854:23: warning: assignment to 'struct trace_array *' from 'int' makes pointer from integer without a cast [-Wint-conversion] drivers/scsi/qla2xxx/qla_os.c:2854:25: error: implicit declaration of function 'trace_array_get_by_name'; did you mean 'trace_array_set_clr_event'? [-Werror=implicit-function-declaration] drivers/scsi/qla2xxx/qla_os.c:2869:9: error: implicit declaration of function 'trace_array_put' [-Werror=implicit-function-declaration] mm/hugetlb.c:5539:14: warning: variable 'reserve_alloc' set but not used [-Wunused-but-set-variable] Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-scsi-qla2xxx-qla_os.c:error:implicit-declaration-of-function-trace_array_get_by_name | |-- drivers-scsi-qla2xxx-qla_os.c:error:implicit-declaration-of-function-trace_array_put | `-- drivers-scsi-qla2xxx-qla_os.c:warning:assignment-to-struct-trace_array-from-int-makes-pointer-from-integer-without-a-cast |-- alpha-randconfig-s033-20220921 | `-- kernel-exit.c:sparse:sparse:incorrect-type-in-initializer-(different-address-spaces)-expected-struct-sighand_struct-sighand-got-struct-sighand_struct-noderef-__rcu-sighand |-- arm64-allyesconfig | |-- arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-alt_cb_patch_nops | |-- arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-apply_alternatives_vdso | `-- mm-hugetlb.c:warning:variable-reserve_alloc-set-but-not-used |-- arm64-randconfig-r013-20220921 | |-- arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-alt_cb_patch_nops | `-- arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-apply_alternatives_vdso |-- i386-allyesconfig | `-- mm-hugetlb.c:warning:variable-reserve_alloc-set-but-not-used |-- i386-defconfig | `-- mm-hugetlb.c:warning:variable-reserve_alloc-set-but-not-used |-- i386-randconfig-c021 | `-- mm-hugetlb.c:warning:variable-reserve_alloc-set-but-not-used |-- i386-randconfig-m021 | `-- drivers-gpu-drm-display-drm_dp_helper.c-drm_dp_phy_name()-warn:unsigned-dp_phy-is-never-less-than-zero.
[pull] amdgpu drm-fixes-6.0
Hi Dave, Daniel, Fixes for 6.0. Mainly fixes for new IPs. The big change here is the DML clean up from Nathan to fix the Clang stack usage warnings on the DCN 3.1.4 code which was recently enabled. The following changes since commit a8671493d2074950553da3cf07d1be43185ef6c6: drm/amdgpu: make sure to init common IP before gmc (2022-09-14 14:21:49 -0400) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.0-2022-09-21 for you to fetch changes up to f525ed19437d376736bed64ee7bc4afee82f2ba9: drm/amd/display: Reduce number of arguments of dml314's CalculateFlipSchedule() (2022-09-21 17:36:57 -0400) amd-drm-fixes-6.0-2022-09-21: amdgpu: - SDMA 6.x fix - GPUVM TF fix - DCN 3.2.x fixes - DCN 3.1.x fixes - SMU 13.x fixes - Clang stack size fixes for recently enabled DML code - Fix drm dirty callback change on non-atomic cases - USB4 display fix Alex Deucher (1): drm/amdgpu: don't register a dirty callback for non-atomic Alvin Lee (1): drm/amd/display: Only consider pixle rate div policy for DCN32+ Charlene Liu (1): drm/amd/display: correct num_dsc based on HW cap Chris Park (1): drm/amd/display: Port DCN30 420 logic to DCN32 Cruise Hung (1): drm/amd/display: Fix DP MST timeslot issue when fallback happened Daniel Miess (1): drm/amd/display: Add shift and mask for ICH_RESET_AT_END_OF_LINE Dmytro Laktyushkin (2): drm/amd/display: fix dcn315 memory channel count and width read drm/amd/display: increase dcn315 pstate change latency Evan Quan (2): drm/amd/pm: add support for 3794 pptable for SMU13.0.0 drm/amd/pm: drop the pptable related workarounds for SMU 13.0.0 George Shen (1): drm/amd/display: Update dummy P-state search to use DCN32 DML Hugo Hu (1): drm/amd/display: update gamut remap if plane has changed Leo Li (1): drm/amd/display: Fix double cursor on non-video RGB MPO Meenakshikumar Somasundaram (1): drm/amd/display: Display distortion after hotplug 5K tiled display Michael Strauss (1): drm/amd/display: Assume an LTTPR is always present on fixed_vs links Mukul Joshi (1): drm/amdgpu: Update PTE flags with TF enabled Nathan Chancellor (2): drm/amd/display: Reduce number of arguments of dml314's CalculateWatermarksAndDRAMSpeedChangeSupport() drm/amd/display: Reduce number of arguments of dml314's CalculateFlipSchedule() Nicholas Kazlauskas (1): drm/amd/display: Disable OTG WA for the plane_state NULL case on DCN314 Yifan Zhang (1): drm/amdgpu/mes: zero the sdma_hqd_mask of 2nd SDMA engine for SDMA 6.0.1 zhikzhai (1): drm/amd/display: skip audio setup when audio stream is enabled drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +- .../amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c | 11 +- .../amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c | 14 +- .../amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 36 +- .../amd/display/dc/clk_mgr/dcn316/dcn316_clk_mgr.c | 11 +- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 16 +- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 17 + .../amd/display/dc/dce110/dce110_hw_sequencer.c| 6 +- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h | 220 --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 1 + .../gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c | 16 +- .../gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.h | 2 - .../gpu/drm/amd/display/dc/dcn314/dcn314_init.c| 1 - .../drm/amd/display/dc/dcn314/dcn314_resource.c| 11 +- .../gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c | 7 +- .../display/dc/dml/dcn314/display_mode_vba_314.c | 420 + .../gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 46 ++- .../gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.h | 6 + .../amd/display/dc/dml/dcn32/display_mode_vba_32.c | 2 + .../dc/dml/dcn32/display_mode_vba_util_32.c| 26 ++ .../dc/dml/dcn32/display_mode_vba_util_32.h| 1 + drivers/gpu/drm/amd/display/dc/inc/resource.h | 4 + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 44 +-- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 53 +-- 28 files changed, 309 insertions(+), 698 deletions(-)
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2022-09-21: 2 gem context related fixes: - to avoid a general protection failure when using perf/OA (Chris) - to avoid kernel warnings on driver release (Janusz) Thanks, Rodrigo. The following changes since commit 521a547ced6477c54b4b0cc206000406c221b4d6: Linux 6.0-rc6 (2022-09-18 13:44:14 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-09-21 for you to fetch changes up to d119888b09bd567e07c6b93a07f175df88857e02: drm/i915/gem: Really move i915_gem_context.link under ref protection (2022-09-20 10:19:05 -0400) 2 gem context related fixes: - to avoid a general protection failure when using perf/OA (Chris) - to avoid kernel warnings on driver release (Janusz) Chris Wilson (1): drm/i915/gem: Really move i915_gem_context.link under ref protection Janusz Krzysztofik (1): drm/i915/gem: Flush contexts on driver release drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 drivers/gpu/drm/i915/i915_gem.c | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-)
Re: [PATCH v2] Documentation: fb: udlfb: clean up text and formatting
Randy Dunlap writes: > Clean up punctuation, spelling, and formatting for command line usage > and modprobe config file usage in udlfb.rst. > > Signed-off-by: Randy Dunlap > Cc: Bernie Thompson > Cc: linux-fb...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: Helge Deller > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Bagas Sanjaya > --- > v2: use some text suggestions from Bagas Sanjaya (Thanks); > add a '.' at the end of a sentence. > > Documentation/fb/udlfb.rst | 23 +++ > 1 file changed, 15 insertions(+), 8 deletions(-) Applied, thanks. jon
Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering
On Wed, Sep 21, 2022 at 12:26:17PM -0700, Matt Roper wrote:
> On Wed, Sep 21, 2022 at 12:58:08PM -0400, Kumar Valsan, Prathap wrote:
> > On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> > > On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 16/09/2022 02:43, Matt Roper wrote:
> > > > > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > > > > that a subset of these are of a "GAM" subclass that has unique rules
> > > > > and
> > > > > doesn't followed regular mslice steering behavior.
> > > > >
> > > > > * Xe_HP SDV: GAM ranges must always be steered to 0,0. These
> > > > > registers share the regular steering control register (0xFDC) with
> > > > > other steering types
> > > > >
> > > > > * DG2: GAM ranges must always be steered to 1,0. GAM registers
> > > > > have a
> > > > > dedicated steering control register (0xFE0) so we can set the
> > > > > value
> > > > > once at startup and rely on implicit steering. Technically the
> > > > > hardware default should already be set to 1,0 properly, but it
> > > > > never
> > > > > hurts to ensure that in the driver.
> > > >
> > > > Do you have any data on whether the "technically should" holds in
> > > > practice?
> > > > What would be the consequences of some platform/machine surprising us
> > > > here?
> > >
> > > The bspec indicates the hardware default value is already the necessary
> > > 1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
> > > it to 0,0 by accident. I don't have any evidence that has ever actually
> > > happened, but explicitly re-programming it to 1,0 in the patch here is a
> > > defensive measure just to be safe.
> > >
> > > If we didn't have this patch _and_ some firmware screwed up the GAM
> > > steering target, then presumably we might read back garbage or 0 from
> > > GAM registers in places where we should have received a real value.
> > Will firmware ever touch the steering target registers. As i was going
> > through the respective hsd. The software driver impact is marked as none
> > so wondering if this change is really required ?
>
> The GAM only has a dedicated steering register on DG2; on XEHPSDV it
> shares 0xFDC with all the other kinds of steering, so it is important to
> handle this range independently of the MSLICE range and make sure we
> properly re-steer GAM accesses to the primary instance (and not just any
> random MSLICE) there.
Ok. I missed that part.
>
> On DG2, if we assume firmware behaves properly, the dedicated steering
> register is initialized properly and we don't need to explicitly
> re-steer. However this patch will ensure that we don't needlessly
> re-program 0xFDC according to MSLICE rules when accessing a GAM
> register.
>
> There's also the worry that firmware may try to "sanitize" the registers
> at startup by programming them to what it thinks are appropriate default
> values. Given that DG2's primary GAM is unusual (instance 1, instead of
> instance 0 as on other platforms), this feels like a place where
> firmware bugs could creep in. They hopefully/probably won't, but
> ensuring we forcefully initialize 0xFE0 to the proper value just ensures
> that we don't even have to worry about it.
Got it.
>
> Finally, splitting the GAM from MSLICE ensures we get more accurate
> debug messages from the drm_printer in dmesg and debugfs.
>
Looks good to me.
Reviewed-by: Prathap Kumar Valsan
>
> Matt
>
> >
> > Thanks,
> > Prathap
> > >
> > >
> > > Matt
> > >
> > > >
> > > > Regards,
> > > >
> > > > Tvrtko
> > > >
> > > > >
> > > > > Bspec: 66534
> > > > > Signed-off-by: Matt Roper
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24
> > > > > +++--
> > > > > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> > > > > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > > > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > > > > 4 files changed, 34 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > > index e79405a45312..a2047a68ea7a 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > > > > "L3BANK",
> > > > > "MSLICE",
> > > > > "LNCF",
> > > > > + "GAM",
> > > > > "INSTANCE 0",
> > > > > };
> > > > > @@ -48,14 +49,23 @@ static const struct intel_mmio_range
> > > > > icl_l3bank_steering_table[] = {
> > > > > {},
> > > > > };
> > > > > +/*
> > > > > + * Although the bspec lists more "MSLICE" ranges than shown here,
> > > > > some of those
> > > > > + * are of a "GAM" subclass that has special rules. Thus we use a
> > > > > separate
> > > > > + * GAM table farther down for those.
> > > > > + */
> > > >
Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering
On Wed, Sep 21, 2022 at 12:58:08PM -0400, Kumar Valsan, Prathap wrote:
> On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> > On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 16/09/2022 02:43, Matt Roper wrote:
> > > > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > > > that a subset of these are of a "GAM" subclass that has unique rules and
> > > > doesn't followed regular mslice steering behavior.
> > > >
> > > > * Xe_HP SDV: GAM ranges must always be steered to 0,0. These
> > > > registers share the regular steering control register (0xFDC) with
> > > > other steering types
> > > >
> > > > * DG2: GAM ranges must always be steered to 1,0. GAM registers have
> > > > a
> > > > dedicated steering control register (0xFE0) so we can set the value
> > > > once at startup and rely on implicit steering. Technically the
> > > > hardware default should already be set to 1,0 properly, but it never
> > > > hurts to ensure that in the driver.
> > >
> > > Do you have any data on whether the "technically should" holds in
> > > practice?
> > > What would be the consequences of some platform/machine surprising us
> > > here?
> >
> > The bspec indicates the hardware default value is already the necessary
> > 1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
> > it to 0,0 by accident. I don't have any evidence that has ever actually
> > happened, but explicitly re-programming it to 1,0 in the patch here is a
> > defensive measure just to be safe.
> >
> > If we didn't have this patch _and_ some firmware screwed up the GAM
> > steering target, then presumably we might read back garbage or 0 from
> > GAM registers in places where we should have received a real value.
> Will firmware ever touch the steering target registers. As i was going
> through the respective hsd. The software driver impact is marked as none
> so wondering if this change is really required ?
The GAM only has a dedicated steering register on DG2; on XEHPSDV it
shares 0xFDC with all the other kinds of steering, so it is important to
handle this range independently of the MSLICE range and make sure we
properly re-steer GAM accesses to the primary instance (and not just any
random MSLICE) there.
On DG2, if we assume firmware behaves properly, the dedicated steering
register is initialized properly and we don't need to explicitly
re-steer. However this patch will ensure that we don't needlessly
re-program 0xFDC according to MSLICE rules when accessing a GAM
register.
There's also the worry that firmware may try to "sanitize" the registers
at startup by programming them to what it thinks are appropriate default
values. Given that DG2's primary GAM is unusual (instance 1, instead of
instance 0 as on other platforms), this feels like a place where
firmware bugs could creep in. They hopefully/probably won't, but
ensuring we forcefully initialize 0xFE0 to the proper value just ensures
that we don't even have to worry about it.
Finally, splitting the GAM from MSLICE ensures we get more accurate
debug messages from the drm_printer in dmesg and debugfs.
Matt
>
> Thanks,
> Prathap
> >
> >
> > Matt
> >
> > >
> > > Regards,
> > >
> > > Tvrtko
> > >
> > > >
> > > > Bspec: 66534
> > > > Signed-off-by: Matt Roper
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 +++--
> > > > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> > > > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > > > 4 files changed, 34 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > index e79405a45312..a2047a68ea7a 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > > > "L3BANK",
> > > > "MSLICE",
> > > > "LNCF",
> > > > + "GAM",
> > > > "INSTANCE 0",
> > > > };
> > > > @@ -48,14 +49,23 @@ static const struct intel_mmio_range
> > > > icl_l3bank_steering_table[] = {
> > > > {},
> > > > };
> > > > +/*
> > > > + * Although the bspec lists more "MSLICE" ranges than shown here, some
> > > > of those
> > > > + * are of a "GAM" subclass that has special rules. Thus we use a
> > > > separate
> > > > + * GAM table farther down for those.
> > > > + */
> > > > static const struct intel_mmio_range xehpsdv_mslice_steering_table[]
> > > > = {
> > > > - { 0x004000, 0x004AFF },
> > > > - { 0x00C800, 0x00CFFF },
> > > > { 0x00DD00, 0x00DDFF },
> > > > { 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
> > > > {},
> > > > };
> > > > +static const struct intel_mmio_range xehpsdv_gam_steering_table[] = {
> > > >
Re: [PATCH v3 1/8] memory: tegra: Add API for retrieving carveout bounds
On 9/21/22 21:37, Krzysztof Kozlowski wrote: On 20/09/2022 10:11, Mikko Perttunen wrote: From: Mikko Perttunen On Tegra234 NVDEC firmware is loaded from a secure carveout, where it has been loaded by a bootloader. When booting NVDEC, we need to tell it the address of this firmware, which we can determine by checking the starting address of the carveout. As such, add an MC API to query the bounds of carveouts, and add related information on Tegra234. Signed-off-by: Mikko Perttunen Acked-by: Krzysztof Kozlowski Best regards, Krzysztof Thanks! Mikko
Re: [PATCH v3 1/8] memory: tegra: Add API for retrieving carveout bounds
On 20/09/2022 10:11, Mikko Perttunen wrote: > From: Mikko Perttunen > > On Tegra234 NVDEC firmware is loaded from a secure carveout, where it > has been loaded by a bootloader. When booting NVDEC, we need to tell it > the address of this firmware, which we can determine by checking the > starting address of the carveout. As such, add an MC API to query the > bounds of carveouts, and add related information on Tegra234. > > Signed-off-by: Mikko Perttunen Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH v4] drm/sched: Add FIFO sched policy to run queue v3
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).
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
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)
+ drm_sched_rq_update_fifo(entity, ts);
+
drm_sched_wakeup(entity->rq->sched);
}
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 4f2395d1a791..565707a1c5c7 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -62,6 +62,64 @@
#define to_drm_sched_job(sched_job)\
container_of((sched_job),
Re: [Intel-gfx] [RFC v4 08/14] drm/i915/vm_bind: Abstract out common execbuf functions
On Wed, Sep 21, 2022 at 11:18:53AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between these two paths by abstracting out the
common functionalities into a separate file where possible.
Looks like a good start to me. A couple comments/questions below.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 507 ++---
.../drm/i915/gem/i915_gem_execbuffer_common.c | 530 ++
.../drm/i915/gem/i915_gem_execbuffer_common.h | 47 ++
4 files changed, 612 insertions(+), 473 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bf939ef18ea..bf952f478555 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_create.o \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
+ gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 33d989a20227..363b2a788cdf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -9,8 +9,6 @@
#include
#include
-#include
-
#include "display/intel_frontbuffer.h"
#include "gem/i915_gem_ioctls.h"
@@ -28,6 +26,7 @@
#include "i915_file_private.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
#include "i915_gem_evict.h"
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
@@ -235,13 +234,6 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
-struct eb_fence {
- struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
- struct dma_fence *dma_fence;
- u64 value;
- struct dma_fence_chain *chain_fence;
-};
-
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -2446,164 +2438,29 @@ static const enum intel_engine_id user_ring_map[] = {
[I915_EXEC_VEBOX] = VECS0
};
-static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct
intel_context *ce)
-{
- struct intel_ring *ring = ce->ring;
- struct intel_timeline *tl = ce->timeline;
- struct i915_request *rq;
-
- /*
-* Completely unscientific finger-in-the-air estimates for suitable
-* maximum user request size (to avoid blocking) and then backoff.
-*/
- if (intel_ring_update_space(ring) >= PAGE_SIZE)
- return NULL;
-
- /*
-* Find a request that after waiting upon, there will be at least half
-* the ring available. The hysteresis allows us to compete for the
-* shared ring and should mean that we sleep less often prior to
-* claiming our resources, but not so long that the ring completely
-* drains before we can submit our next request.
-*/
- list_for_each_entry(rq, >requests, link) {
- if (rq->ring != ring)
- continue;
-
- if (__intel_ring_space(rq->postfix,
- ring->emit, ring->size) > ring->size / 2)
- break;
- }
- if (>link == >requests)
- return NULL; /* weird, we will check again later for real */
-
- return i915_request_get(rq);
-}
-
-static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context
*ce,
- bool throttle)
-{
- struct intel_timeline *tl;
- struct i915_request *rq = NULL;
-
- /*
-* Take a local wakeref for preparing to dispatch the execbuf as
-* we expect to access the hardware fairly frequently in the
-* process, and require the engine to be kept awake between accesses.
-* Upon dispatch, we acquire another prolonged wakeref that we hold
-* until the timeline is idle, which in turn releases the wakeref
-* taken on the engine, and the parent device.
-*/
- tl = intel_context_timeline_lock(ce);
- if (IS_ERR(tl))
- return PTR_ERR(tl);
-
- intel_context_enter(ce);
- if (throttle)
- rq = eb_throttle(eb, ce);
- intel_context_timeline_unlock(tl);
-
- if (rq) {
- bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
- long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
-
- if (i915_request_wait(rq,
Re: [Intel-gfx] [RFC v4 03/14] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
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.
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: [Intel-gfx] [RFC v4 02/14] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()
On Wed, Sep 21, 2022 at 10:06:48AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_sw_fence.c | 25 ++---
drivers/gpu/drm/i915/i915_sw_fence.h | 7 ++-
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 6fc0d1b89690..0ce8f4efc1ed 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -569,12 +569,11 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
return ret;
}
-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)
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp)
{
struct dma_resv_iter cursor;
struct dma_fence *f;
@@ -583,7 +582,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
*fence,
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
- dma_resv_iter_begin(, resv, dma_resv_usage_rw(write));
+ dma_resv_iter_begin(, resv, usage);
dma_resv_for_each_fence_unlocked(, f) {
pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
gfp);
@@ -598,6 +597,18 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
*fence,
return ret;
}
+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)
+{
+ return __i915_sw_fence_await_reservation(fence, resv,
+dma_resv_usage_rw(write),
+timeout, gfp);
+}
Drive by observation - it looked dodgy that you create a wrapper here
which ignores one function parameter.
On a more detailed look it seems no callers actually use exclude and
it's even unused inside this function since 1b5bdf071e62 ("drm/i915:
use the new iterator in i915_sw_fence_await_reservation v3").
So a cleanup patch before this one?
Thanks Tvrtko.
Yah, I noticed it, but did not want to fix that here.
Sure, will post a patch beforehand to fix that.
Niranjana
Regards,
Tvrtko
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/lib_sw_fence.c"
#include "selftests/i915_sw_fence.c"
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h
b/drivers/gpu/drm/i915/i915_sw_fence.h
index 619fc5a22f0c..3cf4b6e16f35 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -10,13 +10,13 @@
#define _I915_SW_FENCE_H_
#include
+#include
#include
#include
#include /* for NOTIFY_DONE */
#include
struct completion;
-struct dma_resv;
struct i915_sw_fence;
enum i915_sw_fence_notify {
@@ -89,6 +89,11 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
unsigned long timeout,
gfp_t gfp);
+int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
+ struct dma_resv *resv,
+ enum dma_resv_usage usage,
+ unsigned long timeout,
+ gfp_t gfp);
int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
const struct dma_fence_ops *exclude,
[PATCH] drm/vmwgfx: Protect pin_user_pages with mmap_lock
This patch includes changes below:
1) pin_user_pages() is unsafe without protection of mmap_lock,
fix it by calling mmap_read_lock() & mmap_read_unlock().
2) fix & refactor the incorrect exception handling procedure in
vmw_mksstat_add_ioctl().
based-on branch: vmwgfx/drm-misc-fixes
based commit: d8a79c03054911c375a2252627a429c9bc4615b6
Signed-off-by: Dawei Li
---
drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 2aceac7856e2..ec40a3364e0a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -1020,9 +1020,9 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void
*data,
const size_t num_pages_info = PFN_UP(arg->info_len);
const size_t num_pages_strs = PFN_UP(arg->strs_len);
long desc_len;
- long nr_pinned_stat;
- long nr_pinned_info;
- long nr_pinned_strs;
+ long nr_pinned_stat = 0;
+ long nr_pinned_info = 0;
+ long nr_pinned_strs = 0;
struct page *pages_stat[ARRAY_SIZE(pdesc->statPPNs)];
struct page *pages_info[ARRAY_SIZE(pdesc->infoPPNs)];
struct page *pages_strs[ARRAY_SIZE(pdesc->strsPPNs)];
@@ -1076,6 +1076,7 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void
*data,
if (desc_len < 0) {
atomic_set(_priv->mksstat_user_pids[slot], 0);
+ __free_page(page);
return -EFAULT;
}
@@ -1083,28 +1084,33 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void
*data,
reset_ppn_array(pdesc->infoPPNs, ARRAY_SIZE(pdesc->infoPPNs));
reset_ppn_array(pdesc->strsPPNs, ARRAY_SIZE(pdesc->strsPPNs));
+ /* pin_user_pages() needs protection of mmap_lock */
+ mmap_read_lock(current->mm);
+
/* Pin mksGuestStat user pages and store those in the instance
descriptor */
nr_pinned_stat = pin_user_pages(arg->stat, num_pages_stat,
FOLL_LONGTERM, pages_stat, NULL);
if (num_pages_stat != nr_pinned_stat)
- goto err_pin_stat;
+ goto __err_pin_pages;
for (i = 0; i < num_pages_stat; ++i)
pdesc->statPPNs[i] = page_to_pfn(pages_stat[i]);
nr_pinned_info = pin_user_pages(arg->info, num_pages_info,
FOLL_LONGTERM, pages_info, NULL);
if (num_pages_info != nr_pinned_info)
- goto err_pin_info;
+ goto __err_pin_pages;
for (i = 0; i < num_pages_info; ++i)
pdesc->infoPPNs[i] = page_to_pfn(pages_info[i]);
nr_pinned_strs = pin_user_pages(arg->strs, num_pages_strs,
FOLL_LONGTERM, pages_strs, NULL);
if (num_pages_strs != nr_pinned_strs)
- goto err_pin_strs;
+ goto __err_pin_pages;
for (i = 0; i < num_pages_strs; ++i)
pdesc->strsPPNs[i] = page_to_pfn(pages_strs[i]);
+ mmap_read_unlock(current->mm);
+
/* Send the descriptor to the host via a hypervisor call. The
mksGuestStat
pages will remain in use until the user requests a matching remove
stats
or a stats reset occurs. */
@@ -1119,15 +1125,15 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void
*data,
return 0;
-err_pin_strs:
+__err_pin_pages:
+ mmap_read_unlock(current->mm);
+
if (nr_pinned_strs > 0)
unpin_user_pages(pages_strs, nr_pinned_strs);
-err_pin_info:
if (nr_pinned_info > 0)
unpin_user_pages(pages_info, nr_pinned_info);
-err_pin_stat:
if (nr_pinned_stat > 0)
unpin_user_pages(pages_stat, nr_pinned_stat);
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915: Split GAM and MSLICE steering
On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> >
> > On 16/09/2022 02:43, Matt Roper wrote:
> > > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > > that a subset of these are of a "GAM" subclass that has unique rules and
> > > doesn't followed regular mslice steering behavior.
> > >
> > > * Xe_HP SDV: GAM ranges must always be steered to 0,0. These
> > > registers share the regular steering control register (0xFDC) with
> > > other steering types
> > >
> > > * DG2: GAM ranges must always be steered to 1,0. GAM registers have a
> > > dedicated steering control register (0xFE0) so we can set the value
> > > once at startup and rely on implicit steering. Technically the
> > > hardware default should already be set to 1,0 properly, but it never
> > > hurts to ensure that in the driver.
> >
> > Do you have any data on whether the "technically should" holds in practice?
> > What would be the consequences of some platform/machine surprising us here?
>
> The bspec indicates the hardware default value is already the necessary
> 1,0 value; I'm mostly paranoid about some kind of boot firmware wiping
> it to 0,0 by accident. I don't have any evidence that has ever actually
> happened, but explicitly re-programming it to 1,0 in the patch here is a
> defensive measure just to be safe.
>
> If we didn't have this patch _and_ some firmware screwed up the GAM
> steering target, then presumably we might read back garbage or 0 from
> GAM registers in places where we should have received a real value.
Will firmware ever touch the steering target registers. As i was going
through the respective hsd. The software driver impact is marked as none
so wondering if this change is really required ?
Thanks,
Prathap
>
>
> Matt
>
> >
> > Regards,
> >
> > Tvrtko
> >
> > >
> > > Bspec: 66534
> > > Signed-off-by: Matt Roper
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 +++--
> > > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> > > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +
> > > 4 files changed, 34 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > index e79405a45312..a2047a68ea7a 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > > @@ -40,6 +40,7 @@ static const char * const intel_steering_types[] = {
> > > "L3BANK",
> > > "MSLICE",
> > > "LNCF",
> > > + "GAM",
> > > "INSTANCE 0",
> > > };
> > > @@ -48,14 +49,23 @@ static const struct intel_mmio_range
> > > icl_l3bank_steering_table[] = {
> > > {},
> > > };
> > > +/*
> > > + * Although the bspec lists more "MSLICE" ranges than shown here, some
> > > of those
> > > + * are of a "GAM" subclass that has special rules. Thus we use a
> > > separate
> > > + * GAM table farther down for those.
> > > + */
> > > static const struct intel_mmio_range xehpsdv_mslice_steering_table[] = {
> > > - { 0x004000, 0x004AFF },
> > > - { 0x00C800, 0x00CFFF },
> > > { 0x00DD00, 0x00DDFF },
> > > { 0x00E900, 0x00 }, /* 0xEA00 - OxEFFF is unused */
> > > {},
> > > };
> > > +static const struct intel_mmio_range xehpsdv_gam_steering_table[] = {
> > > + { 0x004000, 0x004AFF },
> > > + { 0x00C800, 0x00CFFF },
> > > + {},
> > > +};
> > > +
> > > static const struct intel_mmio_range xehpsdv_lncf_steering_table[] = {
> > > { 0x00B000, 0x00B0FF },
> > > { 0x00D800, 0x00D8FF },
> > > @@ -114,9 +124,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > > } else if (IS_DG2(i915)) {
> > > gt->steering_table[MSLICE] =
> > > xehpsdv_mslice_steering_table;
> > > gt->steering_table[LNCF] = dg2_lncf_steering_table;
> > > + /*
> > > + * No need to hook up the GAM table since it has a dedicated
> > > + * steering control register on DG2 and can use implicit
> > > + * steering.
> > > + */
> > > } else if (IS_XEHPSDV(i915)) {
> > > gt->steering_table[MSLICE] =
> > > xehpsdv_mslice_steering_table;
> > > gt->steering_table[LNCF] = xehpsdv_lncf_steering_table;
> > > + gt->steering_table[GAM] = xehpsdv_gam_steering_table;
> > > } else if (GRAPHICS_VER(i915) >= 11 &&
> > > GRAPHICS_VER_FULL(i915) < IP_VER(12, 50)) {
> > > gt->steering_table[L3BANK] = icl_l3bank_steering_table;
> > > @@ -351,6 +367,10 @@ static void get_nonterminated_steering(struct
> > > intel_gt *gt,
> > > *group = __ffs(gt->info.mslice_mask) << 1;
> > > *instance = 0; /* unused */
> > >
Re: [PATCH v2 10/10] drm/ofdrm: Support color management
Hi Thomas,
On Wed, Sep 21, 2022 at 2:55 PM Thomas Zimmermann wrote:
> Am 05.08.22 um 02:19 schrieb Benjamin Herrenschmidt:
> > On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
> >> +#if !defined(CONFIG_PPC)
> >> +static inline void out_8(void __iomem *addr, int val)
> >> +{ }
> >> +static inline void out_le32(void __iomem *addr, int val)
> >> +{ }
> >> +static inline unsigned int in_le32(const void __iomem *addr)
> >> +{
> >> + return 0;
> >> +}
> >> +#endif
> >
> > These guys could just be replaced with readb/writel/readl respectively
> > (beware of the argument swap).
>
> I only added them for COMPILE_TEST. There appears to be no portable
> interface that implements out_le32() and in_le32()?
iowrite32() and ioread32()?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 1/6] dt-bindings: arm: mediatek: mmsys: change compatible for MT8195
On Wed, 2022-09-21 at 08:28 +0200, Krzysztof Kozlowski wrote:
> On 21/09/2022 06:16, Jason-JH Lin wrote:
> > Hi Krzysztof,
> >
> > Thanks for the reviews.
> >
> > On Tue, 2022-09-20 at 17:25 +0200, Krzysztof Kozlowski wrote:
> > > On 20/09/2022 16:01, Jason-JH.Lin wrote:
> > > > For previous MediaTek SoCs, such as MT8173, there are 2 display
> > > > HW
> > > > pipelines binding to 1 mmsys with the same power domain, the
> > > > same
> > > > clock driver and the same mediatek-drm driver.
> > > >
> > > > For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines
> > > > binding
> > > > to
> > > > 2 different power domains, different clock drivers and
> > > > different
> > > > mediatek-drm drivers.
> > > >
> > > > Moreover, Hardware pipeline of VDOSYS0 has these components:
> > > > COLOR,
> > > > CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
> > > > Quality)
> > > > and they makes VDOSYS0 supports PQ function while they are not
> > > > including in VDOSYS1.
> > > >
> > > > Hardware pipeline of VDOSYS1 has the component ETHDR (HDR
> > > > related
> > > > component). It makes VDOSYS1 supports the HDR function while
> > > > it's
> > > > not
> > > > including in VDOSYS0.
> > > >
> > > > To summarize0:
> > > > Only VDOSYS0 can support PQ adjustment.
> > > > Only VDOSYS1 can support HDR adjustment.
> > > >
> > > > Therefore, we need to separate these two different mmsys
> > > > hardwares
> > > > to
> > > > 2 different compatibles for MT8195.
> > > >
> > > > Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add
> > > > mt8195
> > > > SoC binding")
> > > > Signed-off-by: Jason-JH.Lin
> > > > Signed-off-by: Bo-Chen Chen
> > > > ---
> > > > .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> > > > | 4
> > > >
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > index 6ad023eec193..df9184b6772c 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > +++
> > > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
> > > > .yam
> > > > l
> > > > @@ -38,6 +38,10 @@ properties:
> > > >- const: mediatek,mt7623-mmsys
> > > >- const: mediatek,mt2701-mmsys
> > > >- const: syscon
> > > > + - items:
> > > > + - const: mediatek,mt8195-vdosys0
> > > > + - const: mediatek,mt8195-mmsys
> > > > + - const: syscon
> > >
> > > and why mediatek,mt8195-mmsys is kept as non-deprecated?
> >
> > Shouldn't we keep this for fallback compatible?
>
> I am not talking about it.
>
> >
> > I think this items could support the device node like:
> > foo {
> > compatible = "mediatek,mt8195-vdosys0", "mediatek,mt8195-mmsys",
> >"syscon";
> > }
> >
>
> Yes, this one ok.
>
> >
> > Or should I change the items like this?
> > - items:
> > - const: mediatek,mt8195-vdosys0
> > - enum:
> > - mediatek,mt8195-mmsys
> > - const: syscon
> >
>
> No, this does not look correct.
OK, I'll keep this one:
- items:
- const: mediatek,mt8195-vdosys0
- const: mediatek,mt8195-mmsys
- const: syscon
Thanks for the reviews.
>
> I asked why do you keep old mediatek,mt8195-mmsys compatible in the
> same
> place (the alone one), without making it deprecated?
- items:
- enum:
- mediatek,mt2701-mmsys
- mediatek,mt2712-mmsys
- mediatek,mt6765-mmsys
- mediatek,mt6779-mmsys
- mediatek,mt6797-mmsys
- mediatek,mt8167-mmsys
- mediatek,mt8173-mmsys
- mediatek,mt8183-mmsys
- mediatek,mt8186-mmsys
- mediatek,mt8192-mmsys
- mediatek,mt8195-mmsys
Do you mean this one can be deprecated?
I'm not sure if I should keep this after adding the new item.
If so, I can remove this at the next version.
- mediatek,mt8365-mmsys
- const: syscon
Regards,
Jason-JH.Lin
>
> Best regards,
> Krzysztof
--
Jason-JH Lin
Re: [PATCH V2 2/3] dt-bindings: display: panel: Add NewVision NV3051D bindings
On Wed, Sep 21, 2022 at 05:57:55PM +0200, Krzysztof Kozlowski wrote: > On 21/09/2022 17:50, Chris Morgan wrote: > > On Wed, Sep 21, 2022 at 05:21:19PM +0200, Krzysztof Kozlowski wrote: > >> On 21/09/2022 16:38, Chris Morgan wrote: > > + compatible: > > +items: > > + - enum: > > + - anbernic,rg353p-panel > > Are these vendor prefixs documented? > >>> > >>> Yes, they are in another patch series referenced in the cover letter. > >>> They were added for the Anbernic devicetrees and should (I believe) > >>> land in 6.1. > >> > >> OK... you still need to test your bindings. Your patch was clearly not > >> tested before sending. :( > > > > I did: yamllint, make dt_binding_check (with DT_SCHEMA_FILES specified), and > > make dtbs_check (with DT_SCHEMA_FILES specified again). > > I have doubts. So if you say you did it, then you probably did not look > at the results... or whatever other reason the test was not effective, > because your binding cannot pass the dt_binding_check. > > > That's the proper > > testing flow correct? In this case it's the pre-requisite that's causing > > the issue as I see on a pristine master tree I'm warned about the missing > > vendor prefix for anbernic. Should I wait for that to go upstream before > > I submit this again? > > Not really. The testing fails on wrong compatible in example. My mistake, I see what I did wrong and apologize for the trouble. I misinterpreted the error I did get (I expected an issue with a missing vendor string, but as you correctly point out the received error is not for that). I'll correct and resend. Would you be so kind as to confirm if you're okay with the "anbernic,rg353-panel", "newvision,nv3051d" strings? Thank you once again and I apologize for my mistake. > > Best regards, > Krzysztof >
Re: [PATCH v3 15/15] vfio: Add struct device to vfio_device
On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote: > > From: Alex Williamson > > Sent: Wednesday, September 21, 2022 4:27 AM > > > > On Fri, 9 Sep 2022 18:22:47 +0800 > > Kevin Tian wrote: > > > > > From: Yi Liu > > > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > > sysfs path of the parent, indicating the device is bound to a vfio > > > driver, e.g.: > > > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > > > It is also a preparatory step toward adding cdev for supporting future > > > device-oriented uAPI. > > > > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > > > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > > > /proc/devices. > > > > What's the risk/reward here, is this just more aesthetically pleasing > > symmetry vs 'vfio-dev'? The char major number to name association in > > /proc/devices seems pretty obscure, but what due diligence have we done > > to make sure this doesn't break anyone? Thanks, > > I'm not sure whether the content of /proc/devices is considered as ABI. > > @Jason? Ah, I've forgotten why we got here - didn't we have a naming conflict with the new stuff that is being introduced? ABI wise it is not a problem unless there is a real user, I'm not aware of anything scanning /proc, that has been obsoleted by sysfs a long time ago. Jason
Re: [PATCH V2 2/3] dt-bindings: display: panel: Add NewVision NV3051D bindings
On 21/09/2022 17:50, Chris Morgan wrote: > On Wed, Sep 21, 2022 at 05:21:19PM +0200, Krzysztof Kozlowski wrote: >> On 21/09/2022 16:38, Chris Morgan wrote: > + compatible: > +items: > + - enum: > + - anbernic,rg353p-panel Are these vendor prefixs documented? >>> >>> Yes, they are in another patch series referenced in the cover letter. >>> They were added for the Anbernic devicetrees and should (I believe) >>> land in 6.1. >> >> OK... you still need to test your bindings. Your patch was clearly not >> tested before sending. :( > > I did: yamllint, make dt_binding_check (with DT_SCHEMA_FILES specified), and > make dtbs_check (with DT_SCHEMA_FILES specified again). I have doubts. So if you say you did it, then you probably did not look at the results... or whatever other reason the test was not effective, because your binding cannot pass the dt_binding_check. > That's the proper > testing flow correct? In this case it's the pre-requisite that's causing > the issue as I see on a pristine master tree I'm warned about the missing > vendor prefix for anbernic. Should I wait for that to go upstream before > I submit this again? Not really. The testing fails on wrong compatible in example. Best regards, Krzysztof
[PATCH AUTOSEL 5.4 5/5] drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode *mode);
The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.
The return type of cdn_dp_connector_mode_valid should be changed from
int to enum drm_mode_status.
Reported-by: Dan Carpenter
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: l...@lists.linux.dev
Signed-off-by: Nathan Huckleberry
Reviewed-by: Nathan Chancellor
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/2022091320.155149-1-nh...@google.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 8f299d76b69b..67dae1354aa6 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -275,8 +275,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector
*connector)
return ret;
}
-static int cdn_dp_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+cdn_dp_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
struct cdn_dp_device *dp = connector_to_dp(connector);
struct drm_display_info *display_info = >connector.display_info;
--
2.35.1
[PATCH AUTOSEL 4.19 3/3] drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode *mode);
The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.
The return type of cdn_dp_connector_mode_valid should be changed from
int to enum drm_mode_status.
Reported-by: Dan Carpenter
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: l...@lists.linux.dev
Signed-off-by: Nathan Huckleberry
Reviewed-by: Nathan Chancellor
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/2022091320.155149-1-nh...@google.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 3feab563e50a..3f992e5a75c9 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -284,8 +284,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector
*connector)
return ret;
}
-static int cdn_dp_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+cdn_dp_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
struct cdn_dp_device *dp = connector_to_dp(connector);
struct drm_display_info *display_info = >connector.display_info;
--
2.35.1
[PATCH AUTOSEL 4.19 2/3] drm/amd/display: Limit user regamma to a valid value
From: Yao Wang1 [ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ] [Why] For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value. [How] Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths. Tested-by: Daniel Wheeler Reviewed-by: Krunoslav Kovac Reviewed-by: Aric Cyr Acked-by: Pavle Kotarac Signed-off-by: Yao Wang1 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index 11ea1a0e629b..4e866317ec25 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1206,6 +1206,7 @@ static void interpolate_user_regamma(uint32_t hw_points_num, struct fixed31_32 lut2; struct fixed31_32 delta_lut; struct fixed31_32 delta_index; + const struct fixed31_32 one = dc_fixpt_from_int(1); i = 0; /* fixed_pt library has problems handling too small values */ @@ -1234,6 +1235,9 @@ static void interpolate_user_regamma(uint32_t hw_points_num, } else hw_x = coordinates_x[i].x; + if (dc_fixpt_le(one, hw_x)) + hw_x = one; + norm_x = dc_fixpt_mul(norm_factor, hw_x); index = dc_fixpt_floor(norm_x); if (index < 0 || index > 255) -- 2.35.1
[PATCH AUTOSEL 5.15 09/10] drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage
From: Nathan Chancellor
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ]
This function consumes a lot of stack space and it blows up the size of
dml30_ModeSupportAndSystemConfigurationFull() with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6:
error: stack frame size (2200) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Commit a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
aimed to address this for i386 but it did not help x86_64.
To reduce the amount of stack space that
dml30_ModeSupportAndSystemConfigurationFull() uses, mark
UseMinimumDCFCLK() as noinline, using the _for_stack variant for
documentation. While this will increase the total amount of stack usage
between the two functions (1632 and 1304 bytes respectively), it will
make sure both stay below the limit of 2048 bytes for these files. The
aforementioned change does help reduce UseMinimumDCFCLK()'s stack usage
so it should not be reverted in favor of this change.
Link: https://github.com/ClangBuiltLinux/linux/issues/1681
Reported-by: "Sudip Mukherjee (Codethink)"
Tested-by: Maíra Canal
Reviewed-by: Rodrigo Siqueira
Signed-off-by: Nathan Chancellor
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
index e3d9f1decdfc..518672a2450f 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
@@ -6658,8 +6658,7 @@ static double CalculateUrgentLatency(
return ret;
}
-
-static void UseMinimumDCFCLK(
+static noinline_for_stack void UseMinimumDCFCLK(
struct display_mode_lib *mode_lib,
int MaxInterDCNTileRepeaters,
int MaxPrefetchMode,
--
2.35.1
[PATCH AUTOSEL 5.10 6/7] drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage
From: Nathan Chancellor
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ]
This function consumes a lot of stack space and it blows up the size of
dml30_ModeSupportAndSystemConfigurationFull() with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6:
error: stack frame size (2200) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Commit a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
aimed to address this for i386 but it did not help x86_64.
To reduce the amount of stack space that
dml30_ModeSupportAndSystemConfigurationFull() uses, mark
UseMinimumDCFCLK() as noinline, using the _for_stack variant for
documentation. While this will increase the total amount of stack usage
between the two functions (1632 and 1304 bytes respectively), it will
make sure both stay below the limit of 2048 bytes for these files. The
aforementioned change does help reduce UseMinimumDCFCLK()'s stack usage
so it should not be reverted in favor of this change.
Link: https://github.com/ClangBuiltLinux/linux/issues/1681
Reported-by: "Sudip Mukherjee (Codethink)"
Tested-by: Maíra Canal
Reviewed-by: Rodrigo Siqueira
Signed-off-by: Nathan Chancellor
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
index 2663f1b31842..e427f4ffa080 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
@@ -6653,8 +6653,7 @@ static double CalculateUrgentLatency(
return ret;
}
-
-static void UseMinimumDCFCLK(
+static noinline_for_stack void UseMinimumDCFCLK(
struct display_mode_lib *mode_lib,
int MaxInterDCNTileRepeaters,
int MaxPrefetchMode,
--
2.35.1
[PATCH AUTOSEL 5.10 2/7] drm/gma500: Fix BUG: sleeping function called from invalid context errors
From: Hans de Goede
[ Upstream commit 63e37a79f7bd939314997e29c2f5a9f0ef184281 ]
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253,
name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<>] 0x0
[ 512.123134] hardirqs last disabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123176] softirqs last enabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123207] softirqs last disabled at (0): [<>] 0x0
[ 512.123233] Preemption disabled at:
[ 512.123241] [<>] 0x0
[ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: GW
5.19.0+ #1
[ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 512.123323] Call Trace:
[ 512.123346]
[ 512.123370] dump_stack_lvl+0x5b/0x77
[ 512.123412] __might_resched.cold+0xff/0x13a
[ 512.123458] ww_mutex_lock+0x1e/0xa0
[ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx]
[ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx]
[ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx]
[ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0
[ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.123936] drm_ioctl_kernel+0xa1/0x150
[ 512.123984] drm_ioctl+0x21f/0x420
[ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60
[ 512.124104] ? lock_release+0x1ef/0x2d0
[ 512.124161] __x64_sys_ioctl+0x8d/0xd0
[ 512.124203] do_syscall_64+0x58/0x80
[ 512.124239] ? do_syscall_64+0x67/0x80
[ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0
[ 512.124300] ? do_syscall_64+0x67/0x80
[ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80
[ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 512.124411] RIP: 0033:0x7fcc4a70740f
[ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00
00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d
00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[ 512.124470] RSP: 002b:7ffda73f5390 EFLAGS: 0246 ORIG_RAX:
0010
[ 512.124503] RAX: ffda RBX: 55cc9e474500 RCX: 7fcc4a70740f
[ 512.124524] RDX: 7ffda73f5420 RSI: c01864b0 RDI: 0009
[ 512.124544] RBP: 7ffda73f5420 R08: 55cc9c0b0cb0 R09: 0034
[ 512.124564] R10: R11: 0246 R12: c01864b0
[ 512.124584] R13: 0009 R14: 55cc9df484d0 R15: 55cc9af5d0c0
[ 512.124647]
Signed-off-by: Hans de Goede
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20220906203852.527663-2-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/gma_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 3df6d6e850f5..70148ae16f14 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -529,15 +529,18 @@ int gma_crtc_page_flip(struct drm_crtc *crtc,
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
gma_crtc->page_flip_event = event;
+ spin_unlock_irqrestore(>event_lock, flags);
/* Call this locked if we want an event at vblank interrupt. */
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
if (ret) {
- gma_crtc->page_flip_event = NULL;
- drm_crtc_vblank_put(crtc);
+ spin_lock_irqsave(>event_lock, flags);
+ if (gma_crtc->page_flip_event) {
+ gma_crtc->page_flip_event = NULL;
+ drm_crtc_vblank_put(crtc);
+ }
+ spin_unlock_irqrestore(>event_lock, flags);
}
-
- spin_unlock_irqrestore(>event_lock, flags);
} else {
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
}
--
2.35.1
[PATCH AUTOSEL 5.15 07/10] drm/amd/display: Reduce number of arguments of dml31's CalculateWatermarksAndDRAMSpeedChangeSupport()
From: Nathan Chancellor [ Upstream commit 37934d4118e22bceb80141804391975078f31734 ] Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml31_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with LLVM 16 (2216 -> 1976), helping clear up the following clang warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame size (2216) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) ^ 1 error generated. Link: https://github.com/ClangBuiltLinux/linux/issues/1681 Reported-by: "Sudip Mukherjee (Codethink)" Tested-by: Maíra Canal Reviewed-by: Rodrigo Siqueira Signed-off-by: Nathan Chancellor Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- .../dc/dml/dcn31/display_mode_vba_31.c| 248 -- 1 file changed, 52 insertions(+), 196 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c index d58925cff420..a6ce22d23b26 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c @@ -319,64 +319,28 @@ static void CalculateVupdateAndDynamicMetadataParameters( static void CalculateWatermarksAndDRAMSpeedChangeSupport( struct display_mode_lib *mode_lib, unsigned int PrefetchMode, - unsigned int NumberOfActivePlanes, - unsigned int MaxLineBufferLines, - unsigned int LineBufferSize, - unsigned int WritebackInterfaceBufferSize, double DCFCLK, double ReturnBW, - bool SynchronizedVBlank, - unsigned int dpte_group_bytes[], - unsigned int MetaChunkSize, double UrgentLatency, double ExtraLatency, - double WritebackLatency, - double WritebackChunkSize, double SOCCLK, - double DRAMClockChangeLatency, - double SRExitTime, - double SREnterPlusExitTime, - double SRExitZ8Time, - double SREnterPlusExitZ8Time, double DCFCLKDeepSleep, unsigned int DETBufferSizeY[], unsigned int DETBufferSizeC[], unsigned int SwathHeightY[], unsigned int SwathHeightC[], - unsigned int LBBitPerPixel[], double SwathWidthY[], double SwathWidthC[], - double HRatio[], - double HRatioChroma[], - unsigned int vtaps[], - unsigned int VTAPsChroma[], - double VRatio[], - double VRatioChroma[], - unsigned int HTotal[], - double PixelClock[], - unsigned int BlendingAndTiming[], unsigned int DPPPerPlane[], double BytePerPixelDETY[], double BytePerPixelDETC[], - double DSTXAfterScaler[], - double DSTYAfterScaler[], - bool WritebackEnable[], - enum source_format_class WritebackPixelFormat[], - double WritebackDestinationWidth[], - double WritebackDestinationHeight[], - double WritebackSourceHeight[], bool UnboundedRequestEnabled, int unsigned CompressedBufferSizeInkByte, enum clock_change_support *DRAMClockChangeSupport, - double *UrgentWatermark, - double *WritebackUrgentWatermark, - double *DRAMClockChangeWatermark, - double *WritebackDRAMClockChangeWatermark, double *StutterExitWatermark, double *StutterEnterPlusExitWatermark, double *Z8StutterExitWatermark, - double *Z8StutterEnterPlusExitWatermark, - double *MinActiveDRAMClockChangeLatencySupported); + double *Z8StutterEnterPlusExitWatermark); static void CalculateDCFCLKDeepSleep( struct display_mode_lib *mode_lib, @@ -3072,64 +3036,28 @@ static void DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman CalculateWatermarksAndDRAMSpeedChangeSupport( mode_lib, PrefetchMode, - v->NumberOfActivePlanes, - v->MaxLineBufferLines, - v->LineBufferSize, - v->WritebackInterfaceBufferSize, v->DCFCLK,
[PATCH AUTOSEL 5.4 4/5] drm/amd/display: Limit user regamma to a valid value
From: Yao Wang1 [ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ] [Why] For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value. [How] Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths. Tested-by: Daniel Wheeler Reviewed-by: Krunoslav Kovac Reviewed-by: Aric Cyr Acked-by: Pavle Kotarac Signed-off-by: Yao Wang1 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index e042d8ce05b4..22d105635e33 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1486,6 +1486,7 @@ static void interpolate_user_regamma(uint32_t hw_points_num, struct fixed31_32 lut2; struct fixed31_32 delta_lut; struct fixed31_32 delta_index; + const struct fixed31_32 one = dc_fixpt_from_int(1); i = 0; /* fixed_pt library has problems handling too small values */ @@ -1514,6 +1515,9 @@ static void interpolate_user_regamma(uint32_t hw_points_num, } else hw_x = coordinates_x[i].x; + if (dc_fixpt_le(one, hw_x)) + hw_x = one; + norm_x = dc_fixpt_mul(norm_factor, hw_x); index = dc_fixpt_floor(norm_x); if (index < 0 || index > 255) -- 2.35.1
[PATCH AUTOSEL 5.10 7/7] drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode *mode);
The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.
The return type of cdn_dp_connector_mode_valid should be changed from
int to enum drm_mode_status.
Reported-by: Dan Carpenter
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: l...@lists.linux.dev
Signed-off-by: Nathan Huckleberry
Reviewed-by: Nathan Chancellor
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/2022091320.155149-1-nh...@google.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index dec54c70e008..857c47c69ef1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -276,8 +276,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector
*connector)
return ret;
}
-static int cdn_dp_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+cdn_dp_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
struct cdn_dp_device *dp = connector_to_dp(connector);
struct drm_display_info *display_info = >connector.display_info;
--
2.35.1
[PATCH AUTOSEL 5.4 3/5] drm/amdgpu: use dirty framebuffer helper
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index b588e0e409e7..d8687868407d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -495,6 +496,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
--
2.35.1
[PATCH AUTOSEL 5.15 08/10] drm/amd/display: Reduce number of arguments of dml31's CalculateFlipSchedule()
From: Nathan Chancellor
[ Upstream commit 21485d3da659b66c37d99071623af83ee1c6733d ]
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml31_ModeSupportAndSystemConfigurationFull() uses by 112 bytes with
LLVM 16 (1976 -> 1864), helping clear up the following clang warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6:
error: stack frame size (2216) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/1681
Reported-by: "Sudip Mukherjee (Codethink)"
Tested-by: Maíra Canal
Reviewed-by: Rodrigo Siqueira
Signed-off-by: Nathan Chancellor
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../dc/dml/dcn31/display_mode_vba_31.c| 172 +-
1 file changed, 47 insertions(+), 125 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
index a6ce22d23b26..aa0507e01792 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
@@ -259,33 +259,13 @@ static void CalculateRowBandwidth(
static void CalculateFlipSchedule(
struct display_mode_lib *mode_lib,
+ unsigned int k,
double HostVMInefficiencyFactor,
double UrgentExtraLatency,
double UrgentLatency,
- unsigned int GPUVMMaxPageTableLevels,
- bool HostVMEnable,
- unsigned int HostVMMaxNonCachedPageTableLevels,
- bool GPUVMEnable,
- double HostVMMinPageSize,
double PDEAndMetaPTEBytesPerFrame,
double MetaRowBytes,
- double DPTEBytesPerRow,
- double BandwidthAvailableForImmediateFlip,
- unsigned int TotImmediateFlipBytes,
- enum source_format_class SourcePixelFormat,
- double LineTime,
- double VRatio,
- double VRatioChroma,
- double Tno_bw,
- bool DCCEnable,
- unsigned int dpte_row_height,
- unsigned int meta_row_height,
- unsigned int dpte_row_height_chroma,
- unsigned int meta_row_height_chroma,
- double *DestinationLinesToRequestVMInImmediateFlip,
- double *DestinationLinesToRequestRowInImmediateFlip,
- double *final_flip_bw,
- bool *ImmediateFlipSupportedForPipe);
+ double DPTEBytesPerRow);
static double CalculateWriteBackDelay(
enum source_format_class WritebackPixelFormat,
double WritebackHRatio,
@@ -2923,33 +2903,13 @@ static void
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
for (k = 0; k < v->NumberOfActivePlanes; ++k) {
CalculateFlipSchedule(
mode_lib,
+ k,
HostVMInefficiencyFactor,
v->UrgentExtraLatency,
v->UrgentLatency,
- v->GPUVMMaxPageTableLevels,
- v->HostVMEnable,
-
v->HostVMMaxNonCachedPageTableLevels,
- v->GPUVMEnable,
- v->HostVMMinPageSize,
v->PDEAndMetaPTEBytesFrame[k],
v->MetaRowByte[k],
- v->PixelPTEBytesPerRow[k],
-
v->BandwidthAvailableForImmediateFlip,
- v->TotImmediateFlipBytes,
- v->SourcePixelFormat[k],
- v->HTotal[k] / v->PixelClock[k],
- v->VRatio[k],
- v->VRatioChroma[k],
- v->Tno_bw[k],
- v->DCCEnable[k],
- v->dpte_row_height[k],
- v->meta_row_height[k],
-
[PATCH AUTOSEL 5.10 5/7] drm/amd/display: Limit user regamma to a valid value
From: Yao Wang1 [ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ] [Why] For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value. [How] Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths. Tested-by: Daniel Wheeler Reviewed-by: Krunoslav Kovac Reviewed-by: Aric Cyr Acked-by: Pavle Kotarac Signed-off-by: Yao Wang1 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index 09bc2c249e1a..3c4390d71a82 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1524,6 +1524,7 @@ static void interpolate_user_regamma(uint32_t hw_points_num, struct fixed31_32 lut2; struct fixed31_32 delta_lut; struct fixed31_32 delta_index; + const struct fixed31_32 one = dc_fixpt_from_int(1); i = 0; /* fixed_pt library has problems handling too small values */ @@ -1552,6 +1553,9 @@ static void interpolate_user_regamma(uint32_t hw_points_num, } else hw_x = coordinates_x[i].x; + if (dc_fixpt_le(one, hw_x)) + hw_x = one; + norm_x = dc_fixpt_mul(norm_factor, hw_x); index = dc_fixpt_floor(norm_x); if (index < 0 || index > 255) -- 2.35.1
[PATCH AUTOSEL 5.10 4/7] drm/amdgpu: use dirty framebuffer helper
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 7cc7af2a6822..947f50e402ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -498,6 +499,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
--
2.35.1
[PATCH AUTOSEL 5.15 04/10] drm/amd/pm: disable BACO entry/exit completely on several sienna cichlid cards
From: Guchun Chen [ Upstream commit 7c6fb61a400bf3218c6504cb2d48858f98822c9d ] To avoid hardware intermittent failures. Signed-off-by: Guchun Chen Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- .../gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c index 79976921dc46..c71d50e82168 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c @@ -358,6 +358,17 @@ static void sienna_cichlid_check_bxco_support(struct smu_context *smu) smu_baco->platform_support = (val & RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true : false; + + /* +* Disable BACO entry/exit completely on below SKUs to +* avoid hardware intermittent failures. +*/ + if (((adev->pdev->device == 0x73A1) && + (adev->pdev->revision == 0x00)) || + ((adev->pdev->device == 0x73BF) && + (adev->pdev->revision == 0xCF))) + smu_baco->platform_support = false; + } } -- 2.35.1
[PATCH AUTOSEL 5.15 10/10] drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode *mode);
The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.
The return type of cdn_dp_connector_mode_valid should be changed from
int to enum drm_mode_status.
Reported-by: Dan Carpenter
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: l...@lists.linux.dev
Signed-off-by: Nathan Huckleberry
Reviewed-by: Nathan Chancellor
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/2022091320.155149-1-nh...@google.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 13c6b857158f..6b5d0722afa6 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -277,8 +277,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector
*connector)
return ret;
}
-static int cdn_dp_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+cdn_dp_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
struct cdn_dp_device *dp = connector_to_dp(connector);
struct drm_display_info *display_info = >connector.display_info;
--
2.35.1
[PATCH AUTOSEL 5.15 02/10] drm/gma500: Fix BUG: sleeping function called from invalid context errors
From: Hans de Goede
[ Upstream commit 63e37a79f7bd939314997e29c2f5a9f0ef184281 ]
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253,
name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<>] 0x0
[ 512.123134] hardirqs last disabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123176] softirqs last enabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123207] softirqs last disabled at (0): [<>] 0x0
[ 512.123233] Preemption disabled at:
[ 512.123241] [<>] 0x0
[ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: GW
5.19.0+ #1
[ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 512.123323] Call Trace:
[ 512.123346]
[ 512.123370] dump_stack_lvl+0x5b/0x77
[ 512.123412] __might_resched.cold+0xff/0x13a
[ 512.123458] ww_mutex_lock+0x1e/0xa0
[ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx]
[ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx]
[ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx]
[ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0
[ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.123936] drm_ioctl_kernel+0xa1/0x150
[ 512.123984] drm_ioctl+0x21f/0x420
[ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60
[ 512.124104] ? lock_release+0x1ef/0x2d0
[ 512.124161] __x64_sys_ioctl+0x8d/0xd0
[ 512.124203] do_syscall_64+0x58/0x80
[ 512.124239] ? do_syscall_64+0x67/0x80
[ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0
[ 512.124300] ? do_syscall_64+0x67/0x80
[ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80
[ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 512.124411] RIP: 0033:0x7fcc4a70740f
[ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00
00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d
00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[ 512.124470] RSP: 002b:7ffda73f5390 EFLAGS: 0246 ORIG_RAX:
0010
[ 512.124503] RAX: ffda RBX: 55cc9e474500 RCX: 7fcc4a70740f
[ 512.124524] RDX: 7ffda73f5420 RSI: c01864b0 RDI: 0009
[ 512.124544] RBP: 7ffda73f5420 R08: 55cc9c0b0cb0 R09: 0034
[ 512.124564] R10: R11: 0246 R12: c01864b0
[ 512.124584] R13: 0009 R14: 55cc9df484d0 R15: 55cc9af5d0c0
[ 512.124647]
Signed-off-by: Hans de Goede
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20220906203852.527663-2-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/gma_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index b03f7b8241f2..7162f4c946af 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -529,15 +529,18 @@ int gma_crtc_page_flip(struct drm_crtc *crtc,
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
gma_crtc->page_flip_event = event;
+ spin_unlock_irqrestore(>event_lock, flags);
/* Call this locked if we want an event at vblank interrupt. */
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
if (ret) {
- gma_crtc->page_flip_event = NULL;
- drm_crtc_vblank_put(crtc);
+ spin_lock_irqsave(>event_lock, flags);
+ if (gma_crtc->page_flip_event) {
+ gma_crtc->page_flip_event = NULL;
+ drm_crtc_vblank_put(crtc);
+ }
+ spin_unlock_irqrestore(>event_lock, flags);
}
-
- spin_unlock_irqrestore(>event_lock, flags);
} else {
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
}
--
2.35.1
[PATCH AUTOSEL 5.19 11/16] drm/amd/display: Limit user regamma to a valid value
From: Yao Wang1 [ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ] [Why] For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value. [How] Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths. Tested-by: Daniel Wheeler Reviewed-by: Krunoslav Kovac Reviewed-by: Aric Cyr Acked-by: Pavle Kotarac Signed-off-by: Yao Wang1 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index 64a38f08f497..5a51be753e87 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1603,6 +1603,7 @@ static void interpolate_user_regamma(uint32_t hw_points_num, struct fixed31_32 lut2; struct fixed31_32 delta_lut; struct fixed31_32 delta_index; + const struct fixed31_32 one = dc_fixpt_from_int(1); i = 0; /* fixed_pt library has problems handling too small values */ @@ -1631,6 +1632,9 @@ static void interpolate_user_regamma(uint32_t hw_points_num, } else hw_x = coordinates_x[i].x; + if (dc_fixpt_le(one, hw_x)) + hw_x = one; + norm_x = dc_fixpt_mul(norm_factor, hw_x); index = dc_fixpt_floor(norm_x); if (index < 0 || index > 255) -- 2.35.1
[PATCH AUTOSEL 5.15 06/10] drm/amd/display: Limit user regamma to a valid value
From: Yao Wang1 [ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ] [Why] For HDR mode, we get total 512 tf_point and after switching to SDR mode we actually get 400 tf_point and the rest of points(401~512) still use dirty value from HDR mode. We should limit the rest of the points to max value. [How] Limit the value when coordinates_x.x > 1, just like what we do in translate_from_linear_space for other re-gamma build paths. Tested-by: Daniel Wheeler Reviewed-by: Krunoslav Kovac Reviewed-by: Aric Cyr Acked-by: Pavle Kotarac Signed-off-by: Yao Wang1 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index ef742d95ef05..c707c9bfed43 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1597,6 +1597,7 @@ static void interpolate_user_regamma(uint32_t hw_points_num, struct fixed31_32 lut2; struct fixed31_32 delta_lut; struct fixed31_32 delta_index; + const struct fixed31_32 one = dc_fixpt_from_int(1); i = 0; /* fixed_pt library has problems handling too small values */ @@ -1625,6 +1626,9 @@ static void interpolate_user_regamma(uint32_t hw_points_num, } else hw_x = coordinates_x[i].x; + if (dc_fixpt_le(one, hw_x)) + hw_x = one; + norm_x = dc_fixpt_mul(norm_factor, hw_x); index = dc_fixpt_floor(norm_x); if (index < 0 || index > 255) -- 2.35.1
[PATCH AUTOSEL 5.19 10/16] drm/amdgpu: Skip reset error status for psp v13_0_0
From: Candice Li
[ Upstream commit 86875d558b91cb46f43be112799c06ecce60ec1e ]
No need to reset error status since only umc ras supported on psp v13_0_0.
Signed-off-by: Candice Li
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index dac202ae864d..9193ca5d6fe7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1805,7 +1805,8 @@ static void amdgpu_ras_log_on_err_counter(struct
amdgpu_device *adev)
amdgpu_ras_query_error_status(adev, );
if (adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 2) &&
- adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 4)) {
+ adev->ip_versions[MP0_HWIP][0] != IP_VERSION(11, 0, 4) &&
+ adev->ip_versions[MP0_HWIP][0] != IP_VERSION(13, 0, 0)) {
if (amdgpu_ras_reset_error_status(adev,
info.head.block))
dev_warn(adev->dev, "Failed to reset error
counter and error status");
}
--
2.35.1
[PATCH AUTOSEL 5.19 14/16] drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage
From: Nathan Chancellor
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ]
This function consumes a lot of stack space and it blows up the size of
dml30_ModeSupportAndSystemConfigurationFull() with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6:
error: stack frame size (2200) exceeds limit (2048) in
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Commit a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
aimed to address this for i386 but it did not help x86_64.
To reduce the amount of stack space that
dml30_ModeSupportAndSystemConfigurationFull() uses, mark
UseMinimumDCFCLK() as noinline, using the _for_stack variant for
documentation. While this will increase the total amount of stack usage
between the two functions (1632 and 1304 bytes respectively), it will
make sure both stay below the limit of 2048 bytes for these files. The
aforementioned change does help reduce UseMinimumDCFCLK()'s stack usage
so it should not be reverted in favor of this change.
Link: https://github.com/ClangBuiltLinux/linux/issues/1681
Reported-by: "Sudip Mukherjee (Codethink)"
Tested-by: Maíra Canal
Reviewed-by: Rodrigo Siqueira
Signed-off-by: Nathan Chancellor
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
index f47d82da115c..42a567e71439 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
@@ -6651,8 +6651,7 @@ static double CalculateUrgentLatency(
return ret;
}
-
-static void UseMinimumDCFCLK(
+static noinline_for_stack void UseMinimumDCFCLK(
struct display_mode_lib *mode_lib,
int MaxInterDCNTileRepeaters,
int MaxPrefetchMode,
--
2.35.1
[PATCH AUTOSEL 5.19 13/16] drm/amd/display: Reduce number of arguments of dml31's CalculateFlipSchedule()
From: Nathan Chancellor
[ Upstream commit 21485d3da659b66c37d99071623af83ee1c6733d ]
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
dml31_ModeSupportAndSystemConfigurationFull() uses by 112 bytes with
LLVM 16 (1976 -> 1864), helping clear up the following clang warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6:
error: stack frame size (2216) exceeds limit (2048) in
'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
^
1 error generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/1681
Reported-by: "Sudip Mukherjee (Codethink)"
Tested-by: Maíra Canal
Reviewed-by: Rodrigo Siqueira
Signed-off-by: Nathan Chancellor
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../dc/dml/dcn31/display_mode_vba_31.c| 172 +-
1 file changed, 47 insertions(+), 125 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
index 586825d85d66..40a672236198 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c
@@ -261,33 +261,13 @@ static void CalculateRowBandwidth(
static void CalculateFlipSchedule(
struct display_mode_lib *mode_lib,
+ unsigned int k,
double HostVMInefficiencyFactor,
double UrgentExtraLatency,
double UrgentLatency,
- unsigned int GPUVMMaxPageTableLevels,
- bool HostVMEnable,
- unsigned int HostVMMaxNonCachedPageTableLevels,
- bool GPUVMEnable,
- double HostVMMinPageSize,
double PDEAndMetaPTEBytesPerFrame,
double MetaRowBytes,
- double DPTEBytesPerRow,
- double BandwidthAvailableForImmediateFlip,
- unsigned int TotImmediateFlipBytes,
- enum source_format_class SourcePixelFormat,
- double LineTime,
- double VRatio,
- double VRatioChroma,
- double Tno_bw,
- bool DCCEnable,
- unsigned int dpte_row_height,
- unsigned int meta_row_height,
- unsigned int dpte_row_height_chroma,
- unsigned int meta_row_height_chroma,
- double *DestinationLinesToRequestVMInImmediateFlip,
- double *DestinationLinesToRequestRowInImmediateFlip,
- double *final_flip_bw,
- bool *ImmediateFlipSupportedForPipe);
+ double DPTEBytesPerRow);
static double CalculateWriteBackDelay(
enum source_format_class WritebackPixelFormat,
double WritebackHRatio,
@@ -2878,33 +2858,13 @@ static void
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
for (k = 0; k < v->NumberOfActivePlanes; ++k) {
CalculateFlipSchedule(
mode_lib,
+ k,
HostVMInefficiencyFactor,
v->UrgentExtraLatency,
v->UrgentLatency,
- v->GPUVMMaxPageTableLevels,
- v->HostVMEnable,
-
v->HostVMMaxNonCachedPageTableLevels,
- v->GPUVMEnable,
- v->HostVMMinPageSize,
v->PDEAndMetaPTEBytesFrame[k],
v->MetaRowByte[k],
- v->PixelPTEBytesPerRow[k],
-
v->BandwidthAvailableForImmediateFlip,
- v->TotImmediateFlipBytes,
- v->SourcePixelFormat[k],
- v->HTotal[k] / v->PixelClock[k],
- v->VRatio[k],
- v->VRatioChroma[k],
- v->Tno_bw[k],
- v->DCCEnable[k],
- v->dpte_row_height[k],
- v->meta_row_height[k],
-
[PATCH AUTOSEL 5.19 15/16] drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode *mode);
The mismatched return type breaks forward edge kCFI since the underlying
function definition does not match the function hook definition.
The return type of cdn_dp_connector_mode_valid should be changed from
int to enum drm_mode_status.
Reported-by: Dan Carpenter
Link: https://github.com/ClangBuiltLinux/linux/issues/1703
Cc: l...@lists.linux.dev
Signed-off-by: Nathan Huckleberry
Reviewed-by: Nathan Chancellor
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/2022091320.155149-1-nh...@google.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c204e9b95c1f..518ee13b1d6f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -283,8 +283,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector
*connector)
return ret;
}
-static int cdn_dp_connector_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+cdn_dp_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
struct cdn_dp_device *dp = connector_to_dp(connector);
struct drm_display_info *display_info = >connector.display_info;
--
2.35.1
[PATCH AUTOSEL 5.19 09/16] drm/amdgpu: add HDP remap functionality to nbio 7.7
From: Alex Deucher
[ Upstream commit 8c5708d3da37b8c7c3c22c7e945b9a76a7c9539b ]
Was missing before and would have resulted in a write to
a non-existant register. Normally APUs don't use HDP, but
other asics could use this code and APUs do use the HDP
when used in passthrough.
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c
b/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c
index cdc0c9779848..6c1fd471a4c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_7.c
@@ -28,6 +28,14 @@
#include "nbio/nbio_7_7_0_sh_mask.h"
#include
+static void nbio_v7_7_remap_hdp_registers(struct amdgpu_device *adev)
+{
+ WREG32_SOC15(NBIO, 0, regBIF_BX0_REMAP_HDP_MEM_FLUSH_CNTL,
+adev->rmmio_remap.reg_offset +
KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL);
+ WREG32_SOC15(NBIO, 0, regBIF_BX0_REMAP_HDP_REG_FLUSH_CNTL,
+adev->rmmio_remap.reg_offset +
KFD_MMIO_REMAP_HDP_REG_FLUSH_CNTL);
+}
+
static u32 nbio_v7_7_get_rev_id(struct amdgpu_device *adev)
{
u32 tmp;
@@ -237,4 +245,5 @@ const struct amdgpu_nbio_funcs nbio_v7_7_funcs = {
.ih_doorbell_range = nbio_v7_7_ih_doorbell_range,
.ih_control = nbio_v7_7_ih_control,
.init_registers = nbio_v7_7_init_registers,
+ .remap_hdp_registers = nbio_v7_7_remap_hdp_registers,
};
--
2.35.1
[PATCH AUTOSEL 5.19 12/16] drm/amd/display: Reduce number of arguments of dml31's CalculateWatermarksAndDRAMSpeedChangeSupport()
From: Nathan Chancellor [ Upstream commit 37934d4118e22bceb80141804391975078f31734 ] Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml31_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with LLVM 16 (2216 -> 1976), helping clear up the following clang warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame size (2216) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) ^ 1 error generated. Link: https://github.com/ClangBuiltLinux/linux/issues/1681 Reported-by: "Sudip Mukherjee (Codethink)" Tested-by: Maíra Canal Reviewed-by: Rodrigo Siqueira Signed-off-by: Nathan Chancellor Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- .../dc/dml/dcn31/display_mode_vba_31.c| 248 -- 1 file changed, 52 insertions(+), 196 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c index e4b9fd31223c..586825d85d66 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/display_mode_vba_31.c @@ -321,64 +321,28 @@ static void CalculateVupdateAndDynamicMetadataParameters( static void CalculateWatermarksAndDRAMSpeedChangeSupport( struct display_mode_lib *mode_lib, unsigned int PrefetchMode, - unsigned int NumberOfActivePlanes, - unsigned int MaxLineBufferLines, - unsigned int LineBufferSize, - unsigned int WritebackInterfaceBufferSize, double DCFCLK, double ReturnBW, - bool SynchronizedVBlank, - unsigned int dpte_group_bytes[], - unsigned int MetaChunkSize, double UrgentLatency, double ExtraLatency, - double WritebackLatency, - double WritebackChunkSize, double SOCCLK, - double DRAMClockChangeLatency, - double SRExitTime, - double SREnterPlusExitTime, - double SRExitZ8Time, - double SREnterPlusExitZ8Time, double DCFCLKDeepSleep, unsigned int DETBufferSizeY[], unsigned int DETBufferSizeC[], unsigned int SwathHeightY[], unsigned int SwathHeightC[], - unsigned int LBBitPerPixel[], double SwathWidthY[], double SwathWidthC[], - double HRatio[], - double HRatioChroma[], - unsigned int vtaps[], - unsigned int VTAPsChroma[], - double VRatio[], - double VRatioChroma[], - unsigned int HTotal[], - double PixelClock[], - unsigned int BlendingAndTiming[], unsigned int DPPPerPlane[], double BytePerPixelDETY[], double BytePerPixelDETC[], - double DSTXAfterScaler[], - double DSTYAfterScaler[], - bool WritebackEnable[], - enum source_format_class WritebackPixelFormat[], - double WritebackDestinationWidth[], - double WritebackDestinationHeight[], - double WritebackSourceHeight[], bool UnboundedRequestEnabled, int unsigned CompressedBufferSizeInkByte, enum clock_change_support *DRAMClockChangeSupport, - double *UrgentWatermark, - double *WritebackUrgentWatermark, - double *DRAMClockChangeWatermark, - double *WritebackDRAMClockChangeWatermark, double *StutterExitWatermark, double *StutterEnterPlusExitWatermark, double *Z8StutterExitWatermark, - double *Z8StutterEnterPlusExitWatermark, - double *MinActiveDRAMClockChangeLatencySupported); + double *Z8StutterEnterPlusExitWatermark); static void CalculateDCFCLKDeepSleep( struct display_mode_lib *mode_lib, @@ -3027,64 +2991,28 @@ static void DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman CalculateWatermarksAndDRAMSpeedChangeSupport( mode_lib, PrefetchMode, - v->NumberOfActivePlanes, - v->MaxLineBufferLines, - v->LineBufferSize, - v->WritebackInterfaceBufferSize, v->DCFCLK,
[PATCH AUTOSEL 5.15 05/10] drm/amdgpu: use dirty framebuffer helper
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 5c08047adb59..47fb722ab374 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -490,6 +491,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
--
2.35.1
[PATCH AUTOSEL 5.19 03/16] drm/gma500: Fix WARN_ON(lock->magic != lock) error
From: Hans de Goede [ Upstream commit b6f25c3b94f2aadbf5cbef954db4073614943d74 ] psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex gets destroyed by drm_gem_object_release() move the drm_gem_object_release() call in psb_gem_free_object() to after the unpin to fix the below warning: [ 79.693962] [ cut here ] [ 79.693992] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse [ 79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: GW E 6.0.0-rc3+ #490 [ 79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11 [ 79.694513] RSP: 0018:ad1dc048bbe0 EFLAGS: 00010282 [ 79.694623] RAX: 0028 RBX: RCX: [ 79.694636] RDX: 0001 RSI: aa8b0ffc RDI: [ 79.694650] RBP: ad1dc048bc80 R08: R09: ad1dc048ba90 [ 79.694662] R10: 0003 R11: aad62fe8 R12: 9ff302103138 [ 79.694675] R13: 9ff306ec8000 R14: 9ff307779078 R15: 9ff3014c0270 [ 79.694690] FS: 7ff1cccf1740() GS:9ff3bc20() knlGS: [ 79.694705] CS: 0010 DS: ES: CR0: 80050033 [ 79.694719] CR2: 559ecbcb4420 CR3: 1321 CR4: 06f0 [ 79.694734] Call Trace: [ 79.694749] [ 79.694761] ? __schedule+0x47f/0x1670 [ 79.694796] ? psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694830] ? lock_is_held_type+0xe3/0x140 [ 79.694864] ? ww_mutex_lock+0x38/0xa0 [ 79.694885] ? __cond_resched+0x1c/0x30 [ 79.694902] ww_mutex_lock+0x38/0xa0 [ 79.694925] psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694964] psb_gem_unpin+0x199/0x1a0 [gma500_gfx] [ 79.694996] drm_gem_object_release_handle+0x50/0x60 [ 79.695020] ? drm_gem_object_handle_put_unlocked+0xf0/0xf0 [ 79.695042] idr_for_each+0x4b/0xb0 [ 79.695066] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 79.695095] drm_gem_release+0x1c/0x30 [ 79.695118] drm_file_free.part.0+0x1ea/0x260 [ 79.695150] drm_release+0x6a/0x120 [ 79.695175] __fput+0x9f/0x260 [ 79.695203] task_work_run+0x59/0xa0 [ 79.695227] do_exit+0x387/0xbe0 [ 79.695250] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 79.695275] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695304] do_group_exit+0x33/0xb0 [ 79.695331] __x64_sys_exit_group+0x14/0x20 [ 79.695353] do_syscall_64+0x58/0x80 [ 79.695376] ? up_read+0x17/0x20 [ 79.695401] ? lock_is_held_type+0xe3/0x140 [ 79.695429] ? asm_exc_page_fault+0x22/0x30 [ 79.695450] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695473] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 79.695493] RIP: 0033:0x7ff1ccefe3f1 [ 79.695516] Code: Unable to access opcode bytes at RIP 0x7ff1ccefe3c7. [ 79.695607] RSP: 002b:7ffed4413378 EFLAGS: 0246 ORIG_RAX: 00e7 [ 79.695629] RAX: ffda RBX: 7ff1cd0159e0 RCX: 7ff1ccefe3f1 [ 79.695644] RDX: 003c RSI: 00e7 RDI: [ 79.695656] RBP: R08: ff80 R09: 7ff1cd020b20 [ 79.695671] R10: R11: 0246 R12: 7ff1cd0159e0 [ 79.695684] R13: R14: 7ff1cd01aee8 R15: 7ff1cd01af00 [ 79.695733] [ 79.695746] irq event stamp: 725979 [ 79.695757] hardirqs last enabled at (725979): [] finish_task_switch.isra.0+0xe4/0x3f0 [ 79.695780] hardirqs last disabled at (725978): [] __schedule+0xdd3/0x1670 [ 79.695803] softirqs last enabled at (725974): [] __irq_exit_rcu+0xed/0x160 [ 79.695825] softirqs last disabled at (725969): [] __irq_exit_rcu+0xed/0x160 [ 79.695845] ---[ end trace ]--- Signed-off-by: Hans de Goede Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20220906203852.527663-3-hdego...@redhat.com
[PATCH AUTOSEL 5.19 07/16] drm/amdgpu: use dirty framebuffer helper
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 4dfd6724b3ca..3451147beda3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -493,6 +494,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
+ .dirty = drm_atomic_helper_dirtyfb,
};
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
--
2.35.1
[PATCH AUTOSEL 5.19 06/16] drm/amd/pm: disable BACO entry/exit completely on several sienna cichlid cards
From: Guchun Chen [ Upstream commit 7c6fb61a400bf3218c6504cb2d48858f98822c9d ] To avoid hardware intermittent failures. Signed-off-by: Guchun Chen Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- .../gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c index 32bb6b1d9526..d13e455c8827 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c @@ -368,6 +368,17 @@ static void sienna_cichlid_check_bxco_support(struct smu_context *smu) smu_baco->platform_support = (val & RCC_BIF_STRAP0__STRAP_PX_CAPABLE_MASK) ? true : false; + + /* +* Disable BACO entry/exit completely on below SKUs to +* avoid hardware intermittent failures. +*/ + if (((adev->pdev->device == 0x73A1) && + (adev->pdev->revision == 0x00)) || + ((adev->pdev->device == 0x73BF) && + (adev->pdev->revision == 0xCF))) + smu_baco->platform_support = false; + } } -- 2.35.1
[PATCH AUTOSEL 5.19 08/16] drm/amdgpu: change the alignment size of TMR BO to 1M
From: Yang Wang
[ Upstream commit 36de13fdb04abef3ee03ade5129ab146de63983b ]
align TMR BO size TO tmr size is not necessary,
modify the size to 1M to avoid re-create BO fail
when serious VRAM fragmentation.
v2:
add new macro PSP_TMR_ALIGNMENT for TMR BO alignment size
Signed-off-by: Yang Wang
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 2b00f8fe15a8..7b8d4484c3c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -748,7 +748,7 @@ static int psp_tmr_init(struct psp_context *psp)
}
pptr = amdgpu_sriov_vf(psp->adev) ? _buf : NULL;
- ret = amdgpu_bo_create_kernel(psp->adev, tmr_size,
PSP_TMR_SIZE(psp->adev),
+ ret = amdgpu_bo_create_kernel(psp->adev, tmr_size, PSP_TMR_ALIGNMENT,
AMDGPU_GEM_DOMAIN_VRAM,
>tmr_bo, >tmr_mc_addr, pptr);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
index e431f4994931..cd366c7f311f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
@@ -36,6 +36,7 @@
#define PSP_CMD_BUFFER_SIZE0x1000
#define PSP_1_MEG 0x10
#define PSP_TMR_SIZE(adev) ((adev)->asic_type == CHIP_ALDEBARAN ? 0x80
: 0x40)
+#define PSP_TMR_ALIGNMENT 0x10
#define PSP_FW_NAME_LEN0x24
enum psp_shared_mem_size {
--
2.35.1
[PATCH AUTOSEL 5.19 04/16] drm/gma500: Fix (vblank) IRQs not working after suspend/resume
From: Hans de Goede
[ Upstream commit 235fdbc32d559db21e580f85035c59372704f09e ]
Fix gnome-shell (and other page-flip users) hanging after suspend/resume
because of the gma500's IRQs not working.
This fixes 2 problems with the IRQ handling:
1. gma_power_off() calls gma_irq_uninstall() which does a free_irq(), but
gma_power_on() called gma_irq_preinstall() + gma_irq_postinstall() which
do not call request_irq. Replace the pre- + post-install calls with
gma_irq_install() which does prep + request + post.
2. After fixing 1. IRQs still do not work on a Packard Bell Dot SC (Intel
Atom N2600, cedarview) netbook.
Cederview uses MSI interrupts and it seems that the BIOS re-configures
things back to normal APIC based interrupts during S3 suspend. There is
some MSI PCI-config registers save/restore code which tries to deal with
this, but on the Packard Bell Dot SC this is not sufficient to restore
MSI IRQ functionality after a suspend/resume.
Replace the PCI-config registers save/restore with pci_disable_msi() on
suspend + pci_enable_msi() on resume. Fixing e.g. gnome-shell hanging.
Signed-off-by: Hans de Goede
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20220906203852.527663-4-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_device.c | 4 +---
drivers/gpu/drm/gma500/oaktrail_device.c | 5 +
drivers/gpu/drm/gma500/power.c | 8 +---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 5 +
drivers/gpu/drm/gma500/psb_irq.c | 15 ---
drivers/gpu/drm/gma500/psb_irq.h | 2 +-
7 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c
b/drivers/gpu/drm/gma500/cdv_device.c
index dd32b484dd82..ce96234f3df2 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -581,11 +581,9 @@ static const struct psb_offset cdv_regmap[2] = {
static int cdv_chip_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
- struct pci_dev *pdev = to_pci_dev(dev->dev);
INIT_WORK(_priv->hotplug_work, cdv_hotplug_work_func);
- if (pci_enable_msi(pdev))
- dev_warn(dev->dev, "Enabling MSI failed!\n");
+ dev_priv->use_msi = true;
dev_priv->regmap = cdv_regmap;
gma_get_core_freq(dev);
psb_intel_opregion_init(dev);
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 5923a9c89312..f90e628cb482 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -501,12 +501,9 @@ static const struct psb_offset oaktrail_regmap[2] = {
static int oaktrail_chip_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = to_drm_psb_private(dev);
- struct pci_dev *pdev = to_pci_dev(dev->dev);
int ret;
- if (pci_enable_msi(pdev))
- dev_warn(dev->dev, "Enabling MSI failed!\n");
-
+ dev_priv->use_msi = true;
dev_priv->regmap = oaktrail_regmap;
ret = mid_chip_setup(dev);
diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index b91de6d36e41..66873085d450 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -139,8 +139,6 @@ static void gma_suspend_pci(struct pci_dev *pdev)
dev_priv->regs.saveBSM = bsm;
pci_read_config_dword(pdev, 0xFC, );
dev_priv->regs.saveVBT = vbt;
- pci_read_config_dword(pdev, PSB_PCIx_MSI_ADDR_LOC, _priv->msi_addr);
- pci_read_config_dword(pdev, PSB_PCIx_MSI_DATA_LOC, _priv->msi_data);
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
@@ -168,9 +166,6 @@ static bool gma_resume_pci(struct pci_dev *pdev)
pci_restore_state(pdev);
pci_write_config_dword(pdev, 0x5c, dev_priv->regs.saveBSM);
pci_write_config_dword(pdev, 0xFC, dev_priv->regs.saveVBT);
- /* restoring MSI address and data in PCIx space */
- pci_write_config_dword(pdev, PSB_PCIx_MSI_ADDR_LOC, dev_priv->msi_addr);
- pci_write_config_dword(pdev, PSB_PCIx_MSI_DATA_LOC, dev_priv->msi_data);
ret = pci_enable_device(pdev);
if (ret != 0)
@@ -223,8 +218,7 @@ int gma_power_resume(struct device *_dev)
mutex_lock(_mutex);
gma_resume_pci(pdev);
gma_resume_display(pdev);
- gma_irq_preinstall(dev);
- gma_irq_postinstall(dev);
+ gma_irq_install(dev);
mutex_unlock(_mutex);
return 0;
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 1d8744f3e702..54e756b48606 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -383,7 +383,7 @@ static int psb_driver_load(struct drm_device *dev, unsigned
long flags)
PSB_WVDC32(0x,
[PATCH AUTOSEL 5.19 02/16] drm/gma500: Fix BUG: sleeping function called from invalid context errors
From: Hans de Goede
[ Upstream commit 63e37a79f7bd939314997e29c2f5a9f0ef184281 ]
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253,
name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<>] 0x0
[ 512.123134] hardirqs last disabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123176] softirqs last enabled at (0): []
copy_process+0x9fc/0x1de0
[ 512.123207] softirqs last disabled at (0): [<>] 0x0
[ 512.123233] Preemption disabled at:
[ 512.123241] [<>] 0x0
[ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: GW
5.19.0+ #1
[ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 512.123323] Call Trace:
[ 512.123346]
[ 512.123370] dump_stack_lvl+0x5b/0x77
[ 512.123412] __might_resched.cold+0xff/0x13a
[ 512.123458] ww_mutex_lock+0x1e/0xa0
[ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx]
[ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx]
[ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx]
[ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0
[ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.123936] drm_ioctl_kernel+0xa1/0x150
[ 512.123984] drm_ioctl+0x21f/0x420
[ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10
[ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60
[ 512.124104] ? lock_release+0x1ef/0x2d0
[ 512.124161] __x64_sys_ioctl+0x8d/0xd0
[ 512.124203] do_syscall_64+0x58/0x80
[ 512.124239] ? do_syscall_64+0x67/0x80
[ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0
[ 512.124300] ? do_syscall_64+0x67/0x80
[ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80
[ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 512.124411] RIP: 0033:0x7fcc4a70740f
[ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00
00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d
00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[ 512.124470] RSP: 002b:7ffda73f5390 EFLAGS: 0246 ORIG_RAX:
0010
[ 512.124503] RAX: ffda RBX: 55cc9e474500 RCX: 7fcc4a70740f
[ 512.124524] RDX: 7ffda73f5420 RSI: c01864b0 RDI: 0009
[ 512.124544] RBP: 7ffda73f5420 R08: 55cc9c0b0cb0 R09: 0034
[ 512.124564] R10: R11: 0246 R12: c01864b0
[ 512.124584] R13: 0009 R14: 55cc9df484d0 R15: 55cc9af5d0c0
[ 512.124647]
Signed-off-by: Hans de Goede
Signed-off-by: Patrik Jakobsson
Link:
https://patchwork.freedesktop.org/patch/msgid/20220906203852.527663-2-hdego...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/gma_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 34ec3fca09ba..12287c9bb4d8 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -531,15 +531,18 @@ int gma_crtc_page_flip(struct drm_crtc *crtc,
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
gma_crtc->page_flip_event = event;
+ spin_unlock_irqrestore(>event_lock, flags);
/* Call this locked if we want an event at vblank interrupt. */
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
if (ret) {
- gma_crtc->page_flip_event = NULL;
- drm_crtc_vblank_put(crtc);
+ spin_lock_irqsave(>event_lock, flags);
+ if (gma_crtc->page_flip_event) {
+ gma_crtc->page_flip_event = NULL;
+ drm_crtc_vblank_put(crtc);
+ }
+ spin_unlock_irqrestore(>event_lock, flags);
}
-
- spin_unlock_irqrestore(>event_lock, flags);
} else {
ret = crtc_funcs->mode_set_base(crtc, crtc->x, crtc->y, old_fb);
}
--
2.35.1
Re: [PATCH V2 2/3] dt-bindings: display: panel: Add NewVision NV3051D bindings
On Wed, Sep 21, 2022 at 05:21:19PM +0200, Krzysztof Kozlowski wrote: > On 21/09/2022 16:38, Chris Morgan wrote: > >>> + compatible: > >>> +items: > >>> + - enum: > >>> + - anbernic,rg353p-panel > >> > >> Are these vendor prefixs documented? > > > > Yes, they are in another patch series referenced in the cover letter. > > They were added for the Anbernic devicetrees and should (I believe) > > land in 6.1. > > OK... you still need to test your bindings. Your patch was clearly not > tested before sending. :( I did: yamllint, make dt_binding_check (with DT_SCHEMA_FILES specified), and make dtbs_check (with DT_SCHEMA_FILES specified again). That's the proper testing flow correct? In this case it's the pre-requisite that's causing the issue as I see on a pristine master tree I'm warned about the missing vendor prefix for anbernic. Should I wait for that to go upstream before I submit this again? I'll make the other change about the space and the description of the vdd-supply when I resubmit. Are we good with the panel compatibles? I'm still not entirely sure the best thing to name them as I have no part number whatsoever except the driver IC. Thank you. > > Best regards, > Krzysztof >
Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
Hi Badal,
> > > +struct hwm_reg {
> > > +};
> > > +
> > > +struct hwm_drvdata {
> > > + struct i915_hwmon *hwmon;
> > > + struct intel_uncore *uncore;
> > > + struct device *hwmon_dev;
> > > + char name[12];
> > > +};
> > > +
> > > +struct i915_hwmon {
> > > + struct hwm_drvdata ddat;
> > > + struct mutex hwmon_lock;/* counter overflow logic and
> > > rmw */
> > > + struct hwm_reg rg;
> > > +};
> > > +
> > > +static const struct hwmon_channel_info *hwm_info[] = {
> > > + NULL
> > > +};
> > > +
> > > +static umode_t
> > > +hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
> > > +u32 attr, int channel)
> > > +{
> > > + switch (type) {
> > > + default:
> > > + return 0;
> > > + }
> > > +}
> > > +
> > > +static int
> > > +hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
> > > + int channel, long *val)
> > > +{
> > > + switch (type) {
> > > + default:
> > > + return -EOPNOTSUPP;
> > > + }
> > > +}
> > > +
> > > +static int
> > > +hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
> > > + int channel, long val)
> > > +{
> > > + switch (type) {
> > > + default:
> > > + return -EOPNOTSUPP;
> > > + }
> > > +}
> > > +
> > > +static const struct hwmon_ops hwm_ops = {
> > > + .is_visible = hwm_is_visible,
> > > + .read = hwm_read,
> > > + .write = hwm_write,
> > > +};
> > > +
> > > +static const struct hwmon_chip_info hwm_chip_info = {
> > > + .ops = _ops,
> > > + .info = hwm_info,
> > > +};
> >
> > what's the point for splitting so much? Can't you just send the
> > hwmon driver all at once? With this patch you are not actually
> > doing anything useful. In my opinion this should be squashed with
> > the next ones.
> During discussion in cover letter of rev0 series we decided to create
> separate infrastructure patch, as we wanted to keep kconfig, i915 hwmon
> structures and new file addition in separate patch. Further feature wise we
> kept adding new patches.
I don't really like this patch splitting, but it's my fault I
haven't reviewed it already in v1. Please, ignore then.
Andi
Re: [PATCH V2 2/3] dt-bindings: display: panel: Add NewVision NV3051D bindings
On 21/09/2022 16:38, Chris Morgan wrote: >>> + compatible: >>> +items: >>> + - enum: >>> + - anbernic,rg353p-panel >> >> Are these vendor prefixs documented? > > Yes, they are in another patch series referenced in the cover letter. > They were added for the Anbernic devicetrees and should (I believe) > land in 6.1. OK... you still need to test your bindings. Your patch was clearly not tested before sending. :( Best regards, Krzysztof
Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
On 21-09-2022 18:14, Andi Shyti wrote:
Hi Badal,
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+ struct i915_hwmon *hwmon;
+ struct intel_uncore *uncore;
+ struct device *hwmon_dev;
+ char name[12];
+};
+
+struct i915_hwmon {
+ struct hwm_drvdata ddat;
+ struct mutex hwmon_lock;/* counter overflow logic and
rmw */
+ struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+ NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops hwm_ops = {
+ .is_visible = hwm_is_visible,
+ .read = hwm_read,
+ .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+ .ops = _ops,
+ .info = hwm_info,
+};
what's the point for splitting so much? Can't you just send the
hwmon driver all at once? With this patch you are not actually
doing anything useful. In my opinion this should be squashed with
the next ones.
During discussion in cover letter of rev0 series we decided to create
separate infrastructure patch, as we wanted to keep kconfig, i915 hwmon
structures and new file addition in separate patch. Further feature wise
we kept adding new patches.
+static void
+hwm_get_preregistration_info(struct drm_i915_private *i915)
+{
+}
+
+void i915_hwmon_register(struct drm_i915_private *i915)
+{
+ struct device *dev = i915->drm.dev;
+ struct i915_hwmon *hwmon;
+ struct device *hwmon_dev;
+ struct hwm_drvdata *ddat;
+
+ /* hwmon is available only for dGfx */
+ if (!IS_DGFX(i915))
+ return;
+
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
why don't we use devm_kzalloc?
+ if (!hwmon)
+ return;
+
+ i915->hwmon = hwmon;
+ mutex_init(>hwmon_lock);
+ ddat = >ddat;
+
+ ddat->hwmon = hwmon;
+ ddat->uncore = >uncore;
+ snprintf(ddat->name, sizeof(ddat->name), "i915");
+
+ hwm_get_preregistration_info(i915);
+
+ /* hwmon_dev points to device hwmon */
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ _chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev)) {
+ mutex_destroy(>hwmon_lock);
there is not such a big need to destroy the mutex. Destroying
mutexes is more useful when you actually are creating/destroying
and there is some debug need. I don't think that's the case.
With the devm_kzalloc this would be just a return.
I think we can switch to devm_kzalloc.
Regards,
Badal
Andi
+ i915->hwmon = NULL;
+ kfree(hwmon);
+ return;
+ }
+
+ ddat->hwmon_dev = hwmon_dev;
+}
+
+void i915_hwmon_unregister(struct drm_i915_private *i915)
+{
+ struct i915_hwmon *hwmon;
+ struct hwm_drvdata *ddat;
+
+ hwmon = fetch_and_zero(>hwmon);
+ if (!hwmon)
+ return;
+
+ ddat = >ddat;
+ if (ddat->hwmon_dev)
+ hwmon_device_unregister(ddat->hwmon_dev);
+
+ mutex_destroy(>hwmon_lock);
+ kfree(hwmon);
+}
diff --git a/drivers/gpu/drm/i915/i915_hwmon.h
b/drivers/gpu/drm/i915/i915_hwmon.h
new file mode 100644
index ..7ca9cf2c34c9
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_HWMON_H__
+#define __I915_HWMON_H__
+
+struct drm_i915_private;
+
+#if IS_REACHABLE(CONFIG_HWMON)
+void i915_hwmon_register(struct drm_i915_private *i915);
+void i915_hwmon_unregister(struct drm_i915_private *i915);
+#else
+static inline void i915_hwmon_register(struct drm_i915_private *i915) { };
+static inline void i915_hwmon_unregister(struct drm_i915_private *i915) { };
+#endif
+
+#endif /* __I915_HWMON_H__ */
--
2.25.1
Re: [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
- Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: Updated date, kernel version in documentation
Cc: Sujaritha Sundaresan
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 94101f818a70..cc70596fff44 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_crit
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/curr1_crit
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/energy1_input
Date: September 2022
KernelVersion:6
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index a42cfad78bef..bd9ba312c474 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,16 +11,19 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
#include "gt/intel_gt_regs.h"
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - curr - milliamperes
* - energy - microjoules
*/
#define SF_VOLTAGE1000
#define SF_POWER 100
+#define SF_CURR1000
#define SF_ENERGY 100
struct hwm_reg {
@@ -160,11 +163,25 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
- HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+ HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
};
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+ return snb_pcode_read_p(>uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+ return snb_pcode_write_p(>uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
static umode_t
hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
@@ -198,13 +215,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
static umode_t
hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
{
+ struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+ u32 uval;
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+ case hwmon_power_crit:
+ return (hwm_pcode_read_i1(i915, ) ||
+ !(uval & POWER_SETUP_I1_WATTS))
Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi, On Sun, Sep 11, 2022 at 06:48:50AM +0200, Mateusz Kwiatkowski wrote: > >> Those extra vbp lines will be treated as a black bar at the top of the > >> frame, > >> and extra vfp lines will be at the bottom of the frame. > >> > >> However if someone specifies e.g. 720x604, there's nothing more you could > >> remove from vfp, so your only option is to reduce vbp compared to the > >> standard > >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will > >> not be > >> centered, the topmost lines will get cropped out, but that's the best we > >> can do > >> and if someone is requesting such resolution, they most likely want to > >> actually > >> access the VBI to e.g. emit teletext. > >> > >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then > >> increases both vfp and vbp proportionately. This puts vsync dead center in > >> the > >> VBI, which is not how it's supposed to be - and that in turn causes the > >> image > >> to be significantly shifted upwards. > >> > >> I hope this makes more sense to you now. > > > > I'm really struggling with this, so thanks for explaining this further > > (and patiently ;)) > > > > If I get this right, what you'd like to change is this part of the > > calculus (simplified a bit, and using PAL, 576i): > > > > vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 > > vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6 > > vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > > > > porches = params->num_lines - vactive - vslen; // 43 > > porches_rem = porches - vfp_min - vbp_min; // 32 > > > > vfp = vfp_min + (porches_rem / 2); // 21 > > vbp = porches - vfp; // 22 > > > > Which is indeed having sync centered. > > > > I initially changed it to: > > > > vfp = vfp_min; // 6 > > vbp = num_lines - vactive - vslen - vfp; // 38 > > > > Which is close enough for 576i, but at 480i/50Hz would end up with 134, > > so still fairly far off. > > > > I guess your suggestion would be along the line of: > > > > vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 > > vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 38 > > vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > > > > porches = params->num_lines - vactive - vslen; // 0 > > porches_rem = porches - vfp_min - vbp_min; // 0 > > > > vfp = vfp_min + (porches_rem / 2); // 5 > > vbp = porches - vfp; // 38 > > > > Which is still close enough for 576i, but for 480i would end up with: > > > > porches = params->num_lines - vactive - vslen; // 139 > > porches_rem = porches - vfp_min - vbp_min; // 96 > > > > vfp = vfp_min + (porches_rem / 2); // 53 > > vbp = porches - vfp; // 86 > > > > Right? > > Yes. And if that's supposed to mean 480i in 50 Hz "PAL" mode, that's also > "close enough" to the values I suggested above. > > If you substitute values for true 60 Hz "NTSC" 480i, you should also get > values > that are "close enough" to the official spec. > > The only thing I'd conceptually change is that the 38 lines is not really > "vbp_min". It's more like "vbp_typ". As I mentioned above, we may want to > lower > this value if someone wants more active lines than the official 486/576. porches_rem is an int, so if vactive > (num_lines + vslen + vfp_min + vbp_min), porches_rem is going to be negative and we'll remove equally between vfp and vbp to match what's been asked So I believe this should work fine? Maxime signature.asc Description: PGP signature
Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
On 21-09-2022 17:15, Gupta, Anshuman wrote:
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6:
- Fix review comments (Ashutosh)
- Update date, kernel version in documentation
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 +++
drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 6 +
4 files changed, 187 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-devel@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in
microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 45745afa5c5b..5183cf51a49b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
/*
* SF_* - scale factors for particular quantities according to hwmon
spec.
* - voltage - millivolts
+ * - power - microwatts
*/
#define SF_VOLTAGE 1000
+#define SF_POWER 100
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock; /* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(>hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the
scaling
+ * of the field taken from the 32-bit register value might cause a
result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* Computation in 64-bits to avoid overflow. Round to nearest. */
+ nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+ bits_to_clear = field_msk;
+ bits_to_set = FIELD_PREP(field_msk, nval);
+
+ hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
+ bits_to_clear, bits_to_set);
+}
+
Re: [PATCH V2 2/3] dt-bindings: display: panel: Add NewVision NV3051D bindings
On Wed, Sep 21, 2022 at 08:51:34AM +0200, Krzysztof Kozlowski wrote: > On 20/09/2022 16:59, Chris Morgan wrote: > > From: Chris Morgan > > > > Add documentation for the NewVision NV3051D panel bindings. > > Note that for the two expected consumers of this panel binding > > the underlying LCD model is unknown. Name "anbernic,rg353p-panel" > > is used because the hardware itself is known as "anbernic,rg353p". > > > > Signed-off-by: Chris Morgan > > --- > > .../display/panel/newvision,nv3051d.yaml | 55 +++ > > 1 file changed, 55 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > new file mode 100644 > > index ..d90bca4171c2 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > @@ -0,0 +1,55 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fpanel%2Fnewvision%2Cnv3051d.yaml%23data=05%7C01%7C%7C844872fdf91b413aa65a08da9b9db9e7%7C84df9e7fe9f640afb435%7C1%7C0%7C637993398994635658%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=eTM2IFjR0TKPlQNYfoq3Poao8QYLSHRVaqiXtufJ7VA%3Dreserved=0 > > +$schema: > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=05%7C01%7C%7C844872fdf91b413aa65a08da9b9db9e7%7C84df9e7fe9f640afb435%7C1%7C0%7C637993398994635658%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=sjb7x2Z2wKu1C8mMBW1epwuXipe8V26zxpHcCAuKLZY%3Dreserved=0 > > + > > +title: NewVision NV3051D based LCD panel > > + > > +description: | > > + The NewVision NV3051D is a driver chip used to drive DSI panels. For now, > > + this driver only supports the 640x480 panels found in the Anbernic RG353 > > + based devices. > > + > > +maintainers: > > + - Chris Morgan > > + > > +allOf: > > + - $ref: panel-common.yaml# > > + > > +properties: > > + compatible: > > +items: > > + - enum: > > + - anbernic,rg353p-panel > > Are these vendor prefixs documented? Yes, they are in another patch series referenced in the cover letter. They were added for the Anbernic devicetrees and should (I believe) land in 6.1. > > > + - anbernic,rg353v-panel > > + - const: newvision,nv3051d > > Blank line. > Ack. > > + reg: true > > + backlight: true > > + port: true > > + reset-gpios: true > > + vdd-supply: > > +description: regulator that supplies the vdd voltage > > Skip description and make it just "true". It's kind of obvious. > Ack. > > + > > +required: > > + - compatible > > + - reg > > + - backlight > > + - vdd-supply > > Best regards, > Krzysztof
Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi, Thanks again for your help On Sun, Sep 11, 2022 at 06:30:39AM +0200, kFYatek wrote: > W dniu 9.09.2022 o 16:00, Maxime Ripard pisze: > > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > >> The "canonical" modelines (at least for vc4's VEC, see the notes below): > >> > >> - (vfp==4, vsync==6, vbp==39) for 576i > >> - (vfp==7, vsync==6, vbp==32) for 480i > >> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally > >> specified) > > > > It's not clear to me either how you come up with those timings? > > Well, experimentally ;) > > The values for 480i and 576i are the values currently used by the downstream > kernel, and those in turn has been copied from the firmware (or more > precisely, > I chose them so that the PV registers end up the same as the values set by the > firmware). > > I also checked with an oscilloscope that the waveforms look as they should. > VEC doesn't exactly handle the half-lines at the start and end of the odd > field > right, but otherwise, the blanking and sync pulses are where they should be. > > The 486i values has been constructed from the 480i ones according to the > calculations from cross-referencing SMPTE documents, see my previous e-mail. > > I know this is perhaps unsatisfactory ;) I don't have access to the VC4 > documentation, so this was _almost_ reverse engineering for me. It's not really that it's unsatisfactory, but the function here is supposed to be generic and thus generate a mode that is supposed to be a somewhat reasonable for a given set of parameters. If the vc4 driver needs some adjustments, then it needs to be out of that function and into the vc4 driver. And this is pretty much what I struggle with: I have a hard time (on top of everything else) figuring out what is supposed to be specific to vc4, and what isn't. I guess your 480i example, since it follows the spec, is fine, but I'm not sure for 576i. Maxime signature.asc Description: PGP signature
Re: [PATCH v10 3/9] compiler_types.h: Add assert_type to catch type mis-match while compiling
On 9/13/22 3:01 PM, Kees Cook wrote:
On Fri, Sep 09, 2022 at 07:59:07PM +0900, Gwan-gyeong Mun wrote:
It adds assert_type and assert_typable macros to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added assert_type() macro uses the _Static_assert() keyword (which is
introduced in C11) to generate a build break when the types are different
and can be used to detect explicit build errors.
Unlike the assert_type() macro, assert_typable() macro allows a constant
value as the second argument.
Suggested-by: Kees Cook
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Mauro Carvalho Chehab
Cc: Andrzej Hajda
Cc: Kees Cook
---
include/linux/compiler_types.h | 39 ++
1 file changed, 39 insertions(+)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 4f2a819fd60a..19cc125918bb 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -294,6 +294,45 @@ struct ftrace_likely_data {
/* Are two types/vars the same type (ignoring qualifiers)? */
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
+/**
+ * assert_type - break compile if the first argument's data type and the second
+ * argument's data type are not the same
+ *
+ * @t1: data type or variable
+ * @t2: data type or variable
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). It determines whether the first argument's data type and the second
+ * argument's data type are the same while compiling, and it breaks compile if
+ * the two types are not the same.
+ * See also assert_typable().
+ */
+#define assert_type(t1, t2) _Static_assert(__same_type(t1, t2))
+
+/**
+ * assert_typable - break compile if the first argument's data type and the
+ * second argument's data type are not the same
+ *
+ * @t: data type or variable
+ * @n: data type or variable or constant value
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). Unlike the assert_type() macro, this macro allows a constant value
+ * as the second argument. And if the second argument is a constant value, it
+ * always passes. And it doesn't mean that the types are explicitly the same.
+ * When a constant value is used as the second argument, if you need an
+ * overflow check when assigning a constant value to a variable of the type of
+ * the first argument, you can use the overflows_type() macro. When a constant
I wonder if the overflows_type() check should happen in this test? It
seems weird that assert_typable(u8, 1024) would pass...
Yes, that's right. If a constant is used as an argument here, it seems
necessary to check whether an overflow occurs when the constant value is
assigned to the target type or target variable.
+ * value is not used as a second argument, it determines whether the first
+ * argument's data type and the second argument's data type are the same while
+ * compiling, and it breaks compile if the two types are not the same.
+ * See also assert_type() and overflows_type().
+ */
+#define assert_typable(t, n) _Static_assert(__builtin_constant_p(n) || \
+ __same_type(t, typeof(n)))
Totally untested -- I'm not sure if this gets the right semantics for
constant expressoins, etc...
static_assert(__builtin_choose_expression(__builtin_constant_p(n), \
overflows_type(n, typeof(t)), \
__same_type(t, typeof(n
However, if we change the macro in the form below, the "error:
expression in static assertion is not constant" error occurs due to the
restriction [1][2] of _Static_assert() as you mentioned.
( overflows_type() internally uses the __builtin_add_overflow() builtin
function [3], which returns a bool type.)
#define assert_same_typable(t, n) static_assert( \
__builtin_choose_expr(__builtin_constant_p(n), \
overflows_type(n, typeof(t)) == false, \
__same_type(t, typeof(n
Can I have your opinion on the new addition of
overflows_type_return_const_expr(), which returns a constant value at
compile time to check whether an overflow occurs when assigning a
constant value to an argument type?
If it is allowable to add the macro, I would try to use the macro that
returns "an integer constant expression" after checking for overflow
between the constant value and the argument type at compile time with
reference to implemented in the previous version. [4] or [5]
#define assert_same_typable(t, n)
Re: [PATCH v2 00/41] drm: Analog TV Improvements
On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote:
>
>
> Den 07.09.2022 12.36, skrev Stefan Wahren:
> > Hi Maxime,
> >
> > Am 05.09.22 um 16:57 schrieb Maxime Ripard:
> >> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
> >>>
> >>> Den 01.09.2022 21.35, skrev Noralf Trønnes:
>
> I have finally found a workaround for my kernel hangs.
>
> Dom had a look at my kernel and found that the VideoCore was fine, and
> he said this:
>
> > That suggests cause of lockup was on arm side rather than VC side.
> >
> > But it's hard to diagnose further. Once you've had a peripheral not
> > respond, the AXI bus locks up and no further operations are possible.
> > Usual causes of this are required clocks being stopped or domains
> > disabled and then trying to access the hardware.
> >
> So when I got this on my 64-bit build:
>
> [ 166.702171] SError Interrupt on CPU1, code 0xbf02 --
> SError
> [ 166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: G W
> 5.19.0-rc6-00096-gba7973977976-dirty #1
> [ 166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
> [ 166.702206] Workqueue: events_freezable_power_
> thermal_zone_device_check
> [ 166.702231] pstate: 20c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [ 166.702242] pc : regmap_mmio_read32le+0x10/0x28
> [ 166.702261] lr : regmap_mmio_read+0x44/0x70
> ...
> [ 166.702606] bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal]
>
> I wondered if that reg read was stalled due to a clock being stopped.
>
> Lo and behold, disabling runtime pm and keeping the vec clock running
> all the time fixed it[1].
>
> I don't know what the problem is, but at least I can now test this
> patchset.
>
> [1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065
>
> >>> It turns out I didn't have to disable runtime pm:
> >>> https://gist.github.com/notro/0adcfcb12460b54e54458afe11dc8ea2
> >> If the bcm2711_thermal IP needs that clock to be enabled, it should grab
> >> a reference itself, but it looks like even the device tree binding
> >> doesn't ask for one.
> > The missing clock in the device tree binding is expected, because
> > despite of the code there is not much information about the BCM2711
> > clock tree. But i'm skeptical that the AVS IP actually needs the VEC
> > clock, i think it's more likely that the VEC clock parent is changed and
> > that cause this issue. I could take care of the bcm2711 binding & driver
> > if i know which clock is really necessary.
>
> Seems you're right, keeping the parent always enabled is enough:
>
> clk_prepare_enable(clk_get_parent(vec->clock)); // pllc_per
>
> I tried enabling just the grandparent clock as well, but that didn't help.
Yeah, adding tracing to the clock framework shows that it indeed
disables PLLC_PER. So there's probably some other device that depends on
it but doesn't take a reference to it.
I had a look, but it's not really obvious what that might be.
This patch makes sure that the PLL*_PER are never disabled, could you
test it? It seems to work for me.
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 48a1eb9f2d55..3839261ee419 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1675,7 +1675,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.load_mask = CM_PLLA_LOADPER,
.hold_mask = CM_PLLA_HOLDPER,
.fixed_divider = 1,
- .flags = CLK_SET_RATE_PARENT),
+ .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),
[BCM2835_PLLA_DSI0] = REGISTER_PLL_DIV(
SOC_ALL,
.name = "plla_dsi0",
@@ -1784,7 +1784,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.load_mask = CM_PLLC_LOADPER,
.hold_mask = CM_PLLC_HOLDPER,
.fixed_divider = 1,
- .flags = CLK_SET_RATE_PARENT),
+ .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),
/*
* PLLD is the display PLL, used to drive DSI display panels.
@@ -1891,7 +1891,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.load_mask = CM_PLLH_LOADAUX,
.hold_mask = 0,
.fixed_divider = 1,
- .flags = CLK_SET_RATE_PARENT),
+ .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),
[BCM2835_PLLH_PIX] = REGISTER_PLL_DIV(
SOC_BCM2835,
.name = "pllh_pix",
Maxime
signature.asc
Description: PGP signature
Re: [PATCH v6,3/3] drm: mediatek: Add mt8186 dpi compatible to mtk_dpi.c
On Wed, 2022-09-21 at 09:42 +0800, CK Hu wrote:
> Hi, Xinlei:
>
> On Wed, 2022-09-14 at 21:21 +0800, xinlei@mediatek.com wrote:
> > From: Xinlei Lee
> >
> > Add the compatible because use edge_cfg_in_mmsys in mt8186.
> >
> > Signed-off-by: Xinlei Lee
> > ---
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 6e02f02f163c..52bcc4114afd 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -942,6 +942,24 @@ static const struct mtk_dpi_conf mt8183_conf =
> > {
> > .csc_enable_bit = CSC_ENABLE,
> > };
> >
> > +static const struct mtk_dpi_conf mt8186_conf = {
> > + .cal_factor = mt8183_calculate_factor,
> > + .reg_h_fre_con = 0xe0,
> > + .max_clock_khz = 15,
> > + .output_fmts = mt8183_output_fmts,
> > + .num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
> > + .edge_cfg_in_mmsys = true,
>
> According to the previous review, edge_cfg_in_mmsys is not necessary,
> so mt8186_conf is identical to mt8192_conf.
>
> Regards,
> CK
>
> > + .pixels_per_iter = 1,
> > + .is_ck_de_pol = true,
> > + .swap_input_support = true,
> > + .support_direct_pin = true,
> > + .dimension_mask = HPW_MASK,
> > + .hvsize_mask = HSIZE_MASK,
> > + .channel_swap_shift = CH_SWAP,
> > + .yuv422_en_bit = YUV422_EN,
> > + .csc_enable_bit = CSC_ENABLE,
> > +};
> > +
> > static const struct mtk_dpi_conf mt8192_conf = {
> > .cal_factor = mt8183_calculate_factor,
> > .reg_h_fre_con = 0xe0,
> > @@ -1092,6 +1110,9 @@ static const struct of_device_id
> > mtk_dpi_of_ids[] = {
> > { .compatible = "mediatek,mt8183-dpi",
> > .data = _conf,
> > },
> > + { .compatible = "mediatek,mt8186-dpi",
> > + .data = _conf,
> > + },
> > { .compatible = "mediatek,mt8192-dpi",
> > .data = _conf,
> > },
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 546b79412815..3d32fbc66ac1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -646,6 +646,8 @@ static const struct of_device_id
> > mtk_ddp_comp_dt_ids[] = {
> > .data = (void *)MTK_DPI },
> > { .compatible = "mediatek,mt8183-dpi",
> > .data = (void *)MTK_DPI },
> > + { .compatible = "mediatek,mt8186-dpi",
> > + .data = (void *)MTK_DPI },
> > { .compatible = "mediatek,mt8192-dpi",
> > .data = (void *)MTK_DPI },
> > { .compatible = "mediatek,mt8195-dp-intf",
>
>
Hi CK:
Thanks for your review.
Because the difference between MT8186 and other ICs is that modifying
the output format requires modifying the mmsys register to take effect.
I think this mt8186_conf needs to be reserved so that we can
distinguish it from the settings of other ICs when setting
dpi_dual_edge.
(the edge_cfg_in mmsys flag inside can prevent other ICs from setting
the mmsys register)
Best Regards!
Xinlei
Re: [PATCH v6,2/3] drm: mediatek: Adjust the dpi output format to MT8186
On Wed, 2022-09-21 at 09:35 +0800, CK Hu wrote:
> Hi, Xinlei:
>
> On Wed, 2022-09-14 at 21:21 +0800, xinlei@mediatek.com wrote:
> > From: Xinlei Lee
> >
> > Dpi output needs to adjust the output format to dual edge for
> > MT8186.
> > The bridge ic on MT8186 uses the output format of
> > RGB888_dual_edge.
>
> I think different sink ic may support different output format, so
> query
> the sink information to decide which outout format.
>
> > Due
> > to hardware changes, we need to modify the output format
> > corresponding
> > to the mmsys register.
> >
> > Co-developed-by: Jitao Shi
> > Signed-off-by: Jitao Shi
> > Signed-off-by: Xinlei Lee
> > Reviewed-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delre...@collabora.com>
> > Reviewed-by: Nís F. R. A. Prado
> > ---
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index fb0b79704636..6e02f02f163c 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include
> > @@ -28,6 +29,7 @@
> > #include "mtk_disp_drv.h"
> > #include "mtk_dpi_regs.h"
> > #include "mtk_drm_ddp_comp.h"
> > +#include "mtk_drm_drv.h"
> >
> > enum mtk_dpi_out_bit_num {
> > MTK_DPI_OUT_BIT_NUM_8BITS,
> > @@ -58,6 +60,11 @@ enum mtk_dpi_out_color_format {
> > MTK_DPI_COLOR_FORMAT_YCBCR_422
> > };
> >
> > +enum mtk_dpi_out_format_con {
> > + MTK_DPI_RGB888_DDR_CON,
> > + MTK_DPI_RGB565_SDR_CON
> > +};
> > +
> > struct mtk_dpi {
> > struct drm_encoder encoder;
> > struct drm_bridge bridge;
> > @@ -80,6 +87,7 @@ struct mtk_dpi {
> > struct pinctrl_state *pins_dpi;
> > u32 output_fmt;
> > int refcount;
> > + struct device *mmsys_dev;
> > };
> >
> > static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
> > @@ -133,6 +141,7 @@ struct mtk_dpi_yc_limit {
> > * @yuv422_en_bit: Enable bit of yuv422.
> > * @csc_enable_bit: Enable bit of CSC.
> > * @pixels_per_iter: Quantity of transferred pixels per iteration.
> > + * @edge_cfg_in_mmsys: If the edge configuration for DPI's output
> > needs to be set in MMSYS.
> > */
> > struct mtk_dpi_conf {
> > unsigned int (*cal_factor)(int clock);
> > @@ -151,6 +160,7 @@ struct mtk_dpi_conf {
> > u32 yuv422_en_bit;
> > u32 csc_enable_bit;
> > u32 pixels_per_iter;
> > + bool edge_cfg_in_mmsys;
> > };
> >
> > static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val,
> > u32 mask)
> > @@ -447,6 +457,8 @@ static void mtk_dpi_dual_edge(struct mtk_dpi
> > *dpi)
> > mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING,
> > dpi->output_fmt ==
> > MEDIA_BUS_FMT_RGB888_2X12_LE ?
> > EDGE_SEL : 0, EDGE_SEL);
> > + if (dpi->conf->edge_cfg_in_mmsys)
> > + mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev,
> > MTK_DPI_RGB888_DDR_CON);
>
> Why do you set a DPI driver defined value MTK_DPI_RGB888_DDR_CON into
> mmsys driver? I think you should set a value which mmsys driver
> understand.
>
> Regards,
> CK
>
> > } else {
> > mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
> > 0);
> > }
> > @@ -776,8 +788,10 @@ static int mtk_dpi_bind(struct device *dev,
> > struct device *master, void *data)
> > {
> > struct mtk_dpi *dpi = dev_get_drvdata(dev);
> > struct drm_device *drm_dev = data;
> > + struct mtk_drm_private *priv = drm_dev->dev_private;
> > int ret;
> >
> > + dpi->mmsys_dev = priv->mmsys_dev;
> > ret = drm_simple_encoder_init(drm_dev, >encoder,
> > DRM_MODE_ENCODER_TMDS);
> > if (ret) {
>
>
Hi CK:
Thanks for your review.
Yes, different sink ICs may support other output formats.
The current DRM architecture supports retrieving the output formats of
all bridges (implemented through .atomic_check &
.atomic_get_output_bus_fmts & .atomic_get_input_bus_fmts in dpi).
If no unified output format is found It will use the default format
output of soc (MEDIA_BUS_FMT_RGB888_2X12_LE is used in mt8186).
The difference between MT8186 and other ICs is that when modifying the
output format, we need to modify the mmsys_base + 0x400 register to
take effect.
Therefore, if there are other format sink ICs (RGB888_DDR/RGB888_SDR)
in the future, the sink IC needs to add the func implementation
mentioned above needs to be added.
And the drm architecture will select the appropriate format to change
the dpi output.
I will put the registers that control mmsys in mtk-mmsys.h in the next
release.
Best Regards!
Xinlei
Re: [PATCH v2 10/10] drm/ofdrm: Support color management
Hi
Am 05.08.22 um 02:19 schrieb Benjamin Herrenschmidt:
On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
+#if !defined(CONFIG_PPC)
+static inline void out_8(void __iomem *addr, int val)
+{ }
+static inline void out_le32(void __iomem *addr, int val)
+{ }
+static inline unsigned int in_le32(const void __iomem *addr)
+{
+ return 0;
+}
+#endif
These guys could just be replaced with readb/writel/readl respectively
(beware of the argument swap).
I only added them for COMPILE_TEST. There appears to be no portable
interface that implements out_le32() and in_le32()?
Best regards
Thomas
Cheers,
Ben.
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
Hi Badal,
> +struct hwm_reg {
> +};
> +
> +struct hwm_drvdata {
> + struct i915_hwmon *hwmon;
> + struct intel_uncore *uncore;
> + struct device *hwmon_dev;
> + char name[12];
> +};
> +
> +struct i915_hwmon {
> + struct hwm_drvdata ddat;
> + struct mutex hwmon_lock;/* counter overflow logic and
> rmw */
> + struct hwm_reg rg;
> +};
> +
> +static const struct hwmon_channel_info *hwm_info[] = {
> + NULL
> +};
> +
> +static umode_t
> +hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
> +u32 attr, int channel)
> +{
> + switch (type) {
> + default:
> + return 0;
> + }
> +}
> +
> +static int
> +hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
> + int channel, long *val)
> +{
> + switch (type) {
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static int
> +hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
> + int channel, long val)
> +{
> + switch (type) {
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static const struct hwmon_ops hwm_ops = {
> + .is_visible = hwm_is_visible,
> + .read = hwm_read,
> + .write = hwm_write,
> +};
> +
> +static const struct hwmon_chip_info hwm_chip_info = {
> + .ops = _ops,
> + .info = hwm_info,
> +};
what's the point for splitting so much? Can't you just send the
hwmon driver all at once? With this patch you are not actually
doing anything useful. In my opinion this should be squashed with
the next ones.
> +static void
> +hwm_get_preregistration_info(struct drm_i915_private *i915)
> +{
> +}
> +
> +void i915_hwmon_register(struct drm_i915_private *i915)
> +{
> + struct device *dev = i915->drm.dev;
> + struct i915_hwmon *hwmon;
> + struct device *hwmon_dev;
> + struct hwm_drvdata *ddat;
> +
> + /* hwmon is available only for dGfx */
> + if (!IS_DGFX(i915))
> + return;
> +
> + hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
why don't we use devm_kzalloc?
> + if (!hwmon)
> + return;
> +
> + i915->hwmon = hwmon;
> + mutex_init(>hwmon_lock);
> + ddat = >ddat;
> +
> + ddat->hwmon = hwmon;
> + ddat->uncore = >uncore;
> + snprintf(ddat->name, sizeof(ddat->name), "i915");
> +
> + hwm_get_preregistration_info(i915);
> +
> + /* hwmon_dev points to device hwmon */
> + hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
> + ddat,
> + _chip_info,
> + NULL);
> + if (IS_ERR(hwmon_dev)) {
> + mutex_destroy(>hwmon_lock);
there is not such a big need to destroy the mutex. Destroying
mutexes is more useful when you actually are creating/destroying
and there is some debug need. I don't think that's the case.
With the devm_kzalloc this would be just a return.
Andi
> + i915->hwmon = NULL;
> + kfree(hwmon);
> + return;
> + }
> +
> + ddat->hwmon_dev = hwmon_dev;
> +}
> +
> +void i915_hwmon_unregister(struct drm_i915_private *i915)
> +{
> + struct i915_hwmon *hwmon;
> + struct hwm_drvdata *ddat;
> +
> + hwmon = fetch_and_zero(>hwmon);
> + if (!hwmon)
> + return;
> +
> + ddat = >ddat;
> + if (ddat->hwmon_dev)
> + hwmon_device_unregister(ddat->hwmon_dev);
> +
> + mutex_destroy(>hwmon_lock);
> + kfree(hwmon);
> +}
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.h
> b/drivers/gpu/drm/i915/i915_hwmon.h
> new file mode 100644
> index ..7ca9cf2c34c9
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_hwmon.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: MIT */
> +
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#ifndef __I915_HWMON_H__
> +#define __I915_HWMON_H__
> +
> +struct drm_i915_private;
> +
> +#if IS_REACHABLE(CONFIG_HWMON)
> +void i915_hwmon_register(struct drm_i915_private *i915);
> +void i915_hwmon_unregister(struct drm_i915_private *i915);
> +#else
> +static inline void i915_hwmon_register(struct drm_i915_private *i915) { };
> +static inline void i915_hwmon_unregister(struct drm_i915_private *i915) { };
> +#endif
> +
> +#endif /* __I915_HWMON_H__ */
> --
> 2.25.1
Re: [PATCH v2 09/10] drm/ofdrm: Add per-model device function
Hi
Am 05.08.22 um 02:22 schrieb Benjamin Herrenschmidt:
On Tue, 2022-07-26 at 16:40 +0200, Michal Suchánek wrote:
Hello,
On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote:
On 7/20/22 16:27, Thomas Zimmermann wrote:
Add a per-model device-function structure in preparation of adding
color-management support. Detection of the individual models has been
taken from fbdev's offb.
Signed-off-by: Thomas Zimmermann
---
Reviewed-by: Javier Martinez Canillas
[...]
+static bool is_avivo(__be32 vendor, __be32 device)
+{
+ /* This will match most R5xx */
+ return (vendor == 0x1002) &&
+ ((device >= 0x7100 && device < 0x7800) || (device >= 0x9400));
+}
Maybe add some constant macros to not have these magic numbers ?
This is based on the existing fbdev implementation's magic numbers:
drivers/video/fbdev/offb.c: ((*did >= 0x7100 && *did < 0x7800)
||
Of course, it would be great if somebody knowledgeable could clarify
those.
I don't think anybody remembers :-) Vendor 0x1002 is PCI_VENDOR_ID_ATI,
I do :)
but the rest is basically ranges of PCI IDs for which we don't have
symbolic constants.
Should we add them to the official list in pci_ids.h? I cannot find
0x7800. The others are R520 and R600.
Best regards
Thomas
Cheers,
Ben.
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 2/2] drm/panfrost: replace endian-specific types with generic ones
> > Or of course we could just actually use native endian and detect from > > the magic which endian is in use. That would require ripping out the > > cpu_to_lexx() calls in Linux and making the user space tool more > > intelligent. I'm happy with that, but it's pushing the complexity onto Mesa. > > If there's a clearly identifiable header, then I'd say making the whole dump > native-endian is probably the way to go. Unless and until anyone actually > demands to be able to do cross-endian post-mortem GPU debugging, the > realistic extent of the complexity in Mesa is that it doesn't recognise the > foreign dump format and gives up, which I assume is already implemented :) +1 to this solution. Gets the complexity out of both kernel and Mesa, and in the vanishingly unlikely scenario that we need this functionality, we can add it to Mesa without kernel changes. As mesa panfrost maintainer I'll take those odds :+1:
RE: [PATCH] virt: acrn: obtain pa from VMA with PFNMAP flag
Hi Daniel,
Thank you for this info, we will fix this issue.
Almost miss this mail, sorry!
-Yonghua
> -Original Message-
> From: Daniel Vetter
> Sent: Wednesday, August 10, 2022 20:20
> To: Huang, Yonghua
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> sta...@vger.kernel.org; Chatre, Reinette ; Wang,
> Zhi A ; Wang, Yu1 ; Li, Fei1
> ; Linux MM ; DRI Development de...@lists.freedesktop.org>
> Subject: Re: [PATCH] virt: acrn: obtain pa from VMA with PFNMAP flag
>
> On Mon, Feb 28, 2022 at 05:22:12AM +0300, Yonghua Huang wrote:
> > acrn_vm_ram_map can't pin the user pages with VM_PFNMAP flag by
> > calling get_user_pages_fast(), the PA(physical pages) may be mapped
> > by kernel driver and set PFNMAP flag.
> >
> > This patch fixes logic to setup EPT mapping for PFN mapped RAM region
> > by checking the memory attribute before adding EPT mapping for them.
> >
> > Fixes: 88f537d5e8dd ("virt: acrn: Introduce EPT mapping management")
> > Signed-off-by: Yonghua Huang
> > Signed-off-by: Fei Li
> > ---
> > drivers/virt/acrn/mm.c | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/virt/acrn/mm.c b/drivers/virt/acrn/mm.c index
> > c4f2e15c8a2b..3b1b1e7a844b 100644
> > --- a/drivers/virt/acrn/mm.c
> > +++ b/drivers/virt/acrn/mm.c
> > @@ -162,10 +162,34 @@ int acrn_vm_ram_map(struct acrn_vm *vm, struct
> acrn_vm_memmap *memmap)
> > void *remap_vaddr;
> > int ret, pinned;
> > u64 user_vm_pa;
> > + unsigned long pfn;
> > + struct vm_area_struct *vma;
> >
> > if (!vm || !memmap)
> > return -EINVAL;
> >
> > + mmap_read_lock(current->mm);
> > + vma = vma_lookup(current->mm, memmap->vma_base);
> > + if (vma && ((vma->vm_flags & VM_PFNMAP) != 0)) {
> > + if ((memmap->vma_base + memmap->len) > vma->vm_end) {
> > + mmap_read_unlock(current->mm);
> > + return -EINVAL;
> > + }
> > +
> > + ret = follow_pfn(vma, memmap->vma_base, );
>
> This races, don't use follow_pfn() and most definitely don't add new users. In
> some cases follow_pte, but the pte/pfn is still only valid for as long as you
> hold
> the pte spinlock.
>
> > + mmap_read_unlock(current->mm);
>
> Definitely after here there's zero guarantees about this pfn and it could
> point at
> anything.
>
> Please fix, I tried pretty hard to get rid of follow_pfn(), but some of them
> are
> just too hard to fix (e.g. kvm needs a pretty hug rewrite to get it all
> sorted).
>
> Cheers, Daniel
>
> > + if (ret < 0) {
> > + dev_dbg(acrn_dev.this_device,
> > + "Failed to lookup PFN at VMA:%pK.\n", (void
> *)memmap->vma_base);
> > + return ret;
> > + }
> > +
> > + return acrn_mm_region_add(vm, memmap->user_vm_pa,
> > +PFN_PHYS(pfn), memmap->len,
> > +ACRN_MEM_TYPE_WB, memmap->attr);
> > + }
> > + mmap_read_unlock(current->mm);
> > +
> > /* Get the page number of the map region */
> > nr_pages = memmap->len >> PAGE_SHIFT;
> > pages = vzalloc(nr_pages * sizeof(struct page *));
> >
> > base-commit: 73878e5eb1bd3c9656685ca60bc3a49d17311e0c
> > --
> > 2.25.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: [PATCH 4/7] drm/i915/hwmon: Show device level energy usage
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
- Updated date, kernel version in documentation
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 ++
drivers/gpu/drm/i915/i915_hwmon.c | 107 +-
drivers/gpu/drm/i915/i915_hwmon.h | 1 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 2 +
4 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index bc061238e35c..94101f818a70 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-devel@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/energy1_input
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RO. Energy input of device in microjoules.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 5183cf51a49b..a42cfad78bef 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -17,21 +17,30 @@
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - energy - microjoules
*/
#define SF_VOLTAGE1000
#define SF_POWER 100
+#define SF_ENERGY 100
struct hwm_reg {
i915_reg_t gt_perf_status;
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+ i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+ u32 reg_val_prev;
+ long accum_energy; /* Accumulated energy for
energy1_input */
};
struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+ struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
};
@@ -40,6 +49,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
+ int scl_shift_energy;
};
static void
@@ -98,9 +108,60 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
}
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct hwm_energy_info *ei = >ei;
+ intel_wakeref_t wakeref;
+ i915_reg_t rgaddr;
+ u32 reg_val;
+
+ rgaddr = hwmon->rg.energy_status_all;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_val = intel_uncore_read(uncore, rgaddr);
+
+ if (reg_val >= ei->reg_val_prev)
+ ei->accum_energy += reg_val - ei->reg_val_prev;
+ else
+ ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+ ei->reg_val_prev = reg_val;
+
+ *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+ mutex_unlock(>hwmon_lock);
+
+ return
Re: [PATCH v9 09/10] leds: flash: mt6370: Add MediaTek MT6370 flashlight support
On Wed, Sep 21, 2022 at 4:48 AM ChiaEn Wu wrote: > On Sun, Sep 18, 2022 at 3:22 AM Han Jingoo wrote: > > On Mon, Aug 29, 2022 ChiaEn Wu wrote: > > > +#define MT6370_ITORCH_MIN_uA 25000 > > > +#define MT6370_ITORCH_STEP_uA 12500 > > > +#define MT6370_ITORCH_MAX_uA 40 > > > +#define MT6370_ITORCH_DOUBLE_MAX_uA80 > > > +#define MT6370_ISTRB_MIN_uA5 > > > +#define MT6370_ISTRB_STEP_uA 12500 > > > +#define MT6370_ISTRB_MAX_uA150 > > > +#define MT6370_ISTRB_DOUBLE_MAX_uA 300 > > > > Use upper letters as below: For microseconds (and other -seconds) the common practice (I assume historically) is to use upper letters, indeed. But for current it's more natural to use small letters for unit multiplier as it's easier to read and understand. > > #define MT6370_ITORCH_MIN_UA 25000 > > #define MT6370_ITORCH_STEP_UA 12500 > > #define MT6370_ITORCH_MAX_UA 40 > > #define MT6370_ITORCH_DOUBLE_MAX_UA80 > > #define MT6370_ISTRB_MIN_UA5 > > #define MT6370_ISTRB_STEP_UA 12500 > > #define MT6370_ISTRB_MAX_UA150 > > #define MT6370_ISTRB_DOUBLE_MAX_UA 300 > > > > > +#define MT6370_STRBTO_MIN_US 64000 > > > +#define MT6370_STRBTO_STEP_US 32000 > > > +#define MT6370_STRBTO_MAX_US 2432000 > > Hi Jingoo, > > This coding style is in accordance with Andy's opinion in this mail: > https://lore.kernel.org/linux-arm-kernel/CAHp75Vciq4M4kVrabNV9vTLLcd1vR=bme8jledaf9mkrtpc...@mail.gmail.com/ True. -- With Best Regards, Andy Shevchenko
Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6:
- Fix review comments (Ashutosh)
- Update date, kernel version in documentation
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 +++
drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 6 +
4 files changed, 187 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-devel@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in
microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 45745afa5c5b..5183cf51a49b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
+ * - power - microwatts
*/
#define SF_VOLTAGE1000
+#define SF_POWER 100
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(>hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* Computation in 64-bits to avoid overflow. Round to nearest. */
+ nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+ bits_to_clear = field_msk;
+ bits_to_set =
