Re: [Intel-gfx] [PATCH v2 09/15] drm/i915/pxp: add huc authentication and loading command

2022-08-18 Thread kernel test robot
Hi Daniele,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]

url:
https://github.com/intel-lab-lkp/linux/commits/Daniele-Ceraolo-Spurio/drm-i915-HuC-loading-for-DG2/20220819-070704
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-s002 
(https://download.01.org/0day-ci/archive/20220819/202208191208.p5c4lvlr-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-5) 11.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-39-gce1a6720-dirty
# 
https://github.com/intel-lab-lkp/linux/commit/5a5d288c4c93865952809443a74032634bfb9921
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Daniele-Ceraolo-Spurio/drm-i915-HuC-loading-for-DG2/20220819-070704
git checkout 5a5d288c4c93865952809443a74032634bfb9921
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir 
ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot 

sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:39:35: sparse: sparse: incorrect 
>> type in assignment (different base types) @@ expected restricted __le64 
>> [assigned] [usertype] huc_base_address @@ got unsigned int [assigned] 
>> [usertype] huc_phys_addr @@
   drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:39:35: sparse: expected 
restricted __le64 [assigned] [usertype] huc_base_address
   drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:39:35: sparse: got unsigned int 
[assigned] [usertype] huc_phys_addr

vim +39 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c

17  
18  int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp)
19  {
20  struct intel_gt *gt = pxp_to_gt(pxp);
21  struct intel_huc *huc = >uc.huc;
22  struct pxp_tee_start_huc_auth_in huc_in = {0};
23  struct pxp_tee_start_huc_auth_out huc_out = {0};
24  dma_addr_t huc_phys_addr;
25  u8 client_id = 0;
26  u8 fence_id = 0;
27  int err;
28  
29  if (!pxp->pxp_component)
30  return -ENODEV;
31  
32  huc_phys_addr = i915_gem_object_get_dma_address(huc->fw.obj, 0);
33  
34  /* write the PXP message into the lmem (the sg list) */
35  huc_in.header.api_version = PXP_TEE_43_APIVER;
36  huc_in.header.command_id  = PXP_TEE_43_START_HUC_AUTH;
37  huc_in.header.status  = 0;
38  huc_in.header.buffer_len  = sizeof(huc_in.huc_base_address);
  > 39  huc_in.huc_base_address   = huc_phys_addr;

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp


[git pull] drm fixes for 6.0-rc2

2022-08-18 Thread Dave Airlie
Hi Linus,

Regular weekly fixes. The nouveau patch just enables modesetting on
GA103 hw which is like other ampere cards that are already supported.
amdgpu has 2 weeks of fixes, as Alex was away, so a bit larger than
usual, otherwise some i915 and misc other fixes.

Dave.

drm-fixes-2022-08-19:
drm fixes for 6.0-rc2

ttm:
- NULL ptr dereference

i915:
- disable pci resize on 32-bit systems
- don't leak the ccs state
- TLB invalidation fixes

nouveau:
- GA103 enablement
- off-by-one fix

amdgpu:
- Revert some DML stack changes
- Rounding fixes in KFD allocations
- atombios vram info table parsing fix
- DCN 3.1.4 fixes
- Clockgating fixes for various new IPs
- SMU 13.0.4 fixes
- DCN 3.1.4 FP fixes
- TMDS fixes for YCbCr420 4k modes
- DCN 3.2.x fixes
- USB 4 fixes
- SMU 13.0 fixes
- SMU driver unload memory leak fixes
- Display orientation fix
- Regression fix for generic fbdev conversion
- SDMA 6.x fixes
- SR-IOV fixes
- IH 6.x fixes
- Use after free fix in bo list handling
- Revert pipe1 support
- XGMI hive reset fix

amdkfd:
- Fix potential crach in kfd_create_indirect_link_prop()

imx:
- warning fix

meson:
- refcounting fix

lvds-codec:
- error check fix

sun4i:
- underflow fix
- dt-binding fix
The following changes since commit 568035b01cfb107af8d2e4bd2fb9aea22cf5b868:

  Linux 6.0-rc1 (2022-08-14 15:50:18 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-08-19

for you to fetch changes up to b1fb6b87ed55ced458b322ea10cf0d0ab151e01b:

  Merge tag 'amd-drm-fixes-6.0-2022-08-17' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-08-19
09:45:22 +1000)


drm fixes for 6.0-rc2

ttm:
- NULL ptr dereference

i915:
- disable pci resize on 32-bit systems
- don't leak the ccs state
- TLB invalidation fixes

nouveau:
- GA103 enablement
- off-by-one fix

amdgpu:
- Revert some DML stack changes
- Rounding fixes in KFD allocations
- atombios vram info table parsing fix
- DCN 3.1.4 fixes
- Clockgating fixes for various new IPs
- SMU 13.0.4 fixes
- DCN 3.1.4 FP fixes
- TMDS fixes for YCbCr420 4k modes
- DCN 3.2.x fixes
- USB 4 fixes
- SMU 13.0 fixes
- SMU driver unload memory leak fixes
- Display orientation fix
- Regression fix for generic fbdev conversion
- SDMA 6.x fixes
- SR-IOV fixes
- IH 6.x fixes
- Use after free fix in bo list handling
- Revert pipe1 support
- XGMI hive reset fix

amdkfd:
- Fix potential crach in kfd_create_indirect_link_prop()

imx:
- warning fix

meson:
- refcounting fix

lvds-codec:
- error check fix

sun4i:
- underflow fix
- dt-binding fix


Alex Deucher (1):
  drm/amdgpu: Only disable prefer_shadow on hawaii

Alvin Lee (8):
  drm/amd/display: Add a variable to update FCLK latency
  drm/amd/display: Revert "attempt to fix the logic in
commit_planes_for_stream()"
  drm/amd/display: For stereo keep "FLIP_ANY_FRAME"
  drm/amd/display: Don't try to enter MALL SS if stereo3d
  drm/amd/display: Add 16 lines margin for SubVP
  drm/amd/display: Don't set DSC for phantom pipes
  drm/amd/display: Use pitch when calculating size to cache in MALL
  drm/amd/display: Include scaling factor for SubVP command

Andrey Strachuk (1):
  drm/amdgpu: remove useless condition in
amdgpu_job_stop_all_jobs_on_sched()

Aric Cyr (2):
  drm/amd/display: 3.2.197
  drm/amd/display: 3.2.198

Arunpravin Paneer Selvam (1):
  drm/ttm: Fix dummy res NULL ptr deref bug

Aurabindo Pillai (4):
  drm/amd/display: Add a missing register field for HPO DP stream encoder
  drm/amd/display: fix CAB allocation for multiple displays
  drm/amd/display: Check correct bounds for stream encoder
instances for DCN303
  drm/amd/display: Enable SubVP by default on DCN32 & DCN321

Chaitanya Dhere (1):
  drm/amd/display: Modify header inclusion pattern

Charlene Liu (1):
  drm/amd/display: avoid doing vm_init multiple time

Chiawen Huang (1):
  drm/amd/display: Device flash garbage before get in OS

Chris Wilson (5):
  drm/i915/gt: Ignore TLB invalidations on idle engines
  drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations
  drm/i915/gt: Skip TLB invalidations once wedged
  drm/i915/gt: Batch TLB invalidations
  drm/i915/gem: Remove shared locking on freeing objects

Dan Carpenter (1):
  drm/amdkfd: potential crash in kfd_create_indirect_link_prop()

Daniel Miess (3):
  drm/amd/display: Use pixels per container logic for DCN314 DCCG dividers
  drm/amd/display: Fix TMDS 4K@60Hz YCbCr420 corruption issue
  drm/amd/display: Add debug parameter to retain default clock table

Daniel Phillips (2):
  drm/amdgpu: Remove rounding from vram allocation path
  drm/amdgpu: Pessimistic availability based on rounded up allocations

Dave Airlie (3):
  Merge tag 'drm-intel-next-fixes-2022-08-11' of

Re: [PATCH 10/13] docs: leds: add leds-qcom-lpg.rst to the index file

2022-08-18 Thread Bagas Sanjaya
On 8/18/22 20:38, Mauro Carvalho Chehab wrote:
> Address this warning:
>   Documentation/leds/leds-qcom-lpg.rst: WARNING: o documento não está 
> incluído em nenhum toctree
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> See [PATCH 00/13] at: 
> https://lore.kernel.org/all/cover.1660829433.git.mche...@kernel.org/
> 
>  Documentation/leds/index.rst   | 1 +
>  drivers/gpu/drm/scheduler/sched_main.c | 1 +
>  include/drm/gpu_scheduler.h| 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
> index e5d63b940045..014e009b0761 100644
> --- a/Documentation/leds/index.rst
> +++ b/Documentation/leds/index.rst
> @@ -25,4 +25,5 @@ LEDs
> leds-lp5562
> leds-lp55xx
> leds-mlxcpld
> +   leds-qcom-lpg
> leds-sc27xx
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 68317d3a7a27..56c53a616816 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -994,6 +994,7 @@ static int drm_sched_main(void *param)
>   *   used
>   * @score: optional score atomic shared with other schedulers
>   * @name: name used for debugging
> + * @dev: Device structure
>   *
>   * Return 0 on success, otherwise error code.
>   */
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index addb135eeea6..f31988e03256 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -435,6 +435,7 @@ struct drm_sched_backend_ops {
>   * @_score: score used when the driver doesn't provide one
>   * @ready: marks if the underlying HW is ready to work
>   * @free_guilty: A hit to time out handler to free the guilty job.
> + * @dev: Device structure
>   *
>   * One scheduler is implemented for each hardware ring.
>   */

Hi Mauro,

I have already sent the fix (resend a long time ago) at [1] and got
Acked-by from Pavel, but seems like he forgot to push it. Maybe the
subsystem had maintenanceship issue as pointed by Andy (CC'ed) ([2]).

[1]: 
https://lore.kernel.org/linux-doc/20220612000125.9777-1-bagasdo...@gmail.com/
[2]: 
https://lore.kernel.org/lkml/cahp75vewkgyz32scczn0c+ijwgzxvp42g0ng0oxrdj34gyh...@mail.gmail.com/

Thanks.

-- 
An old man doll... just what I always wanted! - Clara


Re: [PATCH v1 1/1] kfd: fixed memleak about release topology

2022-08-18 Thread ZhiJie.Zhang




在 2022/8/18 6:31, Felix Kuehling 写道:

Am 2022-07-15 um 04:07 schrieb ZhiJie.zhang:
memleak will happend that reload module due to ignore kfree when 
release topology


Signed-off-by: ZhiJie.zhang 
---
  drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c

index 8d50d207cf66..8b86f56bd50c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -872,6 +872,7 @@ static void kfd_topology_release_sysfs(void)
  }
  kobject_del(sys_props.kobj_topology);
  kobject_put(sys_props.kobj_topology);
+    kfree(sys_props.kobj_topology);


Sorry for the late response. This looks incorrect. kobjects are 
reference counted. The underlying memory should be freed by a callback 
when the reference count reaches 0 in kobject_put. Freeing the object 
here explicitly would lead to a double-free.


The callback in this case is kfd_topology_kobj_release, which calls 
kfree. Am I missing anything?



Yes, Your are right, this is my misstake, please ignore this patch

Regards,
   Felix



  sys_props.kobj_topology = NULL;
  }
  }


Regards.
Zhijie



Re: [PATCH v2 2/3] drm: rcar-du: Add DRM_MODE_BLEND_PREMULTI support

2022-08-18 Thread Takanari Hayama
Hi Laurent,

> 2022/08/19 11:08、Laurent Pinchart のメール:
> 
> Hello Hayama-san,
> 
> Thank you for the patch.
> 
> On Wed, Aug 10, 2022 at 05:37:10PM +0900, Takanari Hayama wrote:
>> R-Car DU driver implicitly supports DRM_MODE_BLEND_COVERAGE only.
>> This adds a support for DRM_MODE_BLEND_PREMULTI. As a consequence,
>> DRM_MODE_BLEND_PREMULTI becomes the default. If DRM_MODE_BLEND_COVERAGE
>> is desired, it should be set explicitly.
>> 
>> This behavior comes from how DRM blend mode is supported.
>> drm_plane_create_blend_mode_property() creates the blend mode property
>> with the default value of DRM_MODE_BLEND_PREMULTI. This default value
>> cannot be modified from the atomic driver.
>> 
>> Signed-off-by: Takanari Hayama 
>> ---
>> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 6 ++
>> 1 file changed, 6 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> index 8eb9b2b097ae..b9580fcfec7a 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -167,6 +167,8 @@ static void rcar_du_vsp_plane_setup(struct 
>> rcar_du_vsp_plane *plane)
>>  cfg.mem[i] = sg_dma_address(state->sg_tables[i].sgl)
>> + fb->offsets[i];
>> 
>> +cfg.premult = (state->state.pixel_blend_mode == 
>> DRM_MODE_BLEND_PREMULTI);
> 
> I'll drop the parentheses here too, and if you don't mind, I'll move
> this down after setting cfg.pixelformat, as premult qualifies the format
> so it's more logical in that reading order (no change on the behaviour
> of course).

Thank you. I also agree with the proposed change in order.

> Reviewed-by: Laurent Pinchart 
> 
>> +
>>  format = rcar_du_format_info(state->format->fourcc);
>>  cfg.pixelformat = format->v4l2;
>> 
>> @@ -444,6 +446,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
>> device_node *np,
>> num_planes - 1);
>>  }
>> 
>> +drm_plane_create_blend_mode_property(>plane,
>> +BIT(DRM_MODE_BLEND_PREMULTI) |
>> +BIT(DRM_MODE_BLEND_COVERAGE));
>> +
>>  vsp->num_planes++;
>>  }
>> 
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Cheers,
Takanari Hayama, Ph.D. 
IGEL Co., Ltd.
https://www.igel.co.jp/



Re: [PATCH v2 1/3] media: vsp1: add premultiplied alpha support

2022-08-18 Thread Laurent Pinchart
Mauro, would you be fine with this patch going through the DRM tree for
v6.1 ? I don't foresee any risk of conflict with other changes to the
VSP driver scheduled for the next kernel version. If that's fine with
you, could you give an Acked-by ? Otherwise I can send you a pull
request to create an immutable branch and base the rest on it in my pull
request for DRM, but given how small this change is, it seems a bit
overkill.

On Fri, Aug 19, 2022 at 05:01:10AM +0300, Laurent Pinchart wrote:
> Hi Hayama-san,
> 
> Thank you for the patch.
> 
> On Wed, Aug 10, 2022 at 05:37:09PM +0900, Takanari Hayama wrote:
> > To support DRM blend mode in R-Car DU driver, we must be able to pass
> > a plane with the premultiplied alpha. Adding a new property to
> > vsp1_du_atomic_config allows the R-Car DU driver to pass the
> > premultiplied alpha plane.
> > 
> > Signed-off-by: Takanari Hayama 
> > ---
> >  drivers/media/platform/renesas/vsp1/vsp1_drm.c | 2 ++
> >  include/media/vsp1.h   | 2 ++
> >  2 files changed, 4 insertions(+)
> > 
> > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drm.c 
> > b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > index 0c2507dc03d6..019e18976bd8 100644
> > --- a/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> > @@ -856,6 +856,8 @@ int vsp1_du_atomic_update(struct device *dev, unsigned 
> > int pipe_index,
> > rpf->mem.addr[1] = cfg->mem[1];
> > rpf->mem.addr[2] = cfg->mem[2];
> >  
> > +   rpf->format.flags = (cfg->premult) ? V4L2_PIX_FMT_FLAG_PREMUL_ALPHA : 0;
> 
> I'll drop the parentheses when applying.
> 
> Reviewed-by: Laurent Pinchart 
> 
> > +
> > vsp1->drm->inputs[rpf_index].crop = cfg->src;
> > vsp1->drm->inputs[rpf_index].compose = cfg->dst;
> > vsp1->drm->inputs[rpf_index].zpos = cfg->zpos;
> > diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> > index cc1b0d42ce95..48f4a5023d81 100644
> > --- a/include/media/vsp1.h
> > +++ b/include/media/vsp1.h
> > @@ -51,6 +51,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> > pipe_index,
> >   * @dst: destination rectangle on the display (integer coordinates)
> >   * @alpha: alpha value (0: fully transparent, 255: fully opaque)
> >   * @zpos: Z position of the plane (from 0 to number of planes minus 1)
> > + * @premult: true for premultiplied alpha
> >   */
> >  struct vsp1_du_atomic_config {
> > u32 pixelformat;
> > @@ -60,6 +61,7 @@ struct vsp1_du_atomic_config {
> > struct v4l2_rect dst;
> > unsigned int alpha;
> > unsigned int zpos;
> > +   bool premult;
> >  };
> >  
> >  /**

-- 
Regards,

Laurent Pinchart


Re: [PATCH v2 3/3] drm: rcar-du: Add DRM_MODE_BLEND_PIXEL_NONE support

2022-08-18 Thread Laurent Pinchart
Hello Hayama-san,

Thank you for the patch.

On Wed, Aug 10, 2022 at 05:37:11PM +0900, Takanari Hayama wrote:
> DRM_MODE_BLEND_PIXEL_NONE ignores an alpha channel.
> 
> Rcar-du driver supports only 3 formats with an alpha channel
> (DRM_FORMAT_ARGB1555, DRM_FORMAT_ARGB and DRM_FORMAT_ARGB). We
> simply override the format passed to VSP1 for blending with the pixel
> format without alpha channel.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Takanari Hayama 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index b9580fcfec7a..7cce2d414ced 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -151,6 +151,7 @@ static void rcar_du_vsp_plane_setup(struct 
> rcar_du_vsp_plane *plane)
>   .alpha = state->state.alpha >> 8,
>   .zpos = state->state.zpos,
>   };
> + u32 fourcc = state->format->fourcc;
>   unsigned int i;
>  
>   cfg.src.left = state->state.src.x1 >> 16;
> @@ -169,7 +170,23 @@ static void rcar_du_vsp_plane_setup(struct 
> rcar_du_vsp_plane *plane)
>  
>   cfg.premult = (state->state.pixel_blend_mode == 
> DRM_MODE_BLEND_PREMULTI);
>  
> - format = rcar_du_format_info(state->format->fourcc);
> + if (state->state.pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE) {
> + switch (fourcc) {
> + case DRM_FORMAT_ARGB1555:
> + fourcc = DRM_FORMAT_XRGB1555;
> + break;
> +
> + case DRM_FORMAT_ARGB:
> + fourcc = DRM_FORMAT_XRGB;
> + break;
> +
> + case DRM_FORMAT_ARGB:
> + fourcc = DRM_FORMAT_XRGB;
> + break;
> + }
> + }
> +
> + format = rcar_du_format_info(fourcc);
>   cfg.pixelformat = format->v4l2;
>  
>   vsp1_du_atomic_update(plane->vsp->vsp, crtc->vsp_pipe,
> @@ -447,6 +464,7 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>   }
>  
>   drm_plane_create_blend_mode_property(>plane,
> + BIT(DRM_MODE_BLEND_PIXEL_NONE) |
>   BIT(DRM_MODE_BLEND_PREMULTI) |
>   BIT(DRM_MODE_BLEND_COVERAGE));
>  

-- 
Regards,

Laurent Pinchart


Re: [PATCH v2 2/3] drm: rcar-du: Add DRM_MODE_BLEND_PREMULTI support

2022-08-18 Thread Laurent Pinchart
Hello Hayama-san,

Thank you for the patch.

On Wed, Aug 10, 2022 at 05:37:10PM +0900, Takanari Hayama wrote:
> R-Car DU driver implicitly supports DRM_MODE_BLEND_COVERAGE only.
> This adds a support for DRM_MODE_BLEND_PREMULTI. As a consequence,
> DRM_MODE_BLEND_PREMULTI becomes the default. If DRM_MODE_BLEND_COVERAGE
> is desired, it should be set explicitly.
> 
> This behavior comes from how DRM blend mode is supported.
> drm_plane_create_blend_mode_property() creates the blend mode property
> with the default value of DRM_MODE_BLEND_PREMULTI. This default value
> cannot be modified from the atomic driver.
> 
> Signed-off-by: Takanari Hayama 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index 8eb9b2b097ae..b9580fcfec7a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -167,6 +167,8 @@ static void rcar_du_vsp_plane_setup(struct 
> rcar_du_vsp_plane *plane)
>   cfg.mem[i] = sg_dma_address(state->sg_tables[i].sgl)
>  + fb->offsets[i];
>  
> + cfg.premult = (state->state.pixel_blend_mode == 
> DRM_MODE_BLEND_PREMULTI);

I'll drop the parentheses here too, and if you don't mind, I'll move
this down after setting cfg.pixelformat, as premult qualifies the format
so it's more logical in that reading order (no change on the behaviour
of course).

Reviewed-by: Laurent Pinchart 

> +
>   format = rcar_du_format_info(state->format->fourcc);
>   cfg.pixelformat = format->v4l2;
>  
> @@ -444,6 +446,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct 
> device_node *np,
>  num_planes - 1);
>   }
>  
> + drm_plane_create_blend_mode_property(>plane,
> + BIT(DRM_MODE_BLEND_PREMULTI) |
> + BIT(DRM_MODE_BLEND_COVERAGE));
> +
>   vsp->num_planes++;
>   }
>  

-- 
Regards,

Laurent Pinchart


Re: [PATCH v2 1/3] media: vsp1: add premultiplied alpha support

2022-08-18 Thread Takanari Hayama
Hi Laurent,

> 2022/08/19 11:01、Laurent Pinchart のメール:
> 
> Hi Hayama-san,
> 
> Thank you for the patch.
> 
> On Wed, Aug 10, 2022 at 05:37:09PM +0900, Takanari Hayama wrote:
>> To support DRM blend mode in R-Car DU driver, we must be able to pass
>> a plane with the premultiplied alpha. Adding a new property to
>> vsp1_du_atomic_config allows the R-Car DU driver to pass the
>> premultiplied alpha plane.
>> 
>> Signed-off-by: Takanari Hayama 
>> ---
>> drivers/media/platform/renesas/vsp1/vsp1_drm.c | 2 ++
>> include/media/vsp1.h   | 2 ++
>> 2 files changed, 4 insertions(+)
>> 
>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drm.c 
>> b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
>> index 0c2507dc03d6..019e18976bd8 100644
>> --- a/drivers/media/platform/renesas/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
>> @@ -856,6 +856,8 @@ int vsp1_du_atomic_update(struct device *dev, unsigned 
>> int pipe_index,
>>  rpf->mem.addr[1] = cfg->mem[1];
>>  rpf->mem.addr[2] = cfg->mem[2];
>> 
>> +rpf->format.flags = (cfg->premult) ? V4L2_PIX_FMT_FLAG_PREMUL_ALPHA : 0;
> 
> I'll drop the parentheses when applying.

Thank you!

> 
> Reviewed-by: Laurent Pinchart 
> 
>> +
>>  vsp1->drm->inputs[rpf_index].crop = cfg->src;
>>  vsp1->drm->inputs[rpf_index].compose = cfg->dst;
>>  vsp1->drm->inputs[rpf_index].zpos = cfg->zpos;
>> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
>> index cc1b0d42ce95..48f4a5023d81 100644
>> --- a/include/media/vsp1.h
>> +++ b/include/media/vsp1.h
>> @@ -51,6 +51,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
>> pipe_index,
>>  * @dst: destination rectangle on the display (integer coordinates)
>>  * @alpha: alpha value (0: fully transparent, 255: fully opaque)
>>  * @zpos: Z position of the plane (from 0 to number of planes minus 1)
>> + * @premult: true for premultiplied alpha
>>  */
>> struct vsp1_du_atomic_config {
>>  u32 pixelformat;
>> @@ -60,6 +61,7 @@ struct vsp1_du_atomic_config {
>>  struct v4l2_rect dst;
>>  unsigned int alpha;
>>  unsigned int zpos;
>> +bool premult;
>> };
>> 
>> /**
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Cheers,
Takanari Hayama, Ph.D. 
IGEL Co., Ltd.
https://www.igel.co.jp/


Re: [PATCH v2 1/3] media: vsp1: add premultiplied alpha support

2022-08-18 Thread Laurent Pinchart
Hi Hayama-san,

Thank you for the patch.

On Wed, Aug 10, 2022 at 05:37:09PM +0900, Takanari Hayama wrote:
> To support DRM blend mode in R-Car DU driver, we must be able to pass
> a plane with the premultiplied alpha. Adding a new property to
> vsp1_du_atomic_config allows the R-Car DU driver to pass the
> premultiplied alpha plane.
> 
> Signed-off-by: Takanari Hayama 
> ---
>  drivers/media/platform/renesas/vsp1/vsp1_drm.c | 2 ++
>  include/media/vsp1.h   | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drm.c 
> b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> index 0c2507dc03d6..019e18976bd8 100644
> --- a/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/renesas/vsp1/vsp1_drm.c
> @@ -856,6 +856,8 @@ int vsp1_du_atomic_update(struct device *dev, unsigned 
> int pipe_index,
>   rpf->mem.addr[1] = cfg->mem[1];
>   rpf->mem.addr[2] = cfg->mem[2];
>  
> + rpf->format.flags = (cfg->premult) ? V4L2_PIX_FMT_FLAG_PREMUL_ALPHA : 0;

I'll drop the parentheses when applying.

Reviewed-by: Laurent Pinchart 

> +
>   vsp1->drm->inputs[rpf_index].crop = cfg->src;
>   vsp1->drm->inputs[rpf_index].compose = cfg->dst;
>   vsp1->drm->inputs[rpf_index].zpos = cfg->zpos;
> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> index cc1b0d42ce95..48f4a5023d81 100644
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -51,6 +51,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   * @dst: destination rectangle on the display (integer coordinates)
>   * @alpha: alpha value (0: fully transparent, 255: fully opaque)
>   * @zpos: Z position of the plane (from 0 to number of planes minus 1)
> + * @premult: true for premultiplied alpha
>   */
>  struct vsp1_du_atomic_config {
>   u32 pixelformat;
> @@ -60,6 +61,7 @@ struct vsp1_du_atomic_config {
>   struct v4l2_rect dst;
>   unsigned int alpha;
>   unsigned int zpos;
> + bool premult;
>  };
>  
>  /**

-- 
Regards,

Laurent Pinchart


[PATCH] drm/amd/display: remove unused header

2022-08-18 Thread Magali Lemes
dml_wrapper* files were removed in commit 724449e30433
("drm/amd/display: Remove unused code"), as they are not used anywhere.
However, the header file wasn't removed, so remove the header as well.

Signed-off-by: Magali Lemes 
---
 .../gpu/drm/amd/display/dc/inc/dml_wrapper.h  | 34 ---
 1 file changed, 34 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/display/dc/inc/dml_wrapper.h

diff --git a/drivers/gpu/drm/amd/display/dc/inc/dml_wrapper.h 
b/drivers/gpu/drm/amd/display/dc/inc/dml_wrapper.h
deleted file mode 100644
index 5dcfbd8e2697..
--- a/drivers/gpu/drm/amd/display/dc/inc/dml_wrapper.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * Copyright 2015 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: AMD
- *
- */
-
-#ifndef DML_WRAPPER_H_
-#define DML_WRAPPER_H_
-
-#include "dc.h"
-#include "dml/display_mode_vba.h"
-
-bool dml_validate(struct dc *dc, struct dc_state *context, bool fast_validate);
-
-#endif
-- 
2.37.1



Re: [PATCH 3/3] drm: rcar-du: fix DSI enable & disable sequence

2022-08-18 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Wed, Aug 17, 2022 at 04:28:03PM +0300, Tomi Valkeinen wrote:
> From: Tomi Valkeinen 
> 
> The rcar crtc depends on the clock provided from the rcar DSI bridge.
> When the DSI bridge is disabled, the clock is stopped, which causes the
> crtc disable to timeout.
> 
> Also, while I have no issue with the enable, the documentation suggests
> to enable the DSI before the crtc so that the crtc has its clock enabled
> at enable time. This is also not done by the current driver.
> 
> To fix this, we need to keep the DSI bridge enabled until the crtc has
> disabled itself, and enable the DSI bridge before crtc enables itself.
> 
> Add functions (rcar_mipi_dsi_atomic_early_enable and
> rcar_mipi_dsi_atomic_late_disable) to the rcar DSI bridge driver which
> the rcar driver can use to enable/disable the DSI clock when needed.
> This is similar to what is already done with the rcar LVDS bridge.

I had hoped we could avoid that :-(

I wonder if we could instead rely on the pre_enable/post_disable bridge
operations, with a custom commit tail implementation to order those
before/after the CRTC enable/disable respectively. That would be pretty
complex though, so probably not worth it.

Thinking more about this, I wonder why pre_enable is not called before
enabling the CRTC in the DRM atomic helpers. That would make more sense
to me, but I suppose changing it would break too many things ? I think
it should at least be discussed to figure out if it was a historical
oversight or if there was a good reason. It's *really* not nice to poke
holes through the abstraction layers like this.

> Also add a new function, rcar_mipi_dsi_stop_video(), called from
> rcar_mipi_dsi_atomic_enable so that the DSI TX gets disabled at the
> correct time, even if the clocks are still kept enabled.

I think this should be split to a separate patch, possibly before this
one, it addresses a separate issue.

> And, while possibly not strictly needed, clear clock related enable bits
> in rcar_mipi_dsi_atomic_late_disable to mirror the sequence done in
> rcar_mipi_dsi_startup() (via rcar_mipi_dsi_atomic_early_enable).

And this too should be a separate patch, possibly bundled with
rcar_mipi_dsi_stop_video().

Have you checked in the BSP code to see if they do the same at disable
time ?

> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 25 +
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h |  2 +
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  4 ++
>  drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c   | 63 +--
>  drivers/gpu/drm/rcar-du/rcar_mipi_dsi.h   | 32 
>  5 files changed, 121 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.h
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index fd3b94649a01..51fd1d99f4e8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -29,6 +29,7 @@
>  #include "rcar_du_regs.h"
>  #include "rcar_du_vsp.h"
>  #include "rcar_lvds.h"
> +#include "rcar_mipi_dsi.h"
>  
>  static u32 rcar_du_crtc_read(struct rcar_du_crtc *rcrtc, u32 reg)
>  {
> @@ -733,6 +734,18 @@ static void rcar_du_crtc_atomic_enable(struct drm_crtc 
> *crtc,
>   rcar_cmm_enable(rcrtc->cmm);
>   rcar_du_crtc_get(rcrtc);
>  

A comment here similar to the LVDS case would be useful. I would
actually move this below the LVDS code, and write

/*
 * Similarly, on V3U, ...
 */

> + if ((rcdu->info->dsi_clk_mask & BIT(rcrtc->index)) &&
> + (rstate->outputs &
> +  (BIT(RCAR_DU_OUTPUT_DSI0) | BIT(RCAR_DU_OUTPUT_DSI1 {
> + struct drm_bridge *bridge = rcdu->dsi[rcrtc->index];
> +
> + /*
> +  * Enable the DSI clock output.
> +  */
> +
> + rcar_mipi_dsi_atomic_early_enable(bridge, state);
> + }

I was wondering if we could merge the DSI and LVDS clock enabling code,
including merging the lvds and dsi fields in rcar_du_device, but it
doesn't seem it will be very clean here.

> +
>   /*
>* On D3/E3 the dot clock is provided by the LVDS encoder attached to
>* the DU channel. We need to enable its clock output explicitly if
> @@ -769,6 +782,18 @@ static void rcar_du_crtc_atomic_disable(struct drm_crtc 
> *crtc,
>   rcar_du_crtc_stop(rcrtc);
>   rcar_du_crtc_put(rcrtc);
>  
> + if ((rcdu->info->dsi_clk_mask & BIT(rcrtc->index)) &&
> + (rstate->outputs &
> +  (BIT(RCAR_DU_OUTPUT_DSI0) | BIT(RCAR_DU_OUTPUT_DSI1 {
> + struct drm_bridge *bridge = rcdu->dsi[rcrtc->index];
> +
> + /*
> +  * Disable the DSI clock output.
> +  */
> +
> + rcar_mipi_dsi_atomic_late_disable(bridge);
> + }
> +
>   if (rcdu->info->lvds_clk_mask & BIT(rcrtc->index) &&
>   rstate->outputs == 

Re: [PATCH 2/3] drm: rcar-du: Fix r8a779a0 color issue.

2022-08-18 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Wed, Aug 17, 2022 at 04:28:02PM +0300, Tomi Valkeinen wrote:
> From: Tomi Valkeinen 
> 
> The rcar DU driver on r8a779a0 has a bug causing some specific colors
> getting converted to transparent colors, which then (usually) show as
> black pixels on the screen.
> 
> The reason seems to be that the driver sets PnMR_SPIM_ALP bit in
> PnMR.SPIM field, which is an illegal setting on r8a779a0. The
> PnMR_SPIM_EOR bit also illegal.
> 
> Add a new feature flag for this (lack of a) feature and make sure the
> bits are zero on r8a779a0.

Good catch !

> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 16 +---
>  3 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 541c202c993a..a2776f1d6f2c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -506,7 +506,8 @@ static const struct rcar_du_device_info 
> rcar_du_r8a7799x_info = {
>  static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
>   .gen = 3,
>   .features = RCAR_DU_FEATURE_CRTC_IRQ
> -   | RCAR_DU_FEATURE_VSP1_SOURCE,
> +   | RCAR_DU_FEATURE_VSP1_SOURCE
> +   | RCAR_DU_FEATURE_NO_BLENDING,
>   .channels_mask = BIT(1) | BIT(0),
>   .routes = {
>   /* R8A779A0 has two MIPI DSI outputs. */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index bfad7775d9a1..712389c7b3d0 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -31,6 +31,7 @@ struct rcar_du_device;
>  #define RCAR_DU_FEATURE_VSP1_SOURCE  BIT(2)  /* Has inputs from VSP1 */
>  #define RCAR_DU_FEATURE_INTERLACED   BIT(3)  /* HW supports interlaced */
>  #define RCAR_DU_FEATURE_TVM_SYNC BIT(4)  /* Has TV switch/sync modes */
> +#define RCAR_DU_FEATURE_NO_BLENDING  BIT(5)  /* PnMR.SPIM does not have ALP 
> nor EOR bits */
>  
>  #define RCAR_DU_QUIRK_ALIGN_128B BIT(0)  /* Align pitches to 128 bytes */
>  
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 9e1f0cbbf642..2103816807cc 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -506,8 +506,19 @@ static void rcar_du_plane_setup_format_gen3(struct 
> rcar_du_group *rgrp,
>   unsigned int index,
>   const struct rcar_du_plane_state 
> *state)
>  {
> - rcar_du_plane_write(rgrp, index, PnMR,
> - PnMR_SPIM_TP_OFF | state->format->pnmr);
> + struct rcar_du_device *rcdu = rgrp->dev;
> + u32 pnmr;
> +
> + pnmr = state->format->pnmr;
> +
> + if (rcdu->info->features & RCAR_DU_FEATURE_NO_BLENDING) {
> + /* No blending. ALP and EOR are not supported */
> + pnmr &= ~(PnMR_SPIM_ALP | PnMR_SPIM_EOR);
> + }
> +
> + pnmr |= PnMR_SPIM_TP_OFF;

I'd combine this with the initial pnmr assignment. I can handle this
when applying, no need to resubmit.

Reviewed-by: Laurent Pinchart 

> +
> + rcar_du_plane_write(rgrp, index, PnMR, pnmr);
>  
>   rcar_du_plane_write(rgrp, index, PnDDCR4,
>   state->format->edf | PnDDCR4_CODE);
> @@ -521,7 +532,6 @@ static void rcar_du_plane_setup_format_gen3(struct 
> rcar_du_group *rgrp,
>* register to 0 to avoid this.
>*/
>  
> - /* TODO: Check if alpha-blending should be disabled in PnMR. */
>   rcar_du_plane_write(rgrp, index, PnALPHAR, 0);
>  }

-- 
Regards,

Laurent Pinchart


Re: [PATCH 1/3] drm: rcar-du: remove unnecessary include

2022-08-18 Thread Laurent Pinchart
Hi Tomi,

Thank you for the patch.

On Wed, Aug 17, 2022 at 04:28:01PM +0300, Tomi Valkeinen wrote:
> From: Tomi Valkeinen 
> 
> rcar_du_regs.h is not needed by rcar_du_drv.c so drop the include.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 00ac233a115e..541c202c993a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -27,7 +27,6 @@
>  
>  #include "rcar_du_drv.h"
>  #include "rcar_du_kms.h"
> -#include "rcar_du_regs.h"
>  
>  /* 
> -
>   * Device Information

-- 
Regards,

Laurent Pinchart


[PATCH drm-misc-next 1/3] drm/vc4: hdmi: unlock mutex when device is unplugged

2022-08-18 Thread Danilo Krummrich
In vc4_hdmi_encoder_{pre,post}_crtc_enable() commit cd00ed5187bf
("drm/vc4: hdmi: Protect device resources after removal") missed to
unlock the mutex before returning due to drm_dev_enter() indicating the
device being unplugged.

Fixes: cd00ed5187bf ("drm/vc4: hdmi: Protect device resources after removal")
Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 84e5a91c2ea7..4d3ff51ad2a8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1425,7 +1425,7 @@ static void vc4_hdmi_encoder_pre_crtc_enable(struct 
drm_encoder *encoder,
mutex_lock(_hdmi->mutex);
 
if (!drm_dev_enter(drm, ))
-   return;
+   goto out;
 
if (vc4_hdmi->variant->csc_setup)
vc4_hdmi->variant->csc_setup(vc4_hdmi, conn_state, mode);
@@ -1436,6 +1436,7 @@ static void vc4_hdmi_encoder_pre_crtc_enable(struct 
drm_encoder *encoder,
 
drm_dev_exit(idx);
 
+out:
mutex_unlock(_hdmi->mutex);
 }
 
@@ -1455,7 +1456,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct 
drm_encoder *encoder,
mutex_lock(_hdmi->mutex);
 
if (!drm_dev_enter(drm, ))
-   return;
+   goto out;
 
spin_lock_irqsave(_hdmi->hw_lock, flags);
 
@@ -1516,6 +1517,8 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct 
drm_encoder *encoder,
vc4_hdmi_enable_scrambling(encoder);
 
drm_dev_exit(idx);
+
+out:
mutex_unlock(_hdmi->mutex);
 }
 
-- 
2.37.2



[PATCH drm-misc-next 3/3] drm/vc4: crtc: protect device resources after removal

2022-08-18 Thread Danilo Krummrich
(Hardware) resources which are bound to the driver and device lifecycle
must not be accessed after the device and driver are unbound.

However, the DRM device isn't freed as long as the last user closed it,
hence userspace can still call into the driver.

Therefore protect the critical sections which are accessing those
resources with drm_dev_enter() and drm_dev_exit().

Fixes: 7cc4214c27cf ("drm/vc4: crtc: Switch to drmm_kzalloc")
Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 41 +-
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 2def6e2ad6f0..51daf190196e 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -295,10 +296,17 @@ struct drm_encoder *vc4_get_crtc_encoder(struct drm_crtc 
*crtc,
 static void vc4_crtc_pixelvalve_reset(struct drm_crtc *crtc)
 {
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
+   int idx;
+
+   if (!drm_dev_enter(dev, ))
+   return;
 
/* The PV needs to be disabled before it can be flushed */
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) & ~PV_CONTROL_EN);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_FIFO_CLR);
+
+   drm_dev_exit(idx);
 }
 
 static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct drm_encoder 
*encoder,
@@ -321,6 +329,10 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, 
struct drm_encoder *encode
u32 format = is_dsi1 ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
u8 ppc = pv_data->pixels_per_clock;
bool debug_dump_regs = false;
+   int idx;
+
+   if (!drm_dev_enter(dev, ))
+   return;
 
if (debug_dump_regs) {
struct drm_printer p = drm_info_printer(_crtc->pdev->dev);
@@ -410,6 +422,8 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, 
struct drm_encoder *encode
 drm_crtc_index(crtc));
drm_print_regset32(, _crtc->regset);
}
+
+   drm_dev_exit(idx);
 }
 
 static void require_hvs_enabled(struct drm_device *dev)
@@ -430,13 +444,18 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   int ret;
+   int idx, ret;
+
+   if (!drm_dev_enter(dev, ))
+   return -ENODEV;
 
CRTC_WRITE(PV_V_CONTROL,
   CRTC_READ(PV_V_CONTROL) & ~PV_VCONTROL_VIDEN);
ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1);
WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n");
 
+   drm_dev_exit(idx);
+
/*
 * This delay is needed to avoid to get a pixel stuck in an
 * unflushable FIFO between the pixelvalve and the HDMI
@@ -588,6 +607,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc, new_state);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
+   int idx;
 
drm_dbg(dev, "Enabling CRTC %s (%u) connected to Encoder %s (%u)",
crtc->name, crtc->base.id, encoder->name, encoder->base.id);
@@ -606,6 +626,9 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
 
vc4_crtc_config_pv(crtc, encoder, state);
 
+   if (!drm_dev_enter(dev, ))
+   return;
+
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
 
if (vc4_encoder->pre_crtc_enable)
@@ -617,6 +640,8 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_WRITE(PV_V_CONTROL,
   CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
 
+   drm_dev_exit(idx);
+
if (vc4_encoder->post_crtc_enable)
vc4_encoder->post_crtc_enable(encoder, state);
 }
@@ -711,17 +736,31 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
 static int vc4_enable_vblank(struct drm_crtc *crtc)
 {
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
+   int idx;
+
+   if (!drm_dev_enter(dev, ))
+   return -ENODEV;
 
CRTC_WRITE(PV_INTEN, PV_INT_VFP_START);
 
+   drm_dev_exit(idx);
+
return 0;
 }
 
 static void vc4_disable_vblank(struct drm_crtc *crtc)
 {
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
+   int idx;
+
+   if (!drm_dev_enter(dev, ))
+   return;
 
CRTC_WRITE(PV_INTEN, 0);
+
+   drm_dev_exit(idx);
 }
 
 static void vc4_crtc_handle_page_flip(struct vc4_crtc *vc4_crtc)
-- 
2.37.2



[PATCH drm-misc-next 0/3] Fixes for vc4 hotplug rework

2022-08-18 Thread Danilo Krummrich
Hi,

I've found a few potential issues left after the hotplug rework.

In vc4_hdmi.c we're missing two mutex_unlock() calls when the device is
unplugged.

vc4_crtc and vc4_plane seem to miss some drm_dev_enter()/drm_dev_exit() calls
to protect against resource access after the device/driver is unbound, but the
DRM potentially isn't freed yet and userspace can still call into the driver.

Danilo Krummrich (3):
  drm/vc4: hdmi: unlock mutex when device is unplugged
  drm/vc4: plane: protect device resources after removal
  drm/vc4: crtc: protect device resources after removal

 drivers/gpu/drm/vc4/vc4_crtc.c  | 41 -
 drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
 drivers/gpu/drm/vc4/vc4_hdmi.c  |  7 --
 drivers/gpu/drm/vc4/vc4_plane.c | 25 
 4 files changed, 71 insertions(+), 3 deletions(-)


base-commit: 8ba9249396bef37cb68be9e8dee7847f1737db9d
-- 
2.37.2



[syzbot] general protection fault in release_udmabuf

2022-08-18 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:7ebfc85e2cd7 Merge tag 'net-6.0-rc1' of git://git.kernel.o..
git tree:   upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1331f44708
kernel config:  https://syzkaller.appspot.com/x/.config?x=924833c12349a8c0
dashboard link: https://syzkaller.appspot.com/bug?extid=c80e9ef5d8bb45894db0
compiler:   gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1601336b08
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16d3292d08

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16e01a3d08
final oops: https://syzkaller.appspot.com/x/report.txt?x=15e01a3d08
console output: https://syzkaller.appspot.com/x/log.txt?x=11e01a3d08

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c80e9ef5d8bb45894...@syzkaller.appspotmail.com

general protection fault, probably for non-canonical address 
0xdc00:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x-0x0007]
CPU: 0 PID: 3609 Comm: syz-executor487 Not tainted 
5.19.0-syzkaller-13930-g7ebfc85e2cd7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
07/22/2022
RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline]
RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline]
RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 04 00 00 48 8d 7d 0c 4c 8b 63 
30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 
e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 e2
RSP: 0018:c900037efd30 EFLAGS: 00010246
RAX: dc00 RBX: 8cb67800 RCX: 
RDX:  RSI: 84ad27e0 RDI: 
RBP: fff4 R08: 0005 R09: 
R10:  R11: 0008c07c R12: 88801fa05000
R13: 888073db07e8 R14: 888025c25440 R15: 
FS:  55fc4300() GS:8880b9a0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fc1c0ce06e4 CR3: 715e6000 CR4: 003506f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 
 dma_buf_release+0x157/0x2d0 drivers/dma-buf/dma-buf.c:78
 __dentry_kill+0x42b/0x640 fs/dcache.c:612
 dentry_kill fs/dcache.c:733 [inline]
 dput+0x806/0xdb0 fs/dcache.c:913
 __fput+0x39c/0x9d0 fs/file_table.c:333
 task_work_run+0xdd/0x1a0 kernel/task_work.c:177
 ptrace_notify+0x114/0x140 kernel/signal.c:2353
 ptrace_report_syscall include/linux/ptrace.h:420 [inline]
 ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline]
 syscall_exit_work kernel/entry/common.c:249 [inline]
 syscall_exit_to_user_mode_prepare+0x129/0x280 kernel/entry/common.c:276
 __syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline]
 syscall_exit_to_user_mode+0x9/0x50 kernel/entry/common.c:294
 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fc1c0c35b6b
Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 
63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 
44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44
RSP: 002b:7ffd78a06090 EFLAGS: 0293 ORIG_RAX: 0003
RAX:  RBX: 0007 RCX: 7fc1c0c35b6b
RDX: 2280 RSI: 40086200 RDI: 0006
RBP: 0007 R08:  R09: 
R10:  R11: 0293 R12: 000c
R13: 0003 R14: 7fc1c0cfe4a0 R15: 7ffd78a06140
 
Modules linked in:
---[ end trace  ]---
RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline]
RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline]
RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 04 00 00 48 8d 7d 0c 4c 8b 63 
30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 
e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 e2
RSP: 0018:c900037efd30 EFLAGS: 00010246
RAX: dc00 RBX: 8cb67800 RCX: 
RDX:  RSI: 84ad27e0 RDI: 
RBP: fff4 R08: 0005 R09: 
R10:  R11: 0008c07c R12: 88801fa05000
R13: 888073db07e8 R14: 888025c25440 R15: 
FS:  55fc4300() GS:8880b9b0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 564b46eeb2c8 CR3: 715e6000 CR4: 003506e0
DR0: 

Re: [PATCH 2/2] [WIP]: media: Add Synaptics compressed tiled format

2022-08-18 Thread Hsia-Jun Li




On 8/19/22 07:13, Laurent Pinchart wrote:

CAUTION: Email originated externally, do not click links or open attachments 
unless you recognize the sender and know the content is safe.


On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:

On 8/18/22 14:06, Tomasz Figa wrote:

On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li  wrote:


From: "Hsia-Jun(Randy) Li" 

The most of detail has been written in the drm.


This patch still needs a description of the format, which should go to
Documentation/userspace-api/media/v4l/.


I just want t tell people we need an extra plane for MVTP and I don't 
have enough space here to place all the pixel formats.


Besides, I was thinking a modifer in v4l2_ext_pix_format is not enough.
Let's take a compression NV12 tile format as an example, we need
1. luma planes
2. chroma planes
3. compression meta data for luma
4. compression meta data for chroma
5. mvtp
and a single data planer version would be
1. luma and chroma data
2. compression meta data
3. mvtp

You see, we actually have 3 kind of data here(not including the 
compression options that I am thinking of storing them somewhere else).



Please notice that the tiled formats here request
one more plane for storing the motion vector metadata.
This buffer won't be compressed, so you can't append
it to luma or chroma plane.


Does the motion vector buffer need to be exposed to userspace? Is the
decoder stateless (requires userspace to specify the reference frames)
or stateful (manages the entire decoding process internally)?


No, users don't need to access them at all. Just they need a different
dma-heap.

You would only get the stateful version of both encoder and decoder.


Shouldn't the motion vectors be stored in a separate V4L2 buffer,
submitted through a different queue then ?

Yes, I like that.
Proposal: A third buffer type for the reconstruction buffers in V4L2 M2M 
encoder

https://www.spinics.net/lists/linux-media/msg214565.html

Although the major usage for the decoder here is producing the non-tile 
buffers, the decoder of us could product the NV12 or the pixel formats 
that GPU likes, but it must happen at the same time a frame is decoded.
Still the reference buffer or we call them the real decoded frame would 
stay in a tiled format. More than one queue would be need here.



Signed-off-by: Hsia-Jun(Randy) Li 
---
   drivers/media/v4l2-core/v4l2-common.c | 1 +
   drivers/media/v4l2-core/v4l2-ioctl.c  | 2 ++
   include/uapi/linux/videodev2.h| 2 ++
   3 files changed, 5 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-common.c 
b/drivers/media/v4l2-core/v4l2-common.c
index e0fbe6ba4b6c..f645278b3055 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -314,6 +314,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
  { .format = V4L2_PIX_FMT_SGBRG12,   .pixel_enc = 
V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 0 }, 
.hdiv = 1, .vdiv = 1 },
  { .format = V4L2_PIX_FMT_SGRBG12,   .pixel_enc = 
V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 0 }, 
.hdiv = 1, .vdiv = 1 },
  { .format = V4L2_PIX_FMT_SRGGB12,   .pixel_enc = 
V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 0 }, 
.hdiv = 1, .vdiv = 1 },
+   { .format = V4L2_PIX_FMT_NV12M_V4H1C, .pixel_enc = 
V4L2_PIXEL_ENC_YUV, .mem_planes = 5, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, 
.hdiv = 2, .vdiv = 2, .block_w = { 128, 128 }, .block_h = { 128, 128 } },
  };
  unsigned int i;

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e6fd355a2e92..8f65964aff08 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1497,6 +1497,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
  case V4L2_PIX_FMT_MT21C:descr = "Mediatek Compressed 
Format"; break;
  case V4L2_PIX_FMT_QC08C:descr = "QCOM Compressed 8-bit 
Format"; break;
  case V4L2_PIX_FMT_QC10C:descr = "QCOM Compressed 10-bit 
Format"; break;
+   case V4L2_PIX_FMT_NV12M_V4H1C:  descr = "Synaptics Compressed 8-bit 
tiled Format";break;
+   case V4L2_PIX_FMT_NV12M_10_V4H3P8C: descr = "Synaptics 
Compressed 10-bit tiled Format";break;
  default:
  if (fmt->description[0])
  return;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 01e630f2ec78..7e928cb69e7c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -661,6 +661,8 @@ struct v4l2_pix_format {
   #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
Y/CbCr 4:2:0 16x16 tiles */
   #define V4L2_PIX_FMT_NV12M_8L128  v4l2_fourcc('N', 'A', '1', '2') /* 
Y/CbCr 4:2:0 8x128 

[PATCH v2 20/21] drm/i915/mtl: Update CHICKEN_TRANS* register addresses

2022-08-18 Thread Radhakrishna Sripada
From: Madhumitha Tolakanahalli Pradeep 


In Display version 14, Transcoder Chicken Registers are moved from DPRZ to DRPOS
to reduce register signal crossings for Unit Interface Optimization.

This patch modifies the CHICKEN_TRANS macro to add a DISPLAY_VER check for
calculating the correct platform offsets.

(And also updates existing CHICKEN_TRANS occurrences to the new definition)

v2: Omit display version check in i915_reg.h(Jani)

Bspec: 34387, 50054
Cc: Jani Nikula 
Signed-off-by: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_display.c | 14 ---
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  5 +++-
 drivers/gpu/drm/i915/display/intel_psr.c |  6 +++--
 drivers/gpu/drm/i915/i915_reg.h  | 25 +++-
 4 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 533fff79aeda..52570d1eb72e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -618,7 +618,10 @@ void intel_disable_transcoder(const struct 
intel_crtc_state *old_crtc_state)
if (!IS_I830(dev_priv))
val &= ~PIPECONF_ENABLE;
 
-   if (DISPLAY_VER(dev_priv) >= 12)
+   if (DISPLAY_VER(dev_priv) >= 14)
+   intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(cpu_transcoder),
+FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
+   else if (DISPLAY_VER(dev_priv) >= 12)
intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder),
 FECSTALL_DIS_DPTSTREAM_DPTTG, 0);
 
@@ -1838,7 +1841,9 @@ static void hsw_set_frame_start_delay(const struct 
intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   i915_reg_t reg = CHICKEN_TRANS(crtc_state->cpu_transcoder);
+   enum transcoder transcoder = crtc_state->cpu_transcoder;
+   i915_reg_t reg = DISPLAY_VER(dev_priv) >= 14 ? 
MTL_CHICKEN_TRANS(transcoder) :
+CHICKEN_TRANS(transcoder);
u32 val;
 
val = intel_de_read(dev_priv, reg);
@@ -4033,6 +4038,7 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_display_power_domain_set power_domain_set = { };
+   i915_reg_t reg;
bool active;
u32 tmp;
 
@@ -4124,7 +4130,9 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
}
 
if (!transcoder_is_dsi(pipe_config->cpu_transcoder)) {
-   tmp = intel_de_read(dev_priv, 
CHICKEN_TRANS(pipe_config->cpu_transcoder));
+   reg = DISPLAY_VER(dev_priv) >= 14 ? 
MTL_CHICKEN_TRANS(pipe_config->cpu_transcoder) :
+   CHICKEN_TRANS(pipe_config->cpu_transcoder);
+   tmp = intel_de_read(dev_priv, reg);
 
pipe_config->framestart_delay = 
REG_FIELD_GET(HSW_FRAME_START_DELAY_MASK, tmp) + 1;
} else {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 14d2a64193b2..a987e88c00d4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -590,7 +590,10 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
 
drm_dp_update_payload_part2(_dp->mst_mgr);
 
-   if (DISPLAY_VER(dev_priv) >= 12 && pipe_config->fec_enable)
+   if (DISPLAY_VER(dev_priv) >= 14 && pipe_config->fec_enable)
+   intel_de_rmw(dev_priv, MTL_CHICKEN_TRANS(trans), 0,
+FECSTALL_DIS_DPTSTREAM_DPTTG);
+   else if (DISPLAY_VER(dev_priv) >= 12 && pipe_config->fec_enable)
intel_de_rmw(dev_priv, CHICKEN_TRANS(trans), 0,
 FECSTALL_DIS_DPTSTREAM_DPTTG);
 
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 98c3c8015a5c..15e649269fa1 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1139,7 +1139,8 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 
if (intel_dp->psr.psr2_enabled) {
if (DISPLAY_VER(dev_priv) == 9)
-   intel_de_rmw(dev_priv, CHICKEN_TRANS(cpu_transcoder), 0,
+   intel_de_rmw(dev_priv,
+CHICKEN_TRANS(cpu_transcoder), 0,
 PSR2_VSC_ENABLE_PROG_HEADER |
 PSR2_ADD_VERTICAL_LINE_COUNT);
 
@@ -1149,7 +1150,8 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 * cause issues if non-supported panels are used.
 */
if (IS_ALDERLAKE_P(dev_priv))
-   

[PATCH v2 17/21] drm/i915/mtl: Update MBUS_DBOX credits

2022-08-18 Thread Radhakrishna Sripada
Display version 14 platforms have different credits values compared to ADL-P.
Update the credits based on pipe usage.

v2: Simplify DBOX BW Credit definition(MattR)

Bspec: 49213

Cc: Jose Roberto de Souza 
Cc: Matt Roper 
Original Author: Caz Yokoyama
Signed-off-by: José Roberto de Souza 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/i915_reg.h |  4 +++
 drivers/gpu/drm/i915/intel_pm.c | 47 ++---
 2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5245af8d0ea8..b2b06c080d09 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1125,8 +1125,12 @@
 #define MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN REG_BIT(16) /* tgl+ */
 #define MBUS_DBOX_BW_CREDIT_MASK   REG_GENMASK(15, 14)
 #define MBUS_DBOX_BW_CREDIT(x) 
REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, x)
+#define MBUS_DBOX_BW_4CREDITS_MTL  
REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 0x2)
+#define MBUS_DBOX_BW_8CREDITS_MTL  
REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 0x3)
 #define MBUS_DBOX_B_CREDIT_MASKREG_GENMASK(12, 8)
 #define MBUS_DBOX_B_CREDIT(x)  
REG_FIELD_PREP(MBUS_DBOX_B_CREDIT_MASK, x)
+#define MBUS_DBOX_I_CREDIT_MASKREG_GENMASK(7, 5)
+#define MBUS_DBOX_I_CREDIT(x)  
REG_FIELD_PREP(MBUS_DBOX_I_CREDIT_MASK, x)
 #define MBUS_DBOX_A_CREDIT_MASKREG_GENMASK(3, 0)
 #define MBUS_DBOX_A_CREDIT(x)  
REG_FIELD_PREP(MBUS_DBOX_A_CREDIT_MASK, x)
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f71b3b8b590c..5cdc2ce4f42b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8443,6 +8443,27 @@ void intel_dbuf_post_plane_update(struct 
intel_atomic_state *state)
new_dbuf_state->enabled_slices);
 }
 
+static bool xelpdp_is_one_pipe_per_dbuf_bank(enum pipe pipe, u8 active_pipes)
+{
+   switch (pipe) {
+   case PIPE_A:
+   case PIPE_D:
+   if (is_power_of_2(active_pipes & (BIT(PIPE_A) | BIT(PIPE_D
+   return true;
+   break;
+   case PIPE_B:
+   case PIPE_C:
+   if (is_power_of_2(active_pipes & (BIT(PIPE_B) | BIT(PIPE_C
+   return true;
+   break;
+   default: /* to suppress compiler warning */
+   MISSING_CASE(pipe);
+   break;
+   }
+
+   return false;
+}
+
 void intel_mbus_dbox_update(struct intel_atomic_state *state)
 {
struct drm_i915_private *i915 = to_i915(state->base.dev);
@@ -8462,20 +8483,28 @@ void intel_mbus_dbox_update(struct intel_atomic_state 
*state)
 new_dbuf_state->active_pipes == old_dbuf_state->active_pipes))
return;
 
+   if (DISPLAY_VER(i915) >= 14)
+   val |= MBUS_DBOX_I_CREDIT(2);
+
if (DISPLAY_VER(i915) >= 12) {
val |= MBUS_DBOX_B2B_TRANSACTIONS_MAX(16);
val |= MBUS_DBOX_B2B_TRANSACTIONS_DELAY(1);
val |= MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN;
}
 
-   /* Wa_22010947358:adl-p */
-   if (IS_ALDERLAKE_P(i915))
+   if (DISPLAY_VER(i915) >= 14)
+   val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(12) :
+MBUS_DBOX_A_CREDIT(8);
+   else if (IS_ALDERLAKE_P(i915))
+   /* Wa_22010947358:adl-p */
val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
 MBUS_DBOX_A_CREDIT(4);
else
val |= MBUS_DBOX_A_CREDIT(2);
 
-   if (IS_ALDERLAKE_P(i915)) {
+   if (DISPLAY_VER(i915) >= 14) {
+   val |= MBUS_DBOX_B_CREDIT(0xA);
+   } else if (IS_ALDERLAKE_P(i915)) {
val |= MBUS_DBOX_BW_CREDIT(2);
val |= MBUS_DBOX_B_CREDIT(8);
} else if (DISPLAY_VER(i915) >= 12) {
@@ -8487,10 +8516,20 @@ void intel_mbus_dbox_update(struct intel_atomic_state 
*state)
}
 
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+   u32 pipe_val = val;
+
if (!new_crtc_state->hw.active ||
!intel_crtc_needs_modeset(new_crtc_state))
continue;
 
-   intel_de_write(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe), val);
+   if (DISPLAY_VER(i915) >= 14) {
+   if (xelpdp_is_one_pipe_per_dbuf_bank(crtc->pipe,
+
new_dbuf_state->active_pipes))
+   pipe_val |= MBUS_DBOX_BW_8CREDITS_MTL;
+   else
+   pipe_val |= MBUS_DBOX_BW_4CREDITS_MTL;
+   }
+
+   intel_de_write(i915, 

[PATCH v2 19/21] drm/i915/display/mtl: Extend MBUS programming

2022-08-18 Thread Radhakrishna Sripada
From: José Roberto de Souza 

Display version 14 also supports MBUS joining just like ADL-P
and also it does not need MBUS initialization, so extending ADL-P
code paths to display version 14 and higher.

Bspec: 49213

Reviewed-by: Matt Roper 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 9c1fefb2da55..439d56c3814f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1102,7 +1102,7 @@ static void icl_mbus_init(struct drm_i915_private 
*dev_priv)
unsigned long abox_regs = INTEL_INFO(dev_priv)->display.abox_mask;
u32 mask, val, i;
 
-   if (IS_ALDERLAKE_P(dev_priv))
+   if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
return;
 
mask = MBUS_ABOX_BT_CREDIT_POOL1_MASK |
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ebddde200bc..2d658ddcf3c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1360,7 +1360,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
  IS_ALDERLAKE_S(dev_priv))
 
-#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915))
+#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 
14)
 
 #define HAS_3D_PIPELINE(i915)  (INTEL_INFO(i915)->has_3d_pipeline)
 
-- 
2.25.1



[PATCH v2 10/21] drm/i915/mtl: Add display power wells

2022-08-18 Thread Radhakrishna Sripada
From: Imre Deak 

Add support for display power wells on MTL. The differences from XE_LPD:
- The AUX HW block is moved to the PICA block, where the registers are on
  an always-on power well and the functionality needs to be powered on/off
  via the AUX_CH_CTL register: [1], [2]
- The DDI IO power on/off programming sequence is moved to the PHY PLL
  enable/disable sequence. [3], [4], [5]

Bspec: [1] 49233, [2] 65247, [3] 64568, [4] 65451, [5] 65450

v2:
 - Update the comment in aux power well enable
 - Reuse the noop sync fn for aux sync.
 - Use REG_BIT for new register bit definitions

Signed-off-by: Imre Deak 
Signed-off-by: Radhakrishna Sripada 
---
 .../i915/display/intel_display_power_map.c| 115 +-
 .../i915/display/intel_display_power_well.c   |  44 +++
 .../i915/display/intel_display_power_well.h   |   4 +
 drivers/gpu/drm/i915/display/intel_dp_aux.c   |   8 ++
 drivers/gpu/drm/i915/i915_reg.h   |  21 
 5 files changed, 191 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c 
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 97b367f39f35..cd28976f8076 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1350,6 +1350,117 @@ static const struct i915_power_well_desc_list 
xelpd_power_wells[] = {
I915_PW_DESCRIPTORS(xelpd_power_wells_main),
 };
 
+/*
+ * MTL is based on XELPD power domains with the exception of power gating for:
+ * - DDI_IO (moved to PLL logic)
+ * - AUX and AUX_IO functionality and register access for USBC1-4 (PICA 
always-on)
+ */
+#define XELPDP_PW_2_POWER_DOMAINS \
+   XELPD_PW_B_POWER_DOMAINS, \
+   XELPD_PW_C_POWER_DOMAINS, \
+   XELPD_PW_D_POWER_DOMAINS, \
+   POWER_DOMAIN_AUDIO_PLAYBACK, \
+   POWER_DOMAIN_VGA, \
+   POWER_DOMAIN_PORT_DDI_LANES_TC1, \
+   POWER_DOMAIN_PORT_DDI_LANES_TC2, \
+   POWER_DOMAIN_PORT_DDI_LANES_TC3, \
+   POWER_DOMAIN_PORT_DDI_LANES_TC4
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_pw_2,
+   XELPDP_PW_2_POWER_DOMAINS,
+   POWER_DOMAIN_INIT);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_dc_off,
+   XELPDP_PW_2_POWER_DOMAINS,
+   POWER_DOMAIN_AUDIO_MMIO,
+   POWER_DOMAIN_MODESET,
+   POWER_DOMAIN_AUX_A,
+   POWER_DOMAIN_AUX_B,
+   POWER_DOMAIN_INIT);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc1,
+   POWER_DOMAIN_AUX_USBC1,
+   POWER_DOMAIN_AUX_TBT1);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc2,
+   POWER_DOMAIN_AUX_USBC2,
+   POWER_DOMAIN_AUX_TBT2);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc3,
+   POWER_DOMAIN_AUX_USBC3,
+   POWER_DOMAIN_AUX_TBT3);
+
+I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc4,
+   POWER_DOMAIN_AUX_USBC4,
+   POWER_DOMAIN_AUX_TBT4);
+
+static const struct i915_power_well_desc xelpdp_power_wells_main[] = {
+   {
+   .instances = _PW_INSTANCES(
+   I915_PW("DC_off", _pwdoms_dc_off,
+   .id = SKL_DISP_DC_OFF),
+   ),
+   .ops = _dc_off_power_well_ops,
+   }, {
+   .instances = _PW_INSTANCES(
+   I915_PW("PW_2", _pwdoms_pw_2,
+   .hsw.idx = ICL_PW_CTL_IDX_PW_2,
+   .id = SKL_DISP_PW_2),
+   ),
+   .ops = _power_well_ops,
+   .has_vga = true,
+   .has_fuses = true,
+   }, {
+   .instances = _PW_INSTANCES(
+   I915_PW("PW_A", _pwdoms_pw_a,
+   .hsw.idx = XELPD_PW_CTL_IDX_PW_A),
+   ),
+   .ops = _power_well_ops,
+   .irq_pipe_mask = BIT(PIPE_A),
+   .has_fuses = true,
+   }, {
+   .instances = _PW_INSTANCES(
+   I915_PW("PW_B", _pwdoms_pw_b,
+   .hsw.idx = XELPD_PW_CTL_IDX_PW_B),
+   ),
+   .ops = _power_well_ops,
+   .irq_pipe_mask = BIT(PIPE_B),
+   .has_fuses = true,
+   }, {
+   .instances = _PW_INSTANCES(
+   I915_PW("PW_C", _pwdoms_pw_c,
+   .hsw.idx = XELPD_PW_CTL_IDX_PW_C),
+   ),
+   .ops = _power_well_ops,
+   .irq_pipe_mask = BIT(PIPE_C),
+   .has_fuses = true,
+   }, {
+   .instances = _PW_INSTANCES(
+   I915_PW("PW_D", _pwdoms_pw_d,
+   .hsw.idx = XELPD_PW_CTL_IDX_PW_D),
+   ),
+   .ops = _power_well_ops,
+   .irq_pipe_mask = BIT(PIPE_D),
+   .has_fuses = true,
+   }, {
+   .instances = _PW_INSTANCES(
+   I915_PW("AUX_A", _pwdoms_aux_a, .xelpdp.aux_ch = 
AUX_CH_A),
+   I915_PW("AUX_B", _pwdoms_aux_b, .xelpdp.aux_ch = 
AUX_CH_B),
+ 

[PATCH v2 18/21] drm/i915/mtl: Reuse adl-p DBUF calculations

2022-08-18 Thread Radhakrishna Sripada
Meteorlake uses a similar DBUF calculations as ADL-P.
Reuse the call flow for meteorlake.

Bspec: 49255

Original Author: Caz Yokoyama
Reviewed-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5cdc2ce4f42b..d09e9e5f4481 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4934,7 +4934,7 @@ static u8 skl_compute_dbuf_slices(struct intel_crtc 
*crtc, u8 active_pipes, bool
 
if (IS_DG2(dev_priv))
return dg2_compute_dbuf_slices(pipe, active_pipes, join_mbus);
-   else if (IS_ALDERLAKE_P(dev_priv))
+   else if (DISPLAY_VER(dev_priv) >= 13)
return adlp_compute_dbuf_slices(pipe, active_pipes, join_mbus);
else if (DISPLAY_VER(dev_priv) == 12)
return tgl_compute_dbuf_slices(pipe, active_pipes, join_mbus);
-- 
2.25.1



[PATCH v2 11/21] drm/i915/mtl: Add DP AUX support on TypeC ports

2022-08-18 Thread Radhakrishna Sripada
From: Imre Deak 

On MTL TypeC ports the AUX_CH_CTL and AUX_CH_DATA addresses have
changed wrt. previous platforms, adjust the code accordingly.

Signed-off-by: Imre Deak 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 45 -
 drivers/gpu/drm/i915/i915_reg.h |  9 +
 2 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 40c4bdd9cb26..10616e18dc18 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -637,6 +637,46 @@ static i915_reg_t tgl_aux_data_reg(struct intel_dp 
*intel_dp, int index)
}
 }
 
+static i915_reg_t xelpdp_aux_ctl_reg(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   enum aux_ch aux_ch = dig_port->aux_ch;
+
+   switch (aux_ch) {
+   case AUX_CH_A:
+   case AUX_CH_B:
+   case AUX_CH_USBC1:
+   case AUX_CH_USBC2:
+   case AUX_CH_USBC3:
+   case AUX_CH_USBC4:
+   return XELPDP_DP_AUX_CH_CTL(aux_ch);
+   default:
+   MISSING_CASE(aux_ch);
+   return XELPDP_DP_AUX_CH_CTL(AUX_CH_A);
+   }
+}
+
+static i915_reg_t xelpdp_aux_data_reg(struct intel_dp *intel_dp, int index)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   enum aux_ch aux_ch = dig_port->aux_ch;
+
+   switch (aux_ch) {
+   case AUX_CH_A:
+   case AUX_CH_B:
+   case AUX_CH_USBC1:
+   case AUX_CH_USBC2:
+   case AUX_CH_USBC3:
+   case AUX_CH_USBC4:
+   return XELPDP_DP_AUX_CH_DATA(aux_ch, index);
+   default:
+   MISSING_CASE(aux_ch);
+   return XELPDP_DP_AUX_CH_DATA(AUX_CH_A, index);
+   }
+}
+
 void intel_dp_aux_fini(struct intel_dp *intel_dp)
 {
if (cpu_latency_qos_request_active(_dp->pm_qos))
@@ -652,7 +692,10 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
struct intel_encoder *encoder = _port->base;
enum aux_ch aux_ch = dig_port->aux_ch;
 
-   if (DISPLAY_VER(dev_priv) >= 12) {
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   intel_dp->aux_ch_ctl_reg = xelpdp_aux_ctl_reg;
+   intel_dp->aux_ch_data_reg = xelpdp_aux_data_reg;
+   } else if (DISPLAY_VER(dev_priv) >= 12) {
intel_dp->aux_ch_ctl_reg = tgl_aux_ctl_reg;
intel_dp->aux_ch_data_reg = tgl_aux_data_reg;
} else if (DISPLAY_VER(dev_priv) >= 9) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 234c17596c3a..04a269fa8717 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3533,6 +3533,15 @@
   
_XELPDP_USBC3_AUX_CH_CTL, \
   
_XELPDP_USBC4_AUX_CH_CTL))
 
+#define XELPDP_DP_AUX_CH_DATA(aux_ch, i)   _MMIO(_PICK(aux_ch, \
+  _DPA_AUX_CH_DATA1, \
+  _DPB_AUX_CH_DATA1, \
+  0, /* port/aux_ch C is 
non-existent */ \
+  
_XELPDP_USBC1_AUX_CH_DATA1, \
+  
_XELPDP_USBC2_AUX_CH_DATA1, \
+  
_XELPDP_USBC3_AUX_CH_DATA1, \
+  
_XELPDP_USBC4_AUX_CH_DATA1) + (i) * 4)
+
 #define   DP_AUX_CH_CTL_SEND_BUSY  (1 << 31)
 #define   DP_AUX_CH_CTL_DONE   (1 << 30)
 #define   DP_AUX_CH_CTL_INTERRUPT  (1 << 29)
-- 
2.25.1



[PATCH v2 14/21] drm/i915/mtl: memory latency data from LATENCY_LPX_LPY for WM

2022-08-18 Thread Radhakrishna Sripada
Since Xe LPD+, Memory latency data are in LATENCY_LPX_LPY registers
instead of GT driver mailbox.

v2: Use the extracted wm latency adjustment function(Matt)

Bspec: 64608

Cc: Matt Roper 
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/i915_reg.h |  7 +++
 drivers/gpu/drm/i915/intel_pm.c | 21 ++---
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 04a269fa8717..b2d5e1230c25 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8390,4 +8390,11 @@ enum skl_power_gate {
 #define GEN12_STATE_ACK_DEBUG  _MMIO(0x20BC)
 
 #define MTL_MEDIA_GSI_BASE 0x38
+
+#define MTL_LATENCY_LP0_LP1_MMIO(0x45780)
+#define MTL_LATENCY_LP2_LP3_MMIO(0x45784)
+#define MTL_LATENCY_LP4_LP5_MMIO(0x45788)
+#define  MTL_LATENCY_LEVEL0_2_4_MASK   REG_GENMASK(12, 0)
+#define  MTL_LATENCY_LEVEL1_3_5_MASK   REG_GENMASK(28, 16)
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 898e56d2eaf7..fac565d23d57 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2908,13 +2908,28 @@ static void intel_read_wm_latency(struct 
drm_i915_private *dev_priv,
  u16 wm[])
 {
struct intel_uncore *uncore = _priv->uncore;
+   int max_level = ilk_wm_max_level(dev_priv);
 
-   if (DISPLAY_VER(dev_priv) >= 9) {
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   u32 val;
+
+   val = intel_uncore_read(uncore, MTL_LATENCY_LP0_LP1);
+   wm[0] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
+   wm[1] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
+   val = intel_uncore_read(uncore, MTL_LATENCY_LP2_LP3);
+   wm[2] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
+   wm[3] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
+   val = intel_uncore_read(uncore, MTL_LATENCY_LP4_LP5);
+   wm[4] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
+   wm[5] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
+
+   adjust_wm_latency(wm, max_level, 6,
+ dev_priv->dram_info.wm_lv_0_adjust_needed);
+   } else if (DISPLAY_VER(dev_priv) >= 9) {
int read_latency = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
+   int mult = IS_DG2(dev_priv) ? 2 : 1;
u32 val;
int ret;
-   int max_level = ilk_wm_max_level(dev_priv);
-   int mult = IS_DG2(dev_priv) ? 2 : 1;
 
/* read the first set of memory latencies[0:3] */
val = 0; /* data0 to be programmed to 0 for first set */
-- 
2.25.1



[PATCH v2 16/21] drm/i915/mtl: Update memory bandwidth parameters

2022-08-18 Thread Radhakrishna Sripada
Like ADL_P, Meteorlake has different memory characteristics from
past platforms. Update the values used by our memory bandwidth
calculations accordingly.

Bspec: 64631

Reviewed-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 40 +++--
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 46b63afd536a..0182f0948fb9 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -183,7 +183,32 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
qi->num_points = dram_info->num_qgv_points;
qi->num_psf_points = dram_info->num_psf_gv_points;
 
-   if (DISPLAY_VER(dev_priv) >= 12)
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   switch (dram_info->type) {
+   case INTEL_DRAM_DDR4:
+   qi->t_bl = 4;
+   qi->max_numchannels = 2;
+   qi->channel_width = 64;
+   qi->deinterleave = 2;
+   break;
+   case INTEL_DRAM_DDR5:
+   qi->t_bl = 8;
+   qi->max_numchannels = 4;
+   qi->channel_width = 32;
+   qi->deinterleave = 2;
+   break;
+   case INTEL_DRAM_LPDDR4:
+   case INTEL_DRAM_LPDDR5:
+   qi->t_bl = 16;
+   qi->max_numchannels = 8;
+   qi->channel_width = 16;
+   qi->deinterleave = 4;
+   break;
+   default:
+   MISSING_CASE(dram_info->type);
+   return -EINVAL;
+   }
+   } else if (DISPLAY_VER(dev_priv) >= 12) {
switch (dram_info->type) {
case INTEL_DRAM_DDR4:
qi->t_bl = is_y_tile ? 8 : 4;
@@ -217,7 +242,7 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
qi->max_numchannels = 1;
break;
}
-   else if (DISPLAY_VER(dev_priv) == 11) {
+   } else if (DISPLAY_VER(dev_priv) == 11) {
qi->t_bl = dev_priv->dram_info.type == INTEL_DRAM_DDR4 ? 4 : 8;
qi->max_numchannels = 1;
}
@@ -316,6 +341,13 @@ static const struct intel_sa_info adlp_sa_info = {
.derating = 20,
 };
 
+static const struct intel_sa_info mtl_sa_info = {
+   .deburst = 32,
+   .deprogbwlimit = 38, /* GB/s */
+   .displayrtids = 256,
+   .derating = 20,
+};
+
 static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct 
intel_sa_info *sa)
 {
struct intel_qgv_info qi = {};
@@ -590,7 +622,9 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
-   if (IS_DG2(dev_priv))
+   if (DISPLAY_VER(dev_priv) >= 14)
+   tgl_get_bw_info(dev_priv, _sa_info);
+   else if (IS_DG2(dev_priv))
dg2_get_bw_info(dev_priv);
else if (IS_ALDERLAKE_P(dev_priv))
tgl_get_bw_info(dev_priv, _sa_info);
-- 
2.25.1



[PATCH v2 21/21] drm/i915/mtl: Do not update GV point, mask value

2022-08-18 Thread Radhakrishna Sripada
No need to update mask value/restrict because
"Pcode only wants to use GV bandwidth value, not the mask value."
for Display version greater than 14.

Bspec: 646365
Cc: Matt Roper 
Original Author: Caz Yokoyama
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d09e9e5f4481..47869fe964ba 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3924,6 +3924,14 @@ void intel_sagv_pre_plane_update(struct 
intel_atomic_state *state)
 {
struct drm_i915_private *i915 = to_i915(state->base.dev);
 
+   /*
+* No need to update mask value/restrict because
+* "Pcode only wants to use GV bandwidth value, not the mask value."
+* for DISPLAY_VER() >= 14.
+*/
+   if (DISPLAY_VER(i915) >= 14)
+   return;
+
/*
 * Just return if we can't control SAGV or don't have it.
 * This is different from situation when we have SAGV but just can't
@@ -3944,6 +3952,16 @@ void intel_sagv_post_plane_update(struct 
intel_atomic_state *state)
 {
struct drm_i915_private *i915 = to_i915(state->base.dev);
 
+   /*
+* No need to update mask value/restrict because
+* "Pcode only wants to use GV bandwidth value, not the mask value."
+* for DISPLAY_VER() >= 14.
+*
+* GV bandwidth will be set by intel_pmdemand_post_plane_update()
+*/
+   if (DISPLAY_VER(i915) >= 14)
+   return;
+
/*
 * Just return if we can't control SAGV or don't have it.
 * This is different from situation when we have SAGV but just can't
-- 
2.25.1



[PATCH v2 12/21] drm/i915/mtl: Fix rawclk for Meteorlake PCH

2022-08-18 Thread Radhakrishna Sripada
From: Clint Taylor 

MTL has a fixed rawclk of 38400Khz. Register does not need to be
reprogrammed.

Bspec: 49304

Reviewed-by: Matt Roper 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 86a22c3766e5..1ee61abd40bc 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -3036,6 +3036,13 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
 
if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
freq = dg1_rawclk(dev_priv);
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTP)
+   /*
+* MTL always uses a 38.4 MHz rawclk.  The bspec tells us
+* "RAWCLK_FREQ defaults to the values for 38.4 and does
+* not need to be programmed."
+*/
+   freq = 38400;
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
-- 
2.25.1



[PATCH v2 13/21] drm/i915: Extract wm latency adjustment to its own function

2022-08-18 Thread Radhakrishna Sripada
Watermark latency is adjusted in cases when latency is 0us for level
greater than 1, the subsequent levels are disabled. Extract this logic
into its own function.

Suggested-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_pm.c | 88 ++---
 1 file changed, 48 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ef7553b494ea..898e56d2eaf7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2861,15 +2861,59 @@ static void ilk_compute_wm_level(const struct 
drm_i915_private *dev_priv,
result->enable = true;
 }
 
+static void
+adjust_wm_latency(u16 wm[], int max_level, int read_latency,
+ bool wm_lv_0_adjust_needed)
+{
+   int i, level;
+
+   /*
+* If a level n (n > 1) has a 0us latency, all levels m (m >= n)
+* need to be disabled. We make sure to sanitize the values out
+* of the punit to satisfy this requirement.
+*/
+   for (level = 1; level <= max_level; level++) {
+   if (wm[level] == 0) {
+   for (i = level + 1; i <= max_level; i++)
+   wm[i] = 0;
+
+   max_level = level - 1;
+   break;
+   }
+   }
+
+   /*
+* WaWmMemoryReadLatency
+*
+* punit doesn't take into account the read latency so we need
+* to add proper adjustement to each valid level we retrieve
+* from the punit when level 0 response data is 0us.
+*/
+   if (wm[0] == 0) {
+   for (level = 0; level <= max_level; level++)
+   wm[level] += read_latency;
+   }
+
+   /*
+* WA Level-0 adjustment for 16GB DIMMs: SKL+
+* If we could not get dimm info enable this WA to prevent from
+* any underrun. If not able to get Dimm info assume 16GB dimm
+* to avoid any underrun.
+*/
+   if (wm_lv_0_adjust_needed)
+   wm[0] += 1;
+}
+
 static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
  u16 wm[])
 {
struct intel_uncore *uncore = _priv->uncore;
 
if (DISPLAY_VER(dev_priv) >= 9) {
+   int read_latency = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
u32 val;
-   int ret, i;
-   int level, max_level = ilk_wm_max_level(dev_priv);
+   int ret;
+   int max_level = ilk_wm_max_level(dev_priv);
int mult = IS_DG2(dev_priv) ? 2 : 1;
 
/* read the first set of memory latencies[0:3] */
@@ -2909,44 +2953,8 @@ static void intel_read_wm_latency(struct 
drm_i915_private *dev_priv,
wm[7] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
 
-   /*
-* If a level n (n > 1) has a 0us latency, all levels m (m >= n)
-* need to be disabled. We make sure to sanitize the values out
-* of the punit to satisfy this requirement.
-*/
-   for (level = 1; level <= max_level; level++) {
-   if (wm[level] == 0) {
-   for (i = level + 1; i <= max_level; i++)
-   wm[i] = 0;
-
-   max_level = level - 1;
-
-   break;
-   }
-   }
-
-   /*
-* WaWmMemoryReadLatency
-*
-* punit doesn't take into account the read latency so we need
-* to add proper adjustement to each valid level we retrieve
-* from the punit when level 0 response data is 0us.
-*/
-   if (wm[0] == 0) {
-   u8 adjust = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
-
-   for (level = 0; level <= max_level; level++)
-   wm[level] += adjust;
-   }
-
-   /*
-* WA Level-0 adjustment for 16GB DIMMs: SKL+
-* If we could not get dimm info enable this WA to prevent from
-* any underrun. If not able to get Dimm info assume 16GB dimm
-* to avoid any underrun.
-*/
-   if (dev_priv->dram_info.wm_lv_0_adjust_needed)
-   wm[0] += 1;
+   adjust_wm_latency(wm, max_level, read_latency,
+ dev_priv->dram_info.wm_lv_0_adjust_needed);
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
 
-- 
2.25.1



[PATCH v2 03/21] drm/i915/mtl: MMIO range is now 4MB

2022-08-18 Thread Radhakrishna Sripada
From: Matt Roper 

Previously only dgfx platforms had a 4MB MMIO range, but starting with
MTL we now use the larger range for all platforms.

Bspec: 63834, 63830
Signed-off-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_uncore.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index a852c471d1b3..e0a8a8cb2052 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2232,14 +2232,15 @@ int intel_uncore_setup_mmio(struct intel_uncore 
*uncore, phys_addr_t phys_addr)
 * clobbering the GTT which we want ioremap_wc instead. Fortunately,
 * the register BAR remains the same size for all the earlier
 * generations up to Ironlake.
-* For dgfx chips register range is expanded to 4MB.
+* For dgfx chips register range is expanded to 4MB, and this larger
+* range is also used for integrated gpus beginning with Meteor Lake.
 */
-   if (GRAPHICS_VER(i915) < 5)
-   mmio_size = 512 * 1024;
-   else if (IS_DGFX(i915))
+   if (IS_DGFX(i915) || GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
mmio_size = 4 * 1024 * 1024;
-   else
+   else if (GRAPHICS_VER(i915) >= 5)
mmio_size = 2 * 1024 * 1024;
+   else
+   mmio_size = 512 * 1024;
 
uncore->regs = ioremap(phys_addr, mmio_size);
if (uncore->regs == NULL) {
-- 
2.25.1



[PATCH v2 05/21] drm/i915/mtl: Define engine context layouts

2022-08-18 Thread Radhakrishna Sripada
From: Matt Roper 

The part of the media and blitter engine contexts that we care about for
setting up an initial state are the same on MTL as they were on DG2
(and PVC), so we need to update the driver conditions to re-use the DG2
context table.

For render/compute engines, the part of the context images are nearly
the same, although the layout had a very slight change --- one POSH
register was removed and the placement of some LRI/noops adjusted
slightly to compensate.

Bspec: 46261, 46260, 45585
Signed-off-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 47 -
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index eec73c66406c..d3833cbaabcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -606,6 +606,49 @@ static const u8 dg2_rcs_offsets[] = {
END
 };
 
+static const u8 mtl_rcs_offsets[] = {
+   NOP(1),
+   LRI(15, POSTED),
+   REG16(0x244),
+   REG(0x034),
+   REG(0x030),
+   REG(0x038),
+   REG(0x03c),
+   REG(0x168),
+   REG(0x140),
+   REG(0x110),
+   REG(0x1c0),
+   REG(0x1c4),
+   REG(0x1c8),
+   REG(0x180),
+   REG16(0x2b4),
+   REG(0x120),
+   REG(0x124),
+
+   NOP(1),
+   LRI(9, POSTED),
+   REG16(0x3a8),
+   REG16(0x28c),
+   REG16(0x288),
+   REG16(0x284),
+   REG16(0x280),
+   REG16(0x27c),
+   REG16(0x278),
+   REG16(0x274),
+   REG16(0x270),
+
+   NOP(2),
+   LRI(2, POSTED),
+   REG16(0x5a8),
+   REG16(0x5ac),
+
+   NOP(6),
+   LRI(1, 0),
+   REG(0x0c8),
+
+   END
+};
+
 #undef END
 #undef REG16
 #undef REG
@@ -624,7 +667,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs 
*engine)
   !intel_engine_has_relative_mmio(engine));
 
if (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE) {
-   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
+   if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
+   return mtl_rcs_offsets;
+   else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
return dg2_rcs_offsets;
else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
return xehp_rcs_offsets;
-- 
2.25.1



[PATCH v2 02/21] drm/i915: Parse and set stepping for platforms with GMD

2022-08-18 Thread Radhakrishna Sripada
From: José Roberto de Souza 

The GMD step field do not properly match the current stepping convention
that we use(STEP_A0, STEP_A1, STEP_B0...).

One platform could have { arch = 12, rel = 70, step = 1 } and the
actual stepping is STEP_B0 but without the translation of the step
field would mean STEP_A1.
That is why we will need to have gmd_to_intel_step tables for each IP.

Signed-off-by: José Roberto de Souza 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_step.c | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index 42b3133d8387..0fa7147c7d0f 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -135,6 +135,48 @@ static const struct intel_step_info adlp_n_revids[] = {
[0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
 };
 
+struct gmd_to_intel_step {
+   struct ip_version gmd;
+   enum intel_step step;
+};
+
+static const struct gmd_to_intel_step gmd_graphics_table[] = {
+   { .gmd.ver = 12, .gmd.rel = 70, .gmd.step = 0, .step = STEP_A0 },
+   { .gmd.ver = 12, .gmd.rel = 70, .gmd.step = 4, .step = STEP_B0 },
+   { .gmd.ver = 12, .gmd.rel = 71, .gmd.step = 0, .step = STEP_A0 },
+   { .gmd.ver = 12, .gmd.rel = 71, .gmd.step = 4, .step = STEP_B0 },
+   { .gmd.ver = 12, .gmd.rel = 73, .gmd.step = 0, .step = STEP_A0 },
+   { .gmd.ver = 12, .gmd.rel = 73, .gmd.step = 4, .step = STEP_B0 },
+};
+
+static const struct gmd_to_intel_step gmd_media_table[] = {
+   { .gmd.ver = 13, .gmd.rel = 70, .gmd.step = 0, .step = STEP_A0 },
+   { .gmd.ver = 13, .gmd.rel = 70, .gmd.step = 4, .step = STEP_B0 },
+};
+
+static const struct gmd_to_intel_step gmd_display_table[] = {
+   { .gmd.ver = 14, .gmd.rel = 0, .gmd.step = 0, .step = STEP_A0 },
+   { .gmd.ver = 14, .gmd.rel = 0, .gmd.step = 4, .step = STEP_B0 },
+};
+
+static u8 gmd_to_intel_step(struct drm_i915_private *i915,
+   struct ip_version *gmd,
+   const struct gmd_to_intel_step *table,
+   int len)
+{
+   int i;
+
+   for (i = 0; i < len; i++) {
+   if (table[i].gmd.ver == gmd->ver &&
+   table[i].gmd.rel == gmd->rel &&
+   table[i].gmd.step == gmd->step)
+   return table[i].step;
+   }
+
+   drm_dbg(>drm, "Using future steppings\n");
+   return STEP_FUTURE;
+}
+
 static void pvc_step_init(struct drm_i915_private *i915, int pci_revid);
 
 void intel_step_init(struct drm_i915_private *i915)
@@ -144,6 +186,24 @@ void intel_step_init(struct drm_i915_private *i915)
int revid = INTEL_REVID(i915);
struct intel_step_info step = {};
 
+   if (HAS_GMD_ID(i915)) {
+   step.graphics_step = gmd_to_intel_step(i915,
+  
_INFO(i915)->graphics,
+  gmd_graphics_table,
+  
ARRAY_SIZE(gmd_graphics_table));
+   step.media_step = gmd_to_intel_step(i915,
+   _INFO(i915)->media,
+   gmd_media_table,
+   
ARRAY_SIZE(gmd_media_table));
+   step.display_step = gmd_to_intel_step(i915,
+ 
_INFO(i915)->display,
+ gmd_display_table,
+ 
ARRAY_SIZE(gmd_display_table));
+   RUNTIME_INFO(i915)->step = step;
+
+   return;
+   }
+
if (IS_PONTEVECCHIO(i915)) {
pvc_step_init(i915, revid);
return;
-- 
2.25.1



[PATCH v2 01/21] drm/i915: Read graphics/media/display arch version from hw

2022-08-18 Thread Radhakrishna Sripada
From: Matt Roper 

Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be read
directly from a register in the MMIO space.  New hardware programming
styles, features, and workarounds should be conditional solely on the
architecture version, and should no longer be derived from the PCI
device ID, revision ID, or platform-specific feature flags.

v1.1: Fix build error

Bspec: 63361, 64111

Signed-off-by: Matt Roper 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  2 +
 drivers/gpu/drm/i915/i915_driver.c| 80 ++-
 drivers/gpu/drm/i915/i915_drv.h   | 16 ++--
 drivers/gpu/drm/i915/i915_pci.c   |  1 +
 drivers/gpu/drm/i915/i915_reg.h   |  6 ++
 drivers/gpu/drm/i915/intel_device_info.c  | 32 
 drivers/gpu/drm/i915/intel_device_info.h  | 14 
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
 8 files changed, 128 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 94f9ddcfb3a5..a053493dae24 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -39,6 +39,8 @@
 #define FORCEWAKE_ACK_RENDER_GEN9  _MMIO(0xd84)
 #define FORCEWAKE_ACK_MEDIA_GEN9   _MMIO(0xd88)
 
+#define GMD_ID_GRAPHICS_MMIO(0xd8c)
+
 #define MCFG_MCR_SELECTOR  _MMIO(0xfd0)
 #define SF_MCR_SELECTOR_MMIO(0xfd8)
 #define GEN8_MCR_SELECTOR  _MMIO(0xfdc)
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965..33566f6e9546 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -70,6 +70,7 @@
 #include "gem/i915_gem_pm.h"
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_regs.h"
 #include "gt/intel_rc6.h"
 
 #include "pxp/intel_pxp_pm.h"
@@ -306,15 +307,83 @@ static void sanitize_gpu(struct drm_i915_private *i915)
__intel_gt_reset(to_gt(i915), ALL_ENGINES);
 }
 
+#define IP_VER_READ(offset, ri_prefix) \
+   addr = pci_iomap_range(pdev, 0, offset, sizeof(u32)); \
+   if (drm_WARN_ON(>drm, !addr)) { \
+   /* Fall back to whatever was in the device info */ \
+   RUNTIME_INFO(i915)->ri_prefix.ver = 
INTEL_INFO(i915)->ri_prefix.ver; \
+   RUNTIME_INFO(i915)->ri_prefix.rel = 
INTEL_INFO(i915)->ri_prefix.rel; \
+   goto ri_prefix##done; \
+   } \
+   \
+   ver = ioread32(addr); \
+   pci_iounmap(pdev, addr); \
+   \
+   RUNTIME_INFO(i915)->ri_prefix.ver = REG_FIELD_GET(GMD_ID_ARCH_MASK, 
ver); \
+   RUNTIME_INFO(i915)->ri_prefix.rel = REG_FIELD_GET(GMD_ID_RELEASE_MASK, 
ver); \
+   RUNTIME_INFO(i915)->ri_prefix.step = REG_FIELD_GET(GMD_ID_STEP, ver); \
+   \
+   /* Sanity check against expected versions from device info */ \
+   if (RUNTIME_INFO(i915)->ri_prefix.ver != 
INTEL_INFO(i915)->ri_prefix.ver || \
+   RUNTIME_INFO(i915)->ri_prefix.rel > 
INTEL_INFO(i915)->ri_prefix.rel) \
+   drm_dbg(>drm, \
+   "Hardware reports " #ri_prefix " IP version %u.%u but 
minimum expected is %u.%u\n", \
+   RUNTIME_INFO(i915)->ri_prefix.ver, \
+   RUNTIME_INFO(i915)->ri_prefix.rel, \
+   INTEL_INFO(i915)->ri_prefix.ver, \
+   INTEL_INFO(i915)->ri_prefix.rel); \
+ri_prefix##done:
+
+/**
+ * intel_ipver_early_init - setup IP version values
+ * @dev_priv: device private
+ *
+ * Setup the graphics version for the current device.  This must be done before
+ * any code that performs checks on GRAPHICS_VER or DISPLAY_VER, so this
+ * function should be called very early in the driver initialization sequence.
+ *
+ * Regular MMIO access is not yet setup at the point this function is called so
+ * we peek at the appropriate MMIO offset directly.  The GMD_ID register is
+ * part of an 'always on' power well by design, so we don't need to worry about
+ * forcewake while reading it.
+ */
+static void intel_ipver_early_init(struct drm_i915_private *i915)
+{
+   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+   void __iomem *addr;
+   u32 ver;
+
+   if (!HAS_GMD_ID(i915)) {
+   drm_WARN_ON(>drm, INTEL_INFO(i915)->graphics.ver > 12);
+
+   RUNTIME_INFO(i915)->graphics.ver = 
INTEL_INFO(i915)->graphics.ver;
+   RUNTIME_INFO(i915)->graphics.rel = 
INTEL_INFO(i915)->graphics.rel;
+   /* media ver = graphics ver for older platforms */
+   

[PATCH v2 04/21] drm/i915/mtl: Don't mask off CCS according to DSS fusing

2022-08-18 Thread Radhakrishna Sripada
From: Matt Roper 

Unlike the Xe_HP platforms, MTL only has a single CCS engine; the
quad-based engine masking logic does not apply to this platform (or
presumably any future platforms that only have 0 or 1 CCS).

Signed-off-by: Matt Roper 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 37fa813af766..17e7f20bbb48 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -672,7 +672,7 @@ static void engine_mask_apply_compute_fuses(struct intel_gt 
*gt)
unsigned long ccs_mask;
unsigned int i;
 
-   if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
+   if (hweight32(CCS_MASK(gt)) <= 1)
return;
 
ccs_mask = 
intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
-- 
2.25.1



[PATCH v2 07/21] drm/i915/mtl: Add gmbus and gpio support

2022-08-18 Thread Radhakrishna Sripada
Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
>From spec we have registers GPIO_CTL[1-5] mapped to native display phys and
GPIO_CTL[9-14] are mapped to TC ports.

BSpec: 49306

Original Author: Brian J Lovin
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_gmbus.c | 17 +
 drivers/gpu/drm/i915/display/intel_gmbus.h |  1 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index a6ba7fb72339..542b8b2654be 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -116,6 +116,20 @@ static const struct gmbus_pin gmbus_pins_dg2[] = {
[GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
 };
 
+static const struct gmbus_pin gmbus_pins_mtp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
+   [GMBUS_PIN_5_MTP] = { "dpe", GPIOF },
+   [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
+   [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
+   [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
+   [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
+   [GMBUS_PIN_13_TC5_TGP] = { "tc5", GPION },
+   [GMBUS_PIN_14_TC6_TGP] = { "tc6", GPIOO },
+};
+
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *i915,
 unsigned int pin)
 {
@@ -128,6 +142,9 @@ static const struct gmbus_pin *get_gmbus_pin(struct 
drm_i915_private *i915,
} else if (INTEL_PCH_TYPE(i915) >= PCH_DG1) {
pins = gmbus_pins_dg1;
size = ARRAY_SIZE(gmbus_pins_dg1);
+   } else if (INTEL_PCH_TYPE(i915) >= PCH_MTP) {
+   pins = gmbus_pins_mtp;
+   size = ARRAY_SIZE(gmbus_pins_mtp);
} else if (INTEL_PCH_TYPE(i915) >= PCH_ICP) {
pins = gmbus_pins_icp;
size = ARRAY_SIZE(gmbus_pins_icp);
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.h 
b/drivers/gpu/drm/i915/display/intel_gmbus.h
index 8edc2e99cf53..20f704bd4e70 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.h
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.h
@@ -24,6 +24,7 @@ struct i2c_adapter;
 #define GMBUS_PIN_2_BXT2
 #define GMBUS_PIN_3_BXT3
 #define GMBUS_PIN_4_CNP4
+#define GMBUS_PIN_5_MTP5
 #define GMBUS_PIN_9_TC1_ICP9
 #define GMBUS_PIN_10_TC2_ICP   10
 #define GMBUS_PIN_11_TC3_ICP   11
-- 
2.25.1



[PATCH v2 06/21] drm/i915/mtl: Add PCH support

2022-08-18 Thread Radhakrishna Sripada
Add support for Meteorpoint(MTP) PCH used with Meteorlake.

Cc: Matt Roper 
Reviewed-by: Anusha Srivatsa 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_pch.c | 9 -
 drivers/gpu/drm/i915/intel_pch.h | 4 
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index 0fec25be146a..ba9843cb1b13 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -138,6 +138,11 @@ intel_pch_type(const struct drm_i915_private *dev_priv, 
unsigned short id)
drm_WARN_ON(_priv->drm, !IS_ALDERLAKE_S(dev_priv) &&
!IS_ALDERLAKE_P(dev_priv));
return PCH_ADP;
+   case INTEL_PCH_MTP_DEVICE_ID_TYPE:
+   case INTEL_PCH_MTP2_DEVICE_ID_TYPE:
+   drm_dbg_kms(_priv->drm, "Found Meteor Lake PCH\n");
+   drm_WARN_ON(_priv->drm, !IS_METEORLAKE(dev_priv));
+   return PCH_MTP;
default:
return PCH_NONE;
}
@@ -166,7 +171,9 @@ intel_virt_detect_pch(const struct drm_i915_private 
*dev_priv,
 * make an educated guess as to which PCH is really there.
 */
 
-   if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv))
+   if (IS_METEORLAKE(dev_priv))
+   id = INTEL_PCH_MTP_DEVICE_ID_TYPE;
+   else if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv))
id = INTEL_PCH_ADP_DEVICE_ID_TYPE;
else if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv))
id = INTEL_PCH_TGP_DEVICE_ID_TYPE;
diff --git a/drivers/gpu/drm/i915/intel_pch.h b/drivers/gpu/drm/i915/intel_pch.h
index 7c8ce9781d1a..32aff5a70d04 100644
--- a/drivers/gpu/drm/i915/intel_pch.h
+++ b/drivers/gpu/drm/i915/intel_pch.h
@@ -25,6 +25,7 @@ enum intel_pch {
PCH_ICP,/* Ice Lake/Jasper Lake PCH */
PCH_TGP,/* Tiger Lake/Mule Creek Canyon PCH */
PCH_ADP,/* Alder Lake PCH */
+   PCH_MTP,/* Meteor Lake PCH */
 
/* Fake PCHs, functionality handled on the same PCI dev */
PCH_DG1 = 1024,
@@ -57,12 +58,15 @@ enum intel_pch {
 #define INTEL_PCH_ADP2_DEVICE_ID_TYPE  0x5180
 #define INTEL_PCH_ADP3_DEVICE_ID_TYPE  0x7A00
 #define INTEL_PCH_ADP4_DEVICE_ID_TYPE  0x5480
+#define INTEL_PCH_MTP_DEVICE_ID_TYPE   0x7E00
+#define INTEL_PCH_MTP2_DEVICE_ID_TYPE  0xAE00
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv)   ((dev_priv)->pch_type)
 #define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
+#define HAS_PCH_MTP(dev_priv)  (INTEL_PCH_TYPE(dev_priv) == 
PCH_MTP)
 #define HAS_PCH_DG2(dev_priv)  (INTEL_PCH_TYPE(dev_priv) == 
PCH_DG2)
 #define HAS_PCH_ADP(dev_priv)  (INTEL_PCH_TYPE(dev_priv) == 
PCH_ADP)
 #define HAS_PCH_DG1(dev_priv)  (INTEL_PCH_TYPE(dev_priv) == 
PCH_DG1)
-- 
2.25.1



[PATCH v2 00/21] Initial Meteorlake Support

2022-08-18 Thread Radhakrishna Sripada
The PCI Id's and platform definition are posted earlier.
This series adds handful of early enablement patches including
support for display power wells, VBT and AUX Channel mapping,
PCH and gmbus support, dbus, mbus, sagv and memory bandwidth support.

This series also add the support for a new way to read Graphics,
Media and Display versions. 

Clint Taylor (1):
  drm/i915/mtl: Fix rawclk for Meteorlake PCH

Imre Deak (3):
  drm/i915/mtl: Add VBT port and AUX_CH mapping
  drm/i915/mtl: Add display power wells
  drm/i915/mtl: Add DP AUX support on TypeC ports

José Roberto de Souza (2):
  drm/i915: Parse and set stepping for platforms with GMD
  drm/i915/display/mtl: Extend MBUS programming

Madhumitha Tolakanahalli Pradeep (1):
  drm/i915/mtl: Update CHICKEN_TRANS* register addresses

Matt Roper (4):
  drm/i915: Read graphics/media/display arch version from hw
  drm/i915/mtl: MMIO range is now 4MB
  drm/i915/mtl: Don't mask off CCS according to DSS fusing
  drm/i915/mtl: Define engine context layouts

Radhakrishna Sripada (10):
  drm/i915/mtl: Add PCH support
  drm/i915/mtl: Add gmbus and gpio support
  drm/i915/mtl: Add support for MTL in Display Init sequences
  drm/i915: Extract wm latency adjustment to its own function
  drm/i915/mtl: memory latency data from LATENCY_LPX_LPY for WM
  drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox
  drm/i915/mtl: Update memory bandwidth parameters
  drm/i915/mtl: Update MBUS_DBOX credits
  drm/i915/mtl: Reuse adl-p DBUF calculations
  drm/i915/mtl: Do not update GV point, mask value

 drivers/gpu/drm/i915/display/intel_bios.c |  14 +-
 drivers/gpu/drm/i915/display/intel_bw.c   |  82 +++-
 drivers/gpu/drm/i915/display/intel_cdclk.c|   7 +
 drivers/gpu/drm/i915/display/intel_display.c  |  14 +-
 .../drm/i915/display/intel_display_power.c|   5 +-
 .../i915/display/intel_display_power_map.c| 115 ++-
 .../i915/display/intel_display_power_well.c   |  44 +
 .../i915/display/intel_display_power_well.h   |   4 +
 drivers/gpu/drm/i915/display/intel_dp_aux.c   |  53 +-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   5 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  17 ++
 drivers/gpu/drm/i915/display/intel_gmbus.h|   1 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   6 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   |  47 -
 drivers/gpu/drm/i915/i915_driver.c|  80 +++-
 drivers/gpu/drm/i915/i915_drv.h   |  18 +-
 drivers/gpu/drm/i915/i915_pci.c   |   1 +
 drivers/gpu/drm/i915/i915_reg.h   |  91 -
 drivers/gpu/drm/i915/intel_device_info.c  |  32 ++--
 drivers/gpu/drm/i915/intel_device_info.h  |  14 ++
 drivers/gpu/drm/i915/intel_dram.c |  41 +++-
 drivers/gpu/drm/i915/intel_pch.c  |   9 +-
 drivers/gpu/drm/i915/intel_pch.h  |   4 +
 drivers/gpu/drm/i915/intel_pm.c   | 180 +-
 drivers/gpu/drm/i915/intel_step.c |  60 ++
 drivers/gpu/drm/i915/intel_uncore.c   |  11 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   1 +
 29 files changed, 848 insertions(+), 112 deletions(-)

-- 
2.25.1



Re: [PATCH 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers

2022-08-18 Thread Hsia-Jun Li




On 8/19/22 07:16, Laurent Pinchart wrote:

CAUTION: Email originated externally, do not click links or open attachments 
unless you recognize the sender and know the content is safe.


Hi Hsia-Jun,

Thank you for the patch.

On Tue, Aug 09, 2022 at 12:27:49AM +0800, Hsia-Jun Li wrote:

From: "Hsia-Jun(Randy) Li" 

Memory Traffic Reduction(MTR) is a module in Synaptics
VideoSmart platform could process lossless compression image
and cache the tile memory line.

Those modifiers only record the parameters would effort pixel
layout or memory layout. Whether physical memory page mapping
is used is not a part of format.

We would allocate the same size of memory for uncompressed
and compressed luma and chroma data, while the compressed buffer
would request two extra planes holding the metadata for
the decompression.

The reason why we need to allocate the same size of memory for
the compressed frame:
1. The compression ratio is not fixed and differnt platforms could
use a different compression protocol. These protocols are complete
vendor proprietaries, the other device won't be able to use them.
It is not necessary to define the version of them here.

2. Video codec could discard the compression attribute when the
intra block copy applied to this frame. It would waste lots of
time on re-allocation.

I am wondering if it is better to add an addtional plane property to
describe whether the current framebuffer is compressed?
While the compression flag is still a part of format modifier,
because it would have two extra meta data planes in the compression
version.


Would it possible to show an example of how these modifiers apply to a
particular format (such as NV12 for instance) ? Otherwise I'm having
trouble understanding how they actually workThis version didn't contains the big tile information as I was 
considering moving them into compression options. The uncompressed tile 
in big tile pixel formats do exist, but I never see them being used.

Anyway, let me just try to describe the most simple tile here.
For example a NV12 tile format(V4H1)
(0, 0) (0, 1) (0, 2)
(1, 0) (1, 1)
(2, 0) (2, 1)
(3, 0)
(0, 0) (1, 0) (2, 0) (3, 0) is a tile, then (0, 1)..(3, 1) after that.
(4, 0) is after (3, y).

For example a NV15 tiled format(V4H3P8),
(0, 0) (0, 1) (0, 2)
(1, 0) (1, 1)
(2, 0) (2, 1)
(3, 0)

(0, 0) (1, 0) (2, 0) (3, 0) (0, 1) (1, 1) (2, 1) ... (3, 2) are 120bits, 
then fill it with an extra 8 bits, (0, 3) would be placed that the first 
128bits in the memory.



Signed-off-by: Hsia-Jun(Randy) Li 
---
  include/uapi/drm/drm_fourcc.h | 49 +++
  1 file changed, 49 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0206f812c569..b67884e8bc69 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -381,6 +381,7 @@ extern "C" {
  #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
  #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
  #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
+#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b

  /* add more to the end as needed */

@@ -1452,6 +1453,54 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
  #define AMD_FMT_MOD_CLEAR(field) \
   (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))

+/*
+ * Synaptics VideoSmart modifiers
+ *
+ *   Macro
+ * Bits  Param Description
+ *   - 
-
+ *
+ *  7:0  f Scan direction description.
+ *
+ *   0 = Invalid
+ *   1 = V4, the scan would always start from vertical for 4 pixel
+ *   then move back to the start pixel of the next horizontal
+ *   direction.
+ *   2 = Reserved for future use.
+ *
+ * 15:8  m The times of pattern repeat in the right angle direction from
+ * the first scan direction.
+ *
+ * 19:16 p The padding bits after the whole scan, could be zero.
+ *
+ * 35:20 - Reserved for future use.  Must be zero.
+ *
+ * 36:36 c Compression flag.
+ *
+ * 55:37 - Reserved for future use.  Must be zero.
+ *
+ */
+
+#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1)
+
+#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, c) \
+ fourcc_mod_code(SYNAPTICS, (((f) & 0xff) | \
+  (((m) & 0xff) << 8) | \
+  (((p) & 0xf) << 16) | \
+  (((c) & 0x1) << 36)))
+
+#define DRM_FORMAT_MOD_SYNA_V4H1 \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8 \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0)
+
+#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1)
+
+#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \
+ DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1)
+
  #if defined(__cplusplus)
  }
  #endif


--
Regards,

Laurent Pinchart


--
Hsia-Jun(Randy) Li


Re: [PATCH 0/2] Add pixel formats used in Synatpics SoC

2022-08-18 Thread Hsia-Jun Li




On 8/19/22 07:08, Laurent Pinchart wrote:

CAUTION: Email originated externally, do not click links or open attachments 
unless you recognize the sender and know the content is safe.


Hi Hsia-Jun,

On Tue, Aug 09, 2022 at 12:27:48AM +0800, Hsia-Jun Li wrote:

From: "Hsia-Jun(Randy) Li" 

Those pixel formats are used in Synaptics's VideoSmart series SoCs,
likes VS640, VS680.  I just disclose the pixel formats used in the video
codecs and display pipeline this time. Actually any device with a MTR
module could support those tiled and compressed pixel formats. The more
detail about MTR module could be found in the first patch of this serial
of mail.

We may not be able to post any drivers here in a short time, the most of
work in this platform is done in the Trusted Execution Environment and
we didn't use the optee framework.


Is that so for the display side too, or only for the video decoder ?
These pixel formats are using in both video decoder and display(Not the 
GPU). Besides, ISP and NPU in vs680 support some patterns of them.


Please notice that after I reviewed the compression options of our 
platform, I found using modifies are not enough to store all the 
compression options here. I would post a second version here.


I may use the same way that Intel, I would try to disclose more details 
here, hoping we could find a better way to describe them.



Please notice that, the memory planes used for video codecs would be 5
when the compression is invoked while it would be 4 for display, the
extra planes in the video codecs is for the decoding internally usage,
it can't append the luma or chroma buffer as many other drivers do,
because this buffer could be only accessed by the video codecs itself,
it requests a different memory security attributes. Any other reason is
described in the v4l pixel formats's patch. I don't know whether a
different numbers of memory planes between drm and v4l2 is acceptable.


I don't think that's a problem as such, as long as both the V4L2 and DRM
formats make sense on their own.


I only posted the compression fourcc for the v4l2, because it is really
hard to put the uncompression version of pixel formats under the fourcc.
I would be better that we could have something likes format modifers in
drm here.


Agreed, we need modifiers support in V4L2. This has been discussed
previously ([1]), and a proposal ([2]) has been submitted two years ago,
it needs to be revived.
Thank you, I have found those v4l2_ext_pix_format, I would relay my 
comment in the email that posting synaptics v4l2 pixel formats.


[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dmedia_20170821155203.GB38943-40e107564-2Dlin.cambridge.arm.com_=DwIBaQ=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY=P4xb2_7biqBxD4LGGPrSV6j-jf3C3xlR7PXU-mLTeZE=Ktu-e-R1Mn89Laxioh6RlL6Y2aycZ9NrJTIyONaDdRQvnlv-Nd570KldQ51vmigK=_7eMTIYwWUOWkXijcRfotLJlpR7G5yx-ZXuTwh9uZw4=
[2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dmedia_20200804192939.2251988-2D1-2Dhelen.koike-40collabora.com_=DwIBaQ=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY=P4xb2_7biqBxD4LGGPrSV6j-jf3C3xlR7PXU-mLTeZE=Ktu-e-R1Mn89Laxioh6RlL6Y2aycZ9NrJTIyONaDdRQvnlv-Nd570KldQ51vmigK=f1dbc5ciUeIkO6VMtlRuEvXqJad2NsoaDBFyNUsSdpg=


https://synaptics.com/products/multimedia-solutions

Hsia-Jun(Randy) Li (2):
   drm/fourcc: Add Synaptics VideoSmart tiled modifiers
   [WIP]: media: Add Synaptics compressed tiled format

  drivers/media/v4l2-core/v4l2-common.c |  1 +
  drivers/media/v4l2-core/v4l2-ioctl.c  |  2 ++
  include/uapi/drm/drm_fourcc.h | 49 +++
  include/uapi/linux/videodev2.h|  2 ++
  4 files changed, 54 insertions(+)


--
Regards,

Laurent Pinchart


--
Hsia-Jun(Randy) Li


Re: [PATCH 1/2] drm/fourcc: Add Synaptics VideoSmart tiled modifiers

2022-08-18 Thread Laurent Pinchart
Hi Hsia-Jun,

Thank you for the patch.

On Tue, Aug 09, 2022 at 12:27:49AM +0800, Hsia-Jun Li wrote:
> From: "Hsia-Jun(Randy) Li" 
> 
> Memory Traffic Reduction(MTR) is a module in Synaptics
> VideoSmart platform could process lossless compression image
> and cache the tile memory line.
> 
> Those modifiers only record the parameters would effort pixel
> layout or memory layout. Whether physical memory page mapping
> is used is not a part of format.
> 
> We would allocate the same size of memory for uncompressed
> and compressed luma and chroma data, while the compressed buffer
> would request two extra planes holding the metadata for
> the decompression.
> 
> The reason why we need to allocate the same size of memory for
> the compressed frame:
> 1. The compression ratio is not fixed and differnt platforms could
> use a different compression protocol. These protocols are complete
> vendor proprietaries, the other device won't be able to use them.
> It is not necessary to define the version of them here.
> 
> 2. Video codec could discard the compression attribute when the
> intra block copy applied to this frame. It would waste lots of
> time on re-allocation.
> 
> I am wondering if it is better to add an addtional plane property to
> describe whether the current framebuffer is compressed?
> While the compression flag is still a part of format modifier,
> because it would have two extra meta data planes in the compression
> version.

Would it possible to show an example of how these modifiers apply to a
particular format (such as NV12 for instance) ? Otherwise I'm having
trouble understanding how they actually work.

> Signed-off-by: Hsia-Jun(Randy) Li 
> ---
>  include/uapi/drm/drm_fourcc.h | 49 +++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0206f812c569..b67884e8bc69 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -381,6 +381,7 @@ extern "C" {
>  #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
>  #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
>  #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> +#define DRM_FORMAT_MOD_VENDOR_SYNAPTICS 0x0b
>  
>  /* add more to the end as needed */
>  
> @@ -1452,6 +1453,54 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>  #define AMD_FMT_MOD_CLEAR(field) \
>   (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
>  
> +/*
> + * Synaptics VideoSmart modifiers
> + *
> + *   Macro
> + * Bits  Param Description
> + *   - 
> -
> + *
> + *  7:0  f Scan direction description.
> + *
> + *   0 = Invalid
> + *   1 = V4, the scan would always start from vertical for 4 
> pixel
> + *   then move back to the start pixel of the next horizontal
> + *   direction.
> + *   2 = Reserved for future use.
> + *
> + * 15:8  m The times of pattern repeat in the right angle direction from
> + * the first scan direction.
> + *
> + * 19:16 p The padding bits after the whole scan, could be zero.
> + *
> + * 35:20 - Reserved for future use.  Must be zero.
> + *
> + * 36:36 c Compression flag.
> + *
> + * 55:37 - Reserved for future use.  Must be zero.
> + *
> + */
> +
> +#define DRM_FORMAT_MOD_SYNA_V4_TILED fourcc_mod_code(SYNAPTICS, 1)
> +
> +#define DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(f, m, p, c) \
> + fourcc_mod_code(SYNAPTICS, (((f) & 0xff) | \
> +  (((m) & 0xff) << 8) | \
> +  (((p) & 0xf) << 16) | \
> +  (((c) & 0x1) << 36)))
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H1 \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H3P8 \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 0)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H1_COMPRESSED \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H3P8_COMPRESSED \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1)
> +
>  #if defined(__cplusplus)
>  }
>  #endif

-- 
Regards,

Laurent Pinchart


Re: [PATCH 2/2] [WIP]: media: Add Synaptics compressed tiled format

2022-08-18 Thread Laurent Pinchart
On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:
> On 8/18/22 14:06, Tomasz Figa wrote:
> > On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li  wrote:
> >>
> >> From: "Hsia-Jun(Randy) Li" 
> >>
> >> The most of detail has been written in the drm.

This patch still needs a description of the format, which should go to
Documentation/userspace-api/media/v4l/.

> >> Please notice that the tiled formats here request
> >> one more plane for storing the motion vector metadata.
> >> This buffer won't be compressed, so you can't append
> >> it to luma or chroma plane.
> > 
> > Does the motion vector buffer need to be exposed to userspace? Is the
> > decoder stateless (requires userspace to specify the reference frames)
> > or stateful (manages the entire decoding process internally)?
> 
> No, users don't need to access them at all. Just they need a different 
> dma-heap.
> 
> You would only get the stateful version of both encoder and decoder.

Shouldn't the motion vectors be stored in a separate V4L2 buffer,
submitted through a different queue then ?

> >> Signed-off-by: Hsia-Jun(Randy) Li 
> >> ---
> >>   drivers/media/v4l2-core/v4l2-common.c | 1 +
> >>   drivers/media/v4l2-core/v4l2-ioctl.c  | 2 ++
> >>   include/uapi/linux/videodev2.h| 2 ++
> >>   3 files changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-common.c 
> >> b/drivers/media/v4l2-core/v4l2-common.c
> >> index e0fbe6ba4b6c..f645278b3055 100644
> >> --- a/drivers/media/v4l2-core/v4l2-common.c
> >> +++ b/drivers/media/v4l2-core/v4l2-common.c
> >> @@ -314,6 +314,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 
> >> format)
> >>  { .format = V4L2_PIX_FMT_SGBRG12,   .pixel_enc = 
> >> V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 
> >> 0 }, .hdiv = 1, .vdiv = 1 },
> >>  { .format = V4L2_PIX_FMT_SGRBG12,   .pixel_enc = 
> >> V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 
> >> 0 }, .hdiv = 1, .vdiv = 1 },
> >>  { .format = V4L2_PIX_FMT_SRGGB12,   .pixel_enc = 
> >> V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 
> >> 0 }, .hdiv = 1, .vdiv = 1 },
> >> +   { .format = V4L2_PIX_FMT_NV12M_V4H1C, .pixel_enc = 
> >> V4L2_PIXEL_ENC_YUV, .mem_planes = 5, .comp_planes = 2, .bpp = { 1, 2, 0, 0 
> >> }, .hdiv = 2, .vdiv = 2, .block_w = { 128, 128 }, .block_h = { 128, 128 } 
> >> },
> >>  };
> >>  unsigned int i;
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> >> b/drivers/media/v4l2-core/v4l2-ioctl.c
> >> index e6fd355a2e92..8f65964aff08 100644
> >> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> >> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> >> @@ -1497,6 +1497,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc 
> >> *fmt)
> >>  case V4L2_PIX_FMT_MT21C:descr = "Mediatek 
> >> Compressed Format"; break;
> >>  case V4L2_PIX_FMT_QC08C:descr = "QCOM Compressed 
> >> 8-bit Format"; break;
> >>  case V4L2_PIX_FMT_QC10C:descr = "QCOM Compressed 
> >> 10-bit Format"; break;
> >> +   case V4L2_PIX_FMT_NV12M_V4H1C:  descr = "Synaptics 
> >> Compressed 8-bit tiled Format";break;
> >> +   case V4L2_PIX_FMT_NV12M_10_V4H3P8C: descr = "Synaptics 
> >> Compressed 10-bit tiled Format";break;
> >>  default:
> >>  if (fmt->description[0])
> >>  return;
> >> diff --git a/include/uapi/linux/videodev2.h 
> >> b/include/uapi/linux/videodev2.h
> >> index 01e630f2ec78..7e928cb69e7c 100644
> >> --- a/include/uapi/linux/videodev2.h
> >> +++ b/include/uapi/linux/videodev2.h
> >> @@ -661,6 +661,8 @@ struct v4l2_pix_format {
> >>   #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
> >> Y/CbCr 4:2:0 16x16 tiles */
> >>   #define V4L2_PIX_FMT_NV12M_8L128  v4l2_fourcc('N', 'A', '1', '2') /* 
> >> Y/CbCr 4:2:0 8x128 tiles */
> >>   #define V4L2_PIX_FMT_NV12M_10BE_8L128 v4l2_fourcc_be('N', 'T', '1', '2') 
> >> /* Y/CbCr 4:2:0 10-bit 8x128 tiles */
> >> +#define V4L2_PIX_FMT_NV12M_V4H1C v4l2_fourcc('S', 'Y', '1', '2')   /* 12  
> >> Y/CbCr 4:2:0 tiles */
> >> +#define V4L2_PIX_FMT_NV12M_10_V4H3P8C v4l2_fourcc('S', 'Y', '1', '0')   
> >> /* 12  Y/CbCr 4:2:0 10-bits tiles */
> >>
> >>   /* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */
> >>   #define V4L2_PIX_FMT_SBGGR8  v4l2_fourcc('B', 'A', '8', '1') /*  8  
> >> BGBG.. GRGR.. */

-- 
Regards,

Laurent Pinchart


Re: [Freedreno] [PATCH] drm/msm/dsi: Set panel orientation when directly connected

2022-08-18 Thread Abhinav Kumar

Hi Doug

On 8/17/2022 1:48 PM, Doug Anderson wrote:

Hi,

On Wed, Jul 20, 2022 at 3:42 PM Doug Anderson  wrote:


Hi,

On Wed, Jul 20, 2022 at 1:46 PM Rob Clark  wrote:


On Fri, Jul 8, 2022 at 8:25 AM Doug Anderson  wrote:


Hi,

On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd  wrote:


Set the panel orientation in drm when the panel is directly connected,
i.e. we're not using an external bridge. The external bridge case is
already handled by the panel bridge code, so we only update the path we
take when the panel is directly connected/internal. This silences a
warning splat coming from __drm_mode_object_add() on Wormdingler boards.

Cc: Hsin-Yi Wang 
Cc: Douglas Anderson 
Signed-off-by: Stephen Boyd 
---

This relies on commit 5e41b01a7808 ("drm/panel: Add an API to allow drm
to set orientation from panel") which is in drm-misc

  drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 ++
  1 file changed, 2 insertions(+)


I don't personally have objections to this, but (to my understanding)
"the future" is that everyone should use panel_bridge. If we made the
move to panel_bridge today then we wouldn't need to do this. In
general I think panel_bridge would end up letting us delete a bunch of
code...

See commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with
panel-bridge") for when this was done by ti-sn65dsi86.

Then again, I spent a small amount of time looking into this and it's
definitely non-trivial. Still likely worthwhile, but not worth
blocking a tiny fix like this. It also should be fairly obvious that
we should delete this when we switch to panel_bridge.

Thus:

Reviewed-by: Douglas Anderson 

I'll assume that we'll just snooze this commit until drm-misc-next
merges into a tree that msm-next is based on, which will probably be
the next -rc1. If desired and Acked I could land this in
drm-misc-next, but it's probably not worth it?


if you want to land this patch via drm-misc, which might be the
easier/faster route, then:

Acked-by: Rob Clark 


As per discussion on IRC, I'm not going to apply this to drm-misc-next.

Given where we are in the cycle landing in drm-misc-next means it
won't be in mainline for a couple versions and I suspect that'll cause
merge conflicts with Dmitry's series [1]. ...and, of course, if
Dmitry's series lands then we don't even need ${SUBJECT} patch...

So I think the plan is:

1. Snooze waiting for the next -rc1 since
drm_connector_set_orientation_from_panel() won't be in mainline until
then.

2. If Dmitry's series looks like a long way off, we could land
${SUBJECT} patch in msm-next as a stopgap fix.


[1] 
https://lore.kernel.org/r/20220711094320.368062-5-dmitry.barysh...@linaro.org/


Just checking up. What's the latest thinking here? Do we want to land
Stephen's change as a stopgap?
drm_connector_set_orientation_from_panel() is available in v6.0-rc1.

-Doug


As per todays discussion with Rob on IRC, we will start preparing the 
tree for the next release. So lets drop this one and take the panel 
bridge change instead since my comments on that were minor and can also 
be addressed in a follow up change, will take it up and send it over to 
Rob with some other changes.


Thanks

Abhinav


Re: [PATCH 0/2] Add pixel formats used in Synatpics SoC

2022-08-18 Thread Laurent Pinchart
Hi Hsia-Jun,

On Tue, Aug 09, 2022 at 12:27:48AM +0800, Hsia-Jun Li wrote:
> From: "Hsia-Jun(Randy) Li" 
> 
> Those pixel formats are used in Synaptics's VideoSmart series SoCs,
> likes VS640, VS680.  I just disclose the pixel formats used in the video
> codecs and display pipeline this time. Actually any device with a MTR
> module could support those tiled and compressed pixel formats. The more
> detail about MTR module could be found in the first patch of this serial
> of mail.
> 
> We may not be able to post any drivers here in a short time, the most of
> work in this platform is done in the Trusted Execution Environment and
> we didn't use the optee framework.

Is that so for the display side too, or only for the video decoder ?

> Please notice that, the memory planes used for video codecs would be 5
> when the compression is invoked while it would be 4 for display, the
> extra planes in the video codecs is for the decoding internally usage,
> it can't append the luma or chroma buffer as many other drivers do,
> because this buffer could be only accessed by the video codecs itself,
> it requests a different memory security attributes. Any other reason is
> described in the v4l pixel formats's patch. I don't know whether a
> different numbers of memory planes between drm and v4l2 is acceptable.

I don't think that's a problem as such, as long as both the V4L2 and DRM
formats make sense on their own.

> I only posted the compression fourcc for the v4l2, because it is really
> hard to put the uncompression version of pixel formats under the fourcc.
> I would be better that we could have something likes format modifers in
> drm here.

Agreed, we need modifiers support in V4L2. This has been discussed
previously ([1]), and a proposal ([2]) has been submitted two years ago,
it needs to be revived.

[1] 
https://lore.kernel.org/linux-media/20170821155203.gb38...@e107564-lin.cambridge.arm.com/
[2] 
https://lore.kernel.org/linux-media/20200804192939.2251988-1-helen.ko...@collabora.com/

> https://synaptics.com/products/multimedia-solutions
> 
> Hsia-Jun(Randy) Li (2):
>   drm/fourcc: Add Synaptics VideoSmart tiled modifiers
>   [WIP]: media: Add Synaptics compressed tiled format
> 
>  drivers/media/v4l2-core/v4l2-common.c |  1 +
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  2 ++
>  include/uapi/drm/drm_fourcc.h | 49 +++
>  include/uapi/linux/videodev2.h|  2 ++
>  4 files changed, 54 insertions(+)

-- 
Regards,

Laurent Pinchart


[PATCH v2 11/15] drm/i915/huc: track delayed HuC load with a fence

2022-08-18 Thread Daniele Ceraolo Spurio
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.

The full HuC loading flow on boot DG2 is as follows:
1) i915 exports the GSC as an aux device;
2) the mei-gsc driver is loaded on the aux device;
3) the mei-pxp component is loaded;
4) mei-pxp calls back into i915 and we load the HuC.

Between steps 1 and 2 there can be several seconds of gap, mainly due to
the kernel doing other work during the boot.
The resume flow is slightly different, because we don't need to
re-expose or re-probe the aux device, so we go directly to step 3 once
i915 and mei-gsc have completed their resume flow.

Here's an example of the boot timing, captured with some logs added to
i915:

[   17.908307] [drm] adding GSC device
[   17.915717] [drm] i915 probe done
[   22.282917] [drm] mei-gsc bound
[   22.938153] [drm] HuC authenticated

Also to note is that if something goes wrong during GSC HW init the
mei-gsc driver will still bind, but steps 3 and 4 will not happen.

The status tracking is done by registering a bus_notifier to receive a
callback when the mei-gsc driver binds, with a large enough timeout to
account for delays. Once mei-gsc is bound, we switch to a smaller
timeout to wait for the mei-pxp component to load.
The fence is signalled on HuC load complete or if anything goes wrong in
any of the tracking steps. Timeout are enforced via hrtimer callbacks.

Signed-off-by: Daniele Ceraolo Spurio 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c|  22 ++-
 drivers/gpu/drm/i915/gt/uc/intel_huc.c | 198 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.h |  19 +++
 3 files changed, 236 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 162bea57fbb5..bc9db728cdc8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -154,8 +154,14 @@ static void gsc_destroy_one(struct drm_i915_private *i915,
struct intel_gsc_intf *intf = >intf[intf_id];
 
if (intf->adev) {
-   auxiliary_device_delete(>adev->aux_dev);
-   auxiliary_device_uninit(>adev->aux_dev);
+   struct auxiliary_device *aux_dev = >adev->aux_dev;
+
+   if (intf_id == 0)
+   
intel_huc_unregister_gsc_notifier(_to_gt(gsc)->uc.huc,
+ aux_dev->dev.bus);
+
+   auxiliary_device_delete(aux_dev);
+   auxiliary_device_uninit(aux_dev);
intf->adev = NULL;
}
 
@@ -254,14 +260,24 @@ static void gsc_init_one(struct drm_i915_private *i915, 
struct intel_gsc *gsc,
goto fail;
}
 
+   intf->adev = adev; /* needed by the notifier */
+
+   if (intf_id == 0)
+   intel_huc_register_gsc_notifier(_to_gt(gsc)->uc.huc,
+   aux_dev->dev.bus);
+
ret = auxiliary_device_add(aux_dev);
if (ret < 0) {
drm_err(>drm, "gsc aux add failed %d\n", ret);
+   if (intf_id == 0)
+   
intel_huc_unregister_gsc_notifier(_to_gt(gsc)->uc.huc,
+ aux_dev->dev.bus);
+   intf->adev = NULL;
+
/* adev will be freed with the put_device() and .release 
sequence */
auxiliary_device_uninit(aux_dev);
goto fail;
}
-   intf->adev = adev;
 
return;
 fail:
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 40217fb69824..9a97b8cc90c7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -10,6 +10,8 @@
 #include "intel_huc.h"
 #include "i915_drv.h"
 
+#include 
+
 /**
  * DOC: HuC
  *
@@ -42,6 +44,164 @@
  * HuC-specific commands.
  */
 
+/*
+ * MEI-GSC load is an async process. The probing of the exposed aux device
+ * (see intel_gsc.c) usually happens a few seconds after i915 probe, depending
+ * on when the kernel schedules it. Unless something goes terribly wrong, we're
+ * guaranteed for this to happen during boot, so the big timeout is a safety 
net
+ * that we never expect to need.
+ * MEI-PXP + HuC load usually takes ~300ms, but if the GSC needs to be resumed
+ * and/or reset, this can take longer.
+ */
+#define GSC_INIT_TIMEOUT_MS 1
+#define PXP_INIT_TIMEOUT_MS 2000
+
+static int sw_fence_dummy_notify(struct i915_sw_fence *sf,
+enum i915_sw_fence_notify state)
+{
+   return NOTIFY_DONE;
+}
+
+static void __delayed_huc_load_complete(struct intel_huc *huc)
+{
+   if (!i915_sw_fence_done(>delayed_load.fence))
+   i915_sw_fence_complete(>delayed_load.fence);
+}
+
+static void 

[PATCH v2 15/15] HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI

2022-08-18 Thread Daniele Ceraolo Spurio
Both are required for HuC loading.

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/Kconfig.debug | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index e7fd3e76f8a2..a6576ffbc4dc 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -48,6 +48,8 @@ config DRM_I915_DEBUG
select DRM_I915_DEBUG_RUNTIME_PM
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
+   select INTEL_MEI_GSC
+   select INTEL_MEI_PXP
select BROKEN # for prototype uAPI
default n
help
-- 
2.37.2



[PATCH v2 09/15] drm/i915/pxp: add huc authentication and loading command

2022-08-18 Thread Daniele Ceraolo Spurio
From: Tomas Winkler 

Add support for loading HuC via a pxp stream command.

Signed-off-by: Tomas Winkler 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile |  3 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  | 69 +++
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h  | 15 
 .../drm/i915/pxp/intel_pxp_tee_interface.h| 21 ++
 4 files changed, 107 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
 create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 589823ad62ed..5bee787d3c2a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -310,7 +310,8 @@ i915-y += i915_perf.o
 # Protected execution platform (PXP) support. Base support is required for HuC
 i915-y += \
pxp/intel_pxp.o \
-   pxp/intel_pxp_tee.o
+   pxp/intel_pxp_tee.o \
+   pxp/intel_pxp_huc.o
 
 i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
new file mode 100644
index ..6d25f436f329
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#include "drm/i915_drm.h"
+#include "i915_drv.h"
+
+#include "gem/i915_gem_region.h"
+#include "gt/intel_gt.h"
+
+#include "intel_pxp.h"
+#include "intel_pxp_huc.h"
+#include "intel_pxp_tee.h"
+#include "intel_pxp_types.h"
+#include "intel_pxp_tee_interface.h"
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp)
+{
+   struct intel_gt *gt = pxp_to_gt(pxp);
+   struct intel_huc *huc = >uc.huc;
+   struct pxp_tee_start_huc_auth_in huc_in = {0};
+   struct pxp_tee_start_huc_auth_out huc_out = {0};
+   dma_addr_t huc_phys_addr;
+   u8 client_id = 0;
+   u8 fence_id = 0;
+   int err;
+
+   if (!pxp->pxp_component)
+   return -ENODEV;
+
+   huc_phys_addr = i915_gem_object_get_dma_address(huc->fw.obj, 0);
+
+   /* write the PXP message into the lmem (the sg list) */
+   huc_in.header.api_version = PXP_TEE_43_APIVER;
+   huc_in.header.command_id  = PXP_TEE_43_START_HUC_AUTH;
+   huc_in.header.status  = 0;
+   huc_in.header.buffer_len  = sizeof(huc_in.huc_base_address);
+   huc_in.huc_base_address   = huc_phys_addr;
+
+   err = intel_pxp_tee_stream_message(pxp, client_id, fence_id,
+  _in, sizeof(huc_in),
+  _out, sizeof(huc_out));
+   if (err < 0) {
+   drm_err(>i915->drm,
+   "Failed to send HuC load and auth command to GSC 
[%d]!\n",
+   err);
+   return err;
+   }
+
+   /*
+* HuC does sometimes survive suspend/resume (it depends on how "deep"
+* a sleep state the device reaches) so we can end up here on resume
+* with HuC already loaded, in which case the GSC will return
+* PXP_STATUS_OP_NOT_PERMITTED. We can therefore consider the GuC
+* correctly transferred in this scenario; if the same error is ever
+* returned with HuC not loaded we'll still catch it when we check the
+* authentication bit later.
+*/
+   if (huc_out.header.status != PXP_STATUS_SUCCESS &&
+   huc_out.header.status != PXP_STATUS_OP_NOT_PERMITTED) {
+   drm_err(>i915->drm,
+   "HuC load failed with GSC error = 0x%x\n",
+   huc_out.header.status);
+   return -EPROTO;
+   }
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
new file mode 100644
index ..6cf2d00548c0
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_HUC_H__
+#define __INTEL_PXP_HUC_H__
+
+#include 
+
+struct intel_pxp;
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp);
+
+#endif /* __INTEL_PXP_HUC_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
index 36e9b0868f5c..1de98959a89d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
@@ -9,8 +9,20 @@
 #include 
 
 #define PXP_TEE_APIVER 0x40002
+#define PXP_TEE_43_APIVER 0x00040003
 #define PXP_TEE_ARB_CMDID 0x1e
 #define PXP_TEE_ARB_PROTECTION_MODE 0x2
+#define PXP_TEE_43_START_HUC_AUTH   0x003A
+
+/*
+ * there are a lot of status codes for PXP, but we only define the ones we
+ * actually can handle in the 

[PATCH v2 13/15] drm/i915/huc: better define HuC status getparam possible return values.

2022-08-18 Thread Daniele Ceraolo Spurio
The current HuC status getparam return values are a bit confusing in
regards to what happens in some scenarios. In particular, most of the
error cases cause the ioctl to return an error, but a couple of them,
INIT_FAIL and LOAD_FAIL, are not explicitly handled and neither is
their expected return value documented; these 2 error cases therefore
end up into the catch-all umbrella of the "HuC not loaded" case, with
this case therefore including both some error scenarios and the load
in progress one.

The updates included in this patch change the handling so that all
error cases behave the same way, i.e. return an errno code, and so
that the HuC load in progress case is unambiguous.

The patch also includes a small change to the FW init path to make sure
we always transition to an error state if something goes wrong.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Tony Ye 
Acked-by: Tvrtko Ursulin 
Acked-by: Tony Ye 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c   |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.c   | 14 +++---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  1 -
 include/uapi/drm/i915_drm.h  | 16 
 4 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 01f2705cb94a..10b2da810a8f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -443,6 +443,7 @@ int intel_guc_init(struct intel_guc *guc)
 err_fw:
intel_uc_fw_fini(>fw);
 out:
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_INIT_FAIL);
i915_probe_error(gt->i915, "failed with %d\n", ret);
return ret;
 }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 9a97b8cc90c7..1a34c902d081 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -284,6 +284,7 @@ int intel_huc_init(struct intel_huc *huc)
return 0;
 
 out:
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_INIT_FAIL);
drm_info(>drm, "HuC init failed with %d\n", err);
return err;
 }
@@ -403,13 +404,8 @@ bool intel_huc_is_authenticated(struct intel_huc *huc)
  * This function reads status register to verify if HuC
  * firmware was successfully loaded.
  *
- * Returns:
- *  * -ENODEV if HuC is not present on this platform,
- *  * -EOPNOTSUPP if HuC firmware is disabled,
- *  * -ENOPKG if HuC firmware was not installed,
- *  * -ENOEXEC if HuC firmware is invalid or mismatched,
- *  * 0 if HuC firmware is not running,
- *  * 1 if HuC firmware is authenticated and running.
+ * The return values match what is expected for the I915_PARAM_HUC_STATUS
+ * getparam.
  */
 int intel_huc_check_status(struct intel_huc *huc)
 {
@@ -422,6 +418,10 @@ int intel_huc_check_status(struct intel_huc *huc)
return -ENOPKG;
case INTEL_UC_FIRMWARE_ERROR:
return -ENOEXEC;
+   case INTEL_UC_FIRMWARE_INIT_FAIL:
+   return -ENOMEM;
+   case INTEL_UC_FIRMWARE_LOAD_FAIL:
+   return -EIO;
default:
break;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 58547292efa0..cec6bf6bad3f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -749,7 +749,6 @@ int intel_uc_fw_init(struct intel_uc_fw *uc_fw)
 out_unpin:
i915_gem_object_unpin_pages(uc_fw->obj);
 out:
-   intel_uc_fw_change_status(uc_fw, INTEL_UC_FIRMWARE_INIT_FAIL);
return err;
 }
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 520ad2691a99..629198f1d8d8 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -645,6 +645,22 @@ typedef struct drm_i915_irq_wait {
  */
 #define   I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP   (1ul << 5)
 
+/*
+ * Query the status of HuC load.
+ *
+ * The query can fail in the following scenarios with the listed error codes:
+ *  -ENODEV if HuC is not present on this platform,
+ *  -EOPNOTSUPP if HuC firmware usage is disabled,
+ *  -ENOPKG if HuC firmware fetch failed,
+ *  -ENOEXEC if HuC firmware is invalid or mismatched,
+ *  -ENOMEM if i915 failed to prepare the FW objects for transfer to the uC,
+ *  -EIO if the FW transfer or the FW authentication failed.
+ *
+ * If the IOCTL is successful, the returned parameter will be set to one of the
+ * following values:
+ *  * 0 if HuC firmware load is not complete,
+ *  * 1 if HuC firmware is authenticated and running.
+ */
 #define I915_PARAM_HUC_STATUS   42
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of
-- 
2.37.2



[PATCH v2 10/15] drm/i915/dg2: setup HuC loading via GSC

2022-08-18 Thread Daniele Ceraolo Spurio
The GSC will perform both the load and teh authentication, so we just
need to check the auth bit after the GSC has replied.
Since we require the PXP module to load the HuC, the earliest we can
trigger the load is during the pxp_bind operation.

Note that GSC-loaded HuC survives GT reset, so we need to just mark it
as ready when we re-init the GT HW.

v2: move setting of HuC fw error state to the failure path of the HuC
auth function, so it covers both the legacy and new auth flows

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Reviewed-by: Alan Previn  #v1
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 41 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  2 ++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 34 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |  1 +
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 14 +++-
 5 files changed, 77 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..40217fb69824 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -125,6 +125,28 @@ void intel_huc_fini(struct intel_huc *huc)
intel_uc_fw_fini(>fw);
 }
 
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc)
+{
+   struct intel_gt *gt = huc_to_gt(huc);
+   int ret;
+
+   ret = __intel_wait_for_register(gt->uncore,
+   huc->status.reg,
+   huc->status.mask,
+   huc->status.value,
+   2, 50, NULL);
+
+   if (ret) {
+   drm_err(>i915->drm,"HuC: Firmware not verified %d\n", ret);
+   intel_uc_fw_change_status(>fw, 
INTEL_UC_FIRMWARE_LOAD_FAIL);
+   return ret;
+   }
+
+   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_RUNNING);
+   drm_info(>i915->drm, "HuC authenticated\n");
+   return 0;
+}
+
 /**
  * intel_huc_auth() - Authenticate HuC uCode
  * @huc: intel_huc structure
@@ -161,27 +183,18 @@ int intel_huc_auth(struct intel_huc *huc)
}
 
/* Check authentication status, it should be done by now */
-   ret = __intel_wait_for_register(gt->uncore,
-   huc->status.reg,
-   huc->status.mask,
-   huc->status.value,
-   2, 50, NULL);
-   if (ret) {
-   DRM_ERROR("HuC: Firmware not verified %d\n", ret);
+   ret = intel_huc_wait_for_auth_complete(huc);
+   if (ret)
goto fail;
-   }
 
-   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_RUNNING);
-   drm_info(>i915->drm, "HuC authenticated\n");
return 0;
 
 fail:
i915_probe_error(gt->i915, "HuC: Authentication failed %d\n", ret);
-   intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_LOAD_FAIL);
return ret;
 }
 
-static bool huc_is_authenticated(struct intel_huc *huc)
+bool intel_huc_is_authenticated(struct intel_huc *huc)
 {
struct intel_gt *gt = huc_to_gt(huc);
intel_wakeref_t wakeref;
@@ -223,7 +236,7 @@ int intel_huc_check_status(struct intel_huc *huc)
break;
}
 
-   return huc_is_authenticated(huc);
+   return intel_huc_is_authenticated(huc);
 }
 
 void intel_huc_update_auth_status(struct intel_huc *huc)
@@ -231,7 +244,7 @@ void intel_huc_update_auth_status(struct intel_huc *huc)
if (!intel_uc_fw_is_loadable(>fw))
return;
 
-   if (huc_is_authenticated(huc))
+   if (intel_huc_is_authenticated(huc))
intel_uc_fw_change_status(>fw,
  INTEL_UC_FIRMWARE_RUNNING);
 }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index d7e25b6e879e..51f9d96a3ca3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -26,8 +26,10 @@ void intel_huc_init_early(struct intel_huc *huc);
 int intel_huc_init(struct intel_huc *huc);
 void intel_huc_fini(struct intel_huc *huc);
 int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_wait_for_auth_complete(struct intel_huc *huc);
 int intel_huc_check_status(struct intel_huc *huc);
 void intel_huc_update_auth_status(struct intel_huc *huc);
+bool intel_huc_is_authenticated(struct intel_huc *huc);
 
 static inline int intel_huc_sanitize(struct intel_huc *huc)
 {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 9d6ab1e01639..4f246416db17 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -3,9 +3,43 @@
  * Copyright © 2014-2019 Intel Corporation
  */
 
+#include "gt/intel_gsc.h"
 #include "gt/intel_gt.h"
+#include "intel_huc.h"
 #include 

[PATCH v2 08/15] drm/i915/pxp: implement function for sending tee stream command

2022-08-18 Thread Daniele Ceraolo Spurio
From: Vitaly Lubart 

Command to be sent via the stream interface are written to a local
memory page, whose address is then provided to the GSC.
The interface supports providing a full sg with multiple pages for both
input and output messages, but since for now we only aim to support short
and synchronous messages we can use a single page for both input and
output.

Note that the mei interface expects an sg of 4k pages, while our lmem pages
are 64k. If we ever need to support more than 4k we'll need to convert.
Added a TODO comment to the code to record this.

Signed-off-by: Vitaly Lubart 
Signed-off-by: Tomas Winkler 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Rodrigo Vivi 
Cc: Alan Previn 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   | 114 -
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h   |   5 +
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |   6 ++
 3 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 2c1fc49ecec1..e0d09455a92e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include "gem/i915_gem_region.h"
 
 #include "i915_drv.h"
 #include "intel_pxp.h"
@@ -69,6 +70,47 @@ static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
return ret;
 }
 
+int intel_pxp_tee_stream_message(struct intel_pxp *pxp,
+u8 client_id, u32 fence_id,
+void *msg_in, size_t msg_in_len,
+void *msg_out, size_t msg_out_len)
+{
+   /* TODO: for bigger objects we need to use a sg of 4k pages */
+   const size_t max_msg_size = PAGE_SIZE;
+   struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+   struct i915_pxp_component *pxp_component = pxp->pxp_component;
+   unsigned int offset = 0;
+   struct scatterlist *sg;
+   int ret;
+
+   if (msg_in_len > max_msg_size || msg_out_len > max_msg_size)
+   return -ENOSPC;
+
+   mutex_lock(>tee_mutex);
+
+   if (unlikely(!pxp_component || !pxp_component->ops->gsc_command)) {
+   ret = -ENODEV;
+   goto unlock;
+   }
+
+   GEM_BUG_ON(!pxp->stream_cmd.obj);
+
+   sg = i915_gem_object_get_sg_dma(pxp->stream_cmd.obj, 0, );
+
+   memcpy(pxp->stream_cmd.vaddr, msg_in, msg_in_len);
+
+   ret = pxp_component->ops->gsc_command(pxp_component->tee_dev, client_id,
+ fence_id, sg, msg_in_len, sg);
+   if (ret < 0)
+   drm_err(>drm, "Failed to send PXP TEE gsc command\n");
+   else
+   memcpy(msg_out, pxp->stream_cmd.vaddr, msg_out_len);
+
+unlock:
+   mutex_unlock(>tee_mutex);
+   return ret;
+}
+
 /**
  * i915_pxp_tee_component_bind - bind function to pass the function pointers 
to pxp_tee
  * @i915_kdev: pointer to i915 kernel device
@@ -126,6 +168,66 @@ static const struct component_ops 
i915_pxp_tee_component_ops = {
.unbind = i915_pxp_tee_component_unbind,
 };
 
+static int alloc_streaming_command(struct intel_pxp *pxp)
+{
+   struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
+   struct drm_i915_gem_object *obj = NULL;
+   void *cmd;
+   int err;
+
+   pxp->stream_cmd.obj = NULL;
+   pxp->stream_cmd.vaddr = NULL;
+
+   if (!IS_DGFX(i915))
+   return 0;
+
+   /* allocate lmem object of one page for PXP command memory and store it 
*/
+   obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(obj)) {
+   drm_err(>drm, "Failed to allocate pxp streaming 
command!\n");
+   return PTR_ERR(obj);
+   }
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err) {
+   drm_err(>drm, "Failed to pin gsc message page!\n");
+   goto out_put;
+   }
+
+   /* map the lmem into the virtual memory pointer */
+   cmd = i915_gem_object_pin_map_unlocked(obj, 
i915_coherent_map_type(i915, obj, true));
+   if (IS_ERR(cmd)) {
+   drm_err(>drm, "Failed to map gsc message page!\n");
+   err = PTR_ERR(cmd);
+   goto out_unpin;
+   }
+
+   memset(cmd, 0, obj->base.size);
+
+   pxp->stream_cmd.obj = obj;
+   pxp->stream_cmd.vaddr = cmd;
+
+   return 0;
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+   return err;
+}
+
+static void free_streaming_command(struct intel_pxp *pxp)
+{
+   struct drm_i915_gem_object *obj = fetch_and_zero(>stream_cmd.obj);
+
+   if (!obj)
+   return;
+
+   i915_gem_object_unpin_map(obj);
+   i915_gem_object_unpin_pages(obj);
+   i915_gem_object_put(obj);
+}
+
 int intel_pxp_tee_component_init(struct intel_pxp *pxp)
 {
int ret;
@@ -134,16 +236,24 @@ int 

[PATCH v2 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2

2022-08-18 Thread Daniele Ceraolo Spurio
The fw name is different and we need to record the fact that the blob is
gsc-loaded, so add a new macro to help.

Note: A-step DG2 G10 does not support HuC loading via GSC and would
require a separate firmware to be loaded the legacy way, but that's
not a production stepping so we're not going to bother.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Tony Ye 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 ++--
 1 file changed, 37 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index cec6bf6bad3f..776b43d79772 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -74,35 +74,39 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
fw_def(ALDERLAKE_P,  0, guc_def(adlp, 69, 0, 3)) \
fw_def(ALDERLAKE_S,  0, guc_def(tgl,  69, 0, 3))
 
-#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_def) \
-   fw_def(ALDERLAKE_P,  0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(ALDERLAKE_S,  0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(DG1,  0, huc_def(dg1,  7, 9, 3)) \
-   fw_def(ROCKETLAKE,   0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(TIGERLAKE,0, huc_def(tgl,  7, 9, 3)) \
-   fw_def(JASPERLAKE,   0, huc_def(ehl,  9, 0, 0)) \
-   fw_def(ELKHARTLAKE,  0, huc_def(ehl,  9, 0, 0)) \
-   fw_def(ICELAKE,  0, huc_def(icl,  9, 0, 0)) \
-   fw_def(COMETLAKE,5, huc_def(cml,  4, 0, 0)) \
-   fw_def(COMETLAKE,0, huc_def(kbl,  4, 0, 0)) \
-   fw_def(COFFEELAKE,   0, huc_def(kbl,  4, 0, 0)) \
-   fw_def(GEMINILAKE,   0, huc_def(glk,  4, 0, 0)) \
-   fw_def(KABYLAKE, 0, huc_def(kbl,  4, 0, 0)) \
-   fw_def(BROXTON,  0, huc_def(bxt,  2, 0, 0)) \
-   fw_def(SKYLAKE,  0, huc_def(skl,  2, 0, 0))
-
-#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
+#define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_dma_def, huc_gsc_def) \
+   fw_def(DG2,  0, huc_gsc_def(dg2,  7, 10, 0)) \
+   fw_def(ALDERLAKE_P,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(ALDERLAKE_S,  0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(DG1,  0, huc_dma_def(dg1,  7, 9, 3)) \
+   fw_def(ROCKETLAKE,   0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(TIGERLAKE,0, huc_dma_def(tgl,  7, 9, 3)) \
+   fw_def(JASPERLAKE,   0, huc_dma_def(ehl,  9, 0, 0)) \
+   fw_def(ELKHARTLAKE,  0, huc_dma_def(ehl,  9, 0, 0)) \
+   fw_def(ICELAKE,  0, huc_dma_def(icl,  9, 0, 0)) \
+   fw_def(COMETLAKE,5, huc_dma_def(cml,  4, 0, 0)) \
+   fw_def(COMETLAKE,0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(COFFEELAKE,   0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(GEMINILAKE,   0, huc_dma_def(glk,  4, 0, 0)) \
+   fw_def(KABYLAKE, 0, huc_dma_def(kbl,  4, 0, 0)) \
+   fw_def(BROXTON,  0, huc_dma_def(bxt,  2, 0, 0)) \
+   fw_def(SKYLAKE,  0, huc_dma_def(skl,  2, 0, 0))
+
+#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_, postfix_) \
"i915/" \
__stringify(prefix_) name_ \
__stringify(major_) "." \
__stringify(minor_) "." \
-   __stringify(patch_) ".bin"
+   __stringify(patch_) postfix_ ".bin"
 
 #define MAKE_GUC_FW_PATH(prefix_, major_, minor_, patch_) \
-   __MAKE_UC_FW_PATH(prefix_, "_guc_", major_, minor_, patch_)
+   __MAKE_UC_FW_PATH(prefix_, "_guc_", major_, minor_, patch_, "")
 
 #define MAKE_HUC_FW_PATH(prefix_, major_, minor_, bld_num_) \
-   __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_)
+   __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_, "")
+
+#define MAKE_HUC_GSC_FW_PATH(prefix_, major_, minor_, bld_num_) \
+   __MAKE_UC_FW_PATH(prefix_, "_huc_", major_, minor_, bld_num_, "_gsc")
 
 /* All blobs need to be declared via MODULE_FIRMWARE() */
 #define INTEL_UC_MODULE_FW(platform_, revid_, uc_) \
@@ -110,26 +114,31 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
 
 INTEL_GUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH)
 INTEL_GUC_FIRMWARE_DEFS_FALLBACK(INTEL_UC_MODULE_FW, MAKE_GUC_FW_PATH)
-INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH)
+INTEL_HUC_FIRMWARE_DEFS(INTEL_UC_MODULE_FW, MAKE_HUC_FW_PATH, 
MAKE_HUC_GSC_FW_PATH)
 
 /* The below structs and macros are used to iterate across the list of blobs */
 struct __packed uc_fw_blob {
u8 major;
u8 minor;
+   bool loaded_via_gsc;
const char *path;
 };
 
-#define UC_FW_BLOB(major_, minor_, path_) \
-   { .major = major_, .minor = minor_, .path = path_ }
+#define UC_FW_BLOB(major_, minor_, gsc_, path_) \
+   { .major = major_, .minor = minor_, .loaded_via_gsc = gsc_, .path = 
path_ }
 
 #define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
-   UC_FW_BLOB(major_, minor_, \
+   UC_FW_BLOB(major_, minor_, false, \
   MAKE_GUC_FW_PATH(prefix_, major_, minor_, patch_))
 
 #define 

[PATCH v2 12/15] drm/i915/huc: stall media submission until HuC is loaded

2022-08-18 Thread Daniele Ceraolo Spurio
Wait on the fence to be signalled to avoid the submissions finding HuC
not yet loaded.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Tony Ye 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_huc.h |  6 ++
 drivers/gpu/drm/i915/i915_request.c| 24 
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index 49374f306a7f..209de60474a5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -77,6 +77,12 @@ static inline bool intel_huc_is_loaded_by_gsc(const struct 
intel_huc *huc)
return huc->fw.loaded_via_gsc;
 }
 
+static inline bool intel_huc_wait_required(struct intel_huc *huc)
+{
+   return intel_huc_is_used(huc) && intel_huc_is_loaded_by_gsc(huc) &&
+  !intel_huc_is_authenticated(huc);
+}
+
 void intel_huc_load_status(struct intel_huc *huc, struct drm_printer *p);
 
 #endif
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 62fad16a55e8..77f45a3cb01f 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1621,6 +1621,20 @@ i915_request_await_object(struct i915_request *to,
return ret;
 }
 
+static void i915_request_await_huc(struct i915_request *rq)
+{
+   struct intel_huc *huc = >context->engine->gt->uc.huc;
+
+   /* don't stall kernel submissions! */
+   if (!rcu_access_pointer(rq->context->gem_context))
+   return;
+
+   if (intel_huc_wait_required(huc))
+   i915_sw_fence_await_sw_fence(>submit,
+>delayed_load.fence,
+>submitq);
+}
+
 static struct i915_request *
 __i915_request_ensure_parallel_ordering(struct i915_request *rq,
struct intel_timeline *timeline)
@@ -1702,6 +1716,16 @@ __i915_request_add_to_timeline(struct i915_request *rq)
struct intel_timeline *timeline = i915_request_timeline(rq);
struct i915_request *prev;
 
+   /*
+* Media workloads may require HuC, so stall them until HuC loading is
+* complete. Note that HuC not being loaded when a user submission
+* arrives can only happen when HuC is loaded via GSC and in that case
+* we still expect the window between us starting to accept submissions
+* and HuC loading completion to be small (a few hundred ms).
+*/
+   if (rq->engine->class == VIDEO_DECODE_CLASS)
+   i915_request_await_huc(rq);
+
/*
 * Dependency tracking and request ordering along the timeline
 * is special cased so that we can eliminate redundant ordering
-- 
2.37.2



[PATCH v2 06/15] mei: pxp: support matching with a gfx discrete card

2022-08-18 Thread Daniele Ceraolo Spurio
From: Tomas Winkler 

With on-boards graphics card, both i915 and MEI
are in the same device hierarchy with the same parent,
while for discrete gfx card the MEI is its child device.
Adjust the match function for that scenario
by matching MEI parent device with i915.

V2:
 1. More detailed commit message
 2. Check for dev is not null before it is accessed.

Signed-off-by: Tomas Winkler 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Vitaly Lubart 
Reviewed-by: Alan Previn 
---
 drivers/misc/mei/pxp/mei_pxp.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
index 17c5d201603f..afc047627800 100644
--- a/drivers/misc/mei/pxp/mei_pxp.c
+++ b/drivers/misc/mei/pxp/mei_pxp.c
@@ -159,17 +159,24 @@ static int mei_pxp_component_match(struct device *dev, 
int subcomponent,
 {
struct device *base = data;
 
+   if (!dev)
+   return 0;
+
if (!dev->driver || strcmp(dev->driver->name, "i915") ||
subcomponent != I915_COMPONENT_PXP)
return 0;
 
base = base->parent;
-   if (!base)
+   if (!base) /* mei device */
return 0;
 
-   base = base->parent;
-   dev = dev->parent;
+   base = base->parent; /* pci device */
+   /* for dgfx */
+   if (base && dev == base)
+   return 1;
 
+   /* for pch */
+   dev = dev->parent;
return (base && dev && dev == base);
 }
 
-- 
2.37.2



[PATCH v2 03/15] mei: bus: enable sending gsc commands

2022-08-18 Thread Daniele Ceraolo Spurio
From: Tomas Winkler 

GSC command is and extended header containing a scatter gather
list and without a data buffer. Using MEI_CL_IO_SGL flag,
the caller send the GSC command as a data and the function internally
moves it to the extended header.

Signed-off-by: Tomas Winkler 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Vitaly Lubart 
---
 drivers/misc/mei/bus.c | 20 ++--
 drivers/misc/mei/mei_dev.h |  4 
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 46aa3554e97b..225f0b04c021 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -100,9 +100,18 @@ ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, 
size_t length, u8 vtag,
cb->internal = !!(mode & MEI_CL_IO_TX_INTERNAL);
cb->blocking = !!(mode & MEI_CL_IO_TX_BLOCKING);
memcpy(cb->buf.data, buf, length);
+   /* hack we point data to header */
+   if (mode & MEI_CL_IO_SGL) {
+   cb->ext_hdr = (struct mei_ext_hdr *)cb->buf.data;
+   cb->buf.data = NULL;
+   cb->buf.size = 0;
+   }
 
rets = mei_cl_write(cl, cb);
 
+   if (mode & MEI_CL_IO_SGL && rets == 0)
+   rets = length;
+
 out:
mutex_unlock(>device_lock);
 
@@ -205,9 +214,16 @@ ssize_t __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t 
length, u8 *vtag,
goto free;
}
 
-   r_length = min_t(size_t, length, cb->buf_idx);
-   memcpy(buf, cb->buf.data, r_length);
+   /* for the GSC type - copy the extended header to the buffer */
+   if (cb->ext_hdr && cb->ext_hdr->type == MEI_EXT_HDR_GSC) {
+   r_length = min_t(size_t, length, cb->ext_hdr->length * 
sizeof(u32));
+   memcpy(buf, cb->ext_hdr, r_length);
+   } else {
+   r_length = min_t(size_t, length, cb->buf_idx);
+   memcpy(buf, cb->buf.data, r_length);
+   }
rets = r_length;
+
if (vtag)
*vtag = cb->vtag;
 
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 862190b297aa..5e28294d5dca 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -109,12 +109,16 @@ enum mei_cb_file_ops {
  * @MEI_CL_IO_TX_INTERNAL: internal communication between driver and FW
  *
  * @MEI_CL_IO_RX_NONBLOCK: recv is non-blocking
+ *
+ * @MEI_CL_IO_SGL: send command with sgl list.
  */
 enum mei_cl_io_mode {
MEI_CL_IO_TX_BLOCKING = BIT(0),
MEI_CL_IO_TX_INTERNAL = BIT(1),
 
MEI_CL_IO_RX_NONBLOCK = BIT(2),
+
+   MEI_CL_IO_SGL = BIT(3),
 };
 
 /*
-- 
2.37.2



[PATCH v2 07/15] drm/i915/pxp: load the pxp module when we have a gsc-loaded huc

2022-08-18 Thread Daniele Ceraolo Spurio
The mei_pxp module is required to send the command to load authenticate
the HuC to the GSC even if pxp is not in use for protected content
management.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Reviewed-by: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile| 10 +++---
 drivers/gpu/drm/i915/pxp/intel_pxp.c | 32 +---
 drivers/gpu/drm/i915/pxp/intel_pxp.h | 32 
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h |  8 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  8 -
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 11 +--
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 10 --
 7 files changed, 57 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..589823ad62ed 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -307,15 +307,17 @@ i915-y += \
 
 i915-y += i915_perf.o
 
-# Protected execution platform (PXP) support
-i915-$(CONFIG_DRM_I915_PXP) += \
+# Protected execution platform (PXP) support. Base support is required for HuC
+i915-y += \
pxp/intel_pxp.o \
+   pxp/intel_pxp_tee.o
+
+i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
-   pxp/intel_pxp_session.o \
-   pxp/intel_pxp_tee.o
+   pxp/intel_pxp_session.o
 
 # Post-mortem debug and GPU hang state capture
 i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 15311eaed848..b602a51c3692 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -103,19 +103,15 @@ static int create_vcs_context(struct intel_pxp *pxp)
 
 static void destroy_vcs_context(struct intel_pxp *pxp)
 {
-   intel_engine_destroy_pinned_context(fetch_and_zero(>ce));
+   if (pxp->ce)
+   intel_engine_destroy_pinned_context(fetch_and_zero(>ce));
 }
 
-void intel_pxp_init(struct intel_pxp *pxp)
+static void pxp_init_full(struct intel_pxp *pxp)
 {
struct intel_gt *gt = pxp_to_gt(pxp);
int ret;
 
-   if (!HAS_PXP(gt->i915))
-   return;
-
-   mutex_init(>tee_mutex);
-
/*
 * we'll use the completion to check if there is a termination pending,
 * so we start it as completed and we reinit it when a termination
@@ -124,8 +120,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
 
-   mutex_init(>arb_mutex);
-   INIT_WORK(>session_work, intel_pxp_session_work);
+   intel_pxp_session_management_init(pxp);
 
ret = create_vcs_context(pxp);
if (ret)
@@ -143,11 +138,26 @@ void intel_pxp_init(struct intel_pxp *pxp)
destroy_vcs_context(pxp);
 }
 
-void intel_pxp_fini(struct intel_pxp *pxp)
+void intel_pxp_init(struct intel_pxp *pxp)
 {
-   if (!intel_pxp_is_enabled(pxp))
+   struct intel_gt *gt = pxp_to_gt(pxp);
+
+   /* we rely on the mei PXP module */
+   if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
return;
 
+   /*
+* If HuC is loaded by GSC but PXP is disabled, we can skip the init of
+* the full PXP session/object management and just init the tee channel.
+*/
+   if (HAS_PXP(gt->i915))
+   pxp_init_full(pxp);
+   else if (intel_huc_is_loaded_by_gsc(>uc.huc) && 
intel_uc_uses_huc(>uc))
+   intel_pxp_tee_component_init(pxp);
+}
+
+void intel_pxp_fini(struct intel_pxp *pxp)
+{
pxp->arb_is_valid = false;
 
intel_pxp_tee_component_fini(pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 73847e535cab..2da309088c6d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -12,7 +12,6 @@
 struct intel_pxp;
 struct drm_i915_gem_object;
 
-#ifdef CONFIG_DRM_I915_PXP
 struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
 bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
 bool intel_pxp_is_active(const struct intel_pxp *pxp);
@@ -32,36 +31,5 @@ int intel_pxp_key_check(struct intel_pxp *pxp,
bool assign);
 
 void intel_pxp_invalidate(struct intel_pxp *pxp);
-#else
-static inline void intel_pxp_init(struct intel_pxp *pxp)
-{
-}
-
-static inline void intel_pxp_fini(struct intel_pxp *pxp)
-{
-}
-
-static inline int intel_pxp_start(struct intel_pxp *pxp)
-{
-   return -ENODEV;
-}
-
-static inline bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
-{
-   return false;
-}
-
-static inline bool intel_pxp_is_active(const struct intel_pxp *pxp)
-{
-   return false;
-}
-
-static inline int intel_pxp_key_check(struct intel_pxp *pxp,
- struct drm_i915_gem_object *obj,
- bool 

[PATCH v2 01/15] HAX: mei: GSC support for XeHP SDV and DG2 platform

2022-08-18 Thread Daniele Ceraolo Spurio
This is a squash of the GSC support for XeHP SDV and DG2 series, which
is being reviewed separately at:
https://patchwork.freedesktop.org/series/106638/

Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gsc.c | 118 +---
 drivers/gpu/drm/i915/gt/intel_gsc.h |   3 +
 drivers/misc/mei/bus-fixup.c| 104 
 drivers/misc/mei/client.c   |  14 ++--
 drivers/misc/mei/debugfs.c  |  17 
 drivers/misc/mei/gsc-me.c   |  77 +++---
 drivers/misc/mei/hbm.c  |  12 +--
 drivers/misc/mei/hw-me-regs.h   |   7 ++
 drivers/misc/mei/hw-me.c| 116 ++-
 drivers/misc/mei/hw-me.h|  14 +++-
 drivers/misc/mei/hw-txe.c   |   2 +-
 drivers/misc/mei/hw.h   |   5 ++
 drivers/misc/mei/init.c |  21 -
 drivers/misc/mei/main.c |   2 +-
 drivers/misc/mei/mei_dev.h  |  26 ++
 drivers/misc/mei/mkhi.h |  57 ++
 drivers/misc/mei/pci-me.c   |   2 +-
 include/linux/mei_aux.h |  12 +++
 18 files changed, 518 insertions(+), 91 deletions(-)
 create mode 100644 drivers/misc/mei/mkhi.h

diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c 
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 0e494028b81d..162bea57fbb5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -7,6 +7,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_reg.h"
+#include "gem/i915_gem_region.h"
 #include "gt/intel_gsc.h"
 #include "gt/intel_gt.h"
 
@@ -36,10 +37,68 @@ static int gsc_irq_init(int irq)
return irq_set_chip_data(irq, NULL);
 }
 
+static int
+gsc_ext_om_alloc(struct intel_gsc *gsc, struct intel_gsc_intf *intf, size_t 
size)
+{
+   struct intel_gt *gt = gsc_to_gt(gsc);
+   struct drm_i915_gem_object *obj;
+   void *vaddr;
+   int err;
+
+   obj = i915_gem_object_create_lmem(gt->i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(obj)) {
+   drm_err(>i915->drm, "Failed to allocate gsc memory\n");
+   return PTR_ERR(obj);
+   }
+
+   err = i915_gem_object_pin_pages_unlocked(obj);
+   if (err) {
+   drm_err(>i915->drm, "Failed to pin pages for gsc memory\n");
+   goto out_put;
+   }
+
+   vaddr = i915_gem_object_pin_map_unlocked(obj, 
i915_coherent_map_type(gt->i915, obj, true));
+   if (IS_ERR(vaddr)) {
+   err = PTR_ERR(vaddr);
+   drm_err(>i915->drm, "Failed to map gsc memory\n");
+   goto out_unpin;
+   }
+
+   memset(vaddr, 0, obj->base.size);
+
+   i915_gem_object_unpin_map(obj);
+
+   intf->gem_obj = obj;
+
+   return 0;
+
+out_unpin:
+   i915_gem_object_unpin_pages(obj);
+out_put:
+   i915_gem_object_put(obj);
+   return err;
+}
+
+static void gsc_ext_om_destroy(struct intel_gsc_intf *intf)
+{
+   struct drm_i915_gem_object *obj = fetch_and_zero(>gem_obj);
+
+   if (!obj)
+   return;
+
+   if (i915_gem_object_has_pinned_pages(obj))
+   i915_gem_object_unpin_pages(obj);
+
+   i915_gem_object_put(obj);
+}
+
 struct gsc_def {
const char *name;
unsigned long bar;
size_t bar_size;
+   bool use_polling;
+   bool slow_firmware;
+   size_t lmem_size;
 };
 
 /* gsc resources and definitions (HECI1 and HECI2) */
@@ -54,11 +113,25 @@ static const struct gsc_def gsc_def_dg1[] = {
}
 };
 
+static const struct gsc_def gsc_def_xehpsdv[] = {
+   {
+   /* HECI1 not enabled on the device. */
+   },
+   {
+   .name = "mei-gscfi",
+   .bar = DG1_GSC_HECI2_BASE,
+   .bar_size = GSC_BAR_LENGTH,
+   .use_polling = true,
+   .slow_firmware = true,
+   }
+};
+
 static const struct gsc_def gsc_def_dg2[] = {
{
.name = "mei-gsc",
.bar = DG2_GSC_HECI1_BASE,
.bar_size = GSC_BAR_LENGTH,
+   .lmem_size = SZ_4M,
},
{
.name = "mei-gscfi",
@@ -75,26 +148,32 @@ static void gsc_release_dev(struct device *dev)
kfree(adev);
 }
 
-static void gsc_destroy_one(struct intel_gsc_intf *intf)
+static void gsc_destroy_one(struct drm_i915_private *i915,
+   struct intel_gsc *gsc, unsigned int intf_id)
 {
+   struct intel_gsc_intf *intf = >intf[intf_id];
+
if (intf->adev) {
auxiliary_device_delete(>adev->aux_dev);
auxiliary_device_uninit(>adev->aux_dev);
intf->adev = NULL;
}
+
if (intf->irq >= 0)
irq_free_desc(intf->irq);
intf->irq = -1;
+
+   gsc_ext_om_destroy(intf);
 }
 
-static void gsc_init_one(struct drm_i915_private *i915,
-struct intel_gsc_intf *intf,
+static void gsc_init_one(struct 

[PATCH v2 00/15] drm/i915: HuC loading for DG2

2022-08-18 Thread Daniele Ceraolo Spurio
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need to first export the GSC as an aux device and then wait
for the mei-gsc and mei-pxp modules to start, which means that HuC
load will complete after i915 load is complete. This means that there
is a small window of time after i915 is registered and before HuC is
loaded during which userspace could submit and/or check the HuC load
status, although this is quite unlikely to happen (HuC is usually loaded
before kernel init/resume completes).
We've consulted with the media team in regards to how to handle this and
they've asked us to stall all userspace VCS submission until HuC is
loaded. Stalls are expected to be very rare (if any), due to the fact
that HuC is usually loaded before kernel init/resume is completed.

Timeouts are in place to ensure all submissions are unlocked in case
something goes wrong. Since we need to monitor the status of the mei
driver to know what's happening and when to time out, a notifier has
been added so we get a callback when the status of the mei driver
changes.

Note that this series includes several mei patches that add support for
sending the HuC loading command via mei-gsc. These patches depend on the
GSC support for DG2 [1], which has been included squashed in a single
patch to make the series apply and allow CI to run. We plan to merge
those patches through the drm tree because i915 is the sole user.

[1]: https://patchwork.freedesktop.org/series/106638/

v2: address review comments, Reporting HuC loading still in progress
while we wait for mei-gsc init to complete, rebase on latest mei-gsc
series.

Test-with: 20220818224216.3920822-1-daniele.ceraolospu...@intel.com
Cc: Alan Previn 
Cc: Tony Ye 
Cc: Alexander Usyskin 
Cc: Tomas Winkler 
Cc: Greg Kroah-Hartman 

Daniele Ceraolo Spurio (8):
  HAX: mei: GSC support for XeHP SDV and DG2 platform
  drm/i915/pxp: load the pxp module when we have a gsc-loaded huc
  drm/i915/dg2: setup HuC loading via GSC
  drm/i915/huc: track delayed HuC load with a fence
  drm/i915/huc: stall media submission until HuC is loaded
  drm/i915/huc: better define HuC status getparam possible return
values.
  drm/i915/huc: define gsc-compatible HuC fw for DG2
  HAX: drm/i915: force INTEL_MEI_GSC and INTEL_MEI_PXP on for CI

Tomas Winkler (4):
  mei: add support to GSC extended header
  mei: bus: enable sending gsc commands
  mei: pxp: support matching with a gfx discrete card
  drm/i915/pxp: add huc authentication and loading command

Vitaly Lubart (3):
  mei: bus: extend bus API to support command streamer API
  mei: pxp: add command streamer API to the PXP driver
  drm/i915/pxp: implement function for sending tee stream command

 drivers/gpu/drm/i915/Kconfig.debug|   2 +
 drivers/gpu/drm/i915/Makefile |  11 +-
 drivers/gpu/drm/i915/gt/intel_gsc.c   | 140 +-
 drivers/gpu/drm/i915/gt/intel_gsc.h   |   3 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   1 +
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 253 --
 drivers/gpu/drm/i915/gt/uc/intel_huc.h|  27 ++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c |  34 +++
 drivers/gpu/drm/i915/gt/uc/intel_huc_fw.h |   1 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  65 +++--
 drivers/gpu/drm/i915/i915_request.c   |  24 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.c  |  32 ++-
 drivers/gpu/drm/i915/pxp/intel_pxp.h  |  32 ---
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |  69 +
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h  |  15 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h  |   8 +
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |   8 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.h  |  11 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 138 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h  |   5 +
 .../drm/i915/pxp/intel_pxp_tee_interface.h|  21 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|   6 +
 drivers/misc/mei/bus-fixup.c  | 104 ---
 drivers/misc/mei/bus.c| 145 +-
 drivers/misc/mei/client.c |  69 +++--
 drivers/misc/mei/debugfs.c|  17 ++
 drivers/misc/mei/gsc-me.c |  77 +-
 drivers/misc/mei/hbm.c|  25 +-
 drivers/misc/mei/hw-me-regs.h |   7 +
 drivers/misc/mei/hw-me.c  | 121 +++--
 drivers/misc/mei/hw-me.h  |  14 +-
 drivers/misc/mei/hw-txe.c |   2 +-
 drivers/misc/mei/hw.h |  62 +
 drivers/misc/mei/init.c   |  21 +-
 drivers/misc/mei/interrupt.c  |  47 +++-
 drivers/misc/mei/main.c   

Re: [PATCH] gpu: move from strlcpy with unused retval to strscpy

2022-08-18 Thread Laurent Pinchart
Hi Wolfram,

Thank you for the patch.

On Thu, Aug 18, 2022 at 11:00:07PM +0200, Wolfram Sang wrote:
> Follow the advice of the below link and prefer 'strscpy' in this
> subsystem. Conversion is 1:1 because the return value is not used.
> Generated by a coccinelle script.
> 
> Link: 
> https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
> Signed-off-by: Wolfram Sang 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/amd/amdgpu/atom.c   | 2 +-
>  drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c  | 2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 +++---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 2 +-
>  drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
>  drivers/gpu/drm/display/drm_dp_mst_topology.c   | 2 +-
>  drivers/gpu/drm/drm_mipi_dsi.c  | 2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c   | 2 +-
>  drivers/gpu/drm/i915/selftests/i915_perf.c  | 2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +-
>  drivers/gpu/drm/radeon/radeon_atombios.c| 4 ++--
>  drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
>  drivers/gpu/drm/rockchip/inno_hdmi.c| 2 +-
>  drivers/gpu/drm/rockchip/rk3066_hdmi.c  | 2 +-
>  drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c  | 2 +-
>  15 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 1c5d9388ad0b..5f610e9a5f0f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -1509,7 +1509,7 @@ struct atom_context *amdgpu_atom_parse(struct card_info 
> *card, void *bios)
>   str = CSTR(idx);
>   if (*str != '\0') {
>   pr_info("ATOM BIOS: %s\n", str);
> - strlcpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
> + strscpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
>   }
>  
>   atom_rom_header = (struct _ATOM_ROM_HEADER *)CSTR(base);
> diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c 
> b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> index d3fe149d8476..81fb4e5dd804 100644
> --- a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
> @@ -794,7 +794,7 @@ void amdgpu_add_thermal_controller(struct amdgpu_device 
> *adev)
>   struct i2c_board_info info = { };
>   const char *name = 
> pp_lib_thermal_controller_names[controller->ucType];
>   info.addr = controller->ucI2cAddress >> 1;
> - strlcpy(info.type, name, sizeof(info.type));
> + strscpy(info.type, name, sizeof(info.type));
>   
> i2c_new_client_device(>pm.i2c_bus->adapter, );
>   }
>   } else {
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> index 7d2ed0ed2fe2..4efb62bcdb63 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> @@ -542,8 +542,8 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
>   if (ret < 0)
>   return ret;
>  
> - strlcpy(card->driver, DRIVER_NAME, sizeof(card->driver));
> - strlcpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
> + strscpy(card->driver, DRIVER_NAME, sizeof(card->driver));
> + strscpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
>   snprintf(card->longname, sizeof(card->longname),
>"%s rev 0x%02x, irq %d", card->shortname, revision,
>data->irq);
> @@ -561,7 +561,7 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
>  
>   dw->pcm = pcm;
>   pcm->private_data = dw;
> - strlcpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
> + strscpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
>   snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, _dw_hdmi_ops);
>  
>   /*
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 25a60eb4d67c..4f3ae976e677 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -533,7 +533,7 @@ static struct i2c_adapter *dw_hdmi_i2c_adapter(struct 
> dw_hdmi *hdmi)
>   adap->owner = THIS_MODULE;
>   adap->dev.parent = hdmi->dev;
>   adap->algo = _hdmi_algorithm;
> - strlcpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
> + strscpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
>   i2c_set_adapdata(adap, hdmi);
>  
>   ret = i2c_add_adapter(adap);
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e5bab236b3ae..10a39b36a661 100644
> --- 

Re: [PATCH v25 00/10] Add MediaTek SoC(vdosys1) support for mt8195

2022-08-18 Thread Nícolas F . R . A . Prado
On Fri, Aug 05, 2022 at 06:04:08PM +0800, Nancy.Lin wrote:
[..]
> Hello Matthias,
> 
> This series is about mmsys configuration of external display path.
> 
> It is in version *25*, and it is reviewed by many reviewers, like CK
> and Angelo.
> The reset.h is also reviewed by Krzysztof.
> 
> This series is also well tested by Rex-BC and Angelo.

There is actually a silly but breaking bug in this version [1] affecting a lot
of platforms, including mt8192.

I'll provide a Tested-by tag for mt8192 in the next version, just in case. (If
you can, please CC me, Nancy).

Thanks,
Nícolas

[1] https://lore.kernel.org/all/20220818214715.spbyic34szubx3gi@notapiano/


Re: [PATCH v25 07/10] soc: mediatek: mmsys: add mmsys for support 64 reset bits

2022-08-18 Thread Nícolas F . R . A . Prado
Hi Nancy,

On Mon, Jul 11, 2022 at 03:52:42PM +0800, Nancy.Lin wrote:
[..]
>  static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
>   .clk_driver = "clk-mt2701-mm",
>   .routes = mmsys_default_routing_table,
> @@ -86,6 +88,7 @@ static const struct mtk_mmsys_driver_data 
> mt8173_mmsys_driver_data = {
>   .routes = mmsys_default_routing_table,
>   .num_routes = ARRAY_SIZE(mmsys_default_routing_table),
>   .sw0_rst_offset = MT8183_MMSYS_SW0_RST_B,
> + .num_resets = 32,
>  };
>  
>  static const struct mtk_mmsys_match_data mt8173_mmsys_match_data = {
> @@ -100,6 +103,7 @@ static const struct mtk_mmsys_driver_data 
> mt8183_mmsys_driver_data = {
>   .routes = mmsys_mt8183_routing_table,
>   .num_routes = ARRAY_SIZE(mmsys_mt8183_routing_table),
>   .sw0_rst_offset = MT8183_MMSYS_SW0_RST_B,
> + .num_resets = 32,
>  };
>  
>  static const struct mtk_mmsys_match_data mt8183_mmsys_match_data = {
> @@ -114,6 +118,7 @@ static const struct mtk_mmsys_driver_data 
> mt8186_mmsys_driver_data = {
>   .routes = mmsys_mt8186_routing_table,
>   .num_routes = ARRAY_SIZE(mmsys_mt8186_routing_table),
>   .sw0_rst_offset = MT8186_MMSYS_SW0_RST_B,
> + .num_resets = 32,
>  };
[..]
> @@ -351,18 +362,6 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - spin_lock_init(>lock);
> -
> - mmsys->rcdev.owner = THIS_MODULE;
> - mmsys->rcdev.nr_resets = 32;

The number of resets was previously always set to 32, and now you're instead
setting it based on num_resets from each machine. The issue is, you're
forgetting a bunch of them.

mt8192 didn't get a num_reset, so this commit breaks the display on mt8192 based
devices. But mt8192 isn't the only one, there are other platforms missing this
property. Please set num_resets to 32 in every single one of them, otherwise
there will be display regressions.

Thanks,
Nícolas


Requests For Proposals for hosting XDC 2023 are now open

2022-08-18 Thread Lyude Paul
Hello everyone!

The X.org board is soliciting proposals to host XDC in 2023. Since
XDC 2022 is being held in North America this year, XDC 2023 is expected
to be in Europe. However, the board is open to other locations,
especially if there's an interesting co-location with another
conference.

If you're considering hosting XDC, we've assembled a wiki page with
what's generally expected and needed:

https://www.x.org/wiki/Events/RFP/

When submitting your proposal, please make sure to include at least the
key information about the potential location in question, possible
dates along with estimated costs. Proposals can be submitted to board
at foundation.x.org until the deadline of *September 1st, 2022*. 

Additionally, an quirk early heads-up to the board if you're
considering hosting would be appreciated, in case we need to adjust the
schedule a bit. Also, earlier is better since there generally will be a
bit of Q with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.

Best regards,
Lyude Paul
On behalf of X.org

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat



[PATCH] video: move from strlcpy with unused retval to strscpy

2022-08-18 Thread Wolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang 
---
 drivers/video/console/sticore.c| 2 +-
 drivers/video/fbdev/aty/atyfb_base.c   | 2 +-
 drivers/video/fbdev/aty/radeon_base.c  | 2 +-
 drivers/video/fbdev/bw2.c  | 2 +-
 drivers/video/fbdev/cirrusfb.c | 2 +-
 drivers/video/fbdev/clps711x-fb.c  | 2 +-
 drivers/video/fbdev/core/fbcon.c   | 2 +-
 drivers/video/fbdev/cyber2000fb.c  | 8 
 drivers/video/fbdev/ffb.c  | 2 +-
 drivers/video/fbdev/geode/gx1fb_core.c | 6 +++---
 drivers/video/fbdev/gxt4500.c  | 2 +-
 drivers/video/fbdev/i740fb.c   | 2 +-
 drivers/video/fbdev/imxfb.c| 2 +-
 drivers/video/fbdev/matrox/matroxfb_base.c | 6 +++---
 drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +-
 drivers/video/fbdev/pxa168fb.c | 2 +-
 drivers/video/fbdev/pxafb.c| 2 +-
 drivers/video/fbdev/s3fb.c | 2 +-
 drivers/video/fbdev/simplefb.c | 2 +-
 drivers/video/fbdev/sis/sis_main.c | 4 ++--
 drivers/video/fbdev/sm501fb.c  | 2 +-
 drivers/video/fbdev/sstfb.c| 2 +-
 drivers/video/fbdev/sunxvr1000.c   | 2 +-
 drivers/video/fbdev/sunxvr2500.c   | 2 +-
 drivers/video/fbdev/sunxvr500.c| 2 +-
 drivers/video/fbdev/tcx.c  | 2 +-
 drivers/video/fbdev/tdfxfb.c   | 4 ++--
 drivers/video/fbdev/tgafb.c| 2 +-
 drivers/video/fbdev/tridentfb.c| 2 +-
 29 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/video/console/sticore.c b/drivers/video/console/sticore.c
index bd4dc97d4d34..db568f67e4dc 100644
--- a/drivers/video/console/sticore.c
+++ b/drivers/video/console/sticore.c
@@ -290,7 +290,7 @@ static char default_sti_path[21] __read_mostly;
 static int __init sti_setup(char *str)
 {
if (str)
-   strlcpy (default_sti_path, str, sizeof (default_sti_path));
+   strscpy(default_sti_path, str, sizeof(default_sti_path));

return 1;
 }
diff --git a/drivers/video/fbdev/aty/atyfb_base.c 
b/drivers/video/fbdev/aty/atyfb_base.c
index a3e6faed7745..14eb718bd67c 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3891,7 +3891,7 @@ static int __init atyfb_setup(char *options)
 && (!strncmp(this_opt, "Mach64:", 7))) {
static unsigned char m64_num;
static char mach64_str[80];
-   strlcpy(mach64_str, this_opt + 7, sizeof(mach64_str));
+   strscpy(mach64_str, this_opt + 7, sizeof(mach64_str));
if (!store_video_par(mach64_str, m64_num)) {
m64_num++;
mach64_count = m64_num;
diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 6851f47613e1..73b07c77a4e1 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -1980,7 +1980,7 @@ static int radeon_set_fbinfo(struct radeonfb_info *rinfo)
info->screen_base = rinfo->fb_base;
info->screen_size = rinfo->mapped_vram;
/* Fill fix common fields */
-   strlcpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
+   strscpy(info->fix.id, rinfo->name, sizeof(info->fix.id));
 info->fix.smem_start = rinfo->fb_base_phys;
 info->fix.smem_len = rinfo->video_ram;
 info->fix.type = FB_TYPE_PACKED_PIXELS;
diff --git a/drivers/video/fbdev/bw2.c b/drivers/video/fbdev/bw2.c
index e7702fe1fe7d..6403ae07970d 100644
--- a/drivers/video/fbdev/bw2.c
+++ b/drivers/video/fbdev/bw2.c
@@ -182,7 +182,7 @@ static int bw2_ioctl(struct fb_info *info, unsigned int 
cmd, unsigned long arg)
 
 static void bw2_init_fix(struct fb_info *info, int linebytes)
 {
-   strlcpy(info->fix.id, "bwtwo", sizeof(info->fix.id));
+   strscpy(info->fix.id, "bwtwo", sizeof(info->fix.id));
 
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = FB_VISUAL_MONO01;
diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
index a41a75841e10..2a9fa06881b5 100644
--- a/drivers/video/fbdev/cirrusfb.c
+++ b/drivers/video/fbdev/cirrusfb.c
@@ -1999,7 +1999,7 @@ static int cirrusfb_set_fbinfo(struct fb_info *info)
}
 
/* Fill fix common fields */
-   strlcpy(info->fix.id, cirrusfb_board_info[cinfo->btype].name,
+   strscpy(info->fix.id, cirrusfb_board_info[cinfo->btype].name,

[PATCH] dma-buf: move from strlcpy with unused retval to strscpy

2022-08-18 Thread Wolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang 
---
 drivers/dma-buf/sw_sync.c   | 2 +-
 drivers/dma-buf/sync_file.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 348b3a9170fa..63f0aeb66db6 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -85,7 +85,7 @@ static struct sync_timeline *sync_timeline_create(const char 
*name)
 
kref_init(>kref);
obj->context = dma_fence_context_alloc(1);
-   strlcpy(obj->name, name, sizeof(obj->name));
+   strscpy(obj->name, name, sizeof(obj->name));
 
obj->pt_tree = RB_ROOT;
INIT_LIST_HEAD(>pt_list);
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 3ebec19a8e02..af57799c86ce 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -132,7 +132,7 @@ EXPORT_SYMBOL(sync_file_get_fence);
 char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
 {
if (sync_file->user_name[0]) {
-   strlcpy(buf, sync_file->user_name, len);
+   strscpy(buf, sync_file->user_name, len);
} else {
struct dma_fence *fence = sync_file->fence;
 
@@ -172,7 +172,7 @@ static struct sync_file *sync_file_merge(const char *name, 
struct sync_file *a,
return NULL;
}
sync_file->fence = fence;
-   strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
+   strscpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
 }
 
@@ -262,9 +262,9 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
 static int sync_fill_fence_info(struct dma_fence *fence,
 struct sync_fence_info *info)
 {
-   strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
+   strscpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
-   strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
+   strscpy(info->driver_name, fence->ops->get_driver_name(fence),
sizeof(info->driver_name));
 
info->status = dma_fence_get_status(fence);
-- 
2.35.1



[PATCH] gpu: move from strlcpy with unused retval to strscpy

2022-08-18 Thread Wolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.

Link: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang 
---
 drivers/gpu/drm/amd/amdgpu/atom.c   | 2 +-
 drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c  | 2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 +++---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 2 +-
 drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
 drivers/gpu/drm/display/drm_dp_mst_topology.c   | 2 +-
 drivers/gpu/drm/drm_mipi_dsi.c  | 2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c   | 2 +-
 drivers/gpu/drm/i915/selftests/i915_perf.c  | 2 +-
 drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +-
 drivers/gpu/drm/radeon/radeon_atombios.c| 4 ++--
 drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
 drivers/gpu/drm/rockchip/inno_hdmi.c| 2 +-
 drivers/gpu/drm/rockchip/rk3066_hdmi.c  | 2 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c  | 2 +-
 15 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 1c5d9388ad0b..5f610e9a5f0f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -1509,7 +1509,7 @@ struct atom_context *amdgpu_atom_parse(struct card_info 
*card, void *bios)
str = CSTR(idx);
if (*str != '\0') {
pr_info("ATOM BIOS: %s\n", str);
-   strlcpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
+   strscpy(ctx->vbios_version, str, sizeof(ctx->vbios_version));
}
 
atom_rom_header = (struct _ATOM_ROM_HEADER *)CSTR(base);
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c 
b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
index d3fe149d8476..81fb4e5dd804 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/legacy_dpm.c
@@ -794,7 +794,7 @@ void amdgpu_add_thermal_controller(struct amdgpu_device 
*adev)
struct i2c_board_info info = { };
const char *name = 
pp_lib_thermal_controller_names[controller->ucType];
info.addr = controller->ucI2cAddress >> 1;
-   strlcpy(info.type, name, sizeof(info.type));
+   strscpy(info.type, name, sizeof(info.type));

i2c_new_client_device(>pm.i2c_bus->adapter, );
}
} else {
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index 7d2ed0ed2fe2..4efb62bcdb63 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -542,8 +542,8 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
-   strlcpy(card->driver, DRIVER_NAME, sizeof(card->driver));
-   strlcpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
+   strscpy(card->driver, DRIVER_NAME, sizeof(card->driver));
+   strscpy(card->shortname, "DW-HDMI", sizeof(card->shortname));
snprintf(card->longname, sizeof(card->longname),
 "%s rev 0x%02x, irq %d", card->shortname, revision,
 data->irq);
@@ -561,7 +561,7 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
 
dw->pcm = pcm;
pcm->private_data = dw;
-   strlcpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
+   strscpy(pcm->name, DRIVER_NAME, sizeof(pcm->name));
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, _dw_hdmi_ops);
 
/*
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 25a60eb4d67c..4f3ae976e677 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -533,7 +533,7 @@ static struct i2c_adapter *dw_hdmi_i2c_adapter(struct 
dw_hdmi *hdmi)
adap->owner = THIS_MODULE;
adap->dev.parent = hdmi->dev;
adap->algo = _hdmi_algorithm;
-   strlcpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
+   strscpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
i2c_set_adapdata(adap, hdmi);
 
ret = i2c_add_adapter(adap);
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index e5bab236b3ae..10a39b36a661 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2058,7 +2058,7 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
aux->ddc.owner = THIS_MODULE;
aux->ddc.dev.parent = aux->dev;
 
-   

Re: [PATCH i-g-t] i915/guc: Disable i915_pm_rps when SLPC is enabled

2022-08-18 Thread Vivi, Rodrigo
On Thu, 2022-08-18 at 13:42 -0700, Vinay Belgaumkar wrote:
> These tests were specifically designed for host Turbo. Skip
> them when SLPC is enabled as they fail frequently. We will look
> to keep adding to SLPC test coverage with these scenarios.
> 
> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
> Bug: https://gitlab.freedesktop.org/drm/intel/issues/4016
> Bug: https://gitlab.freedesktop.org/drm/intel/issues/5468
> Bug: https://gitlab.freedesktop.org/drm/intel/issues/5831
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Vinay Belgaumkar 

Ideally we should add other api tests and cases to validate the
expected slpc flow.
But this could be done in a follow-up work since right now it is
important to merge
the fix for the performance regression without the ignore_efficient
freq.

So,
Reviewed-by: Rodrigo Vivi 

> ---
>  lib/igt_pm.c | 15 +++
>  lib/igt_pm.h |  1 +
>  tests/i915/i915_pm_rps.c | 29 -
>  3 files changed, 40 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 6ebbad33..79bd6e2a 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -1202,3 +1202,18 @@ void
> igt_pm_print_pci_card_runtime_status(void)
> igt_pm_print_pci_dev_runtime_status(__pci_dev_pwrattr
> [i].pci_dev);
> }
>  }
> +
> +bool i915_is_slpc_enabled(int fd)
> +{
> +   int debugfs_fd = igt_debugfs_dir(fd);
> +   char buf[4096];
> +   int len;
> +
> +   igt_require(debugfs_fd != -1);
> +
> +   len = igt_debugfs_simple_read(debugfs_fd,
> "gt/uc/guc_slpc_info", buf, sizeof(buf));
> +   if (len < 0)
> +   return false;
> +   else
> +   return strstr(buf, "SLPC state: running");
> +}
> diff --git a/lib/igt_pm.h b/lib/igt_pm.h
> index f28b6ebf..cbbde12b 100644
> --- a/lib/igt_pm.h
> +++ b/lib/igt_pm.h
> @@ -79,5 +79,6 @@ void igt_pm_enable_pci_card_runtime_pm(struct
> pci_device *root,
>  void igt_pm_setup_pci_card_runtime_pm(struct pci_device *pci_dev);
>  void igt_pm_restore_pci_card_runtime_pm(void);
>  void igt_pm_print_pci_card_runtime_status(void);
> +bool i915_is_slpc_enabled(int fd);
>  
>  #endif /* IGT_PM_H */
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index d06ade27..cce07009 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -914,35 +914,54 @@ igt_main
> igt_install_exit_handler(pm_rps_exit_handler);
> }
>  
> -   igt_subtest("basic-api")
> +   igt_subtest("basic-api") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> min_max_config(basic_check, false);
> +   }
>  
> /* Verify the constraints, check if we can reach idle */
> -   igt_subtest("min-max-config-idle")
> +   igt_subtest("min-max-config-idle") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> min_max_config(idle_check, true);
> +   }
>  
> /* Verify the constraints with high load, check if we can
> reach max */
> igt_subtest("min-max-config-loaded") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> load_helper_run(HIGH);
> min_max_config(loaded_check, false);
> load_helper_stop();
> }
>  
> /* Checks if we achieve boost using gem_wait */
> -   igt_subtest("waitboost")
> +   igt_subtest("waitboost") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> waitboost(drm_fd, false);
> +   }
>  
> igt_describe("Check if the order of fences does not affect
> waitboosting");
> -   igt_subtest("fence-order")
> +   igt_subtest("fence-order") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> fence_order(drm_fd);
> +   }
>  
> igt_describe("Check if context reuse does not affect
> waitboosting");
> -   igt_subtest("engine-order")
> +   igt_subtest("engine-order") {
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> engine_order(drm_fd);
> +   }
>  
> /* Test boost frequency after GPU reset */
> igt_subtest("reset") {
> igt_hang_t hang = igt_allow_hang(drm_fd, 0, 0);
> +   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
> + "This subtest is not supported when
> SLPC is enabled");
> waitboost(drm_fd, 

[PATCH i-g-t] i915/guc: Disable i915_pm_rps when SLPC is enabled

2022-08-18 Thread Vinay Belgaumkar
These tests were specifically designed for host Turbo. Skip
them when SLPC is enabled as they fail frequently. We will look
to keep adding to SLPC test coverage with these scenarios.

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3963
Bug: https://gitlab.freedesktop.org/drm/intel/issues/4016
Bug: https://gitlab.freedesktop.org/drm/intel/issues/5468
Bug: https://gitlab.freedesktop.org/drm/intel/issues/5831

Cc: Rodrigo Vivi 
Signed-off-by: Vinay Belgaumkar 
---
 lib/igt_pm.c | 15 +++
 lib/igt_pm.h |  1 +
 tests/i915/i915_pm_rps.c | 29 -
 3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 6ebbad33..79bd6e2a 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -1202,3 +1202,18 @@ void igt_pm_print_pci_card_runtime_status(void)

igt_pm_print_pci_dev_runtime_status(__pci_dev_pwrattr[i].pci_dev);
}
 }
+
+bool i915_is_slpc_enabled(int fd)
+{
+   int debugfs_fd = igt_debugfs_dir(fd);
+   char buf[4096];
+   int len;
+
+   igt_require(debugfs_fd != -1);
+
+   len = igt_debugfs_simple_read(debugfs_fd, "gt/uc/guc_slpc_info", buf, 
sizeof(buf));
+   if (len < 0)
+   return false;
+   else
+   return strstr(buf, "SLPC state: running");
+}
diff --git a/lib/igt_pm.h b/lib/igt_pm.h
index f28b6ebf..cbbde12b 100644
--- a/lib/igt_pm.h
+++ b/lib/igt_pm.h
@@ -79,5 +79,6 @@ void igt_pm_enable_pci_card_runtime_pm(struct pci_device 
*root,
 void igt_pm_setup_pci_card_runtime_pm(struct pci_device *pci_dev);
 void igt_pm_restore_pci_card_runtime_pm(void);
 void igt_pm_print_pci_card_runtime_status(void);
+bool i915_is_slpc_enabled(int fd);
 
 #endif /* IGT_PM_H */
diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
index d06ade27..cce07009 100644
--- a/tests/i915/i915_pm_rps.c
+++ b/tests/i915/i915_pm_rps.c
@@ -914,35 +914,54 @@ igt_main
igt_install_exit_handler(pm_rps_exit_handler);
}
 
-   igt_subtest("basic-api")
+   igt_subtest("basic-api") {
+   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
+ "This subtest is not supported when SLPC is 
enabled");
min_max_config(basic_check, false);
+   }
 
/* Verify the constraints, check if we can reach idle */
-   igt_subtest("min-max-config-idle")
+   igt_subtest("min-max-config-idle") {
+   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
+ "This subtest is not supported when SLPC is 
enabled");
min_max_config(idle_check, true);
+   }
 
/* Verify the constraints with high load, check if we can reach max */
igt_subtest("min-max-config-loaded") {
+   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
+ "This subtest is not supported when SLPC is 
enabled");
load_helper_run(HIGH);
min_max_config(loaded_check, false);
load_helper_stop();
}
 
/* Checks if we achieve boost using gem_wait */
-   igt_subtest("waitboost")
+   igt_subtest("waitboost") {
+   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
+ "This subtest is not supported when SLPC is 
enabled");
waitboost(drm_fd, false);
+   }
 
igt_describe("Check if the order of fences does not affect 
waitboosting");
-   igt_subtest("fence-order")
+   igt_subtest("fence-order") {
+   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
+ "This subtest is not supported when SLPC is 
enabled");
fence_order(drm_fd);
+   }
 
igt_describe("Check if context reuse does not affect waitboosting");
-   igt_subtest("engine-order")
+   igt_subtest("engine-order") {
+   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
+ "This subtest is not supported when SLPC is 
enabled");
engine_order(drm_fd);
+   }
 
/* Test boost frequency after GPU reset */
igt_subtest("reset") {
igt_hang_t hang = igt_allow_hang(drm_fd, 0, 0);
+   igt_skip_on_f(i915_is_slpc_enabled(drm_fd),
+ "This subtest is not supported when SLPC is 
enabled");
waitboost(drm_fd, true);
igt_disallow_hang(drm_fd, hang);
}
-- 
2.35.1



Re: [PATCH v25 1/7] dt-bindings: mediatek: add ethdr definition for mt8195

2022-08-18 Thread Nícolas F . R . A . Prado
Hi Nancy,

On Thu, Aug 04, 2022 at 03:28:21PM +0800, Nancy.Lin wrote:
> Add vdosys1 ETHDR definition.
> 
> Signed-off-by: Nancy.Lin 
> Reviewed-by: Chun-Kuang Hu 
> Reviewed-by: AngeloGioacchino Del Regno
>  

Some line-wrapping happened to your patch when sending, so it's corrupted and
won't apply:

$ b4 am 
https://lore.kernel.org/all/20220804072827.22383-1-nancy@mediatek.com/
$ git am 
./v25_20220804_nancy_lin_add_mediatek_soc_drm_vdosys1_support_for_mt8195.mbx
Applying: dt-bindings: mediatek: add ethdr definition for mt8195
error: corrupt patch at line 228

Fix whatever causes this in your setup and re-send. Tinghan also had this issue
recently [1].

[1] https://lore.kernel.org/all/96e66425-ff2a-4640-8b96-48fa39943...@linaro.org/

Thanks,
Nícolas


Re: drm warning with mainline due to 467e30171b5b ("drm/vc4: hdmi: Move HDMI reset to pm_resume")

2022-08-18 Thread Sudip Mukherjee
On Wed, Aug 17, 2022 at 8:10 AM Maxime Ripard  wrote:
>
> Hi,
>
> On Tue, Aug 16, 2022 at 05:34:51PM +0100, Sudip Mukherjee (Codethink) wrote:
> > Not sure if it has been reported but the mainline kernel shows a drm warning
> > on RPI4B.
> >
> > [   14.821276] WARNING: CPU: 3 PID: 187 at 
> > drivers/gpu/drm/vc4/vc4_hdmi_regs.h:487 vc5_hdmi_reset+0x1f8/0x240 [vc4]



> >
> > git bisect pointed to 467e30171b5b ("drm/vc4: hdmi: Move HDMI reset to 
> > pm_resume")
> > and reverting this commit has fixed the warning.
> >
> > I will be happy to test any patch or provide any extra log if needed.
>
> We have fixes for this in drm-misc-next that have missed the cut for the
> merge window:
>
> https://lore.kernel.org/all/20220629123510.1915022-38-max...@cerno.tech/
> https://lore.kernel.org/all/20220629123510.1915022-39-max...@cerno.tech/
>
> If it fixes it for you, I'll apply it to drm-misc-fixes

Thanks. With these two patches applied on top of the latest mainline,
I don't see the warning anymore.

Tested-by: Sudip Mukherjee 


-- 
Regards
Sudip


[PATCH v5 6/7] drm/msm/a6xx: Improve gpu recovery sequence

2022-08-18 Thread Akhil P Oommen
We can do a few more things to improve our chance at a successful gpu
recovery, especially during a hangcheck timeout:
1. Halt CP and GMU core
2. Do RBBM GBIF HALT sequence
3. Do a soft reset of GPU core

Signed-off-by: Akhil P Oommen 
---

(no changes since v1)

 drivers/gpu/drm/msm/adreno/a6xx.xml.h |  4 ++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 77 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |  7 
 3 files changed, 58 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index b03e2c4..beea4a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -1413,6 +1413,10 @@ static inline uint32_t 
REG_A6XX_RBBM_PERFCTR_RBBM_SEL(uint32_t i0) { return 0x00
 
 #define REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL 0x0011
 
+#define REG_A6XX_RBBM_GBIF_HALT
0x0016
+
+#define REG_A6XX_RBBM_GBIF_HALT_ACK0x0017
+
 #define REG_A6XX_RBBM_WAIT_FOR_GPU_IDLE_CMD0x001c
 #define A6XX_RBBM_WAIT_FOR_GPU_IDLE_CMD_WAIT_GPU_IDLE  0x0001
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 9f76f5b..db05942 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -869,9 +869,47 @@ static void a6xx_gmu_rpmh_off(struct a6xx_gmu *gmu)
(val & 1), 100, 1000);
 }
 
+#define GBIF_CLIENT_HALT_MASK BIT(0)
+#define GBIF_ARB_HALT_MASKBIT(1)
+
+static void a6xx_bus_clear_pending_transactions(struct adreno_gpu *adreno_gpu)
+{
+   struct msm_gpu *gpu = _gpu->base;
+
+   if (!a6xx_has_gbif(adreno_gpu)) {
+   gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0xf);
+   spin_until((gpu_read(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL1) &
+   0xf) == 0xf);
+   gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0);
+
+   return;
+   }
+
+   /* Halt the gx side of GBIF */
+   gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 1);
+   spin_until(gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT_ACK) & 1);
+
+   /* Halt new client requests on GBIF */
+   gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_CLIENT_HALT_MASK);
+   spin_until((gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK) &
+   (GBIF_CLIENT_HALT_MASK)) == GBIF_CLIENT_HALT_MASK);
+
+   /* Halt all AXI requests on GBIF */
+   gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_ARB_HALT_MASK);
+   spin_until((gpu_read(gpu,  REG_A6XX_GBIF_HALT_ACK) &
+   (GBIF_ARB_HALT_MASK)) == GBIF_ARB_HALT_MASK);
+
+   /* The GBIF halt needs to be explicitly cleared */
+   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0x0);
+}
+
 /* Force the GMU off in case it isn't responsive */
 static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
 {
+   struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+   struct adreno_gpu *adreno_gpu = _gpu->base;
+   struct msm_gpu *gpu = _gpu->base;
+
/* Flush all the queues */
a6xx_hfi_stop(gmu);
 
@@ -883,6 +921,15 @@ static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
 
/* Make sure there are no outstanding RPMh votes */
a6xx_gmu_rpmh_off(gmu);
+
+   /* Halt the gmu cm3 core */
+   gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
+
+   a6xx_bus_clear_pending_transactions(adreno_gpu);
+
+   /* Reset GPU core blocks */
+   gpu_write(gpu, REG_A6XX_RBBM_SW_RESET_CMD, 1);
+   udelay(100);
 }
 
 static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu, struct a6xx_gmu 
*gmu)
@@ -1010,36 +1057,6 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
return true;
 }
 
-#define GBIF_CLIENT_HALT_MASK BIT(0)
-#define GBIF_ARB_HALT_MASKBIT(1)
-
-static void a6xx_bus_clear_pending_transactions(struct adreno_gpu *adreno_gpu)
-{
-   struct msm_gpu *gpu = _gpu->base;
-
-   if (!a6xx_has_gbif(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0xf);
-   spin_until((gpu_read(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL1) &
-   0xf) == 0xf);
-   gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0);
-
-   return;
-   }
-
-   /* Halt new client requests on GBIF */
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_CLIENT_HALT_MASK);
-   spin_until((gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK) &
-   (GBIF_CLIENT_HALT_MASK)) == GBIF_CLIENT_HALT_MASK);
-
-   /* Halt all AXI requests on GBIF */
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_ARB_HALT_MASK);
-   spin_until((gpu_read(gpu,  REG_A6XX_GBIF_HALT_ACK) &
-   (GBIF_ARB_HALT_MASK)) == GBIF_ARB_HALT_MASK);
-
-   /* The GBIF halt needs to be explicitly cleared */
-   

[PATCH v5 7/7] drm/msm/a6xx: Handle GMU prepare-slumber hfi failure

2022-08-18 Thread Akhil P Oommen
When prepare-slumber hfi fails, we should follow a6xx_gmu_force_off()
sequence.

Signed-off-by: Akhil P Oommen 
---

(no changes since v1)

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index db05942..3d00ef9 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1082,7 +1082,11 @@ static void a6xx_gmu_shutdown(struct a6xx_gmu *gmu)
a6xx_bus_clear_pending_transactions(adreno_gpu);
 
/* tell the GMU we want to slumber */
-   a6xx_gmu_notify_slumber(gmu);
+   ret = a6xx_gmu_notify_slumber(gmu);
+   if (ret) {
+   a6xx_gmu_force_off(gmu);
+   return;
+   }
 
ret = gmu_poll_timeout(gmu,
REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS, val,
-- 
2.7.4



[PATCH v5 5/7] drm/msm/a6xx: Ensure CX collapse during gpu recovery

2022-08-18 Thread Akhil P Oommen
Because there could be transient votes from other drivers/tz/hyp which
may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
We can use the reset framework to poll for cx gdsc collapse from gpucc
clk driver.

This feature requires support from the platform's gpucc driver.

Signed-off-by: Akhil P Oommen 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Philipp Zabel 
---

Changes in v5:
- Replace devm_reset_control_get_optional() with
devm_reset_control_get_optional_exclusive() (Philipp)

Changes in v3:
- Use reset interface from gpucc driver to poll for cx gdsc collapse
  https://patchwork.freedesktop.org/series/106860/

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 
 drivers/gpu/drm/msm/msm_gpu.c | 4 
 drivers/gpu/drm/msm/msm_gpu.h | 4 
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 0c8f19e..0ec4fcd 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #define GPU_PAS_ID 13
@@ -1229,6 +1230,9 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* And the final one from recover worker */
pm_runtime_put_sync(>pdev->dev);
 
+   /* Call into gpucc driver to poll for cx gdsc collapse */
+   reset_control_reset(gpu->cx_collapse);
+
pm_runtime_use_autosuspend(>pdev->dev);
 
if (active_submits)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 07e55a6..2b6f9d4 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -903,6 +904,9 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
if (IS_ERR(gpu->gpu_cx))
gpu->gpu_cx = NULL;
 
+   gpu->cx_collapse = devm_reset_control_get_optional_exclusive(>dev,
+   "cx_collapse");
+
gpu->pdev = pdev;
platform_set_drvdata(pdev, >adreno_smmu);
 
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6def008..ab59fd2 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "msm_drv.h"
 #include "msm_fence.h"
@@ -268,6 +269,9 @@ struct msm_gpu {
bool hw_apriv;
 
struct thermal_cooling_device *cooling;
+
+   /* To poll for cx gdsc collapse during gpu recovery */
+   struct reset_control *cx_collapse;
 };
 
 static inline struct msm_gpu *dev_to_gpu(struct device *dev)
-- 
2.7.4



[PATCH v5 1/7] drm/msm: Remove unnecessary pm_runtime_get/put

2022-08-18 Thread Akhil P Oommen
We already enable gpu power from msm_gpu_submit(), so avoid a duplicate
pm_runtime_get/put from msm_job_run().

Signed-off-by: Akhil P Oommen 
---

(no changes since v1)

 drivers/gpu/drm/msm/msm_ringbuffer.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c 
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 56eecb4..cad4c35 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -29,8 +29,6 @@ static struct dma_fence *msm_job_run(struct drm_sched_job 
*job)
msm_gem_unlock(obj);
}
 
-   pm_runtime_get_sync(>pdev->dev);
-
/* TODO move submit path over to using a per-ring lock.. */
mutex_lock(>lock);
 
@@ -38,8 +36,6 @@ static struct dma_fence *msm_job_run(struct drm_sched_job 
*job)
 
mutex_unlock(>lock);
 
-   pm_runtime_put(>pdev->dev);
-
return dma_fence_get(submit->hw_fence);
 }
 
-- 
2.7.4



[PATCH v5 2/7] drm/msm: Take single rpm refcount on behalf of all submits

2022-08-18 Thread Akhil P Oommen
Instead of separate refcount for each submit, take single rpm refcount
on behalf of all the submits. This makes it easier to drop the rpm
refcount during recovery in an upcoming patch.

Signed-off-by: Akhil P Oommen 
---

(no changes since v3)

Changes in v3:
- New patch

 drivers/gpu/drm/msm/msm_gpu.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index c8cd9bf..e1dd3cc 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -663,11 +663,12 @@ static void retire_submit(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring,
mutex_lock(>active_lock);
gpu->active_submits--;
WARN_ON(gpu->active_submits < 0);
-   if (!gpu->active_submits)
+   if (!gpu->active_submits) {
msm_devfreq_idle(gpu);
-   mutex_unlock(>active_lock);
+   pm_runtime_put_autosuspend(>pdev->dev);
+   }
 
-   pm_runtime_put_autosuspend(>pdev->dev);
+   mutex_unlock(>active_lock);
 
msm_gem_submit_put(submit);
 }
@@ -756,14 +757,17 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit)
 
/* Update devfreq on transition from idle->active: */
mutex_lock(>active_lock);
-   if (!gpu->active_submits)
+   if (!gpu->active_submits) {
+   pm_runtime_get(>pdev->dev);
msm_devfreq_active(gpu);
+   }
gpu->active_submits++;
mutex_unlock(>active_lock);
 
gpu->funcs->submit(gpu, submit);
gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
 
+   pm_runtime_put(>pdev->dev);
hangcheck_timer_reset(gpu);
 }
 
-- 
2.7.4



[PATCH v5 4/7] drm/msm: Fix cx collapse issue during recovery

2022-08-18 Thread Akhil P Oommen
There are some hardware logic under CX domain. For a successful
recovery, we should ensure cx headswitch collapses to ensure all the
stale states are cleard out. This is especially true to for a6xx family
where we can GMU co-processor.

Currently, cx doesn't collapse due to a devlink between gpu and its
smmu. So the *struct gpu device* needs to be runtime suspended to ensure
that the iommu driver removes its vote on cx gdsc.

Signed-off-by: Akhil P Oommen 
---

(no changes since v4)

Changes in v4:
- Keep active_submit lock across the suspend & resume (Rob)
- Clear gpu->active_submits to silence a WARN() during runpm suspend (Rob)

Changes in v3:
- Simplied the pm refcount drop since we have just a single refcount now
for all active submits

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 32 +---
 drivers/gpu/drm/msm/msm_gpu.c |  4 +---
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 42ed9a3..0c8f19e 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1193,7 +1193,7 @@ static void a6xx_recover(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
-   int i;
+   int i, active_submits;
 
adreno_dump_info(gpu);
 
@@ -1210,8 +1210,34 @@ static void a6xx_recover(struct msm_gpu *gpu)
 */
gmu_write(_gpu->gmu, REG_A6XX_GMU_GMU_PWR_COL_KEEPALIVE, 0);
 
-   gpu->funcs->pm_suspend(gpu);
-   gpu->funcs->pm_resume(gpu);
+   pm_runtime_dont_use_autosuspend(>pdev->dev);
+
+   /* active_submit won't change until we make a submission */
+   mutex_lock(>active_lock);
+   active_submits = gpu->active_submits;
+
+   /*
+* Temporarily clear active_submits count to silence a WARN() in the
+* runtime suspend cb
+*/
+   gpu->active_submits = 0;
+
+   /* Drop the rpm refcount from active submits */
+   if (active_submits)
+   pm_runtime_put(>pdev->dev);
+
+   /* And the final one from recover worker */
+   pm_runtime_put_sync(>pdev->dev);
+
+   pm_runtime_use_autosuspend(>pdev->dev);
+
+   if (active_submits)
+   pm_runtime_get(>pdev->dev);
+
+   pm_runtime_get_sync(>pdev->dev);
+
+   gpu->active_submits = active_submits;
+   mutex_unlock(>active_lock);
 
msm_gpu_hw_init(gpu);
 }
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1945efb..07e55a6 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -426,9 +426,7 @@ static void recover_worker(struct kthread_work *work)
/* retire completed submits, plus the one that hung: */
retire_submits(gpu);
 
-   pm_runtime_get_sync(>pdev->dev);
gpu->funcs->recover(gpu);
-   pm_runtime_put_sync(>pdev->dev);
 
/*
 * Replay all remaining submits starting with highest priority
@@ -445,7 +443,7 @@ static void recover_worker(struct kthread_work *work)
}
}
 
-   pm_runtime_put_sync(>pdev->dev);
+   pm_runtime_put(>pdev->dev);
 
mutex_unlock(>lock);
 
-- 
2.7.4



[PATCH v5 3/7] drm/msm: Correct pm_runtime votes in recover worker

2022-08-18 Thread Akhil P Oommen
In the scenario where there is one a single submit which is hung, gpu is
power collapsed when it is retired. Because of this, by the time we call
reover(), gpu state would be already clear. Fix this by correctly
managing the pm runtime votes.

Signed-off-by: Akhil P Oommen 
---

(no changes since v1)

 drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index e1dd3cc..1945efb 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -398,7 +398,6 @@ static void recover_worker(struct kthread_work *work)
/* Record the crash state */
pm_runtime_get_sync(>pdev->dev);
msm_gpu_crashstate_capture(gpu, submit, comm, cmd);
-   pm_runtime_put_sync(>pdev->dev);
 
kfree(cmd);
kfree(comm);
@@ -446,6 +445,8 @@ static void recover_worker(struct kthread_work *work)
}
}
 
+   pm_runtime_put_sync(>pdev->dev);
+
mutex_unlock(>lock);
 
msm_gpu_retire(gpu);
-- 
2.7.4



[PATCH v5 0/7] Improve GPU Recovery

2022-08-18 Thread Akhil P Oommen


Recently, I debugged a few device crashes which occured during recovery
after a hangcheck timeout. It looks like there are a few things we can
do to improve our chance at a successful gpu recovery.

First one is to ensure that CX GDSC collapses which clears the internal
states in gpu's CX domain. First 5 patches tries to handle this.

Rest of the patches are to ensure that few internal blocks like CP, GMU
and GBIF are halted properly before proceeding for a snapshot followed by
recovery. Also, handle 'prepare slumber' hfi failure correctly. These
are A6x specific improvements.

This series is rebased on top of v2 version of [1] which is based on
linus's master branch.

[1] https://patchwork.freedesktop.org/series/106860/

Changes in v5:
- Replace devm_reset_control_get_optional() with
devm_reset_control_get_optional_exclusive() (Philipp)

Changes in v4:
- Keep active_submit lock across the suspend & resume (Rob)
- Clear gpu->active_submits to silence a WARN() during runpm suspend (Rob)

Changes in v3:
- Use reset interface from gpucc driver to poll for cx gdsc collapse
  https://patchwork.freedesktop.org/series/106860/
- Use single pm refcount for all active submits

Changes in v2:
- Rebased on msm-next tip

Akhil P Oommen (7):
  drm/msm: Remove unnecessary pm_runtime_get/put
  drm/msm: Take single rpm refcount on behalf of all submits
  drm/msm: Correct pm_runtime votes in recover worker
  drm/msm: Fix cx collapse issue during recovery
  drm/msm/a6xx: Ensure CX collapse during gpu recovery
  drm/msm/a6xx: Improve gpu recovery sequence
  drm/msm/a6xx: Handle GMU prepare-slumber hfi failure

 drivers/gpu/drm/msm/adreno/a6xx.xml.h |  4 ++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 83 ++-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 --
 drivers/gpu/drm/msm/msm_gpu.c | 21 ++---
 drivers/gpu/drm/msm/msm_gpu.h |  4 ++
 drivers/gpu/drm/msm/msm_ringbuffer.c  |  4 --
 6 files changed, 114 insertions(+), 45 deletions(-)

-- 
2.7.4



[PATCH v3 5/5] arm64: dts: qcom: sc7280: Add Reset support for gpu

2022-08-18 Thread Akhil P Oommen
Add support for Reset using GPUCC driver for GPU. This helps to ensure
that GPU state is reset by making sure that CX head switch is collapsed.

Signed-off-by: Akhil P Oommen 
---

(no changes since v1)

 arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index e66fc67..f5257d6 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2243,6 +2243,9 @@
nvmem-cells = <_speed_bin>;
nvmem-cell-names = "speed_bin";
 
+   resets = < GPU_CX_COLLAPSE>;
+   reset-names = "cx_collapse";
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
-- 
2.7.4



[PATCH v3 4/5] clk: qcom: gpucc-sc7280: Add cx collapse reset support

2022-08-18 Thread Akhil P Oommen
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.

Signed-off-by: Akhil P Oommen 
---

Changes in v3:
- Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' (Krzysztof)

Changes in v2:
- Minor update to use the updated custom reset ops implementation

 drivers/clk/qcom/gpucc-sc7280.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/qcom/gpucc-sc7280.c
index 9a832f2..fece3f4 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -433,12 +433,22 @@ static const struct regmap_config 
gpu_cc_sc7280_regmap_config = {
.fast_io = true,
 };
 
+static const struct qcom_reset_ops cx_gdsc_reset = {
+   .reset = gdsc_wait_for_collapse,
+};
+
+static const struct qcom_reset_map gpucc_sc7280_resets[] = {
+   [GPU_CX_COLLAPSE] = { .ops = _gdsc_reset, .priv = _gdsc },
+};
+
 static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
.config = _cc_sc7280_regmap_config,
.clks = gpu_cc_sc7280_clocks,
.num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
.gdscs = gpu_cc_sc7180_gdscs,
.num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
+   .resets = gpucc_sc7280_resets,
+   .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),
 };
 
 static const struct of_device_id gpu_cc_sc7280_match_table[] = {
-- 
2.7.4



[PATCH v3 2/5] clk: qcom: Allow custom reset ops

2022-08-18 Thread Akhil P Oommen
Allow soc specific clk drivers to specify a custom reset operation. We
will use this in an upcoming patch to allow gpucc driver to specify a
differet reset operation for cx_gdsc.

Signed-off-by: Akhil P Oommen 
---

Changes in v3:
- Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map (Krzysztof)

Changes in v2:
- Return error when a particular custom reset op is not implemented. (Dmitry)

 drivers/clk/qcom/reset.c | 27 +++
 drivers/clk/qcom/reset.h |  8 
 2 files changed, 35 insertions(+)

diff --git a/drivers/clk/qcom/reset.c b/drivers/clk/qcom/reset.c
index 819d194..b7ae4a3 100644
--- a/drivers/clk/qcom/reset.c
+++ b/drivers/clk/qcom/reset.c
@@ -13,6 +13,21 @@
 
 static int qcom_reset(struct reset_controller_dev *rcdev, unsigned long id)
 {
+   struct qcom_reset_controller *rst;
+   const struct qcom_reset_map *map;
+
+   rst = to_qcom_reset_controller(rcdev);
+   map = >reset_map[id];
+
+   if (map->ops && map->ops->reset)
+   return map->ops->reset(map->priv);
+   /*
+* If custom ops is implemented but just not this callback, return
+* error
+*/
+   else if (map->ops)
+   return -EOPNOTSUPP;
+
rcdev->ops->assert(rcdev, id);
udelay(1);
rcdev->ops->deassert(rcdev, id);
@@ -28,6 +43,12 @@ qcom_reset_assert(struct reset_controller_dev *rcdev, 
unsigned long id)
 
rst = to_qcom_reset_controller(rcdev);
map = >reset_map[id];
+
+   if (map->ops && map->ops->assert)
+   return map->ops->assert(map->priv);
+   else if (map->ops)
+   return -EOPNOTSUPP;
+
mask = BIT(map->bit);
 
return regmap_update_bits(rst->regmap, map->reg, mask, mask);
@@ -42,6 +63,12 @@ qcom_reset_deassert(struct reset_controller_dev *rcdev, 
unsigned long id)
 
rst = to_qcom_reset_controller(rcdev);
map = >reset_map[id];
+
+   if (map->ops && map->ops->deassert)
+   return map->ops->deassert(map->priv);
+   else if (map->ops)
+   return -EOPNOTSUPP;
+
mask = BIT(map->bit);
 
return regmap_update_bits(rst->regmap, map->reg, mask, 0);
diff --git a/drivers/clk/qcom/reset.h b/drivers/clk/qcom/reset.h
index 2a08b5e..f3147eb 100644
--- a/drivers/clk/qcom/reset.h
+++ b/drivers/clk/qcom/reset.h
@@ -8,9 +8,17 @@
 
 #include 
 
+struct qcom_reset_ops {
+   int (*reset)(void *priv);
+   int (*assert)(void *priv);
+   int (*deassert)(void *priv);
+};
+
 struct qcom_reset_map {
unsigned int reg;
u8 bit;
+   const struct qcom_reset_ops *ops;
+   void *priv;
 };
 
 struct regmap;
-- 
2.7.4



[PATCH v3 3/5] clk: qcom: gdsc: Add a reset op to poll gdsc collapse

2022-08-18 Thread Akhil P Oommen
Add a reset op compatible function to poll for gdsc collapse.

Signed-off-by: Akhil P Oommen 
---

(no changes since v2)

Changes in v2:
- Minor update to function prototype

 drivers/clk/qcom/gdsc.c | 23 +++
 drivers/clk/qcom/gdsc.h |  7 +++
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 44520ef..2d0f1d1 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include "gdsc.h"
+#include "reset.h"
 
 #define PWR_ON_MASKBIT(31)
 #define EN_REST_WAIT_MASK  GENMASK_ULL(23, 20)
@@ -116,7 +117,8 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK, val);
 }
 
-static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status)
+static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status,
+   s64 timeout_us, unsigned int interval_ms)
 {
ktime_t start;
 
@@ -124,7 +126,9 @@ static int gdsc_poll_status(struct gdsc *sc, enum 
gdsc_status status)
do {
if (gdsc_check_status(sc, status))
return 0;
-   } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
+   if (interval_ms)
+   msleep(interval_ms);
+   } while (ktime_us_delta(ktime_get(), start) < timeout_us);
 
if (gdsc_check_status(sc, status))
return 0;
@@ -172,7 +176,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum 
gdsc_status status)
udelay(1);
}
 
-   ret = gdsc_poll_status(sc, status);
+   ret = gdsc_poll_status(sc, status, TIMEOUT_US, 0);
WARN(ret, "%s status stuck at 'o%s'", sc->pd.name, status ? "ff" : "n");
 
if (!ret && status == GDSC_OFF && sc->rsupply) {
@@ -343,7 +347,7 @@ static int _gdsc_disable(struct gdsc *sc)
 */
udelay(1);
 
-   ret = gdsc_poll_status(sc, GDSC_ON);
+   ret = gdsc_poll_status(sc, GDSC_ON, TIMEOUT_US, 0);
if (ret)
return ret;
}
@@ -565,3 +569,14 @@ int gdsc_gx_do_nothing_enable(struct generic_pm_domain 
*domain)
return 0;
 }
 EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
+
+int gdsc_wait_for_collapse(void *priv)
+{
+   struct gdsc *sc = priv;
+   int ret;
+
+   ret = gdsc_poll_status(sc, GDSC_OFF, 50, 5);
+   WARN(ret, "%s status stuck at 'on'", sc->pd.name);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(gdsc_wait_for_collapse);
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index ad313d7..d484bdb 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -12,6 +12,7 @@
 struct regmap;
 struct regulator;
 struct reset_controller_dev;
+struct qcom_reset_map;
 
 /**
  * struct gdsc - Globally Distributed Switch Controller
@@ -79,6 +80,7 @@ int gdsc_register(struct gdsc_desc *desc, struct 
reset_controller_dev *,
  struct regmap *);
 void gdsc_unregister(struct gdsc_desc *desc);
 int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain);
+int gdsc_wait_for_collapse(void *priv);
 #else
 static inline int gdsc_register(struct gdsc_desc *desc,
struct reset_controller_dev *rcdev,
@@ -88,5 +90,10 @@ static inline int gdsc_register(struct gdsc_desc *desc,
 }
 
 static inline void gdsc_unregister(struct gdsc_desc *desc) {};
+
+static int gdsc_wait_for_collapse(void *priv)
+{
+   return  -ENOSYS;
+}
 #endif /* CONFIG_QCOM_GDSC */
 #endif /* __QCOM_GDSC_H__ */
-- 
2.7.4



[PATCH v3 1/5] dt-bindings: clk: qcom: Support gpu cx gdsc reset

2022-08-18 Thread Akhil P Oommen
Add necessary definitions in gpucc bindings to ensure gpu cx gdsc collapse
through 'reset' framework for SC7280.

Signed-off-by: Akhil P Oommen 
Acked-by: Krzysztof Kozlowski 
---

(no changes since v1)

 include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/dt-bindings/clock/qcom,gpucc-sc7280.h 
b/include/dt-bindings/clock/qcom,gpucc-sc7280.h
index 669b23b..843a31b 100644
--- a/include/dt-bindings/clock/qcom,gpucc-sc7280.h
+++ b/include/dt-bindings/clock/qcom,gpucc-sc7280.h
@@ -32,4 +32,7 @@
 #define GPU_CC_CX_GDSC 0
 #define GPU_CC_GX_GDSC 1
 
+/* GPU_CC reset IDs */
+#define GPU_CX_COLLAPSE0
+
 #endif
-- 
2.7.4



[PATCH v3 0/5] clk/qcom: Support gdsc collapse polling using 'reset' inteface

2022-08-18 Thread Akhil P Oommen


Some clients like adreno gpu driver would like to ensure that its gdsc
is collapsed at hardware during a gpu reset sequence. This is because it
has a votable gdsc which could be ON due to a vote from another subsystem
like tz, hyp etc or due to an internal hardware signal. To allow
this, gpucc driver can expose an interface to the client driver using
reset framework. Using this the client driver can trigger a polling within
the gdsc driver.

This series is rebased on top of linus's master branch.

Related discussion: https://patchwork.freedesktop.org/patch/493144/

Changes in v3:
- Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map (Krzysztof)

Changes in v2:
- Return error when a particular custom reset op is not implemented. (Dmitry)

Akhil P Oommen (5):
  dt-bindings: clk: qcom: Support gpu cx gdsc reset
  clk: qcom: Allow custom reset ops
  clk: qcom: gdsc: Add a reset op to poll gdsc collapse
  clk: qcom: gpucc-sc7280: Add cx collapse reset support
  arm64: dts: qcom: sc7280: Add Reset support for gpu

 arch/arm64/boot/dts/qcom/sc7280.dtsi  |  3 +++
 drivers/clk/qcom/gdsc.c   | 23 +++
 drivers/clk/qcom/gdsc.h   |  7 +++
 drivers/clk/qcom/gpucc-sc7280.c   | 10 ++
 drivers/clk/qcom/reset.c  | 27 +++
 drivers/clk/qcom/reset.h  |  8 
 include/dt-bindings/clock/qcom,gpucc-sc7280.h |  3 +++
 7 files changed, 77 insertions(+), 4 deletions(-)

-- 
2.7.4



Re: [PATCH v3 09/31] ACPI: video: Make backlight class device registration a separate step (v2)

2022-08-18 Thread Daniel Dadap



On 8/18/22 1:42 PM, Hans de Goede wrote:

On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_video0 device (when acpi_video_get_backlight_type()==native).

This means that userspace briefly sees 2 devices and the disappearing of
acpi_video0 after a brief time confuses the systemd backlight level
save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920

To fix this make backlight class device registration a separate step
done by a new acpi_video_register_backlight() function. The intend is for
this to be called by the drm/kms driver *after* it is done setting up its
own native backlight device. So that acpi_video_get_backlight_type() knows
if a native backlight will be available or not at acpi_video backlight
registration time, avoiding the add + remove dance.

Note the new acpi_video_register_backlight() function is also called from
a delayed work to ensure that the acpi_video backlight devices does get
registered if necessary even if there is no drm/kms driver or when it is
disabled.

Changes in v2:
- Make register_backlight_delay a module parameter, mainly so that it can
   be disabled by Nvidia binary driver users

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
  drivers/acpi/acpi_video.c | 50 ---
  include/acpi/video.h  |  2 ++
  2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 8545bf94866f..09dd86f86cf3 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -73,6 +73,16 @@ module_param(device_id_scheme, bool, 0444);
  static int only_lcd = -1;
  module_param(only_lcd, int, 0444);
  
+/*

+ * Display probing is known to take up to 5 seconds, so delay the fallback
+ * backlight registration by 5 seconds + 3 seconds for some extra margin.
+ */
+static int register_backlight_delay = 8;
+module_param(register_backlight_delay, int, 0444);



Would it make sense to make this parameter writable from userspace, e.g. 
so that it can be set by a udev rule rather than relying on a riskier 
kernel command line edit? Then again, that probably makes things more 
complicated, since you'd have to check the parameter again when the 
worker fires, and changing the parameter to a non-zero value from either 
zero or a different non-zero value would be too weird. And making a 
separate writable parameter to allow userspace to turn the worker into a 
noop despite it being enabled when the kernel was initially loaded seems 
wrong, too.




+MODULE_PARM_DESC(register_backlight_delay,
+   "Delay in seconds before doing fallback (non GPU driver triggered) "
+   "backlight registration, set to 0 to disable.");
+
  static bool may_report_brightness_keys;
  static int register_count;
  static DEFINE_MUTEX(register_count_mutex);
@@ -81,6 +91,9 @@ static LIST_HEAD(video_bus_head);
  static int acpi_video_bus_add(struct acpi_device *device);
  static int acpi_video_bus_remove(struct acpi_device *device);
  static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static void acpi_video_bus_register_backlight_work(struct work_struct 
*ignored);
+static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
+   acpi_video_bus_register_backlight_work);
  void acpi_video_detect_exit(void);
  
  /*

@@ -1859,8 +1872,6 @@ static int acpi_video_bus_register_backlight(struct 
acpi_video_bus *video)
if (video->backlight_registered)
return 0;
  
-	acpi_video_run_bcl_for_osi(video);

-
if (acpi_video_get_backlight_type() != acpi_backlight_video)
return 0;
  
@@ -2086,7 +2097,11 @@ static int acpi_video_bus_add(struct acpi_device *device)

list_add_tail(>entry, _bus_head);
mutex_unlock(_list_lock);
  
-	acpi_video_bus_register_backlight(video);

+   /*
+* The userspace visible backlight_device gets registered separately
+* from acpi_video_register_backlight().
+*/
+   acpi_video_run_bcl_for_osi(video);
acpi_video_bus_add_notify_handler(video);
  
  	return 0;

@@ -2125,6 +2140,11 @@ static int acpi_video_bus_remove(struct acpi_device 
*device)
return 0;
  }
  
+static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)

+{
+   acpi_video_register_backlight();
+}
+
  static int __init is_i740(struct pci_dev *dev)
  {
if (dev->device == 0x00D1)
@@ -2235,6 +2255,18 @@ int acpi_video_register(void)
 */
register_count = 1;
  
+	/*

+* acpi_video_bus_add() skips registering the userspace visible
+* backlight_device. The intend is for this to be registered by the
+* drm/kms driver calling 

Re: [PATCH v3 19/31] platform/x86: nvidia-wmi-ec-backlight: Use acpi_video_get_backlight_type()

2022-08-18 Thread Daniel Dadap

On 8/18/22 1:42 PM, Hans de Goede wrote:

Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec
check. This will make nvidia-wmi-ec-backlight properly honor the user
selecting a different backlight driver through the acpi_backlight=...
kernel commandline option.

Since the auto-detect code check for nvidia-wmi-ec-backlight in
drivers/acpi/video_detect.c already checks that the WMI advertised
brightness-source is the embedded controller, this new check makes it
unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself.

Suggested-by: Daniel Dadap 
Signed-off-by: Hans de Goede 
---
  drivers/platform/x86/Kconfig   |  1 +
  drivers/platform/x86/nvidia-wmi-ec-backlight.c | 14 +++---
  2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index f2f98e942cf2..0cc5ac35fc57 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -93,6 +93,7 @@ config PEAQ_WMI
  
  config NVIDIA_WMI_EC_BACKLIGHT

tristate "EC Backlight Driver for Hybrid Graphics Notebook Systems"
+   depends on ACPI_VIDEO
depends on ACPI_WMI
depends on BACKLIGHT_CLASS_DEVICE
help
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c 
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index e84e1d629b14..83d544180264 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /**

   * wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI 
method
@@ -87,19 +88,10 @@ static int nvidia_wmi_ec_backlight_probe(struct wmi_device 
*wdev, const void *ct
  {
struct backlight_properties props = {};
struct backlight_device *bdev;
-   u32 source;
int ret;
  
-	ret = wmi_brightness_notify(wdev, WMI_BRIGHTNESS_METHOD_SOURCE,

-  WMI_BRIGHTNESS_MODE_GET, );
-   if (ret)
-   return ret;
-
-   /*
-* This driver is only to be used when brightness control is handled
-* by the EC; otherwise, the GPU driver(s) should control brightness.
-*/
-   if (source != WMI_BRIGHTNESS_SOURCE_EC)
+   /* drivers/acpi/video_detect.c also checks that SOURCE == EC */
+   if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
return -ENODEV;
  
  	/*



Reviewed-by: Daniel Dadap 



Re: [PATCH v3 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v2)

2022-08-18 Thread Daniel Dadap



On 8/18/22 1:42 PM, Hans de Goede wrote:

On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.

When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.

Changes in v2:
- Use the new shared nvidia-wmi-ec-backlight.h header for the
   WMI firmware API definitions
- ACPI_VIDEO can now be enabled on non X86 too,
   adjust the Kconfig changes to match this.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
  drivers/acpi/Kconfig   |  1 +
  drivers/acpi/video_detect.c| 37 ++
  drivers/gpu/drm/gma500/Kconfig |  2 ++
  drivers/gpu/drm/i915/Kconfig   |  2 ++
  include/acpi/video.h   |  1 +
  5 files changed, 43 insertions(+)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 7802d8846a8d..44ad4b6bd234 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
tristate "Video"
depends on BACKLIGHT_CLASS_DEVICE
depends on INPUT
+   depends on ACPI_WMI || !X86
select THERMAL
help
  This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index cc9d0d91e268..1749e85d6921 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -32,6 +32,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -75,6 +76,36 @@ find_video(acpi_handle handle, u32 lvl, void *context, void 
**rv)
return AE_OK;
  }
  
+/* This depends on ACPI_WMI which is X86 only */

+#ifdef CONFIG_X86
+static bool nvidia_wmi_ec_supported(void)
+{
+   struct wmi_brightness_args args = {
+   .mode = WMI_BRIGHTNESS_MODE_GET,
+   .val = 0,
+   .ret = 0,
+   };
+   struct acpi_buffer buf = { (acpi_size)sizeof(args),  };
+   acpi_status status;
+
+   status = wmi_evaluate_method("603E9613-EF25-4338-A3D0-C46177516DB7", 0,



I think it would be preferable for the GUID to be in the new shared 
header file as well. Apart from that, I think this change looks sane.




+WMI_BRIGHTNESS_METHOD_SOURCE, , );
+   if (ACPI_FAILURE(status))
+   return false;
+
+   /*
+* If brightness is handled by the EC then nvidia-wmi-ec-backlight
+* should be used, else the GPU driver(s) should be used.
+*/
+   return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+#else
+static bool nvidia_wmi_ec_supported(void)
+{
+   return false;
+}
+#endif
+
  /* Force to use vendor driver when the ACPI device is known to be
   * buggy */
  static int video_detect_force_vendor(const struct dmi_system_id *d)
@@ -541,6 +572,7 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
  static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
  {
static DEFINE_MUTEX(init_mutex);
+   static bool nvidia_wmi_ec_present;
static bool native_available;
static bool init_done;
static long video_caps;
@@ -553,6 +585,7 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
_caps, NULL);
+   nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
init_done = true;
}
if (native)
@@ -570,6 +603,10 @@ static enum acpi_backlight_type 
__acpi_video_get_backlight_type(bool native)
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
  
+	/* Special cases such as nvidia_wmi_ec and apple gmux. */

+   if (nvidia_wmi_ec_present)
+   return acpi_backlight_nvidia_wmi_ec;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..807b989e3c77 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -7,6 +7,8 @@ config DRM_GMA500
select ACPI_VIDEO if ACPI
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
+   select X86_PLATFORM_DEVICES if ACPI
+   select ACPI_WMI if ACPI
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7ae3b7d67fcf..3efce05d7b57 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ 

Re: [PATCH v3 15/31] platform/x86: nvidia-wmi-ec-backlight: Move fw interface definitions to a header

2022-08-18 Thread Daniel Dadap



On 8/18/22 1:42 PM, Hans de Goede wrote:

Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .

Suggested-by: Daniel Dadap 
Signed-off-by: Hans de Goede 
---
  MAINTAINERS   |  1 +
  .../platform/x86/nvidia-wmi-ec-backlight.c| 66 +
  .../x86/nvidia-wmi-ec-backlight.h | 70 +++
  3 files changed, 72 insertions(+), 65 deletions(-)
  create mode 100644 include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a5012ba6ff9..8d59c6e9b4db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14526,6 +14526,7 @@ M:  Daniel Dadap 
  L:platform-driver-...@vger.kernel.org
  S:Supported
  F:drivers/platform/x86/nvidia-wmi-ec-backlight.c
+F: include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
  
  NVM EXPRESS DRIVER

  M:Keith Busch 
diff --git a/drivers/platform/x86/nvidia-wmi-ec-backlight.c 
b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
index 61e37194df70..e84e1d629b14 100644
--- a/drivers/platform/x86/nvidia-wmi-ec-backlight.c
+++ b/drivers/platform/x86/nvidia-wmi-ec-backlight.c
@@ -7,74 +7,10 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
-/**

- * enum wmi_brightness_method - WMI method IDs
- * @WMI_BRIGHTNESS_METHOD_LEVEL:  Get/Set EC brightness level status
- * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
- */
-enum wmi_brightness_method {
-   WMI_BRIGHTNESS_METHOD_LEVEL = 1,
-   WMI_BRIGHTNESS_METHOD_SOURCE = 2,
-   WMI_BRIGHTNESS_METHOD_MAX
-};
-
-/**
- * enum wmi_brightness_mode - Operation mode for WMI-wrapped method
- * @WMI_BRIGHTNESS_MODE_GET:Get the current brightness 
level/source.
- * @WMI_BRIGHTNESS_MODE_SET:Set the brightness level.
- * @WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL:  Get the maximum brightness level. This
- *  is only valid when the WMI method is
- *  %WMI_BRIGHTNESS_METHOD_LEVEL.
- */
-enum wmi_brightness_mode {
-   WMI_BRIGHTNESS_MODE_GET = 0,
-   WMI_BRIGHTNESS_MODE_SET = 1,
-   WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL = 2,
-   WMI_BRIGHTNESS_MODE_MAX
-};
-
-/**
- * enum wmi_brightness_source - Backlight brightness control source selection
- * @WMI_BRIGHTNESS_SOURCE_GPU: Backlight brightness is controlled by the GPU.
- * @WMI_BRIGHTNESS_SOURCE_EC:  Backlight brightness is controlled by the
- * system's Embedded Controller (EC).
- * @WMI_BRIGHTNESS_SOURCE_AUX: Backlight brightness is controlled over the
- * DisplayPort AUX channel.
- */
-enum wmi_brightness_source {
-   WMI_BRIGHTNESS_SOURCE_GPU = 1,
-   WMI_BRIGHTNESS_SOURCE_EC = 2,
-   WMI_BRIGHTNESS_SOURCE_AUX = 3,
-   WMI_BRIGHTNESS_SOURCE_MAX
-};
-
-/**
- * struct wmi_brightness_args - arguments for the WMI-wrapped ACPI method
- * @mode:Pass in an  wmi_brightness_mode value to select between
- *   getting or setting a value.
- * @val: In parameter for value to set when using %WMI_BRIGHTNESS_MODE_SET
- *   mode. Not used in conjunction with %WMI_BRIGHTNESS_MODE_GET or
- *   %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL mode.
- * @ret: Out parameter returning retrieved value when operating in
- *   %WMI_BRIGHTNESS_MODE_GET or %WMI_BRIGHTNESS_MODE_GET_MAX_LEVEL
- *   mode. Not used in %WMI_BRIGHTNESS_MODE_SET mode.
- * @ignored: Padding; not used. The ACPI method expects a 24 byte params 
struct.
- *
- * This is the parameters structure for the WmiBrightnessNotify ACPI method as
- * wrapped by WMI. The value passed in to @val or returned by @ret will be a
- * brightness value when the WMI method ID is %WMI_BRIGHTNESS_METHOD_LEVEL, or
- * an  wmi_brightness_source value with %WMI_BRIGHTNESS_METHOD_SOURCE.
- */
-struct wmi_brightness_args {
-   u32 mode;
-   u32 val;
-   u32 ret;
-   u32 ignored[3];
-};
-
  /**
   * wmi_brightness_notify() - helper function for calling WMI-wrapped ACPI 
method
   * @w:Pointer to the struct wmi_device identified by %WMI_BRIGHTNESS_GUID
diff --git a/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h 
b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
new file mode 100644
index ..d83104c6c6cb
--- /dev/null
+++ b/include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0-only */



Should the copyright notice from nvidia-wmi-ec-backlight be copied here 
as well?




+#ifndef __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
+#define __PLATFORM_DATA_X86_NVIDIA_WMI_EC_BACKLIGHT_H
+
+/**
+ * enum wmi_brightness_method - WMI method IDs
+ * @WMI_BRIGHTNESS_METHOD_LEVEL:  Get/Set EC brightness level status
+ * @WMI_BRIGHTNESS_METHOD_SOURCE: Get/Set EC Brightness Source
+ */
+enum wmi_brightness_method {
+   

Re: build failure of next-20220817 for amdgpu due to 7bc913085765 ("drm/amdkfd: Try to schedule bottom half on same core")

2022-08-18 Thread Randy Dunlap
Hi--

On 8/18/22 12:15, Sudip Mukherjee wrote:
> On Thu, Aug 18, 2022 at 4:10 PM Randy Dunlap  wrote:
>>
>>
>>
>> On 8/18/22 03:43, Sudip Mukherjee wrote:
>>> On Thu, Aug 18, 2022 at 3:09 AM Randy Dunlap  wrote:



 On 8/17/22 19:01, Alex Deucher wrote:
> On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
>  wrote:
>>
>> Hi All,
>>
>> Not sure if it has been reported, build of next-20220817 fails with the
>> error:
>>
>> ERROR: modpost: "cpu_smallcore_map" 
>> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>>
>> Trying to do a git bisect to find out the offending commit.
>>
>
> Thanks.  I don't see that symbol in the driver at all.  Not sure where
> it is coming from.
>

 It's powerpc only.

 Sudip, is it non-CONFIG_SMP by any chance?
>>>
>>> Ohhh.. really sorry for the incomplete report. I should not try to
>>> mail while travelling.
>>>
>>> The error is seen with powerpc allmodconfig and it has CONFIG_SMP=y.
>>
>> OK, I see that also, but it doesn't make any sense (to me).
>>
>> I did 'objdump' on the code file (amdgpu.o) and it's listed as
>> undefined but there are no code references to it.
> 
> cpu_smt_mask() is called by drivers/gpu/drm/amd/amdkfd/kfd_device.c.
> and cpu_smt_mask() is an inline function in
> arch/powerpc/include/asm/smp.h which is doing "return
> per_cpu(cpu_smallcore_map, cpu);"
> 
> So, the offending commit is 7bc913085765 ("drm/amdkfd: Try to schedule
> bottom half on same core").

Thanks for digging that up.

It just needs to have that symbol exported I think.
This builds cleanly now.
I can submit it or one of the AMD gfx developers can do so.


---
 arch/powerpc/kernel/smp.c |1 +
 1 file changed, 1 insertion(+)

--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -86,6 +86,7 @@ DEFINE_PER_CPU(cpumask_var_t, cpu_core_m
 static DEFINE_PER_CPU(cpumask_var_t, cpu_coregroup_map);
 
 EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
+EXPORT_PER_CPU_SYMBOL(cpu_smallcore_map);
 EXPORT_PER_CPU_SYMBOL(cpu_l2_cache_map);
 EXPORT_PER_CPU_SYMBOL(cpu_core_map);
 EXPORT_SYMBOL_GPL(has_big_cores);


-- 
~Randy


[Bug 216376] AMDGPU: display output disables and quickly reenables when switching AVR into/from standby doing HDMI passthrough

2022-08-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=216376

--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
Yes, those are the events.  The desktop environment listens for them and
reacts.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: build failure of next-20220817 for amdgpu due to 7bc913085765 ("drm/amdkfd: Try to schedule bottom half on same core")

2022-08-18 Thread Sudip Mukherjee
On Thu, Aug 18, 2022 at 4:10 PM Randy Dunlap  wrote:
>
>
>
> On 8/18/22 03:43, Sudip Mukherjee wrote:
> > On Thu, Aug 18, 2022 at 3:09 AM Randy Dunlap  wrote:
> >>
> >>
> >>
> >> On 8/17/22 19:01, Alex Deucher wrote:
> >>> On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink)
> >>>  wrote:
> 
>  Hi All,
> 
>  Not sure if it has been reported, build of next-20220817 fails with the
>  error:
> 
>  ERROR: modpost: "cpu_smallcore_map" 
>  [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> 
>  Trying to do a git bisect to find out the offending commit.
> 
> >>>
> >>> Thanks.  I don't see that symbol in the driver at all.  Not sure where
> >>> it is coming from.
> >>>
> >>
> >> It's powerpc only.
> >>
> >> Sudip, is it non-CONFIG_SMP by any chance?
> >
> > Ohhh.. really sorry for the incomplete report. I should not try to
> > mail while travelling.
> >
> > The error is seen with powerpc allmodconfig and it has CONFIG_SMP=y.
>
> OK, I see that also, but it doesn't make any sense (to me).
>
> I did 'objdump' on the code file (amdgpu.o) and it's listed as
> undefined but there are no code references to it.

cpu_smt_mask() is called by drivers/gpu/drm/amd/amdkfd/kfd_device.c.
and cpu_smt_mask() is an inline function in
arch/powerpc/include/asm/smp.h which is doing "return
per_cpu(cpu_smallcore_map, cpu);"

So, the offending commit is 7bc913085765 ("drm/amdkfd: Try to schedule
bottom half on same core").


-- 
Regards
Sudip


[Bug 216376] AMDGPU: display output disables and quickly reenables when switching AVR into/from standby doing HDMI passthrough

2022-08-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=216376

--- Comment #4 from Jure Repinc (jlp.b...@gmail.com) ---
If I got it right, the hotplug events are all posted via udev? If so, is it
correct to use "udevadm monitor --environment --udev" to see these events
posted to userspace? Or is there somethign better? Just trying to make the best
sense out of it to try making a workaround and gather as much relevant
information to report a good bug/feature request with correct info to KDE
developers.


If I use "udevadm monitor --environment --udev" I get the output:

udevadm monitor --environment --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing


< switching AVR from on to standby mode >


UDEV  [35121.304457] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=74
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=12043
USEC_INITIALIZED=4651406
ID_PATH=pci-:01:00.0
ID_PATH_TAG=pci-_01_00_0
ID_FOR_SEAT=drm-pci-_01_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-:01:00.0-card
TAGS=:uaccess:master-of-seat:seat:
CURRENT_TAGS=:uaccess:master-of-seat:seat:

UDEV  [35124.216717] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=74
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=12044
USEC_INITIALIZED=4651406
ID_PATH=pci-:01:00.0
ID_PATH_TAG=pci-_01_00_0
ID_FOR_SEAT=drm-pci-_01_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-:01:00.0-card
TAGS=:uaccess:master-of-seat:seat:
CURRENT_TAGS=:uaccess:master-of-seat:seat:


< switching AVR from standby to on mode >


UDEV  [35155.373681] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=74
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=12048
USEC_INITIALIZED=4651406
ID_PATH=pci-:01:00.0
ID_PATH_TAG=pci-_01_00_0
ID_FOR_SEAT=drm-pci-_01_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-:01:00.0-card
TAGS=:uaccess:master-of-seat:seat:
CURRENT_TAGS=:uaccess:master-of-seat:seat:

UDEV  [35158.196252] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=74
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=12049
USEC_INITIALIZED=4651406
ID_PATH=pci-:01:00.0
ID_PATH_TAG=pci-_01_00_0
ID_FOR_SEAT=drm-pci-_01_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-:01:00.0-card
TAGS=:uaccess:master-of-seat:seat:
CURRENT_TAGS=:uaccess:master-of-seat:seat:

UDEV  [35158.953569] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=74
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=12050
USEC_INITIALIZED=4651406
ID_PATH=pci-:01:00.0
ID_PATH_TAG=pci-_01_00_0
ID_FOR_SEAT=drm-pci-_01_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-:01:00.0-card
TAGS=:uaccess:master-of-seat:seat:
CURRENT_TAGS=:uaccess:master-of-seat:seat:

UDEV  [35161.036327] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=74
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=12051
USEC_INITIALIZED=4651406
ID_PATH=pci-:01:00.0
ID_PATH_TAG=pci-_01_00_0
ID_FOR_SEAT=drm-pci-_01_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-:01:00.0-card
TAGS=:uaccess:master-of-seat:seat:
CURRENT_TAGS=:uaccess:master-of-seat:seat:

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3 31/31] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel

2022-08-18 Thread Hans de Goede
Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.

The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/

Signed-off-by: Hans de Goede 
---
 Documentation/gpu/todo.rst | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7634c27ac562..393d218e4a0c 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -679,6 +679,74 @@ Contact: Sam Ravnborg
 
 Level: Advanced
 
+Brightness handling on devices with multiple internal panels
+
+
+On x86/ACPI devices there can be multiple backlight firmware interfaces:
+(ACPI) video, vendor specific and others. As well as direct/native (PWM)
+register programming by the KMS driver.
+
+To deal with this backlight drivers used on x86/ACPI call
+acpi_video_get_backlight_type() which has heuristics (+quirks) to select
+which backlight interface to use; and backlight drivers which do not match
+the returned type will not register themselves, so that only one backlight
+device gets registered (in a single GPU setup, see below).
+
+At the moment this more or less assumes that there will only
+be 1 (internal) panel on a system.
+
+On systems with 2 panels this may be a problem, depending on
+what interface acpi_video_get_backlight_type() selects:
+
+1. native: in this case the KMS driver is expected to know which backlight
+   device belongs to which output so everything should just work.
+2. video: this does support controlling multiple backlights, but some work
+   will need to be done to get the output <-> backlight device mapping
+
+The above assumes both panels will require the same backlight interface type.
+Things will break on systems with multiple panels where the 2 panels need
+a different type of control. E.g. one panel needs ACPI video backlight control,
+where as the other is using native backlight control. Currently in this case
+only one of the 2 required backlight devices will get registered, based on
+the acpi_video_get_backlight_type() return value.
+
+If this (theoretical) case ever shows up, then supporting this will need some
+work. A possible solution here would be to pass a device and connector-name
+to acpi_video_get_backlight_type() so that it can deal with this.
+
+Note in a way we already have a case where userspace sees 2 panels,
+in dual GPU laptop setups with a mux. On those systems we may see
+either 2 native backlight devices; or 2 native backlight devices.
+
+Userspace already has code to deal with this by detecting if the related
+panel is active (iow which way the mux between the GPU and the panels
+points) and then uses that backlight device. Userspace here very much
+assumes a single panel though. It picks only 1 of the 2 backlight devices
+and then only uses that one.
+
+Note that all userspace code (that I know off) is currently hardcoded
+to assume a single panel.
+
+Before the recent changes to not register multiple (e.g. video + native)
+/sys/class/backlight devices for a single panel (on a single GPU laptop),
+userspace would see multiple backlight devices all controlling the same
+backlight.
+
+To deal with this userspace had to always picks one preferred device under
+/sys/class/backlight and will ignore the others. So to support brightness
+control on multiple panels userspace will need to be updated too.
+
+There are plans to allow brightness control through the KMS API by adding
+a "display brightness" property to drm_connector objects for panels. This
+solves a number of issues with the /sys/class/backlight API, including not
+being able to map a sysfs backlight device to a specific connector. Any
+userspace changes to add support for brightness control on devices with
+multiple panels really should build on top of this new KMS property.
+
+Contact: Hans de Goede
+
+Level: Advanced
+
 Outside DRM
 ===
 
-- 
2.37.2



[PATCH v3 30/31] ACPI: video: Fix indentation of video_detect_dmi_table[] entries

2022-08-18 Thread Hans de Goede
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.

Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.

But over time some entries did not event have the single space
indent in front of the ".name = ..." lines.

Make things consistent by using a single space indent for these
lines everywhere.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 48 ++---
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 150ef8214c73..9b84657f8f6a 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -142,17 +142,17 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Asus UL30VT */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30VT */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Asus UL30A */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Asus UL30A */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
@@ -198,9 +198,9 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* GIGABYTE GB-BXBT-2807 */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* GIGABYTE GB-BXBT-2807 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
@@ -233,17 +233,17 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Sony VPCEH3U1E */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Sony VPCEH3U1E */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"),
},
},
{
-   .callback = video_detect_force_vendor,
-   /* Xiaomi Mi Pad 2 */
-   .matches = {
+.callback = video_detect_force_vendor,
+/* Xiaomi Mi Pad 2 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"),
DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
},
@@ -551,25 +551,25 @@ static const struct dmi_system_id 
video_detect_dmi_table[] = {
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA401 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA401 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA401"),
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA502 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA502 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA502"),
},
},
{
-   .callback = video_detect_force_native,
-   /* ASUSTeK COMPUTER INC. GA503 */
-   .matches = {
+.callback = video_detect_force_native,
+/* ASUSTeK COMPUTER INC. GA503 */
+.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
-- 
2.37.2



[PATCH v3 27/31] ACPI: video: Remove acpi_video_set_dmi_backlight_type()

2022-08-18 Thread Hans de Goede
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.

All callers have been fixed to no longer call it, so remove
acpi_video_set_dmi_backlight_type() now.

This means we now also no longer need acpi_video_unregister_backlight()
for the remove acpi_video backlight after it was wrongly registered hack,
so remove that too.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/acpi_video.c   | 10 --
 drivers/acpi/video_detect.c | 16 
 include/acpi/video.h|  4 
 3 files changed, 30 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index d1e41f30c004..a7c3d11e0dac 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2296,16 +2296,6 @@ void acpi_video_register_backlight(void)
 }
 EXPORT_SYMBOL(acpi_video_register_backlight);
 
-void acpi_video_unregister_backlight(void)
-{
-   struct acpi_video_bus *video;
-
-   mutex_lock(_list_lock);
-   list_for_each_entry(video, _bus_head, entry)
-   acpi_video_bus_unregister_backlight(video);
-   mutex_unlock(_list_lock);
-}
-
 bool acpi_video_handles_brightness_key_presses(void)
 {
return may_report_brightness_keys &&
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 66ea650fb45f..84ae22670e54 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,8 +38,6 @@
 #include 
 #include 
 
-void acpi_video_unregister_backlight(void);
-
 static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
 static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
 
@@ -817,17 +815,3 @@ bool acpi_video_backlight_use_native(void)
return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
 }
 EXPORT_SYMBOL(acpi_video_backlight_use_native);
-
-/*
- * Set the preferred backlight interface type based on DMI info.
- * This function allows DMI blacklists to be implemented by external
- * platform drivers instead of putting a big blacklist in video_detect.c
- */
-void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
-{
-   acpi_backlight_dmi = type;
-   /* Remove acpi-video backlight interface if it is no longer desired */
-   if (acpi_video_get_backlight_type() != acpi_backlight_video)
-   acpi_video_unregister_backlight();
-}
-EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
diff --git a/include/acpi/video.h b/include/acpi/video.h
index dbd48cb8bd23..a275c35e5249 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -60,7 +60,6 @@ extern int acpi_video_get_edid(struct acpi_device *device, 
int type,
   int device_id, void **edid);
 extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
 extern bool acpi_video_backlight_use_native(void);
-extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
 /*
  * Note: The value returned by acpi_video_handles_brightness_key_presses()
  * may change over time and should not be cached.
@@ -86,9 +85,6 @@ static inline bool acpi_video_backlight_use_native(void)
 {
return true;
 }
-static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type 
type)
-{
-}
 static inline bool acpi_video_handles_brightness_key_presses(void)
 {
return false;
-- 
2.37.2



[PATCH v3 29/31] ACPI: video: Drop NL5x?U, PF4NU1F and PF5?U?? acpi_backlight=native quirks

2022-08-18 Thread Hans de Goede
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.

After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.

So this is no longer an issue an the quirks are no longer needed.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683
Tested-by: Werner Sembach 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 92 +
 1 file changed, 1 insertion(+), 91 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index ce6d89fcdc0e..150ef8214c73 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -609,97 +609,7 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_BOARD_NAME, "N250P"),
},
},
-   /*
-* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
-* working native and video interface. However the default detection
-* mechanism first registers the video interface before unregistering
-* it again and switching to the native interface during boot. This
-* results in a dangling SBIOS request for backlight change for some
-* reason, causing the backlight to switch to ~2% once per boot on the
-* first power cord connect or disconnect event. Setting the native
-* interface explicitly circumvents this buggy behaviour, by avoiding
-* the unregistering process.
-*/
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
-   /*
-* The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 
Gen10,
-* Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the 
Clevo
-* NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description
-* above.
-*/
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5PU1G",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF4NU1F",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF4NU1F",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5NU1G",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5NU1G",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "TongFang PF5LUXG",
-   .matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"),
-   },
-   },
+
/*
 * Desktops which falsely report a backlight and which our heuristics
 * for this do not catch.
-- 
2.37.2



[PATCH v3 24/31] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c

2022-08-18 Thread Hans de Goede
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.

acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

Note no entries are dropped from the dmi_system_id table in asus-nb-wmi.c.
This is because the entries using the removed wmi_backlight_power flag
also use other model specific quirks from the asus-wmi quirk_entry struct.
So the quirk_asus_x55u struct and the entries pointing to it cannot be
dropped.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c| 40 ++
 drivers/platform/x86/asus-nb-wmi.c |  7 --
 drivers/platform/x86/asus-wmi.c|  3 ---
 drivers/platform/x86/asus-wmi.h|  1 -
 drivers/platform/x86/eeepc-wmi.c   | 25 +--
 5 files changed, 41 insertions(+), 35 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 4545f9f1a5b1..1574ff837e31 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -174,6 +174,46 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
},
+   {
+.callback = video_detect_force_vendor,
+/* Asus X55U */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X55U"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus X101CH */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus X401U */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X401U"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus X501U */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X501U"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Asus 1015CX */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"),
+   },
+   },
{
.callback = video_detect_force_vendor,
/* GIGABYTE GB-BXBT-2807 */
diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index 478dd300b9c9..810a94557a85 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -79,12 +79,10 @@ static struct quirk_entry quirk_asus_q500a = {
 
 /*
  * For those machines that need software to control bt/wifi status
- * and can't adjust brightness through ACPI interface
  * and have duplicate events(ACPI and WMI) for display toggle
  */
 static struct quirk_entry quirk_asus_x55u = {
.wapf = 4,
-   .wmi_backlight_power = true,
.wmi_backlight_set_devstate = true,
.no_display_toggle = true,
 };
@@ -147,11 +145,6 @@ static const struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "U32U"),
},
-   /*
-* Note this machine has a Brazos APU, and most Brazos Asus
-* machines need quirk_asus_x55u / wmi_backlight_power but
-* here acpi-video seems to work fine for backlight control.
-*/
.driver_data = _asus_wapf4,
},
{
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 301166a5697d..5cf9d9aff164 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
 
-   if (asus->driver->quirks->wmi_backlight_power)
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_native)
acpi_video_set_dmi_backlight_type(acpi_backlight_native);
 
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index b302415bf1d9..30770e411301 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct 

[PATCH v3 26/31] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c

2022-08-18 Thread Hans de Goede
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

Move all the acpi_backlight=[vendor|native] quirks from samsung-laptop to
drivers/acpi/video_detect.c .

Note the X360 -> acpi_backlight=native quirk is not moved because that
already was present in drivers/acpi/video_detect.c .

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c   | 54 +
 drivers/platform/x86/samsung-laptop.c | 87 ---
 2 files changed, 54 insertions(+), 87 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index a871ee69fcb2..66ea650fb45f 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -222,6 +222,33 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
},
+   {
+.callback = video_detect_force_vendor,
+/* Samsung N150/N210/N220 */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N150/N210/N220"),
+   DMI_MATCH(DMI_BOARD_NAME, "N150/N210/N220"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Samsung NF110/NF210/NF310 */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "NF110/NF210/NF310"),
+   DMI_MATCH(DMI_BOARD_NAME, "NF110/NF210/NF310"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+/* Samsung NC210 */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "NC210/NC110"),
+   DMI_MATCH(DMI_BOARD_NAME, "NC210/NC110"),
+   },
+   },
{
.callback = video_detect_force_vendor,
/* Sony VPCEH3U1E */
@@ -572,6 +599,33 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
},
},
+   {
+.callback = video_detect_force_native,
+/* Samsung N150P */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
+   DMI_MATCH(DMI_BOARD_NAME, "N150P"),
+   },
+   },
+   {
+.callback = video_detect_force_native,
+/* Samsung N145P/N250P/N260P */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N145P/N250P/N260P"),
+   DMI_MATCH(DMI_BOARD_NAME, "N145P/N250P/N260P"),
+   },
+   },
+   {
+.callback = video_detect_force_native,
+/* Samsung N250P */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "N250P"),
+   DMI_MATCH(DMI_BOARD_NAME, "N250P"),
+   },
+   },
/*
 * Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
 * working native and video interface. However the default detection
diff --git a/drivers/platform/x86/samsung-laptop.c 
b/drivers/platform/x86/samsung-laptop.c
index c187dcdf82f0..cc30cf08f32d 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -356,23 +356,13 @@ struct samsung_laptop {
 };
 
 struct samsung_quirks {
-   bool broken_acpi_video;
bool four_kbd_backlight_levels;
bool enable_kbd_backlight;
-   bool use_native_backlight;
bool lid_handling;
 };
 
 static struct samsung_quirks samsung_unknown = {};
 
-static struct samsung_quirks samsung_broken_acpi_video = {
-   .broken_acpi_video = true,
-};
-
-static struct samsung_quirks samsung_use_native_backlight = {
-   .use_native_backlight = true,
-};
-
 static struct samsung_quirks samsung_np740u3e = {
.four_kbd_backlight_levels = true,
.enable_kbd_backlight = true,
@@ -1540,76 +1530,6 @@ static const struct dmi_system_id samsung_dmi_table[] 
__initconst = {
},
},
/* Specific DMI ids for laptop with quirks */
-   {
-.callback = samsung_dmi_matched,
-.ident = "N150P",
-.matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
-   DMI_MATCH(DMI_BOARD_NAME, "N150P"),
-   },
-.driver_data = _use_native_backlight,
-   },
-   {
-.callback = 

[PATCH v3 25/31] platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c

2022-08-18 Thread Hans de Goede
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.

acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c|  8 
 drivers/platform/x86/asus-nb-wmi.c | 14 --
 drivers/platform/x86/asus-wmi.c|  3 ---
 drivers/platform/x86/asus-wmi.h|  1 -
 4 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 1574ff837e31..a871ee69fcb2 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -564,6 +564,14 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
+   {
+.callback = video_detect_force_native,
+/* Asus UX303UB */
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
+   },
+   },
/*
 * Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
 * working native and video interface. However the default detection
diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index 810a94557a85..bbfed85051ee 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -97,11 +97,6 @@ static struct quirk_entry quirk_asus_x200ca = {
.wmi_backlight_set_devstate = true,
 };
 
-static struct quirk_entry quirk_asus_ux303ub = {
-   .wmi_backlight_native = true,
-   .wmi_backlight_set_devstate = true,
-};
-
 static struct quirk_entry quirk_asus_x550lb = {
.wmi_backlight_set_devstate = true,
.xusb2pr = 0x01D9,
@@ -372,15 +367,6 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = _asus_x200ca,
},
-   {
-   .callback = dmi_matched,
-   .ident = "ASUSTeK COMPUTER INC. UX303UB",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
-   DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
-   },
-   .driver_data = _asus_ux303ub,
-   },
{
.callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. UX330UAK",
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 5cf9d9aff164..434249ac47a5 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3634,9 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
 
-   if (asus->driver->quirks->wmi_backlight_native)
-   acpi_video_set_dmi_backlight_type(acpi_backlight_native);
-
if (asus->driver->quirks->xusb2pr)
asus_wmi_set_xusb2pr(asus);
 
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 30770e411301..f30252efe1db 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct quirk_entry {
bool hotplug_wireless;
bool scalar_panel_brightness;
bool store_backlight_power;
-   bool wmi_backlight_native;
bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
bool use_kbd_dock_devid;
-- 
2.37.2



[PATCH v3 21/31] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type()

2022-08-18 Thread Hans de Goede
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.

In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.

In case of toshiba_acpi there are no DMI quirks to move to
acpi/video_detect.c, but it also (ab)uses it for transflective
displays. Adding transflective display support to video_detect.c would
be quite involved. But luckily there are only 2 known models with
a transflective display, so we can just add DMI quirks for those.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
---
 drivers/acpi/video_detect.c | 19 +++
 drivers/platform/x86/toshiba_acpi.c | 16 
 2 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 8c0db00a48cf..891138d47def 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -190,6 +190,25 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
},
},
 
+   /*
+* Toshiba models with Transflective display, these need to use
+* the toshiba_acpi vendor driver for proper Transflective handling.
+*/
+   {
+.callback = video_detect_force_vendor,
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R500"),
+   },
+   },
+   {
+.callback = video_detect_force_vendor,
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R600"),
+   },
+   },
+
/*
 * These models have a working acpi_video backlight control, and using
 * native backlight causes a regression where backlight does not work
diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 0fc9e8b8827b..030dc37d50b8 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -271,14 +271,6 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
{ KE_END, 0 },
 };
 
-/*
- * List of models which have a broken acpi-video backlight interface and thus
- * need to use the toshiba (vendor) interface instead.
- */
-static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
-   {}
-};
-
 /*
  * Utility
  */
@@ -2881,14 +2873,6 @@ static int toshiba_acpi_setup_backlight(struct 
toshiba_acpi_dev *dev)
return 0;
}
 
-   /*
-* Tell acpi-video-detect code to prefer vendor backlight on all
-* systems with transflective backlight and on dmi matched systems.
-*/
-   if (dev->tr_backlight_supported ||
-   dmi_check_system(toshiba_vendor_backlight_dmi))
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return 0;
 
-- 
2.37.2



[PATCH v3 23/31] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling

2022-08-18 Thread Hans de Goede
Remove this check from the asus-wmi backlight handling:

/* Some Asus desktop boards export an acpi-video backlight interface,
   stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);

This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be
removed because other changes in this series change the native backlight
drivers to no longer unconditionally register their backlight. Instead
these drivers now do this check:

if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
return 0; /* bail */

So leaving this in place can break things on laptops with a broken
DMI chassis-type, which would have GPU native brightness control before
the addition of the acpi_video_get_backlight_type() != native check.

Removing this should be ok now, since the ACPI video code has improved
heuristics for this itself now (which includes a chassis-type check).

Signed-off-by: Hans de Goede 
---
 drivers/platform/x86/asus-wmi.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 89b604e04d7f..301166a5697d 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3553,7 +3553,6 @@ static int asus_wmi_add(struct platform_device *pdev)
struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver);
struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv);
struct asus_wmi *asus;
-   const char *chassis_type;
acpi_status status;
int err;
u32 result;
@@ -3635,12 +3634,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
 
-   /* Some Asus desktop boards export an acpi-video backlight interface,
-  stop this from showing up */
-   chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
-   if (chassis_type && !strcmp(chassis_type, "3"))
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_power)
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
 
-- 
2.37.2



[PATCH v3 20/31] platform/x86: apple-gmux: Stop calling acpi/video.h functions

2022-08-18 Thread Hans de Goede
Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.

So remove the handling for this from the apple-gmux driver.

Signed-off-by: Hans de Goede 
---
 drivers/platform/x86/apple-gmux.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index ffe98a18440b..ca33df7ea550 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /**
@@ -694,7 +693,6 @@ static int gmux_probe(struct pnp_dev *pnp, const struct 
pnp_device_id *id)
 * backlight control and supports more levels than other options.
 * Disable the other backlight choices.
 */
-   acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
apple_bl_unregister();
 
gmux_data->power_state = VGA_SWITCHEROO_ON;
@@ -804,7 +802,6 @@ static void gmux_remove(struct pnp_dev *pnp)
apple_gmux_data = NULL;
kfree(gmux_data);
 
-   acpi_video_register();
apple_bl_register();
 }
 
-- 
2.37.2



  1   2   >