date:20231012

On 12/10/2023 10:40, Moudy Ho wrote:
> Add compatible string and GCE property for MT8195 SPLIT, of
> which is operated by MDP3.
> 
> Signed-off-by: Moudy Ho 


> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: mediatek,mt8195-mdp3-split
> +
> +then:
> +  required:
> +- mediatek,gce-client-reg

else:
  mediatek,gce-client-reg: false


> +
>  additionalProperties: false
>  
>  examples:

Best regards,
Krzysztof

Re: [PATCH v7 14/16] dt-bindings: display: mediatek: ovl: add compatible for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add a compatible string for the OVL block in MediaTek MT8195 that
> is controlled by MDP3.
> 
> Signed-off-by: Moudy Ho 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 13/16] dt-bindings: display: mediatek: merge: add compatible for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add a compatible string for the MERGE block in MediaTek MT8195 that
> is controlled by MDP3.
> 
> Signed-off-by: Moudy Ho 
> ---

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add a compatible string for the COLOR block in MediaTek MT8195 that
> is controlled by MDP3.
> 
> Signed-off-by: Moudy Ho 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 10/16] dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add the fundamental hardware configuration of component TDSHP,
> which is controlled by MDP3 on MT8195.
> 
> Signed-off-by: Moudy Ho 
> ---

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 09/16] dt-bindings: media: mediatek: mdp3: add component TCC for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add the fundamental hardware configuration of component TCC,
> which is controlled by MDP3 on MT8195.
> 
> Signed-off-by: Moudy Ho 
> ---
>  .../bindings/media/mediatek,mdp3-tcc.yaml | 62 +++

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 08/16] dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add the fundamental hardware configuration of component STITCH,
> which is controlled by MDP3 on MT8195.
> 
> Signed-off-by: Moudy Ho 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 07/16] dt-bindings: media: mediatek: mdp3: add component HDR for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add the fundamental hardware configuration of component HDR,
> which is controlled by MDP3 on MT8195.
> 
> Signed-off-by: Moudy Ho 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 3/3] drm/rockchip: fix the plane format defination of rk3568/6

2023-10-12 Thread Andy Yan


Hi Sacha:

On 10/13/23 14:11, Sascha Hauer wrote:

On Thu, Oct 12, 2023 at 10:37:05AM +0800, Andy Yan wrote:

From: Andy Yan 

The cluster windows on rk3568/6 only support afbc format,
linear format(RGB/YUV) are not supported.
The cluster windows on rk3588 support both linear and afbc rgb
format, but for yuv format it only support afbc.

The esmart windows on rk3588 support uv swap for yuyv, but
rk356x does not support it.

It's a bit hard to track which sentence in the description refers to
which change in the patch. Could you split this up into multiple patches
to make this easier reviewable?

Renaming of the formats could also be a separate patch. Patches marked
with "no functional change" are nice and easy to review.



How do you like if I split  the patch like bellow:

PATCH 1 : fix the format

PATCH 2: rename: s/formats_win_full_10bit/formats_cluster/

s/formats_win_full_10bit_yuyv/formats_rk356x_esmart/

s/formats_win_little/formats_win_smart/


Signed-off-by: Andy Yan 
---

  drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 53 +++-
  1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index 62b573f282a7..cde85a17f138 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -15,7 +15,11 @@
  
  #include "rockchip_drm_vop2.h"
  
-static const uint32_t formats_win_full_10bit[] = {

+static const uint32_t formats_for_cluster[] = {

You can drop the "for_"

Sascha


+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_ARGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_ABGR2101010,
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
@@ -24,12 +28,14 @@ static const uint32_t formats_win_full_10bit[] = {
DRM_FORMAT_BGR888,
DRM_FORMAT_RGB565,
DRM_FORMAT_BGR565,
-   DRM_FORMAT_NV12,
-   DRM_FORMAT_NV16,
-   DRM_FORMAT_NV24,
+   DRM_FORMAT_YUV420_8BIT, /* yuv420_8bit non-Linear mode only */
+   DRM_FORMAT_YUV420_10BIT, /* yuv420_10bit non-Linear mode only */
+   DRM_FORMAT_YUYV, /* yuv422_8bit non-Linear mode only*/
+   DRM_FORMAT_Y210, /* yuv422_10bit non-Linear mode only */
  };
  
-static const uint32_t formats_win_full_10bit_yuyv[] = {

+/* RK356x can't support uv swap for YUYV and UYVY */
+static const uint32_t formats_for_rk356x_esmart[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
@@ -38,14 +44,15 @@ static const uint32_t formats_win_full_10bit_yuyv[] = {
DRM_FORMAT_BGR888,
DRM_FORMAT_RGB565,
DRM_FORMAT_BGR565,
-   DRM_FORMAT_NV12,
-   DRM_FORMAT_NV16,
-   DRM_FORMAT_NV24,
-   DRM_FORMAT_YVYU,
-   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12, /* yuv420_8bit linear mode, 2 plane */
+   DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
+   DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
+   DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
+   DRM_FORMAT_YUYV, /* yuv422_8bit[YUYV] linear mode */
+   DRM_FORMAT_UYVY, /* yuv422_8bit[UYVY] linear mode */
  };
  
-static const uint32_t formats_win_lite[] = {

+static const uint32_t formats_for_smart[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
@@ -144,8 +151,8 @@ static const struct vop2_win_data rk3568_vop_win_data[] = {
.name = "Smart0-win0",
.phys_id = ROCKCHIP_VOP2_SMART0,
.base = 0x1c00,
-   .formats = formats_win_lite,
-   .nformats = ARRAY_SIZE(formats_win_lite),
+   .formats = formats_for_smart,
+   .nformats = ARRAY_SIZE(formats_for_smart),
.format_modifiers = format_modifiers,
.layer_sel_id = 3,
.supported_rotations = DRM_MODE_REFLECT_Y,
@@ -156,8 +163,8 @@ static const struct vop2_win_data rk3568_vop_win_data[] = {
}, {
.name = "Smart1-win0",
.phys_id = ROCKCHIP_VOP2_SMART1,
-   .formats = formats_win_lite,
-   .nformats = ARRAY_SIZE(formats_win_lite),
+   .formats = formats_for_smart,
+   .nformats = ARRAY_SIZE(formats_for_smart),
.format_modifiers = format_modifiers,
.base = 0x1e00,
.layer_sel_id = 7,
@@ -169,8 +176,8 @@ static const struct vop2_win_data rk3568_vop_win_data[] = {
}, {
.name = "Esmart1-win0",
.phys_id = ROCKCHIP_VOP2_ESMART1,
-   .formats = formats_win_full_10bit_yuyv,
-   .nformats = ARRAY_SIZE(formats_win_full_10bit_yuyv),
+   .formats = formats_for_rk356x_esmart,
+   .nformats = ARRAY_SIZE(formats_for_rk356x_esmart),
.format_modifiers = format_modifiers,
.base = 0x1a00,

Re: [PATCH v7 06/16] dt-bindings: media: mediatek: mdp3: add component FG for MT8195

On 12/10/2023 10:40, Moudy Ho wrote:
> Add the fundamental hardware configuration of component FG,
> which is controlled by MDP3 on MT8195.
> 
> Signed-off-by: Moudy Ho 
> ---

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 05/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 WROT

On 12/10/2023 10:40, Moudy Ho wrote:
> MT8195 WROT inherited from MT8183, add the corresponding
> compatible name to it.
> 
> Signed-off-by: Moudy Ho 
> ---

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 04/16] dt-bindings: media: mediatek: mdp3: add compatible for MT8195 RSZ

On 12/10/2023 10:40, Moudy Ho wrote:
> MT8195 RSZ inherited from MT8183, add the corresponding
> compatible name to it.
> 
> Signed-off-by: Moudy Ho 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v7 03/16] dt-bindings: media: mediatek: mdp3: add config for MT8195 RDMA

On 12/10/2023 10:40, Moudy Ho wrote:
> Added the configuration for MT8195 RDMA. In comparison to MT8183, it
> no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox.
> 
> Signed-off-by: Moudy Ho 
> ---
>  .../bindings/media/mediatek,mdp3-rdma.yaml| 26 ++-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml 
> b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> index c043204cf210..504334a76fb3 100644
> --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> @@ -22,6 +22,7 @@ properties:
>compatible:
>  enum:
>- mediatek,mt8183-mdp3-rdma
> +  - mediatek,mt8195-mdp3-rdma
>- mediatek,mt8195-vdo1-rdma
>  
>reg:
> @@ -58,7 +59,7 @@ properties:
>  
>mboxes:
>  minItems: 1
> -maxItems: 2
> +maxItems: 5
>  
>interrupts:
>  maxItems: 1
> @@ -98,6 +99,29 @@ allOf:
>  - mboxes
>  - mediatek,gce-events
>  
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: mediatek,mt8195-mdp3-rdma
> +
> +then:
> +  properties:
> +clocks:
> +  items:
> +- description: RDMA clock
> +
> +mboxes:
> +  items:
> +- description: used for 1st data pipe from RDMA
> +- description: used for 2nd data pipe from RDMA
> +- description: used for 3rd data pipe from RDMA
> +- description: used for 4th data pipe from RDMA
> +- description: used for the data pipe from SPLIT

Missing interrupts

Best regards,
Krzysztof

Re: [PATCH v7 02/16] dt-bindings: media: mediatek: mdp3: merge the indentical RDMA under display

On 12/10/2023 10:40, Moudy Ho wrote:

>  
> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: mediatek,mt8183-mdp3-rdma
> +
> +then:
> +  properties:
> +clocks:
> +  items:
> +- description: RDMA clock
> +- description: RSZ clock (shared SRAM with RDMA)
> +
> +mboxes:
> +  items:
> +- description: used for 1st data pipe from RDMA
> +- description: used for 2nd data pipe from RDMA

interrupts:
  false

> +
> +  required:
> +- mboxes
> +- mediatek,gce-events
> +
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: mediatek,mt8195-vdo1-rdma
> +
> +then:
> +  properties:
> +clocks:
> +  items:
> +- description: RDMA clock

mboxes: false
mediatek,gce-events: false

I am not so sure it is actually "simpler" to merge these. They are quite
different. You will end up with unmanageable allOf  with a lot of
branches (which supposedly you want to remove).


> +
>  additionalProperties: false
>  
>  examples:

Best regards,
Krzysztof

Re: [PATCH 1/3] drm/rockchip: remove unused struct in vop2

2023-10-12 Thread Sascha Hauer

On Thu, Oct 12, 2023 at 10:36:53AM +0800, Andy Yan wrote:
> From: Andy Yan 
> 
> These structs are undefined and un used.
> Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
> 
> Signed-off-by: Andy Yan 

Reviewed-by: Sascha Hauer 

Sascha

> 
> ---
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 --
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 3 ---
>  2 files changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 583df4d22f7e..3c524ca23d53 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -160,7 +160,6 @@ struct vop2_video_port {
>   struct vop2 *vop2;
>   struct clk *dclk;
>   unsigned int id;
> - const struct vop2_video_port_regs *regs;
>   const struct vop2_video_port_data *data;
>  
>   struct completion dsp_hold_completion;
> @@ -2274,7 +2273,6 @@ static int vop2_create_crtcs(struct vop2 *vop2)
>   vp = &vop2->vps[i];
>   vp->vop2 = vop2;
>   vp->id = vp_data->id;
> - vp->regs = vp_data->regs;
>   vp->data = vp_data;
>  
>   snprintf(dclk_name, sizeof(dclk_name), "dclk_vp%d", vp->id);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> index f1234a151130..56fd31e05238 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> @@ -134,16 +134,13 @@ struct vop2_video_port_data {
>   u16 cubic_lut_len;
>   struct vop_rect max_output;
>   const u8 pre_scan_max_dly[4];
> - const struct vop2_video_port_regs *regs;
>   unsigned int offset;
>  };
>  
>  struct vop2_data {
>   u8 nr_vps;
> - const struct vop2_ctrl *ctrl;
>   const struct vop2_win_data *win;
>   const struct vop2_video_port_data *vp;
> - const struct vop_csc_table *csc_table;
>   struct vop_rect max_input;
>   struct vop_rect max_output;
>  
> -- 
> 2.34.1
> 
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v3 04/16] platform/x86/amd/pmf: Add support for PMF Policy Binary

2023-10-12 Thread Shyam Sundar S K




On 10/11/2023 8:47 AM, Shyam Sundar S K wrote:
> 
> 
> On 10/10/2023 9:56 PM, Mario Limonciello wrote:
>> On 10/10/2023 07:59, Shyam Sundar S K wrote:
>>> PMF Policy binary is a encrypted and signed binary that will be part
>>> of the BIOS. PMF driver via the ACPI interface checks the existence
>>> of Smart PC bit. If the advertised bit is found, PMF driver walks
>>> the acpi namespace to find out the policy binary size and the address
>>> which has to be passed to the TA during the TA init sequence.
>>>
>>> The policy binary is comprised of inputs (or the events) and outputs
>>> (or the actions). With the PMF ecosystem, OEMs generate the policy
>>> binary (or could be multiple binaries) that contains a supported set
>>> of inputs and outputs which could be specifically carved out for each
>>> usage segment (or for each user also) that could influence the system
>>> behavior either by enriching the user experience or/and boost/throttle
>>> power limits.
>>>
>>> Once the TA init command succeeds, the PMF driver sends the changing
>>> events in the current environment to the TA for a constant sampling
>>> frequency time (the event here could be a lid close or open) and
>>> if the policy binary has corresponding action built within it, the
>>> TA sends the action for it in the subsequent enact command.
>>>
>>> If the inputs sent to the TA has no output defined in the policy
>>> binary generated by OEMs, there will be no action to be performed
>>> by the PMF driver.
>>>
>>> Example policies:
>>>
>>> 1) if slider is performance ; set the SPL to 40W
>>> Here PMF driver registers with the platform profile interface and
>>> when the slider position is changed, PMF driver lets the TA know
>>> about this. TA sends back an action to update the Sustained
>>> Power Limit (SPL). PMF driver updates this limit via the PMFW mailbox.
>>>
>>> 2) if user_away ; then lock the system
>>> Here PMF driver hooks to the AMD SFH driver to know the user presence
>>> and send the inputs to TA and if the condition is met, the TA sends
>>> the action of locking the system. PMF driver generates a uevent and
>>> based on the udev rule in the userland the system gets locked with
>>> systemctl.
>>>
>>> The intent here is to provide the OEM's to make a policy to lock the
>>> system when the user is away ; but the userland can make a choice to
>>> ignore it.
>>>
>>> and so on.
>>>
>>> The OEMs will have an utility to create numerous such policies and
>>> the policies shall be reviewed by AMD before signing and encrypting
>>> them. Policies are shared between operating systems to have seemless
>>> user
>>> experience.
>>>
>>> Since all this action has to happen via the "amdtee" driver, currently
>>> there is no caller for it in the kernel which can load the amdtee
>>> driver.
>>> Without amdtee driver loading onto the system the "tee" calls shall
>>> fail
>>> from the PMF driver. Hence an explicit "request_module" has been added
>>> to address this.
>>>
>>> Signed-off-by: Shyam Sundar S K 
>>> ---
>>>   drivers/platform/x86/amd/pmf/Kconfig  |   2 +-
>>>   drivers/platform/x86/amd/pmf/acpi.c   |  37 +++
>>>   drivers/platform/x86/amd/pmf/core.c   |  13 +++
>>>   drivers/platform/x86/amd/pmf/pmf.h    | 136 
>>>   drivers/platform/x86/amd/pmf/tee-if.c | 146
>>> +-
>>>   5 files changed, 331 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/platform/x86/amd/pmf/Kconfig
>>> b/drivers/platform/x86/amd/pmf/Kconfig
>>> index 32a029e8db80..f246252bddd8 100644
>>> --- a/drivers/platform/x86/amd/pmf/Kconfig
>>> +++ b/drivers/platform/x86/amd/pmf/Kconfig
>>> @@ -9,7 +9,7 @@ config AMD_PMF
>>>   depends on POWER_SUPPLY
>>>   depends on AMD_NB
>>>   select ACPI_PLATFORM_PROFILE
>>> -    depends on TEE
>>> +    depends on TEE && AMDTEE
>>>   help
>>>     This driver provides support for the AMD Platform Management
>>> Framework.
>>>     The goal is to enhance end user experience by making AMD PCs
>>> smarter,
>>> diff --git a/drivers/platform/x86/amd/pmf/acpi.c
>>> b/drivers/platform/x86/amd/pmf/acpi.c
>>> index 3fc5e4547d9f..d0512af2cd42 100644
>>> --- a/drivers/platform/x86/amd/pmf/acpi.c
>>> +++ b/drivers/platform/x86/amd/pmf/acpi.c
>>> @@ -286,6 +286,43 @@ int apmf_install_handler(struct amd_pmf_dev
>>> *pmf_dev)
>>>   return 0;
>>>   }
>>>   +static acpi_status apmf_walk_resources(struct acpi_resource *res,
>>> void *data)
>>> +{
>>> +    struct amd_pmf_dev *dev = data;
>>> +
>>> +    switch (res->type) {
>>> +    case ACPI_RESOURCE_TYPE_ADDRESS64:
>>> +    dev->policy_addr = res->data.address64.address.minimum;
>>> +    dev->policy_sz = res->data.address64.address.address_length;
>>> +    break;
>>> +    case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
>>> +    dev->policy_addr = res->data.fixed_memory32.address;
>>> +    dev->policy_sz = res->data.fixed_memory32.address_length;
>>> +    break;
>>> +    }
>>> +
>>> +    if (!dev->policy_addr || de

Re: [PATCH 2/3] drm/rockchip: remove NR_LAYERS macro on vop2

2023-10-12 Thread Sascha Hauer

On Thu, Oct 12, 2023 at 10:36:30AM +0800, Andy Yan wrote:
> From: Andy Yan 
> 
> There are 8 layers on rk3588, so a fix defined macro is
> not appropriate.
> Signed-off-by: Andy Yan 
> ---
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Sascha Hauer 

Sascha

> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 3c524ca23d53..57c05c6b246c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -2251,8 +2251,6 @@ static struct vop2_video_port 
> *find_vp_without_primary(struct vop2 *vop2)
>   return NULL;
>  }
>  
> -#define NR_LAYERS 6
> -
>  static int vop2_create_crtcs(struct vop2 *vop2)
>  {
>   const struct vop2_data *vop2_data = vop2->data;
> @@ -2371,7 +2369,7 @@ static int vop2_create_crtcs(struct vop2 *vop2)
>   struct vop2_video_port *vp = &vop2->vps[i];
>  
>   if (vp->crtc.port)
> - vp->nlayers = NR_LAYERS / nvps;
> + vp->nlayers = vop2_data->win_size / nvps;
>   }
>  
>   return 0;
> -- 
> 2.34.1
> 
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 3/3] drm/rockchip: fix the plane format defination of rk3568/6

2023-10-12 Thread Sascha Hauer

On Thu, Oct 12, 2023 at 10:37:05AM +0800, Andy Yan wrote:
> From: Andy Yan 
> 
> The cluster windows on rk3568/6 only support afbc format,
> linear format(RGB/YUV) are not supported.
> The cluster windows on rk3588 support both linear and afbc rgb
> format, but for yuv format it only support afbc.
> 
> The esmart windows on rk3588 support uv swap for yuyv, but
> rk356x does not support it.

It's a bit hard to track which sentence in the description refers to
which change in the patch. Could you split this up into multiple patches
to make this easier reviewable?

Renaming of the formats could also be a separate patch. Patches marked
with "no functional change" are nice and easy to review.

> 
> Signed-off-by: Andy Yan 
> ---
> 
>  drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 53 +++-
>  1 file changed, 30 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c 
> b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 62b573f282a7..cde85a17f138 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -15,7 +15,11 @@
>  
>  #include "rockchip_drm_vop2.h"
>  
> -static const uint32_t formats_win_full_10bit[] = {
> +static const uint32_t formats_for_cluster[] = {

You can drop the "for_"

Sascha

> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_ARGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_ABGR2101010,
>   DRM_FORMAT_XRGB,
>   DRM_FORMAT_ARGB,
>   DRM_FORMAT_XBGR,
> @@ -24,12 +28,14 @@ static const uint32_t formats_win_full_10bit[] = {
>   DRM_FORMAT_BGR888,
>   DRM_FORMAT_RGB565,
>   DRM_FORMAT_BGR565,
> - DRM_FORMAT_NV12,
> - DRM_FORMAT_NV16,
> - DRM_FORMAT_NV24,
> + DRM_FORMAT_YUV420_8BIT, /* yuv420_8bit non-Linear mode only */
> + DRM_FORMAT_YUV420_10BIT, /* yuv420_10bit non-Linear mode only */
> + DRM_FORMAT_YUYV, /* yuv422_8bit non-Linear mode only*/
> + DRM_FORMAT_Y210, /* yuv422_10bit non-Linear mode only */
>  };
>  
> -static const uint32_t formats_win_full_10bit_yuyv[] = {
> +/* RK356x can't support uv swap for YUYV and UYVY */
> +static const uint32_t formats_for_rk356x_esmart[] = {
>   DRM_FORMAT_XRGB,
>   DRM_FORMAT_ARGB,
>   DRM_FORMAT_XBGR,
> @@ -38,14 +44,15 @@ static const uint32_t formats_win_full_10bit_yuyv[] = {
>   DRM_FORMAT_BGR888,
>   DRM_FORMAT_RGB565,
>   DRM_FORMAT_BGR565,
> - DRM_FORMAT_NV12,
> - DRM_FORMAT_NV16,
> - DRM_FORMAT_NV24,
> - DRM_FORMAT_YVYU,
> - DRM_FORMAT_VYUY,
> + DRM_FORMAT_NV12, /* yuv420_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
> + DRM_FORMAT_YUYV, /* yuv422_8bit[YUYV] linear mode */
> + DRM_FORMAT_UYVY, /* yuv422_8bit[UYVY] linear mode */
>  };
>  
> -static const uint32_t formats_win_lite[] = {
> +static const uint32_t formats_for_smart[] = {
>   DRM_FORMAT_XRGB,
>   DRM_FORMAT_ARGB,
>   DRM_FORMAT_XBGR,
> @@ -144,8 +151,8 @@ static const struct vop2_win_data rk3568_vop_win_data[] = 
> {
>   .name = "Smart0-win0",
>   .phys_id = ROCKCHIP_VOP2_SMART0,
>   .base = 0x1c00,
> - .formats = formats_win_lite,
> - .nformats = ARRAY_SIZE(formats_win_lite),
> + .formats = formats_for_smart,
> + .nformats = ARRAY_SIZE(formats_for_smart),
>   .format_modifiers = format_modifiers,
>   .layer_sel_id = 3,
>   .supported_rotations = DRM_MODE_REFLECT_Y,
> @@ -156,8 +163,8 @@ static const struct vop2_win_data rk3568_vop_win_data[] = 
> {
>   }, {
>   .name = "Smart1-win0",
>   .phys_id = ROCKCHIP_VOP2_SMART1,
> - .formats = formats_win_lite,
> - .nformats = ARRAY_SIZE(formats_win_lite),
> + .formats = formats_for_smart,
> + .nformats = ARRAY_SIZE(formats_for_smart),
>   .format_modifiers = format_modifiers,
>   .base = 0x1e00,
>   .layer_sel_id = 7,
> @@ -169,8 +176,8 @@ static const struct vop2_win_data rk3568_vop_win_data[] = 
> {
>   }, {
>   .name = "Esmart1-win0",
>   .phys_id = ROCKCHIP_VOP2_ESMART1,
> - .formats = formats_win_full_10bit_yuyv,
> - .nformats = ARRAY_SIZE(formats_win_full_10bit_yuyv),
> + .formats = formats_for_rk356x_esmart,
> + .nformats = ARRAY_SIZE(formats_for_rk356x_esmart),
>   .format_modifiers = format_modifiers,
>   .base = 0x1a00,
>   .layer_sel_id = 6,
> @@ -182,8 +189,8 @@ static const struct vop2_win_data rk3568_vop_win_data[] = 
> {
>   }, {
>   .name = "Esmart0-win0",
>   .phys_id = ROCKCHIP_VOP2_ESMART0,

Re: [PATCH v7 16/16] dt-bindings: display: mediatek: padding: add compatible for MT8195

2023-10-12 Thread 何宗原

On Thu, 2023-10-12 at 14:35 +0200, AngeloGioacchino Del Regno wrote:
> Il 12/10/23 10:40, Moudy Ho ha scritto:
> > Add a compatible string for the PAD block in MediaTek MT8195 that
> > is controlled by MDP3.
> > 
> > Signed-off-by: Moudy Ho 
> > ---
> >   .../bindings/display/mediatek/mediatek,padding.yaml   | 4
> > +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,paddi
> > ng.yaml
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,paddi
> > ng.yaml
> > index db24801ebc48..636b69133acc 100644
> > ---
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,paddi
> > ng.yaml
> > +++
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,paddi
> > ng.yaml
> > @@ -20,7 +20,9 @@ description:
> >   
> >   properties:
> > compatible:
> > -const: mediatek,mt8188-padding
> > +enum:
> > +  - mediatek,mt8188-padding
> > +  - mediatek,mt8195-mdp3-pad
> 
> mediatek,mt8195-mdp3-padding please!
> 
> Thanks,
> Angelo
> 

Hi Angelo,

Thanks for the reminder. I'll correct it to have consistent naming and
make corresponding modifications in the DTSI.

Sincerely,
Moudy

> >   
> > reg:
> >   maxItems: 1
> 
>

Re: [PATCH v7 06/16] dt-bindings: media: mediatek: mdp3: add component FG for MT8195

2023-10-12 Thread 何宗原

On Thu, 2023-10-12 at 12:22 +0200, AngeloGioacchino Del Regno wrote:
> Il 12/10/23 10:40, Moudy Ho ha scritto:
> > Add the fundamental hardware configuration of component FG,
> > which is controlled by MDP3 on MT8195.
> > 
> > Signed-off-by: Moudy Ho 
> > ---
> >   .../bindings/media/mediatek,mdp3-fg.yaml  | 61
> > +++
> >   1 file changed, 61 insertions(+)
> >   create mode 100644
> > Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > fg.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > fg.yaml
> > new file mode 100644
> > index ..82f4c182c77a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
> > @@ -0,0 +1,61 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: 
> > https://urldefense.com/v3/__http://devicetree.org/schemas/media/mediatek,mdp3-fg.yaml*__;Iw!!CTRNKA9wMg0ARbw!kwDIagzwmR0EvQ8W2Tyd-ES-4zQonsiAVr5bSvTSYK4YTVb-9XiXu0DTwtTrNyfUXvuB-_oleuautf7Ueo1-HhC3otH67Qg$
> >  
> > +$schema: 
> > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!kwDIagzwmR0EvQ8W2Tyd-ES-4zQonsiAVr5bSvTSYK4YTVb-9XiXu0DTwtTrNyfUXvuB-_oleuautf7Ueo1-HhC33EK57yA$
> >  
> > +
> > +title: MediaTek Media Data Path 3 FG
> 
> MediaTek Media Data Path 3 Film Grain
> 
> > +
> > +maintainers:
> > +  - Matthias Brugger 
> > +  - Moudy Ho 
> > +
> > +description:
> 
> Film Grain (FG) is a Media Data Path 3 (MDP3) component used to add
> the film grain according to the AOMedia Video 1 (AV1) standard
> 
> after which
> 
> Reviewed-by: AngeloGioacchino Del Regno <
> zangelogioacchino.delre...@collabora.com>

Hi Angelo,

Thaks for your help in enahncing the descriptions of the components
about FG, HDR, TCC and TDSHP in patch 6, 7, 9 and 10. I'll carefully
review your suggestions and incorporate them into the next submission.

Sincerely,
Moudy

Re: [git pull] drm fixes for 6.6-rc6

2023-10-12 Thread pr-tracker-bot

The pull request you sent on Fri, 13 Oct 2023 14:24:48 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-10-13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/10a6e5feccb877c3c75ad11d27942ad52c24815f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

RE: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline

2023-10-12 Thread Shankar, Uma



> -Original Message-
> From: Christopher Braga 
> Sent: Friday, September 8, 2023 1:39 AM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org; 
> dri-
> de...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; wayland-
> de...@lists.freedesktop.org
> Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane
> Color Pipeline
> 
> 
> 
> On 8/29/2023 12:03 PM, Uma Shankar wrote:
> > Add the documentation for the new proposed Plane Color Pipeline.
> >
> > Co-developed-by: Chaitanya Kumar Borah
> > 
> > Signed-off-by: Chaitanya Kumar Borah 
> > Signed-off-by: Uma Shankar 
> > ---
> >   .../gpu/rfc/plane_color_pipeline.rst  | 394 ++
> >   1 file changed, 394 insertions(+)
> >   create mode 100644 Documentation/gpu/rfc/plane_color_pipeline.rst
> >
> > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst
> > b/Documentation/gpu/rfc/plane_color_pipeline.rst
> > new file mode 100644
> > index ..60ce515b6ea7
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst
> > @@ -0,0 +1,394 @@
> > +===
> > + Plane Color Pipeline: A UAPI proposal
> > +===
> > +
> > +To build the proposal on, lets take the premise of a color pipeline
> > +as shown below.
> > +
> Hi Uma,
> Thanks for posting this. A few comments, with some echoing the sentiments of
> other commenters on the patch set.

Hi Christopher,
Thanks for your inputs on the series and my apologies for a late reply.

> > + +---+
> > + |RAM|
> > + |  +--++-++-+   |
> > + |  | FB 1 ||  FB 2   || FB N|   |
> > + |  +--++-++-+   |
> > + +---+
> > +   |  Plane Color Hardware Block |
> > + ++
> > + | +---v-+   +---v---+   +---v--+ |
> > + | | Plane A |   | Plane B   |   | Plane N  | |
> > + | | Pre-CSC |   | Pre-CSC   |   | Pre-CSC  | |
> > + | +---+-+   +---+---+   +---+--+ |
> > + | | |   ||
> > + | +---v-+   +---v---+   +---v--+ |
> > + | |Plane A  |   | Plane B   |   | Plane N  | |
> > + | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
> > + | +---+-+   ++--+   ++-+ |
> > + | |  |   |   |
> > + | +---v-+   +v--+   +v-+ |
> > + | | Plane A |   | Plane B   |   | Plane N  | |
> > + | |Post-CSC |   | Post-CSC  |   | Post-CSC | |
> > + | +---+-+   ++--+   ++-+ |
> > + | |  |   |   |
> > + ++
> > ++--v--v---v---|
> > +||   ||
> > +||   Pipe Blender||
> > ++++
> > +|||
> > +|+---v--+ |
> > +||  Pipe Pre-CSC| |
> > +||  | |
> > +|+---+--+ |
> > +||Pipe Color  |
> > +|+---v--+ Hardware|
> > +||  Pipe CSC/CTM| |
> > +||  | |
> > +|+---+--+ |
> > +|||
> > +|+---v--+ |
> > +||  Pipe Post-CSC   | |
> > +||  | |
> > +|+---+--+ |
> > +|||
> > ++-+
> > + |
> > + v
> > +Pipe Output
> > +
> > +Each plane consists of the following color blocks
> > + * Pre-CSC : This block can used to linearize the input frame buffer data.
> > + The linear data then can be further acted on by the following
> > + color hardware blocks in the display hardware pipeline
> > +
> > + * CSC/CTM: Used to program color transformation matrix, this block is used
> > +to perform color space conversions like BT2020 to BT709 or 
> > BT601
> > +etc. This block acts on the linearized data coming from the
> > +Pre-CSC HW block.
> > +
> > + * Post-CSC: This HW block can be used to non-linearize frame buffer data 
> > to
> > + match the sink. Another use case of it could be to perform 
> > Tone
> > + mapping for HDR use-cases.
> > +
> > +Data from multiple planes will then be fed to pipe/crtc where it will get
> blended.
> > +There is a similar set of HW blocks available at pipe/crtc level
> > +which acts on this blended d

[git pull] drm fixes for 6.6-rc6

2023-10-12 Thread Dave Airlie

Hi Linus,

Weekly fixes, the core is msm and amdgpu with some scattered fixes
across vmwgfx, panel and the core stuff.

Regards,
Dave.

drm-fixes-2023-10-13:
drm fixes for 6.6-rc6

atomic-helper:
- Relax checks for unregistered connectors

dma-buf:
- Work around race condition when retrieving fence timestamp

gem:
- Avoid OOB access in BO memory range

panel:
- boe-tv101wun-ml6: Fix flickering

simpledrm:
- Fix error output

vwmgfx:
- Fix size calculation in texture-state code
- Ref GEM BOs in surfaces

msm:
- PHY/link training reset fix
- msm8998 - correct highest bank bit
- skip video mode if timing engine disabled
- check irq_of_parse_and_map return code
- add new lines to some prints
- fail atomic check for max mdp clk test

amdgpu:
- Seemless boot fix
- Fix TTM BO resource check
- SI fix for doorbell handling
The following changes since commit 94f6f0550c625fab1f373bb86a6669b45e9748b3:

  Linux 6.6-rc5 (2023-10-08 13:49:43 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-10-13

for you to fetch changes up to 30873697b83743eda54d66ea9a3ea83554f8a535:

  Merge tag 'amd-drm-fixes-6.6-2023-10-11' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-10-13
13:20:24 +1000)


drm fixes for 6.6-rc6

atomic-helper:
- Relax checks for unregistered connectors

dma-buf:
- Work around race condition when retrieving fence timestamp

gem:
- Avoid OOB access in BO memory range

panel:
- boe-tv101wun-ml6: Fix flickering

simpledrm:
- Fix error output

vwmgfx:
- Fix size calculation in texture-state code
- Ref GEM BOs in surfaces

msm:
- PHY/link training reset fix
- msm8998 - correct highest bank bit
- skip video mode if timing engine disabled
- check irq_of_parse_and_map return code
- add new lines to some prints
- fail atomic check for max mdp clk test

amdgpu:
- Seemless boot fix
- Fix TTM BO resource check
- SI fix for doorbell handling


Abhinav Kumar (3):
  drm/msm/dsi: skip the wait for video mode done if not applicable
  drm/msm/dpu: change _dpu_plane_calc_bw() to use u64 to avoid overflow
  drm/msm/dpu: fail dpu_plane_atomic_check() based on mdp clk limits

Christian König (2):
  dma-buf: add dma_fence_timestamp helper
  drm/amdgpu: add missing NULL check

Dan Carpenter (1):
  drm/msm/dsi: fix irq_of_parse_and_map() error checking

Daniel Miess (1):
  drm/amd/display: Don't set dpms_off for seamless boot

Dave Airlie (3):
  Merge tag 'drm-misc-fixes-2023-10-12' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-msm-fixes-2023-10-07' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes
  Merge tag 'amd-drm-fixes-6.6-2023-10-11' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes

Dmitry Baryshkov (1):
  drm/msm/mdss: fix highest-bank-bit for msm8998

Icenowy Zheng (1):
  drm/amdgpu: fix SI failure due to doorbells allocation

Joey Gouly (1):
  drm/tiny: correctly print `struct resource *` on error

Konstantin Meskhidze (1):
  drm/vmwgfx: fix typo of sizeof argument

Kuogee Hsieh (1):
  drm/msm/dp: do not reinitialize phy unless retry during link training

Matthew Wilcox (Oracle) (1):
  drm: Do not overrun array in drm_gem_get_pages()

Ruihai Zhou (1):
  drm/panel: boe-tv101wum-nl6: Completely pull GPW to VGL before TP term

Simon Ser (1):
  drm/atomic-helper: relax unregistered connector check

Stephen Boyd (1):
  drm/msm/dp: Add newlines to debug printks

Zack Rusin (1):
  drm/vmwgfx: Keep a gem reference to user bos in surfaces

 drivers/dma-buf/dma-fence-unwrap.c   | 13 +++---
 drivers/dma-buf/sync_file.c  |  9 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c |  4 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h   |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c |  3 +++
 drivers/gpu/drm/drm_atomic_helper.c  | 17 ++---
 drivers/gpu/drm/drm_gem.c|  6 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 27 ++---
 drivers/gpu/drm/msm/dp/dp_ctrl.c | 13 +-
 drivers/gpu/drm/msm/dp/dp_link.c |  4 +--
 drivers/gpu/drm/msm/dsi/dsi_host.c   | 19 ---
 drivers/gpu/drm/msm/msm_mdss.c   |  2 +-
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c   |  4 +--
 drivers/gpu/drm/scheduler/sched_main.c   |  2 +-
 drivers/gpu/drm/tiny/simpledrm.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c   |  7 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h   | 17 +
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c  |  6 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  4 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  | 12 +
 drivers/gpu/drm/vmwgfx/vmwgfx_ge

Re: [PATCH v11 11/16] drm/mediatek: gamma: Add support for MT8195

Re: [PATCH v11 10/16] drm/mediatek: gamma: Add support for 12-bit LUT

Re: [PATCH v11 08/16] drm/mediatek: De-commonize disp_aal/disp_gamma gamma_set functions

Re: [PATCH v11 06/16] drm/mediatek: gamma: Use bitfield macros

Re: [v3 2/3] drm/panel: ili9882t: Avoid blurred screen from fast sleep

2023-10-12 Thread cong yang

Hi,

On Fri, Oct 13, 2023 at 10:28 AM Doug Anderson  wrote:
>
> Hi,
>
> On Thu, Oct 12, 2023 at 6:12 PM cong yang
>  wrote:
> >
> > Hi,
> >
> > On Thu, Oct 12, 2023 at 11:15 PM Doug Anderson  wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Oct 12, 2023 at 5:10 AM Cong Yang
> > >  wrote:
> > > >
> > > > At present, we have found that there may be a problem of blurred
> > > > screen during fast sleep/resume. The direct cause of the blurred
> > > > screen is that the IC does not receive 0x28/0x10. Because of the
> > > > particularity of the IC, before the panel enters sleep hid must
> > > > stop scanning, as i2c_hid_core_suspend before ili9882t_disable.
> > > > If move the ili9882t_enter_sleep_mode function to ili9882t_unprepare,
> > > > touch reset will pull low before panel entersleep, which does not meet
> > > > the timing requirements..
> > >
> > > The above makes me believe that the reset GPIO should be moved out of
> > > the input driver and into the panel driver. I could just imagine that
> > > the kernel might have some reason it wants to suspend the i2c hid
> > > device. If that causes the panel to suddenly start failing then that
> > > would be bad... I think we should fix this.
> >
> > Thanks, I will confirm with ilitek in further analysis and use "move
> > the ili9882t_enter_sleep_mode
> > function to ili9882t_unprepare".  Is the test failure really because
> > the touch reset timing
> > does not match? There is also a separate reset GPIO on the panel.
> > Shouldn't touch reset not
> > affect the panel?
> >
> > If we find a better solution I will continue upstream,。 So is it
> > possible to apply this plan now?
>
> I wouldn't be too upset at applying the current code as long as you're
> going to continue to investigate. We can always continue to iterate on
> it and having something working reasonably well is better than nothing
> at all. However, I probably would wait at least 1 week before applying
> any patch from you just simply out of courtesy to give others on the
> mailing list time to express their comments. ...presumably we could
> get to the bottom of the problem in that 1 week time anyway...
>
> I'm not trying to be an obstinate pain here--I'm merely trying to make
> sure that whatever we land will continue to work across kernel uprevs,
> even if driver probe order / timing changes in the kernel. If the
> panel is really so tied to the touchscreen device's reset GPIO timing
> then it worries me. What happens, for instance, if you disable the
> touchscreen CONFIG in the kernel? Does the panel still work, or is
> that extra reset GPIO totally critical to the functioning of the
> panel. If it's totally critical then it probably makes sense to move
> to the panel driver given that the touchscreen is a panel follower
> anyway...

Thanks. It looks like the panel works fine after I disable the touch screen
device. So the panel may not depend on touch screen reset.
Need to continue investigating the root cause for current status.

>
>
> > > > So in order to solve this problem, the IC
> > > > can handle it through the exception mechanism when it cannot receive
> > > > 0x28/0x10 command. Handling exceptions requires a reset 50ms delay.
> > > > Refer to vendor detailed analysis [1].
> > > >
> > > > Ilitek vendor also suggested switching the page before entering sleep to
> > > > avoid panel IC not receiving 0x28/0x10 command.
> > > >
> > > > Note: 0x28 is display off, 0x10 is sleep in.
> > > >
> > > > [1]: 
> > > > https://github.com/ILITEK-LoganLin/Document/tree/main/ILITEK_Power_Sequence
> > > >
> > > > Signed-off-by: Cong Yang 
> > > > ---
> > > >  drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 22 ++-
> > > >  1 file changed, 21 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c 
> > > > b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > > > index 93a40c2f1483..54ff1efb94aa 100644
> > > > --- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > > > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > > > @@ -463,6 +463,24 @@ static int ili9882t_init_dcs_cmd(struct ili9882t 
> > > > *ili)
> > > > return 0;
> > > >  }
> > > >
> > > > +static int ili9882t_switch_page(struct mipi_dsi_device *dsi, u8 page)
> > > > +{
> > > > +   int ret;
> > > > +   const struct panel_init_cmd cmd = _INIT_SWITCH_PAGE_CMD(page);
> > > > +
> > > > +   ret = mipi_dsi_dcs_write(dsi, cmd.data[0],
> > > > +cmd.len <= 1 ? NULL :
> > > > +&cmd.data[1],
> > > > +cmd.len - 1);
> > > > +   if (ret) {
> > > > +   dev_err(&dsi->dev,
> > > > +   "error switching panel controller page (%d)\n", 
> > > > ret);
> > > > +   return ret;
> > > > +   }
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > >  static int ili9882t_enter_sleep_mode(struct ili9882t *ili)
> > > >  {
> > > > struct

[PATCH v10 7/7] phy: freescale: Add HDMI PHY driver for i.MX8MQ

Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ.

Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
HDMI PHY mode is configurated in the driver.

Signed-off-by: Sandor Yu 
Tested-by: Alexander Stein 
---
v9->v10:
 - update for mhdp helper driver is introduced.
Remove head file cdns-mhdp-mailbox.h and add cdns-mhdp-helper.h
Add struct cdns_mhdp_base base to struct cdns_hdptx_hdmi_phy.
Init struct cdns_mhdp_base base when driver probe.

 drivers/phy/freescale/Kconfig   |  10 +
 drivers/phy/freescale/Makefile  |   1 +
 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 961 
 3 files changed, 972 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index c39709fd700ac..14f47b7cc77ab 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -45,6 +45,16 @@ config PHY_FSL_IMX8MQ_DP
  Enable this to support the Cadence HDPTX DP PHY driver
  on i.MX8MQ SOC.
 
+config PHY_FSL_IMX8MQ_HDMI
+   tristate "Freescale i.MX8MQ HDMI PHY support"
+   depends on OF && HAS_IOMEM
+   depends on COMMON_CLK
+   select GENERIC_PHY
+   select CDNS_MHDP_HELPER
+   help
+ Enable this to support the Cadence HDPTX HDMI PHY driver
+ on i.MX8MQ SOC.
+
 endif
 
 config PHY_FSL_LYNX_28G
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index 47e5285209fa8..1380ac31c2ead 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o
+obj-$(CONFIG_PHY_FSL_IMX8MQ_HDMI)  += phy-fsl-imx8mq-hdmi.o
 obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)   += phy-fsl-imx8mq-usb.o
 obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)   += phy-fsl-imx8qm-lvds-phy.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)  += phy-fsl-imx8-mipi-dphy.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c 
b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c
new file mode 100644
index 0..9722b5e1803c7
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c
@@ -0,0 +1,961 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence High-Definition Multimedia Interface (HDMI) PHY driver
+ *
+ * Copyright (C) 2022,2023 NXP Semiconductor, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADDR_PHY_AFE   0x8
+
+/* PHY registers */
+#define CMN_SSM_BIAS_TMR   0x0022
+#define CMN_PLLSM0_USER_DEF_CTRL   0x002f
+#define CMN_PSM_CLK_CTRL   0x0061
+#define CMN_CDIAG_REFCLK_CTRL  0x0062
+#define CMN_PLL0_VCOCAL_START  0x0081
+#define CMN_PLL0_VCOCAL_INIT_TMR   0x0084
+#define CMN_PLL0_VCOCAL_ITER_TMR   0x0085
+#define CMN_TXPUCAL_CTRL   0x00e0
+#define CMN_TXPDCAL_CTRL   0x00f0
+#define CMN_TXPU_ADJ_CTRL  0x0108
+#define CMN_TXPD_ADJ_CTRL  0x010c
+#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0
+#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1
+#define CMN_DIAG_PLL0_OVRD 0x01c2
+#define CMN_DIAG_PLL0_TEST_MODE0x01c4
+#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5
+#define CMN_DIAG_PLL0_CP_TUNE  0x01c6
+#define CMN_DIAG_PLL0_LF_PROG  0x01c7
+#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8
+#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9
+#define CMN_DIAG_PLL0_INCLK_CTRL   0x01ca
+#define CMN_DIAG_PLL0_PXL_DIVH 0x01cb
+#define CMN_DIAG_PLL0_PXL_DIVL 0x01cc
+#define CMN_DIAG_HSCLK_SEL 0x01e0
+#define XCVR_PSM_RCTRL 0x4001
+#define TX_TXCC_CAL_SCLR_MULT_00x4047
+#define TX_TXCC_CPOST_MULT_00_00x404c
+#define XCVR_DIAG_PLLDRC_CTRL  0x40e0
+#define XCVR_DIAG_PLLDRC_CTRL  0x40e0
+#define XCVR_DIAG_HSCLK_SEL0x40e1
+#define XCVR_DIAG_BIDI_CTRL0x40e8
+#define TX_PSC_A0  0x4100
+#define TX_PSC_A1  0x4101
+#define TX_PSC_A2  0x4102
+#define TX_PSC_A3  0x4103
+#define TX_DIAG_TX_CTRL0x41e0
+#define TX_DIAG_TX_DRV 0x41e1
+#define TX_DIAG_BGREF_PREDRV_DELAY 0x41e7
+#define TX_DIAG_ACYA_0 0x41ff
+#define TX_DIAG_ACYA_1 0x43ff
+#define TX_DIAG_ACYA_2 0x45ff
+#define TX_DIAG_ACYA_3 0x47ff
+#define TX_ANA_CTRL_REG_1  0x5020
+#define TX_ANA_CTRL_REG_2

[PATCH v10 6/7] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ

Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ

Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
DisplayPort PHY mode is configurated in the driver.

Signed-off-by: Sandor Yu 
---
v9->v10:
 - update for mhdp helper driver is introduced.
Remove head file cdns-mhdp-mailbox.h and add cdns-mhdp-helper.h
Add struct cdns_mhdp_base base to struct cdns_hdptx_dp_phy.
Init struct cdns_mhdp_base base when driver probe.

 drivers/phy/freescale/Kconfig |  10 +
 drivers/phy/freescale/Makefile|   1 +
 drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 720 ++
 3 files changed, 731 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 853958fb2c063..c39709fd700ac 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -35,6 +35,16 @@ config PHY_FSL_IMX8M_PCIE
  Enable this to add support for the PCIE PHY as found on
  i.MX8M family of SOCs.
 
+config PHY_FSL_IMX8MQ_DP
+   tristate "Freescale i.MX8MQ DP PHY support"
+   depends on OF && HAS_IOMEM
+   depends on COMMON_CLK
+   select GENERIC_PHY
+   select CDNS_MHDP_HELPER
+   help
+ Enable this to support the Cadence HDPTX DP PHY driver
+ on i.MX8MQ SOC.
+
 endif
 
 config PHY_FSL_LYNX_28G
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index cedb328bc4d28..47e5285209fa8 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o
 obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)   += phy-fsl-imx8mq-usb.o
 obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)   += phy-fsl-imx8qm-lvds-phy.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)  += phy-fsl-imx8-mipi-dphy.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c 
b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c
new file mode 100644
index 0..5f0d7da16b422
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c
@@ -0,0 +1,720 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence HDP-TX Display Port Interface (DP) PHY driver
+ *
+ * Copyright (C) 2022, 2023 NXP Semiconductor, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADDR_PHY_AFE   0x8
+
+/* PHY registers */
+#define CMN_SSM_BIAS_TMR   0x0022
+#define CMN_PLLSM0_PLLEN_TMR   0x0029
+#define CMN_PLLSM0_PLLPRE_TMR  0x002a
+#define CMN_PLLSM0_PLLVREF_TMR 0x002b
+#define CMN_PLLSM0_PLLLOCK_TMR 0x002c
+#define CMN_PLLSM0_USER_DEF_CTRL   0x002f
+#define CMN_PSM_CLK_CTRL   0x0061
+#define CMN_PLL0_VCOCAL_START  0x0081
+#define CMN_PLL0_VCOCAL_INIT_TMR   0x0084
+#define CMN_PLL0_VCOCAL_ITER_TMR   0x0085
+#define CMN_PLL0_INTDIV0x0094
+#define CMN_PLL0_FRACDIV   0x0095
+#define CMN_PLL0_HIGH_THR  0x0096
+#define CMN_PLL0_DSM_DIAG  0x0097
+#define CMN_PLL0_SS_CTRL2  0x0099
+#define CMN_ICAL_INIT_TMR  0x00c4
+#define CMN_ICAL_ITER_TMR  0x00c5
+#define CMN_RXCAL_INIT_TMR 0x00d4
+#define CMN_RXCAL_ITER_TMR 0x00d5
+#define CMN_TXPUCAL_INIT_TMR   0x00e4
+#define CMN_TXPUCAL_ITER_TMR   0x00e5
+#define CMN_TXPDCAL_INIT_TMR   0x00f4
+#define CMN_TXPDCAL_ITER_TMR   0x00f5
+#define CMN_ICAL_ADJ_INIT_TMR  0x0102
+#define CMN_ICAL_ADJ_ITER_TMR  0x0103
+#define CMN_RX_ADJ_INIT_TMR0x0106
+#define CMN_RX_ADJ_ITER_TMR0x0107
+#define CMN_TXPU_ADJ_INIT_TMR  0x010a
+#define CMN_TXPU_ADJ_ITER_TMR  0x010b
+#define CMN_TXPD_ADJ_INIT_TMR  0x010e
+#define CMN_TXPD_ADJ_ITER_TMR  0x010f
+#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0
+#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1
+#define CMN_DIAG_PLL0_OVRD 0x01c2
+#define CMN_DIAG_PLL0_TEST_MODE0x01c4
+#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5
+#define CMN_DIAG_PLL0_CP_TUNE  0x01c6
+#define CMN_DIAG_PLL0_LF_PROG  0x01c7
+#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8
+#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9
+#define CMN_DIAG_HSCLK_SEL 0x01e0
+#define CMN_DIAG_PER_CAL_ADJ   0x01ec
+#define CMN_DIAG_CAL_CTRL  0x01ed
+#define CMN_DIAG_ACYA  0x01ff
+#define XCVR_PSM_RCTRL 0x4001
+#define XCVR_PSM_CAL

[PATCH v10 5/7] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY

Add bindings for Freescale iMX8MQ DP and HDMI PHY.

Signed-off-by: Sandor Yu 
Reviewed-by: Rob Herring 
---
v9->v10:
 *No change.

 .../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml  | 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml 
b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
new file mode 100644
index 0..917f113503dca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mq-dp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence HDP-TX DP/HDMI PHY for Freescale i.MX8MQ SoC
+
+maintainers:
+  - Sandor Yu 
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8mq-dp-phy
+  - fsl,imx8mq-hdmi-phy
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: PHY reference clock.
+  - description: APB clock.
+
+  clock-names:
+items:
+  - const: ref
+  - const: apb
+
+  "#phy-cells":
+const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+dp_phy: phy@32c0 {
+compatible = "fsl,imx8mq-dp-phy";
+reg = <0x32c0 0x10>;
+#phy-cells = <0>;
+clocks = <&hdmi_phy_27m>, <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
+clock-names = "ref", "apb";
+};
-- 
2.34.1

[PATCH v10 4/7] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver

Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
standards according embedded Firmware running in the uCPU.

For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
SOC's ROM code. Bootload binary included respective specific firmware
is required.

Driver will check display connector type and
then load the corresponding driver.

Signed-off-by: Sandor Yu 
Tested-by: Alexander Stein 
---
v9->v10:
 - struct cdns_mhdp_device is renamed to cdns_mhdp8501_device.
 - update for mhdp helper driver is introduced.
Remove head file cdns-mhdp-mailbox.h and add cdns-mhdp-helper.h
Add struct cdns_mhdp_base base to struct cdns_mhdp8501_device.
Init struct cdns_mhdp_base base when driver probe.

 drivers/gpu/drm/bridge/cadence/Kconfig|  16 +
 drivers/gpu/drm/bridge/cadence/Makefile   |   2 +
 .../drm/bridge/cadence/cdns-mhdp8501-core.c   | 316 
 .../drm/bridge/cadence/cdns-mhdp8501-core.h   | 365 +
 .../gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c | 708 ++
 .../drm/bridge/cadence/cdns-mhdp8501-hdmi.c   | 673 +
 6 files changed, 2080 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.h
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c

diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
b/drivers/gpu/drm/bridge/cadence/Kconfig
index 0b7b4626a7af0..81685ab4e874a 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -50,3 +50,19 @@ config DRM_CDNS_MHDP8546_J721E
  initializes the J721E Display Port and sets up the
  clock and data muxes.
 endif
+
+config DRM_CDNS_MHDP8501
+   tristate "Cadence MHDP8501 DP/HDMI bridge"
+   select DRM_KMS_HELPER
+   select DRM_PANEL_BRIDGE
+   select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HELPER
+   select CDNS_MHDP_HELPER
+   select DRM_CDNS_AUDIO
+   depends on OF
+   help
+ Support Cadence MHDP8501 DisplayPort/HDMI bridge.
+ Cadence MHDP8501 support one or more protocols,
+ including DisplayPort and HDMI.
+ To use the DP and HDMI drivers, their respective
+ specific firmware is required.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile 
b/drivers/gpu/drm/bridge/cadence/Makefile
index 087dc074820d7..02c1a9f3cf6fc 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
 obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
 cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
 cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
+obj-$(CONFIG_DRM_CDNS_MHDP8501) += cdns-mhdp8501.o
+cdns-mhdp8501-y := cdns-mhdp8501-core.o cdns-mhdp8501-dp.o cdns-mhdp8501-hdmi.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
new file mode 100644
index 0..fcb0ea5b358b7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence Display Port Interface (DP) driver
+ *
+ * Copyright (C) 2023 NXP Semiconductor, Inc.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cdns-mhdp8501-core.h"
+
+static int cdns_mhdp8501_read_hpd(struct cdns_mhdp8501_device *mhdp)
+{
+   u8 status;
+   int ret;
+
+   mutex_lock(&mhdp->mbox_mutex);
+
+   ret = cdns_mhdp_mailbox_send(&mhdp->base, MB_MODULE_ID_GENERAL,
+GENERAL_GET_HPD_STATE, 0, NULL);
+   if (ret)
+   goto err_get_hpd;
+
+   ret = cdns_mhdp_mailbox_recv_header(&mhdp->base, MB_MODULE_ID_GENERAL,
+   GENERAL_GET_HPD_STATE,
+   sizeof(status));
+   if (ret)
+   goto err_get_hpd;
+
+   ret = cdns_mhdp_mailbox_recv_data(&mhdp->base, &status, sizeof(status));
+   if (ret)
+   goto err_get_hpd;
+
+   mutex_unlock(&mhdp->mbox_mutex);
+
+   return status;
+
+err_get_hpd:
+   DRM_ERROR("read hpd  failed: %d\n", ret);
+   mutex_unlock(&mhdp->mbox_mutex);
+
+   return ret;
+}
+
+enum drm_connector_status cdns_mhdp8501_detect(struct cdns_mhdp8501_device 
*mhdp)
+{
+   u8 hpd = 0xf;
+
+   hpd = cdns_mhdp8501_read_hpd(mhdp);
+   if (hpd == 1)
+   return connector_status_connected;
+   else if (hpd == 0)
+   return connector_status_disconnected;
+
+   DRM_INFO("Unknown cable status, hdp=%u\n", hpd);
+   return connector_status_unknown;
+}
+
+static void hotplug_work_func(struct work_struct *work)
+

[PATCH v10 3/7] dt-bindings: display: bridge: Add Cadence MHDP8501

Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.

Signed-off-by: Sandor Yu 
Reviewed-by: Krzysztof Kozlowski 
---
v9->v10:
 *No change.

 .../display/bridge/cdns,mhdp8501.yaml | 104 ++
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml 
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
new file mode 100644
index 0..3ae643845cfee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MHDP8501 DP/HDMI bridge
+
+maintainers:
+  - Sandor Yu 
+
+description:
+  Cadence MHDP8501 DisplayPort/HDMI interface.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8mq-mhdp8501
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+description: MHDP8501 DP/HDMI APB clock.
+
+  phys:
+maxItems: 1
+description:
+  phandle to the DisplayPort or HDMI PHY
+
+  interrupts:
+items:
+  - description: Hotplug cable plugin.
+  - description: Hotplug cable plugout.
+
+  interrupt-names:
+items:
+  - const: plug_in
+  - const: plug_out
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Input port from display controller output.
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output port to DisplayPort or HDMI connector.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - interrupts
+  - interrupt-names
+  - phys
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+mhdp: display-bridge@32c0 {
+compatible = "fsl,imx8mq-mhdp8501";
+reg = <0x32c0 0x10>;
+interrupts = ,
+ ;
+interrupt-names = "plug_in", "plug_out";
+clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
+phys = <&dp_phy>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+
+mhdp_in: endpoint {
+remote-endpoint = <&dcss_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+mhdp_out: endpoint {
+remote-endpoint = <&dp_connector>;
+};
+};
+};
+};
-- 
2.34.1

[PATCH v10 2/7] phy: Add HDMI configuration options

Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.

The parameters added here are based on HDMI PHY
implementation practices.  The current set of parameters
should cover the potential users.

Signed-off-by: Sandor Yu 
Reviewed-by: Dmitry Baryshkov 
Acked-by: Vinod Koul 
---
v9->v10:
 *No change.

 include/linux/phy/phy-hdmi.h | 24 
 include/linux/phy/phy.h  |  7 ++-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/phy/phy-hdmi.h

diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
new file mode 100644
index 0..b7de88e9090f0
--- /dev/null
+++ b/include/linux/phy/phy-hdmi.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2022 NXP
+ */
+
+#ifndef __PHY_HDMI_H_
+#define __PHY_HDMI_H_
+
+#include 
+/**
+ * struct phy_configure_opts_hdmi - HDMI configuration set
+ * @pixel_clk_rate: Pixel clock of video modes in KHz.
+ * @bpc: Maximum bits per color channel.
+ * @color_space: Colorspace in enum hdmi_colorspace.
+ *
+ * This structure is used to represent the configuration state of a HDMI phy.
+ */
+struct phy_configure_opts_hdmi {
+   unsigned int pixel_clk_rate;
+   unsigned int bpc;
+   enum hdmi_colorspace color_space;
+};
+
+#endif /* __PHY_HDMI_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f6d607ef0e801..94d489a8a163c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -42,7 +43,8 @@ enum phy_mode {
PHY_MODE_MIPI_DPHY,
PHY_MODE_SATA,
PHY_MODE_LVDS,
-   PHY_MODE_DP
+   PHY_MODE_DP,
+   PHY_MODE_HDMI,
 };
 
 enum phy_media {
@@ -60,11 +62,14 @@ enum phy_media {
  * the DisplayPort protocol.
  * @lvds:  Configuration set applicable for phys supporting
  * the LVDS phy mode.
+ * @hdmi:  Configuration set applicable for phys supporting
+ * the HDMI phy mode.
  */
 union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
struct phy_configure_opts_lvds  lvds;
+   struct phy_configure_opts_hdmi  hdmi;
 };
 
 /**
-- 
2.34.1

[PATCH v10 1/7] drm: bridge: Cadence: Creat mhdp helper driver

MHDP8546 mailbox access functions will be share to other mhdp driver
and Cadence HDP-TX HDMI/DP PHY drivers.
Create a new mhdp helper driver and move all those functions into.

cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(),
because it use the DPTX command ID DPTX_WRITE_REGISTER.

New cdns_mhdp_reg_write() is created with the general command ID
GENERAL_REGISTER_WRITE.

Signed-off-by: Sandor Yu 
---
v9->v10:
 *use mhdp helper driver to replace macro functions,
 move maibox access function and mhdp hdmi/dp common API
 functions into the driver.

 drivers/gpu/drm/bridge/cadence/Kconfig|   4 
 drivers/gpu/drm/bridge/cadence/Makefile   |   1 +
 .../gpu/drm/bridge/cadence/cdns-mhdp-helper.c | 306 ++
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 383 +++---
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  44 +-
 include/drm/bridge/cdns-mhdp-helper.h |  96 +
 6 files changed, 473 insertions(+), 361 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
 create mode 100644 include/drm/bridge/cdns-mhdp-helper.h

diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
b/drivers/gpu/drm/bridge/cadence/Kconfig
index ec35215a20034..0b7b4626a7af0 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -20,6 +20,9 @@ config DRM_CDNS_DSI_J721E
  the routing of the DSS DPI signal to the Cadence DSI.
 endif
 
+config CDNS_MHDP_HELPER
+   tristate
+
 config DRM_CDNS_MHDP8546
tristate "Cadence DPI/DP bridge"
select DRM_DISPLAY_DP_HELPER
@@ -27,6 +30,7 @@ config DRM_CDNS_MHDP8546
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
+   select CDNS_MHDP_HELPER
depends on OF
help
  Support Cadence DPI to DP bridge. This is an internal
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile 
b/drivers/gpu/drm/bridge/cadence/Makefile
index c95fd5b81d137..087dc074820d7 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 cdns-dsi-y := cdns-dsi-core.o
 cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
+obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
 obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
 cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
 cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
new file mode 100644
index 0..2e3eee40494f0
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 NXP Semiconductor, Inc.
+ *
+ */
+#include 
+#include 
+#include 
+
+/* Mailbox helper functions */
+int cdns_mhdp_mailbox_read(struct cdns_mhdp_base *base)
+{
+   int ret, empty;
+
+   WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+   ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_EMPTY,
+empty, !empty, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+   if (ret < 0)
+   return ret;
+
+   return readl(base->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+EXPORT_SYMBOL_GPL(cdns_mhdp_mailbox_read);
+
+int cdns_mhdp_mailbox_write(struct cdns_mhdp_base *base, u8 val)
+{
+   int ret, full;
+
+   WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+   ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_FULL,
+full, !full, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+   if (ret < 0)
+   return ret;
+
+   writel(val, base->regs + CDNS_MAILBOX_TX_DATA);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(cdns_mhdp_mailbox_write);
+
+int cdns_mhdp_mailbox_recv_header(struct cdns_mhdp_base *base,
+ u8 module_id, u8 opcode,
+ u16 req_size)
+{
+   u32 mbox_size, i;
+   u8 header[4];
+   int ret;
+
+   /* read the header of the message */
+   for (i = 0; i < sizeof(header); i++) {
+   ret = cdns_mhdp_mailbox_read(base);
+   if (ret < 0)
+   return ret;
+
+   header[i] = ret;
+   }
+
+   mbox_size = get_unaligned_be16(header + 2);
+
+   if (opcode != header[0] || module_id != header[1] ||
+   req_size != mbox_size) {
+   /*
+* If the message in mailbox is not what we want, we need to
+* clear the mailbox by reading its contents.
+*/
+   for (i = 0; i < mbox_size; i++)
+   if (cdns_mhdp_mailbox_read(base) < 0)
+   break;
+
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(cd

[PATCH v10 0/7] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ

The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge
drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ.

The patch set compose of DRM bridge drivers and PHY drivers.

Both of them need patche #1 and #2 to pass build.

DRM bridges driver patches:
#1: drm: bridge: Cadence: Creat mhdp helper driver
#2: phy: Add HDMI configuration options
#3: dt-bindings: display: bridge: Add Cadence MHDP8501
#4: drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver

PHY driver patches:
#1: drm: bridge: Cadence: Creat mhdp helper driver
#2: phy: Add HDMI configuration options
#5: dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
#6: phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
#7: phy: freescale: Add HDMI PHY driver for i.MX8MQ

v9->v10:
- Create mhdp helper driver to replace macro functions,
move all mhdp mailbox access functions and common functions
into the helper driver.
Patch #1:drm: bridge: Cadence: Creat mhdp helper driver
it is totaly different with v9.

v8->v9:
- Remove compatible string "cdns,mhdp8501" that had removed
from dt-bindings file in v8.
- Add Dmitry's R-b tag to patch #2
- Add Krzysztof's R-b tag to patch #3

v7->v8:
MHDP8501 HDMI/DP:
- Correct DT node name to "display-bridge".
- Remove "cdns,mhdp8501" from mhdp8501 dt-binding doc.

HDMI/DP PHY:
- Introduced functions `wait_for_ack` and `wait_for_ack_clear` to handle
waiting with acknowledgment bits set and cleared respectively.
- Use FIELD_PRE() to set bitfields for both HDMI and DP PHY.

v6->v7:
MHDP8501 HDMI/DP:
- Combine HDMI and DP driver into one mhdp8501 driver.
Use the connector type to load the corresponding functions.
- Remove connector init functions.
- Add in phy_hdmi.h to reuse ‘enum hdmi_colorspace’.

HDMI/DP PHY:
- Lowercase hex values
- Fix parameters indent issue on some functions
- Replace ‘udelay’ with ‘usleep_range’

v5->v6:
HDMI/DP bridge driver
- 8501 is the part number of Cadence MHDP on i.MX8MQ.
Use MHDP8501 to name hdmi/dp drivers and files.
- Add compatible "fsl,imx8mq-mhdp8501-dp" for i.MX8MQ DP driver
- Add compatible "fsl,imx8mq-mhdp8501-hdmi" for i.MX8MQ HDMI driver
- Combine HDMI and DP dt-bindings into one file cdns,mhdp8501.yaml
- Fix HDMI scrambling is not enable issue when driver working in 4Kp60
mode.
- Add HDMI/DP PHY API mailbox protect.

HDMI/DP PHY driver:
- Rename DP and HDMI PHY files and move to folder phy/freescale/
- Remove properties num_lanes and link_rate from DP PHY driver.
- Combine HDMI and DP dt-bindings into one file fsl,imx8mq-dp-hdmi-phy.yaml
- Update compatible string to "fsl,imx8mq-dp-phy".
- Update compatible string to "fsl,imx8mq-hdmi-phy".

v4->v5:
- Drop "clk" suffix in clock name.
- Add output port property in the example of hdmi/dp.

v3->v4:
dt-bindings:
- Correct dt-bindings coding style and address review comments.
- Add apb_clk description.
- Add output port for HDMI/DP connector
PHY:
- Alphabetically sorted in Kconfig and Makefile for DP and HDMI PHY
- Remove unused registers define from HDMI and DP PHY drivers.
- More description in phy_hdmi.h.
- Add apb_clk to HDMI and DP phy driver.
HDMI/DP:
- Use get_unaligned_le32() to replace hardcode type conversion
in HDMI AVI infoframe data fill function.
- Add mailbox mutex lock in HDMI/DP driver for phy functions
to reslove race conditions between HDMI/DP and PHY drivers.
- Add apb_clk to both HDMI and DP driver.
- Rename some function names and add prefix with "cdns_hdmi/cdns_dp".
- Remove bpc 12 and 16 optional that not supported.

v2->v3:
Address comments for dt-bindings files.
- Correct dts-bindings file names
Rename phy-cadence-hdptx-dp.yaml to cdns,mhdp-imx8mq-dp.yaml
Rename phy-cadence-hdptx-hdmi.yaml to cdns,mhdp-imx8mq-hdmi.yaml
- Drop redundant words and descriptions.
- Correct hdmi/dp node name.

v2 is a completely different version compared to v1.
Previous v1 can be available here [1].

v1->v2:
- Reuse Cadence mailbox access functions from mhdp8546 instead of
rockchip DP.
- Mailbox access functions be convert to marco functions
that will be referenced by HDP-TX PHY(HDMI/DP) driver too.
- Plain bridge instead of component driver.
- Standalone Cadence HDP-TX PHY(HDMI/DP) driver.
- Audio driver are removed from the patch set, it will be add in another
patch set later.

[1]
https://patchwork.kernel.org/project/linux-rockchip/cover/cover.1590982881.git.sandor...@nxp.com/

Sandor Yu (7):
drm: bridge: Cadence: Creat mhdp helper driver
phy: Add HDMI configuration options
dt-bindings: display: bridge: Add Cadence MHDP8501
drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
phy: freescale: Add HDMI PHY driver for i.MX8MQ

.../display/bridge/cdns,mhdp8501.yaml | 104 ++
.../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml | 53 +
drivers/gpu/drm/bridge/cadence/Kconfig| 20 +
drivers/gpu/drm/bridge/cadence/Makefile |

[PATCH] drm/amdkfd: clean up some inconsistent indenting

2023-10-12 Thread Jiapeng Chong

No functional modification involved.

drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:305 svm_range_free() warn: 
inconsistent indenting.

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6804
Signed-off-by: Jiapeng Chong 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index f4038b33c404..eef76190800c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -302,7 +302,7 @@ static void svm_range_free(struct svm_range *prange, bool 
do_unmap)
for (gpuidx = 0; gpuidx < MAX_GPU_INSTANCE; gpuidx++) {
if (prange->dma_addr[gpuidx]) {
kvfree(prange->dma_addr[gpuidx]);
-   prange->dma_addr[gpuidx] = NULL;
+   prange->dma_addr[gpuidx] = NULL;
}
}
 
-- 
2.20.1.7.g153144c

Re: [v3 2/3] drm/panel: ili9882t: Avoid blurred screen from fast sleep

Hi,

On Thu, Oct 12, 2023 at 6:12 PM cong yang
 wrote:
>
> Hi,
>
> On Thu, Oct 12, 2023 at 11:15 PM Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Thu, Oct 12, 2023 at 5:10 AM Cong Yang
> >  wrote:
> > >
> > > At present, we have found that there may be a problem of blurred
> > > screen during fast sleep/resume. The direct cause of the blurred
> > > screen is that the IC does not receive 0x28/0x10. Because of the
> > > particularity of the IC, before the panel enters sleep hid must
> > > stop scanning, as i2c_hid_core_suspend before ili9882t_disable.
> > > If move the ili9882t_enter_sleep_mode function to ili9882t_unprepare,
> > > touch reset will pull low before panel entersleep, which does not meet
> > > the timing requirements..
> >
> > The above makes me believe that the reset GPIO should be moved out of
> > the input driver and into the panel driver. I could just imagine that
> > the kernel might have some reason it wants to suspend the i2c hid
> > device. If that causes the panel to suddenly start failing then that
> > would be bad... I think we should fix this.
>
> Thanks, I will confirm with ilitek in further analysis and use "move
> the ili9882t_enter_sleep_mode
> function to ili9882t_unprepare".  Is the test failure really because
> the touch reset timing
> does not match? There is also a separate reset GPIO on the panel.
> Shouldn't touch reset not
> affect the panel?
>
> If we find a better solution I will continue upstream,。 So is it
> possible to apply this plan now?

I wouldn't be too upset at applying the current code as long as you're
going to continue to investigate. We can always continue to iterate on
it and having something working reasonably well is better than nothing
at all. However, I probably would wait at least 1 week before applying
any patch from you just simply out of courtesy to give others on the
mailing list time to express their comments. ...presumably we could
get to the bottom of the problem in that 1 week time anyway...

I'm not trying to be an obstinate pain here--I'm merely trying to make
sure that whatever we land will continue to work across kernel uprevs,
even if driver probe order / timing changes in the kernel. If the
panel is really so tied to the touchscreen device's reset GPIO timing
then it worries me. What happens, for instance, if you disable the
touchscreen CONFIG in the kernel? Does the panel still work, or is
that extra reset GPIO totally critical to the functioning of the
panel. If it's totally critical then it probably makes sense to move
to the panel driver given that the touchscreen is a panel follower
anyway...


> > > So in order to solve this problem, the IC
> > > can handle it through the exception mechanism when it cannot receive
> > > 0x28/0x10 command. Handling exceptions requires a reset 50ms delay.
> > > Refer to vendor detailed analysis [1].
> > >
> > > Ilitek vendor also suggested switching the page before entering sleep to
> > > avoid panel IC not receiving 0x28/0x10 command.
> > >
> > > Note: 0x28 is display off, 0x10 is sleep in.
> > >
> > > [1]: 
> > > https://github.com/ILITEK-LoganLin/Document/tree/main/ILITEK_Power_Sequence
> > >
> > > Signed-off-by: Cong Yang 
> > > ---
> > >  drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 22 ++-
> > >  1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c 
> > > b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > > index 93a40c2f1483..54ff1efb94aa 100644
> > > --- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > > @@ -463,6 +463,24 @@ static int ili9882t_init_dcs_cmd(struct ili9882t 
> > > *ili)
> > > return 0;
> > >  }
> > >
> > > +static int ili9882t_switch_page(struct mipi_dsi_device *dsi, u8 page)
> > > +{
> > > +   int ret;
> > > +   const struct panel_init_cmd cmd = _INIT_SWITCH_PAGE_CMD(page);
> > > +
> > > +   ret = mipi_dsi_dcs_write(dsi, cmd.data[0],
> > > +cmd.len <= 1 ? NULL :
> > > +&cmd.data[1],
> > > +cmd.len - 1);
> > > +   if (ret) {
> > > +   dev_err(&dsi->dev,
> > > +   "error switching panel controller page (%d)\n", 
> > > ret);
> > > +   return ret;
> > > +   }
> > > +
> > > +   return 0;
> > > +}
> > > +
> > >  static int ili9882t_enter_sleep_mode(struct ili9882t *ili)
> > >  {
> > > struct mipi_dsi_device *dsi = ili->dsi;
> > > @@ -484,8 +502,10 @@ static int ili9882t_enter_sleep_mode(struct ili9882t 
> > > *ili)
> > >  static int ili9882t_disable(struct drm_panel *panel)
> > >  {
> > > struct ili9882t *ili = to_ili9882t(panel);
> > > +   struct mipi_dsi_device *dsi = ili->dsi;
> > > int ret;
> > >
> > > +   ili9882t_switch_page(dsi, 0x00);
> > > ret = ili9882t_enter_sleep_mode(ili);
> > > if (ret < 0) {
> > >

[PATCH] drm/radeon: fix a possible null pointer dereference

In radeon_add_common_modes(), the return value of drm_cvt_mode()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_cvt_mode(). Add a check to avoid null pointer
dereference.

Signed-off-by: Ma Ke 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index d2f02c3dfce2..9f7d8ab980e6 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -520,6 +520,8 @@ static void radeon_add_common_modes(struct drm_encoder 
*encoder, struct drm_conn
continue;
 
mode = drm_cvt_mode(dev, common_modes[i].w, common_modes[i].h, 
60, false, false, false);
+   if (!mode)
+   continue;
drm_mode_probed_add(connector, mode);
}
 }
-- 
2.37.2

[PATCH] drm/qxl: fix a possible null pointer dereference

In qxl_add_mode(), the return value of drm_cvt_mode() is assigned
to mode, which will lead to a NULL pointer dereference on failure
of drm_cvt_mode(). Add a check to avoid null pointer dereference.

Signed-off-by: Ma Ke 
---
 drivers/gpu/drm/qxl/qxl_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 6492a70e3c39..8a14edaa4aa3 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -236,6 +236,8 @@ static int qxl_add_mode(struct drm_connector *connector,
return 0;
 
mode = drm_cvt_mode(dev, width, height, 60, false, false, false);
+   if (!mode)
+   return 0;
if (preferred)
mode->type |= DRM_MODE_TYPE_PREFERRED;
mode->hdisplay = width;
-- 
2.37.2

[PATCH] drm/amdgpu/vkms: fix a possible null pointer dereference

In amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_cvt_mode(). Add a check to avoid null pointer
dereference.

Signed-off-by: Ma Ke 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index 7148a216ae2f..db6fc0cb18eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -239,6 +239,8 @@ static int amdgpu_vkms_conn_get_modes(struct drm_connector 
*connector)
 
for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
mode = drm_cvt_mode(dev, common_modes[i].w, common_modes[i].h, 
60, false, false, false);
+   if (!mode)
+   continue;
drm_mode_probed_add(connector, mode);
}
 
-- 
2.37.2

[PATCH] drm/nouveau/dispnv04: fix a possible null pointer dereference

In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference.

Signed-off-by: Ma Ke 
---
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index 670c9739e5e1..9c3dc9a5bb46 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -258,6 +258,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder,
if (modes[i].hdisplay == output_mode->hdisplay &&
modes[i].vdisplay == output_mode->vdisplay) {
mode = drm_mode_duplicate(encoder->dev, output_mode);
+   if (!mode)
+   continue;
mode->type |= DRM_MODE_TYPE_PREFERRED;
 
} else {
@@ -265,6 +267,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder,
modes[i].vdisplay, 60, false,
(output_mode->flags &
 DRM_MODE_FLAG_INTERLACE), false);
+   if (!mode)
+   continue;
}
 
/* CVT modes are sometimes unsuitable... */
-- 
2.37.2

Re: [v3 2/3] drm/panel: ili9882t: Avoid blurred screen from fast sleep

2023-10-12 Thread cong yang

Hi,

On Thu, Oct 12, 2023 at 11:15 PM Doug Anderson  wrote:
>
> Hi,
>
> On Thu, Oct 12, 2023 at 5:10 AM Cong Yang
>  wrote:
> >
> > At present, we have found that there may be a problem of blurred
> > screen during fast sleep/resume. The direct cause of the blurred
> > screen is that the IC does not receive 0x28/0x10. Because of the
> > particularity of the IC, before the panel enters sleep hid must
> > stop scanning, as i2c_hid_core_suspend before ili9882t_disable.
> > If move the ili9882t_enter_sleep_mode function to ili9882t_unprepare,
> > touch reset will pull low before panel entersleep, which does not meet
> > the timing requirements..
>
> The above makes me believe that the reset GPIO should be moved out of
> the input driver and into the panel driver. I could just imagine that
> the kernel might have some reason it wants to suspend the i2c hid
> device. If that causes the panel to suddenly start failing then that
> would be bad... I think we should fix this.

Thanks, I will confirm with ilitek in further analysis and use "move
the ili9882t_enter_sleep_mode
function to ili9882t_unprepare".  Is the test failure really because
the touch reset timing
does not match? There is also a separate reset GPIO on the panel.
Shouldn't touch reset not
affect the panel?

If we find a better solution I will continue upstream,。 So is it
possible to apply this plan now?

>
>
> > So in order to solve this problem, the IC
> > can handle it through the exception mechanism when it cannot receive
> > 0x28/0x10 command. Handling exceptions requires a reset 50ms delay.
> > Refer to vendor detailed analysis [1].
> >
> > Ilitek vendor also suggested switching the page before entering sleep to
> > avoid panel IC not receiving 0x28/0x10 command.
> >
> > Note: 0x28 is display off, 0x10 is sleep in.
> >
> > [1]: 
> > https://github.com/ILITEK-LoganLin/Document/tree/main/ILITEK_Power_Sequence
> >
> > Signed-off-by: Cong Yang 
> > ---
> >  drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 22 ++-
> >  1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c 
> > b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > index 93a40c2f1483..54ff1efb94aa 100644
> > --- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> > @@ -463,6 +463,24 @@ static int ili9882t_init_dcs_cmd(struct ili9882t *ili)
> > return 0;
> >  }
> >
> > +static int ili9882t_switch_page(struct mipi_dsi_device *dsi, u8 page)
> > +{
> > +   int ret;
> > +   const struct panel_init_cmd cmd = _INIT_SWITCH_PAGE_CMD(page);
> > +
> > +   ret = mipi_dsi_dcs_write(dsi, cmd.data[0],
> > +cmd.len <= 1 ? NULL :
> > +&cmd.data[1],
> > +cmd.len - 1);
> > +   if (ret) {
> > +   dev_err(&dsi->dev,
> > +   "error switching panel controller page (%d)\n", 
> > ret);
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  static int ili9882t_enter_sleep_mode(struct ili9882t *ili)
> >  {
> > struct mipi_dsi_device *dsi = ili->dsi;
> > @@ -484,8 +502,10 @@ static int ili9882t_enter_sleep_mode(struct ili9882t 
> > *ili)
> >  static int ili9882t_disable(struct drm_panel *panel)
> >  {
> > struct ili9882t *ili = to_ili9882t(panel);
> > +   struct mipi_dsi_device *dsi = ili->dsi;
> > int ret;
> >
> > +   ili9882t_switch_page(dsi, 0x00);
> > ret = ili9882t_enter_sleep_mode(ili);
> > if (ret < 0) {
> > dev_err(panel->dev, "failed to set panel off: %d\n", ret);
> > @@ -546,7 +566,7 @@ static int ili9882t_prepare(struct drm_panel *panel)
> > gpiod_set_value(ili->enable_gpio, 1);
> > usleep_range(1000, 2000);
> > gpiod_set_value(ili->enable_gpio, 0);
> > -   usleep_range(1000, 2000);
> > +   usleep_range(5, 51000);
>
> From my previous response, I think the above is better as msleep(50).

Sorry. Will be corrected in V4.

linux-next: manual merge of the drm-misc tree with the asm-generic tree

2023-10-12 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  arch/ia64/include/asm/fb.h

between commit:

  cf8e8658100d ("arch: Remove Itanium (IA-64) architecture")

from the asm-generic tree and commit:

  052ddf7b86d2 ("fbdev: Replace fb_pgprotect() with pgprot_framebuffer()")

from the drm-misc tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgprHiMQtg_8L.pgp
Description: OpenPGP digital signature

Re: [PATCH v4] drm/i915/pxp: Add drm_dbgs for critical PXP events.

2023-10-12 Thread Balasubrawmanian, Vivaik


On 9/19/2023 11:04 AM, Alan Previn wrote:

Debugging PXP issues can't even begin without understanding precedding
sequence of important events. Add drm_dbg into the most important PXP
events.

  v3 : - move gt_dbg to after mutex block in function
 i915_gsc_proxy_component_bind. (Vivaik)
  v2 : - remove __func__ since drm_dbg covers that (Jani).
   - add timeout dbg of the restart from front-end (Alan).

Signed-off-by: Alan Previn 
Reviewed-by: Vivaik Balasubrawmanian 
---
  drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c |  2 ++
  drivers/gpu/drm/i915/pxp/intel_pxp.c | 15 ---
  drivers/gpu/drm/i915/pxp/intel_pxp_irq.c |  5 +++--
  drivers/gpu/drm/i915/pxp/intel_pxp_session.c |  6 +-
  drivers/gpu/drm/i915/pxp/intel_pxp_types.h   |  1 +
  5 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
index 5f138de3c14f..40817ebcca71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -322,6 +322,7 @@ static int i915_gsc_proxy_component_bind(struct device 
*i915_kdev,
gsc->proxy.component = data;
gsc->proxy.component->mei_dev = mei_kdev;
mutex_unlock(&gsc->proxy.mutex);
+   gt_dbg(gt, "GSC proxy mei component bound\n");
  
  	return 0;

  }
@@ -342,6 +343,7 @@ static void i915_gsc_proxy_component_unbind(struct device 
*i915_kdev,
with_intel_runtime_pm(&i915->runtime_pm, wakeref)
intel_uncore_rmw(gt->uncore, HECI_H_CSR(MTL_GSC_HECI2_BASE),
 HECI_H_CSR_IE | HECI_H_CSR_RST, 0);
+   gt_dbg(gt, "GSC proxy mei component unbound\n");
  }
  
  static const struct component_ops i915_gsc_proxy_component_ops = {

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index dc327cf40b5a..e11f562b1876 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -303,6 +303,8 @@ static int __pxp_global_teardown_final(struct intel_pxp 
*pxp)
  
  	if (!pxp->arb_is_valid)

return 0;
+
+   drm_dbg(&pxp->ctrl_gt->i915->drm, "PXP: teardown for suspend/fini");
/*
 * To ensure synchronous and coherent session teardown completion
 * in response to suspend or shutdown triggers, don't use a worker.
@@ -324,6 +326,8 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
  
  	if (pxp->arb_is_valid)

return 0;
+
+   drm_dbg(&pxp->ctrl_gt->i915->drm, "PXP: teardown for restart");
/*
 * The arb-session is currently inactive and we are doing a reset and 
restart
 * due to a runtime event. Use the worker that was designed for this.
@@ -332,8 +336,11 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
  
  	timeout = intel_pxp_get_backend_timeout_ms(pxp);
  
-	if (!wait_for_completion_timeout(&pxp->termination, msecs_to_jiffies(timeout)))

+   if (!wait_for_completion_timeout(&pxp->termination, 
msecs_to_jiffies(timeout))) {
+   drm_dbg(&pxp->ctrl_gt->i915->drm, "PXP: restart backend timed out 
(%d ms)",
+   timeout);
return -ETIMEDOUT;
+   }
  
  	return 0;

  }
@@ -414,10 +421,12 @@ int intel_pxp_start(struct intel_pxp *pxp)
int ret = 0;
  
  	ret = intel_pxp_get_readiness_status(pxp, PXP_READINESS_TIMEOUT);

-   if (ret < 0)
+   if (ret < 0) {
+   drm_dbg(&pxp->ctrl_gt->i915->drm, "PXP: tried but not-avail 
(%d)", ret);
return ret;
-   else if (ret > 1)
+   } else if (ret > 1) {
return -EIO; /* per UAPI spec, user may retry later */
+   }
  
  	mutex_lock(&pxp->arb_mutex);
  
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c

index 91e9622c07d0..d81750b9bdda 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -40,11 +40,12 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
   GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT)) {
/* immediately mark PXP as inactive on termination */
intel_pxp_mark_termination_in_progress(pxp);
-   pxp->session_events |= PXP_TERMINATION_REQUEST | 
PXP_INVAL_REQUIRED;
+   pxp->session_events |= PXP_TERMINATION_REQUEST | 
PXP_INVAL_REQUIRED |
+  PXP_EVENT_TYPE_IRQ;
}
  
  	if (iir & GEN12_DISPLAY_STATE_RESET_COMPLETE_INTERRUPT)

-   pxp->session_events |= PXP_TERMINATION_COMPLETE;
+   pxp->session_events |= PXP_TERMINATION_COMPLETE | 
PXP_EVENT_TYPE_IRQ;
  
  	if (pxp->session_events)

queue_work(system_unbound_wq, &pxp->session_work);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 0a3e66b0265e..09

[PATCH v3 5/6] dt-bindings: display: Split common Solomon properties in their own schema

There are DT properties that can be shared across different Solomon OLED
Display Controller families. Split them into a separate common schema to
avoid these properties to be duplicated in different DT bindings schemas.

Suggested-by: Rob Herring 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Rob Herring 
---

Changes in v3:
- Fix "No newline at end of file" in solomon,ssd-common.yaml (Rob Herring).
- Add Rob Herring's Reviewed-by tag to patch #5.

 .../bindings/display/solomon,ssd-common.yaml  | 42 +++
 .../bindings/display/solomon,ssd1307fb.yaml   | 28 +
 MAINTAINERS   |  1 +
 3 files changed, 44 insertions(+), 27 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/solomon,ssd-common.yaml

diff --git a/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml 
b/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
new file mode 100644
index ..3e6998481a75
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for Solomon OLED Display Controllers
+
+maintainers:
+  - Javier Martinez Canillas 
+
+properties:
+  reg:
+maxItems: 1
+
+  reset-gpios:
+maxItems: 1
+
+  # Only required for SPI
+  dc-gpios:
+description:
+  GPIO connected to the controller's D/C# (Data/Command) pin,
+  that is needed for 4-wire SPI to tell the controller if the
+  data sent is for a command register or the display data RAM
+maxItems: 1
+
+  solomon,height:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Height in pixel of the screen driven by the controller.
+  The default value is controller-dependent.
+
+  solomon,width:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Width in pixel of the screen driven by the controller.
+  The default value is controller-dependent.
+
+allOf:
+  - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml 
b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
index 20e2bd15d4d2..3afbb52d1b7f 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
@@ -27,38 +27,12 @@ properties:
   - solomon,ssd1307
   - solomon,ssd1309
 
-  reg:
-maxItems: 1
-
   pwms:
 maxItems: 1
 
-  reset-gpios:
-maxItems: 1
-
-  # Only required for SPI
-  dc-gpios:
-description:
-  GPIO connected to the controller's D/C# (Data/Command) pin,
-  that is needed for 4-wire SPI to tell the controller if the
-  data sent is for a command register or the display data RAM
-maxItems: 1
-
   vbat-supply:
 description: The supply for VBAT
 
-  solomon,height:
-$ref: /schemas/types.yaml#/definitions/uint32
-description:
-  Height in pixel of the screen driven by the controller.
-  The default value is controller-dependent.
-
-  solomon,width:
-$ref: /schemas/types.yaml#/definitions/uint32
-description:
-  Width in pixel of the screen driven by the controller.
-  The default value is controller-dependent.
-
   solomon,page-offset:
 $ref: /schemas/types.yaml#/definitions/uint32
 default: 1
@@ -148,7 +122,7 @@ required:
   - reg
 
 allOf:
-  - $ref: /schemas/spi/spi-peripheral-props.yaml#
+  - $ref: solomon,ssd-common.yaml#
 
   - if:
   properties:
diff --git a/MAINTAINERS b/MAINTAINERS
index 46ca5c4affdb..4a3baf970839 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6732,6 +6732,7 @@ DRM DRIVER FOR SOLOMON SSD130X OLED DISPLAYS
 M: Javier Martinez Canillas 
 S: Maintained
 T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
 F: Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
 F: drivers/gpu/drm/solomon/ssd130x*
 
-- 
2.41.0

[PATCH v3 6/6] dt-bindings: display: Add SSD132x OLED controllers

Add a Device Tree binding schema for the OLED panels based on the Solomon
SSD132x family of controllers.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Rob Herring 
---

Changes in v3:
- Add Rob Herring's Reviewed-by tag to patch #6.

Changes in v2:
- Remove unnecessary 'oneOf' in the SSD132x DT binding schema (Conor Dooley).
- Remove unused DT nodes labels in the binding schema examples (Conor Dooley).
- Split out common Solomon properties into a separate schema (Rob Herring).

 .../bindings/display/solomon,ssd132x.yaml | 89 +++
 MAINTAINERS   |  2 +-
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/solomon,ssd132x.yaml

diff --git a/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml 
b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
new file mode 100644
index ..0aa41bd9ddca
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/solomon,ssd132x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon SSD132x OLED Display Controllers
+
+maintainers:
+  - Javier Martinez Canillas 
+
+properties:
+  compatible:
+- enum:
+- solomon,ssd1322
+- solomon,ssd1325
+- solomon,ssd1327
+
+required:
+  - compatible
+  - reg
+
+allOf:
+  - $ref: solomon,ssd-common.yaml#
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: solomon,ssd1322
+then:
+  properties:
+width:
+  default: 480
+height:
+  default: 128
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: solomon,ssd1325
+then:
+  properties:
+width:
+  default: 128
+height:
+  default: 80
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: solomon,ssd1327
+then:
+  properties:
+width:
+  default: 128
+height:
+  default: 128
+
+unevaluatedProperties: false
+
+examples:
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@3c {
+compatible = "solomon,ssd1327";
+reg = <0x3c>;
+reset-gpios = <&gpio2 7>;
+};
+
+};
+  - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+oled@0 {
+compatible = "solomon,ssd1327";
+reg = <0x0>;
+reset-gpios = <&gpio2 7>;
+dc-gpios = <&gpio2 8>;
+spi-max-frequency = <1000>;
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a3baf970839..5257e0074f2b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6733,7 +6733,7 @@ M:Javier Martinez Canillas 
 S: Maintained
 T: git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
-F: Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+F: Documentation/devicetree/bindings/display/solomon,ssd13*.yaml
 F: drivers/gpu/drm/solomon/ssd130x*
 
 DRM DRIVER FOR ST-ERICSSON MCDE
-- 
2.41.0

[PATCH v3 3/6] drm/ssd130x: Rename commands that are shared across chip families

There are some commands that are shared between the SSD130x and SSD132x
controller families, define these as a common SSD13XX set of commands.

Signed-off-by: Javier Martinez Canillas 
---

(no changes since v1)

 drivers/gpu/drm/solomon/ssd130x-spi.c |  4 +--
 drivers/gpu/drm/solomon/ssd130x.c | 47 +++
 drivers/gpu/drm/solomon/ssd130x.h |  4 +--
 3 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c 
b/drivers/gpu/drm/solomon/ssd130x-spi.c
index 257819bccbc8..89989da705d7 100644
--- a/drivers/gpu/drm/solomon/ssd130x-spi.c
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -34,10 +34,10 @@ static int ssd130x_spi_write(void *context, const void 
*data, size_t count)
struct spi_device *spi = t->spi;
const u8 *reg = data;
 
-   if (*reg == SSD130X_COMMAND)
+   if (*reg == SSD13XX_COMMAND)
gpiod_set_value_cansleep(t->dc, 0);
 
-   if (*reg == SSD130X_DATA)
+   if (*reg == SSD13XX_DATA)
gpiod_set_value_cansleep(t->dc, 1);
 
/* Remove control byte since is not used in a 4-wire SPI interface */
diff --git a/drivers/gpu/drm/solomon/ssd130x.c 
b/drivers/gpu/drm/solomon/ssd130x.c
index 4df4c4ed61f1..b63c28f0e86e 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -44,18 +44,24 @@
 
 #define SSD130X_PAGE_HEIGHT 8
 
+/* ssd13xx commands */
+#define SSD13XX_CONTRAST   0x81
+#define SSD13XX_SET_SEG_REMAP  0xa0
+#define SSD13XX_SET_MULTIPLEX_RATIO0xa8
+#define SSD13XX_DISPLAY_OFF0xae
+#define SSD13XX_DISPLAY_ON 0xaf
+
+#define SSD13XX_SET_SEG_REMAP_MASK GENMASK(0, 0)
+#define SSD13XX_SET_SEG_REMAP_SET(val) 
FIELD_PREP(SSD13XX_SET_SEG_REMAP_MASK, (val))
+
+/* ssd130x commands */
 #define SSD130X_PAGE_COL_START_LOW 0x00
 #define SSD130X_PAGE_COL_START_HIGH0x10
 #define SSD130X_SET_ADDRESS_MODE   0x20
 #define SSD130X_SET_COL_RANGE  0x21
 #define SSD130X_SET_PAGE_RANGE 0x22
-#define SSD130X_CONTRAST   0x81
 #define SSD130X_SET_LOOKUP_TABLE   0x91
 #define SSD130X_CHARGE_PUMP0x8d
-#define SSD130X_SET_SEG_REMAP  0xa0
-#define SSD130X_DISPLAY_OFF0xae
-#define SSD130X_SET_MULTIPLEX_RATIO0xa8
-#define SSD130X_DISPLAY_ON 0xaf
 #define SSD130X_START_PAGE_ADDRESS 0xb0
 #define SSD130X_SET_COM_SCAN_DIR   0xc0
 #define SSD130X_SET_DISPLAY_OFFSET 0xd3
@@ -65,13 +71,12 @@
 #define SSD130X_SET_COM_PINS_CONFIG0xda
 #define SSD130X_SET_VCOMH  0xdb
 
+/* ssd130x commands accessors */
 #define SSD130X_PAGE_COL_START_MASKGENMASK(3, 0)
 #define SSD130X_PAGE_COL_START_HIGH_SET(val)   
FIELD_PREP(SSD130X_PAGE_COL_START_MASK, (val) >> 4)
 #define SSD130X_PAGE_COL_START_LOW_SET(val)
FIELD_PREP(SSD130X_PAGE_COL_START_MASK, (val))
 #define SSD130X_START_PAGE_ADDRESS_MASKGENMASK(2, 0)
 #define SSD130X_START_PAGE_ADDRESS_SET(val)
FIELD_PREP(SSD130X_START_PAGE_ADDRESS_MASK, (val))
-#define SSD130X_SET_SEG_REMAP_MASK GENMASK(0, 0)
-#define SSD130X_SET_SEG_REMAP_SET(val) 
FIELD_PREP(SSD130X_SET_SEG_REMAP_MASK, (val))
 #define SSD130X_SET_COM_SCAN_DIR_MASK  GENMASK(3, 3)
 #define SSD130X_SET_COM_SCAN_DIR_SET(val)  
FIELD_PREP(SSD130X_SET_COM_SCAN_DIR_MASK, (val))
 #define SSD130X_SET_CLOCK_DIV_MASK GENMASK(3, 0)
@@ -171,20 +176,20 @@ static inline struct ssd130x_device 
*drm_to_ssd130x(struct drm_device *drm)
 }
 
 /*
- * Helper to write data (SSD130X_DATA) to the device.
+ * Helper to write data (SSD13XX_DATA) to the device.
  */
 static int ssd130x_write_data(struct ssd130x_device *ssd130x, u8 *values, int 
count)
 {
-   return regmap_bulk_write(ssd130x->regmap, SSD130X_DATA, values, count);
+   return regmap_bulk_write(ssd130x->regmap, SSD13XX_DATA, values, count);
 }
 
 /*
- * Helper to write command (SSD130X_COMMAND). The fist variadic argument
+ * Helper to write command (SSD13XX_COMMAND). The fist variadic argument
  * is the command to write and the following are the command options.
  *
- * Note that the ssd130x protocol requires each command and option to be
- * written as a SSD130X_COMMAND device register value. That is why a call
- * to regmap_write(..., SSD130X_COMMAND, ...) is done for each argument.
+ * Note that the ssd13xx protocol requires each command and option to be
+ * written as a SSD13XX_COMMAND device register value. That is why a call
+ * to regmap_write(..., SSD13XX_COMMAND, ...) is done for each argument.
  */
 static int ssd130x_write_cmd(struct ssd130x_device *ssd130x, int count,
 /* u8 cmd, u8 option, ... */...)
@@ -197,7 +202,7 @@ static int ssd130x_write_cmd(struct ss

[PATCH v3 0/6] drm/solomon: Add support for the SSD132x controller family

Hello,

This patch-set adds support for the family of SSD132x Solomon controllers,
such as the SSD1322, SSD1325 and SSD1327 chips. These are used for 16 Gray
Scale Dot Matrix OLED panels.

This is a v3 that address issues pointed out during review of the v2:

https://lists.freedesktop.org/archives/dri-devel/2023-October/426448.html

The patches were tested on a Waveshare SSD1327 display using glmark2-drm,
fbcon, fbtests and the retroarch emulator.

Patch #1 drops the .page_height field from the device info with a constant
because it's only needed by the SSD130x family and not the SSD132x family.

Patch #2 adds a per controller family id field to the device info data, to
allow the driver to support different Solomon display controller families.

Patch #3 renames some SSD130X_* commands that are shared by both families.

Patch #4 adds the support for the SSD132x controller family.

Patch #5 splits out some properties that are shared across both controller
families bindings and move them into a separate solomon,ssd-common schema.

Finally patch #6 adds a DT binding schema for the SSD132x controllers.

Best regards,
Javier

Changes in v3:
- Drop the per controller family functions table (Thomas Zimmermann).
- Use different modesetting pipelines for chip families (Thomas Zimmermann).
- Change the i,j variables type to unsigned int (Geert Uytterhoeven).
- Fix "No newline at end of file" in solomon,ssd-common.yaml (Rob Herring).
- Add Rob Herring's Reviewed-by tag to patch #5.
- Add Rob Herring's Reviewed-by tag to patch #6.

Changes in v2:
- Add Geert Uytterhoeven's Reviewed-by tag to patch #1.
- Squash patch that uses drm_format_info_min_pitch() to calculate dest_pitch
  with the following patch (Geert Uytterhoeven).
- Store ssd13xx_family_funcs[SSD130X_FAMILY] in struct ssd130x_deviceinfo
  (Geert Uytterhoeven).
- Don't mix switch (family_id) and ssd13xx_funcs[family_id] (Geert 
Uytterhoeven).
- Replace switch (family_id) by an .set_buffer_sizes (Geert Uytterhoeven).
- Move the rect alignment to a per chip family function (Geert Uytterhoeven).
- Align the rectangle to the segment width (Geert Uytterhoeven).
- Drop patches that rename driver and prefixes (Maxime Ripard, Peter Robinson).
- Remove unnecessary 'oneOf' in the SSD132x DT binding schema (Conor Dooley).
- Remove unused DT nodes labels in the binding schema examples (Conor Dooley).
- Split out common Solomon properties into a separate schema (Rob Herring).

Javier Martinez Canillas (6):
  drm/ssd130x: Replace .page_height field in device info with a constant
  drm/ssd130x: Add a controller family id to the device info data
  drm/ssd130x: Rename commands that are shared across chip families
  drm/ssd130x: Add support for the SSD132x OLED controller family
  dt-bindings: display: Split common Solomon properties in their own
schema
  dt-bindings: display: Add SSD132x OLED controllers

 .../bindings/display/solomon,ssd-common.yaml  |  42 ++
 .../bindings/display/solomon,ssd1307fb.yaml   |  28 +-
 .../bindings/display/solomon,ssd132x.yaml |  89 +++
 MAINTAINERS   |   3 +-
 drivers/gpu/drm/solomon/Kconfig   |  12 +-
 drivers/gpu/drm/solomon/ssd130x-i2c.c |  18 +-
 drivers/gpu/drm/solomon/ssd130x-spi.c |  27 +-
 drivers/gpu/drm/solomon/ssd130x.c | 507 --
 drivers/gpu/drm/solomon/ssd130x.h |  17 +-
 9 files changed, 644 insertions(+), 99 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/solomon,ssd132x.yaml

-- 
2.41.0

[PATCH v3 4/6] drm/ssd130x: Add support for the SSD132x OLED controller family

The Solomon SSD132x controllers (such as the SSD1322, SSD1325 and SSD1327)
are used by 16 grayscale dot matrix OLED panels, extend the driver to also
support this chip family.

Instead adding an indirection level to allow the same modesetting pipeline
to be used by both controller families, add another pipeline for SSD132x.

This leads to some code duplication but it makes the driver easier to read
and understand. Once other controller families are added (e.g: SSD133x),
some common code can be factored out in driver helpers to be shared by the
different families. But that can be done later once these patterns emerge.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3:
- Use different modesetting pipelines for chip families (Thomas Zimmermann).
- Change the i,j variables type to unsigned int (Geert Uytterhoeven).

Changes in v2:
- Align the rectangle to the segment width (Geert Uytterhoeven).

 drivers/gpu/drm/solomon/Kconfig   |  12 +-
 drivers/gpu/drm/solomon/ssd130x-i2c.c |  17 +-
 drivers/gpu/drm/solomon/ssd130x-spi.c |  21 +-
 drivers/gpu/drm/solomon/ssd130x.c | 418 +-
 drivers/gpu/drm/solomon/ssd130x.h |   7 +-
 5 files changed, 448 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/solomon/Kconfig b/drivers/gpu/drm/solomon/Kconfig
index e170716d976b..c3ee956c2bb9 100644
--- a/drivers/gpu/drm/solomon/Kconfig
+++ b/drivers/gpu/drm/solomon/Kconfig
@@ -1,31 +1,31 @@
 config DRM_SSD130X
-   tristate "DRM support for Solomon SSD130x OLED displays"
+   tristate "DRM support for Solomon SSD13xx OLED displays"
depends on DRM && MMU
select BACKLIGHT_CLASS_DEVICE
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
help
- DRM driver for the SSD130x Solomon and SINO WEALTH SH110x OLED
+ DRM driver for the SSD13xx Solomon and SINO WEALTH SH110x OLED
  controllers. This is only for the core driver, a driver for the
  appropriate bus transport in your chip also must be selected.
 
  If M is selected the module will be called ssd130x.
 
 config DRM_SSD130X_I2C
-   tristate "DRM support for Solomon SSD130x OLED displays (I2C bus)"
+   tristate "DRM support for Solomon SSD13xx OLED displays (I2C bus)"
depends on DRM_SSD130X && I2C
select REGMAP_I2C
help
- Say Y here if the SSD130x or SH110x OLED display is connected via
+ Say Y here if the SSD13xx or SH110x OLED display is connected via
  I2C bus.
 
  If M is selected the module will be called ssd130x-i2c.
 
 config DRM_SSD130X_SPI
-   tristate "DRM support for Solomon SSD130X OLED displays (SPI bus)"
+   tristate "DRM support for Solomon SSD13xx OLED displays (SPI bus)"
depends on DRM_SSD130X && SPI
select REGMAP
help
- Say Y here if the SSD130x OLED display is connected via SPI bus.
+ Say Y here if the SSD13xx OLED display is connected via SPI bus.
 
  If M is selected the module will be called ssd130x-spi.
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c 
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index 8f89b89d553f..f2ccab9c06d9 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * DRM driver for Solomon SSD130x OLED displays (I2C bus)
+ * DRM driver for Solomon SSD13xx OLED displays (I2C bus)
  *
  * Copyright 2022 Red Hat Inc.
  * Author: Javier Martinez Canillas 
@@ -14,7 +14,7 @@
 #include "ssd130x.h"
 
 #define DRIVER_NAME"ssd130x-i2c"
-#define DRIVER_DESC"DRM driver for Solomon SSD130x OLED displays (I2C)"
+#define DRIVER_DESC"DRM driver for Solomon SSD13xx OLED displays (I2C)"
 
 static const struct regmap_config ssd130x_i2c_regmap_config = {
.reg_bits = 8,
@@ -92,6 +92,19 @@ static const struct of_device_id ssd130x_of_match[] = {
.compatible = "solomon,ssd1309fb-i2c",
.data = &ssd130x_variants[SSD1309_ID],
},
+   /* ssd132x family */
+   {
+   .compatible = "solomon,ssd1322",
+   .data = &ssd130x_variants[SSD1322_ID],
+   },
+   {
+   .compatible = "solomon,ssd1325",
+   .data = &ssd130x_variants[SSD1325_ID],
+   },
+   {
+   .compatible = "solomon,ssd1327",
+   .data = &ssd130x_variants[SSD1327_ID],
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, ssd130x_of_match);
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c 
b/drivers/gpu/drm/solomon/ssd130x-spi.c
index 89989da705d7..84e035a7ab3f 100644
--- a/drivers/gpu/drm/solomon/ssd130x-spi.c
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * DRM driver for Solomon SSD130X OLED displays (SPI bus)
+ * DRM driver for Solomon SSD13xx OLED displays (SPI bus)
  *
  * Copyright 2022 Red Hat Inc.
  * Authors: Javier Martinez Ca

[PATCH v3 2/6] drm/ssd130x: Add a controller family id to the device info data

To allow the driver to have a per Solomon display controller modesetting
pipeline and support aother controller families besides SSD130x.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3:
- Drop the per controller family functions table (Thomas Zimmermann).

Changes in v2:
- Squash patch that uses drm_format_info_min_pitch() to calculate dest_pitch
  with the following patch (Geert Uytterhoeven).
- Store ssd13xx_family_funcs[SSD130X_FAMILY] in struct ssd130x_deviceinfo
  (Geert Uytterhoeven).
- Don't mix switch (family_id) and ssd13xx_funcs[family_id] (Geert 
Uytterhoeven).
- Replace switch (family_id) by an .set_buffer_sizes (Geert Uytterhoeven).
- Move the rect alignment to a per chip family function (Geert Uytterhoeven).

 drivers/gpu/drm/solomon/ssd130x-i2c.c | 1 +
 drivers/gpu/drm/solomon/ssd130x-spi.c | 2 ++
 drivers/gpu/drm/solomon/ssd130x.c | 5 +
 drivers/gpu/drm/solomon/ssd130x.h | 7 +++
 4 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c 
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index b4eb2d64bf6e..8f89b89d553f 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -54,6 +54,7 @@ static void ssd130x_i2c_shutdown(struct i2c_client *client)
 }
 
 static const struct of_device_id ssd130x_of_match[] = {
+   /* ssd130x family */
{
.compatible = "sinowealth,sh1106",
.data = &ssd130x_variants[SH1106_ID],
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c 
b/drivers/gpu/drm/solomon/ssd130x-spi.c
index 19ab4942cb33..257819bccbc8 100644
--- a/drivers/gpu/drm/solomon/ssd130x-spi.c
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -108,6 +108,7 @@ static void ssd130x_spi_shutdown(struct spi_device *spi)
 }
 
 static const struct of_device_id ssd130x_of_match[] = {
+   /* ssd130x family */
{
.compatible = "sinowealth,sh1106",
.data = &ssd130x_variants[SH1106_ID],
@@ -142,6 +143,7 @@ MODULE_DEVICE_TABLE(of, ssd130x_of_match);
  * not be needed for this driver to match the registered SPI devices.
  */
 static const struct spi_device_id ssd130x_spi_table[] = {
+   /* ssd130x family */
{ "sh1106",  SH1106_ID },
{ "ssd1305", SSD1305_ID },
{ "ssd1306", SSD1306_ID },
diff --git a/drivers/gpu/drm/solomon/ssd130x.c 
b/drivers/gpu/drm/solomon/ssd130x.c
index 2852cddb098b..4df4c4ed61f1 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -104,6 +104,7 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_width = 132,
.default_height = 64,
.page_mode_only = 1,
+   .family_id = SSD130X_FAMILY,
},
[SSD1305_ID] = {
.default_vcomh = 0x34,
@@ -111,6 +112,7 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_dclk_frq = 7,
.default_width = 132,
.default_height = 64,
+   .family_id = SSD130X_FAMILY,
},
[SSD1306_ID] = {
.default_vcomh = 0x20,
@@ -119,6 +121,7 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.need_chargepump = 1,
.default_width = 128,
.default_height = 64,
+   .family_id = SSD130X_FAMILY,
},
[SSD1307_ID] = {
.default_vcomh = 0x20,
@@ -127,6 +130,7 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.need_pwm = 1,
.default_width = 128,
.default_height = 39,
+   .family_id = SSD130X_FAMILY,
},
[SSD1309_ID] = {
.default_vcomh = 0x34,
@@ -134,6 +138,7 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_dclk_frq = 10,
.default_width = 128,
.default_height = 64,
+   .family_id = SSD130X_FAMILY,
}
 };
 EXPORT_SYMBOL_NS_GPL(ssd130x_variants, DRM_SSD130X);
diff --git a/drivers/gpu/drm/solomon/ssd130x.h 
b/drivers/gpu/drm/solomon/ssd130x.h
index bbe374453605..c562c2d00c16 100644
--- a/drivers/gpu/drm/solomon/ssd130x.h
+++ b/drivers/gpu/drm/solomon/ssd130x.h
@@ -24,7 +24,12 @@
 #define SSD130X_DATA   0x40
 #define SSD130X_COMMAND0x80
 
+enum ssd130x_family_ids {
+   SSD130X_FAMILY
+};
+
 enum ssd130x_variants {
+   /* ssd130x family */
SH1106_ID,
SSD1305_ID,
SSD1306_ID,
@@ -42,6 +47,8 @@ struct ssd130x_deviceinfo {
bool need_pwm;
bool need_chargepump;
bool page_mode_only;
+
+   enum ssd130x_family_ids family_id;
 };
 
 struct ssd130x_device {
-- 
2.41.0

[PATCH v3 1/6] drm/ssd130x: Replace .page_height field in device info with a constant

This deemed useful to avoid hardcoding a page height and allow to support
other Solomon controller families, but dividing the screen in pages seems
to be something that is specific to the SSD130x chip family.

For example, SSD132x chip family divides the screen in segments (columns)
and common outputs (rows), so the concept of screen pages does not exist
for the SSD132x family.

Let's drop this field from the device info struct and just use a constant
SSD130X_PAGE_HEIGHT macro to define the page height. While being there,
replace hardcoded 8 values in places where it is used as the page height.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Geert Uytterhoeven 
---

(no changes since v2)

Changes in v2:
- Add Geert Uytterhoeven's Reviewed-by tag to patch #1.

 drivers/gpu/drm/solomon/ssd130x.c | 37 +++
 drivers/gpu/drm/solomon/ssd130x.h |  1 -
 2 files changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/solomon/ssd130x.c 
b/drivers/gpu/drm/solomon/ssd130x.c
index 6dcf3e041113..2852cddb098b 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -42,6 +42,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+#define SSD130X_PAGE_HEIGHT 8
+
 #define SSD130X_PAGE_COL_START_LOW 0x00
 #define SSD130X_PAGE_COL_START_HIGH0x10
 #define SSD130X_SET_ADDRESS_MODE   0x20
@@ -102,7 +104,6 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_width = 132,
.default_height = 64,
.page_mode_only = 1,
-   .page_height = 8,
},
[SSD1305_ID] = {
.default_vcomh = 0x34,
@@ -110,7 +111,6 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_dclk_frq = 7,
.default_width = 132,
.default_height = 64,
-   .page_height = 8,
},
[SSD1306_ID] = {
.default_vcomh = 0x20,
@@ -119,7 +119,6 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.need_chargepump = 1,
.default_width = 128,
.default_height = 64,
-   .page_height = 8,
},
[SSD1307_ID] = {
.default_vcomh = 0x20,
@@ -128,7 +127,6 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.need_pwm = 1,
.default_width = 128,
.default_height = 39,
-   .page_height = 8,
},
[SSD1309_ID] = {
.default_vcomh = 0x34,
@@ -136,7 +134,6 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
.default_dclk_frq = 10,
.default_width = 128,
.default_height = 64,
-   .page_height = 8,
}
 };
 EXPORT_SYMBOL_NS_GPL(ssd130x_variants, DRM_SSD130X);
@@ -465,13 +462,13 @@ static int ssd130x_update_rect(struct ssd130x_device 
*ssd130x,
unsigned int width = drm_rect_width(rect);
unsigned int height = drm_rect_height(rect);
unsigned int line_length = DIV_ROUND_UP(width, 8);
-   unsigned int page_height = ssd130x->device_info->page_height;
+   unsigned int page_height = SSD130X_PAGE_HEIGHT;
unsigned int pages = DIV_ROUND_UP(height, page_height);
struct drm_device *drm = &ssd130x->drm;
u32 array_idx = 0;
int ret, i, j, k;
 
-   drm_WARN_ONCE(drm, y % 8 != 0, "y must be aligned to screen page\n");
+   drm_WARN_ONCE(drm, y % page_height != 0, "y must be aligned to screen 
page\n");
 
/*
 * The screen is divided in pages, each having a height of 8
@@ -503,27 +500,32 @@ static int ssd130x_update_rect(struct ssd130x_device 
*ssd130x,
 */
 
if (!ssd130x->page_address_mode) {
+   u8 page_start;
+
/* Set address range for horizontal addressing mode */
ret = ssd130x_set_col_range(ssd130x, ssd130x->col_offset + x, 
width);
if (ret < 0)
return ret;
 
-   ret = ssd130x_set_page_range(ssd130x, ssd130x->page_offset + y 
/ 8, pages);
+   page_start = ssd130x->page_offset + y / page_height;
+   ret = ssd130x_set_page_range(ssd130x, page_start, pages);
if (ret < 0)
return ret;
}
 
for (i = 0; i < pages; i++) {
-   int m = 8;
+   int m = page_height;
 
/* Last page may be partial */
-   if (8 * (y / 8 + i + 1) > ssd130x->height)
-   m = ssd130x->height % 8;
+   if (page_height * (y / page_height + i + 1) > ssd130x->height)
+   m = ssd130x->height % page_height;
+
for (j = 0; j < width; j++) {
u8 data = 0;
 
for (k = 0; k < m; k++) {
-   u8 byte = buf[(8 * i + k) * line_lengt

Re: [PATCH] drm/edid: add 8 bpc quirk to the BenQ GW2765

2023-10-12 Thread Harry Wentland




On 2023-10-12 14:49, Hamza Mahfooz wrote:
> The BenQ GW2765 reports that it supports higher (> 8) bpc modes, but
> when trying to set them we end up with a black screen. So, limit it to 8
> bpc modes.
> 
> Cc: sta...@vger.kernel.org # 6.5+
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2610
> Signed-off-by: Hamza Mahfooz 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_edid.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0454da505687..bca2af4fe1fc 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -123,6 +123,9 @@ static const struct edid_quirk {
>   /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
>   EDID_QUIRK('A', 'E', 'O', 0, EDID_QUIRK_FORCE_6BPC),
>  
> + /* BenQ GW2765 */
> + EDID_QUIRK('B', 'N', 'Q', 0x78d6, EDID_QUIRK_FORCE_8BPC),
> +
>   /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc 
> panel */
>   EDID_QUIRK('B', 'O', 'E', 0x78b, EDID_QUIRK_FORCE_6BPC),
>

Re: [PATCH] drm/nouveau/disp: fix DP capable DSM connectors

2023-10-12 Thread Lyude Paul

Reviewed-by: Lyude Paul 

On Wed, 2023-10-11 at 13:41 +0200, Karol Herbst wrote:
> Just special case DP DSM connectors until we properly figure out how to
> deal with this.
> 
> This resolves user regressions on GPUs with such connectors without
> reverting the original fix.
> 
> Cc: Lyude Paul 
> Cc: sta...@vger.kernel.org # 6.4+
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/255
> Fixes: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR 
> AUX interrupts")
> Signed-off-by: Karol Herbst 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
> index 46b057fe1412e..3249e5c1c8930 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c
> @@ -62,6 +62,18 @@ nvkm_uconn_uevent_gpio(struct nvkm_object *object, u64 
> token, u32 bits)
>   return object->client->event(token, &args, sizeof(args.v0));
>  }
>  
> +static bool
> +nvkm_connector_is_dp_dms(u8 type)
> +{
> + switch (type) {
> + case DCB_CONNECTOR_DMS59_DP0:
> + case DCB_CONNECTOR_DMS59_DP1:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
>  static int
>  nvkm_uconn_uevent(struct nvkm_object *object, void *argv, u32 argc, struct 
> nvkm_uevent *uevent)
>  {
> @@ -101,7 +113,7 @@ nvkm_uconn_uevent(struct nvkm_object *object, void *argv, 
> u32 argc, struct nvkm_
>   if (args->v0.types & NVIF_CONN_EVENT_V0_UNPLUG) bits |= NVKM_GPIO_LO;
>   if (args->v0.types & NVIF_CONN_EVENT_V0_IRQ) {
>   /* TODO: support DP IRQ on ANX9805 and remove this hack. */
> - if (!outp->info.location)
> + if (!outp->info.location && 
> !nvkm_connector_is_dp_dms(conn->info.type))
>   return -EINVAL;
>   }
>  

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

Re: [PATCH v11 08/16] drm/mediatek: De-commonize disp_aal/disp_gamma gamma_set functions

2023-10-12 Thread Nícolas F . R . A . Prado

On Thu, Oct 12, 2023 at 11:57:28AM +0200, AngeloGioacchino Del Regno wrote:
> In preparation for adding a 12-bits gamma support for the DISP_GAMMA
> IP, remove the mtk_gamma_set_common() function and move the relevant
> bits in mtk_gamma_set() for DISP_GAMMA and mtk_aal_gamma_set() for
> DISP_AAL: since the latter has no more support for gamma manipulation
> (being moved to a different IP) in newer revisions, those functions
> are about to diverge and it makes no sense to keep a common one (with
> all the complications of passing common data and making exclusions
> for device driver data) for just a few bits.
> 
> This commit brings no functional changes.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 

Reviewed-by: Nícolas F. R. A. Prado 

Thanks,
Nícolas

[PATCH] drm/edid: add 8 bpc quirk to the BenQ GW2765

2023-10-12 Thread Hamza Mahfooz

The BenQ GW2765 reports that it supports higher (> 8) bpc modes, but
when trying to set them we end up with a black screen. So, limit it to 8
bpc modes.

Cc: sta...@vger.kernel.org # 6.5+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2610
Signed-off-by: Hamza Mahfooz 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0454da505687..bca2af4fe1fc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -123,6 +123,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
EDID_QUIRK('A', 'E', 'O', 0, EDID_QUIRK_FORCE_6BPC),
 
+   /* BenQ GW2765 */
+   EDID_QUIRK('B', 'N', 'Q', 0x78d6, EDID_QUIRK_FORCE_8BPC),
+
/* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc 
panel */
EDID_QUIRK('B', 'O', 'E', 0x78b, EDID_QUIRK_FORCE_6BPC),
 
-- 
2.42.0

Re: [PATCH v1] dynamic_debug: add support for logs destination

2023-10-12 Thread jim . cromie

> If you want the kernel to keep separate flight recorders I guess we could
> add that, but I don't think it currently exists for the dyndbg stuff at
> least. Maybe a flight recorder v2 feature, once the basics are in.
>

dyndbg has   +pwrites to syslog
+T  would separately independently write the same to global trace

This would allow  graceful switchover to tracefs,
without removing logging from dmesg, where most folks
(and any monitor tools) would expect it.

Lukas (iiuc) wants to steer each site to just 1 destination.
Or maybe (in addition to +p > syslog) one trace destination,
either global via events, or a separate tracebuf

Im ambivalent, but thinking the smooth rollover from syslog to trace
might be worth having to ease migration / weaning off syslog.

And we have a 4 byte hole in struct _ddebug we could just use.
Unless the align 8 is optional on 32-bits,
I think we're never gonna close the hole anywhere.

is align 8 a generic expression of an architectural simplifying constraint ?
or a need for 1-7 ptr offsets ?




> > That's my idea of it. It is interesting to see how far the requirements
> > can be reasonably realised.
>
> I think aside from the "make it available directly to unpriviledged
> userspace" everything sounds reasonable and doable.
>
> More on the process side of things, I think Jim is very much looking for
> acks and tested-by by people who are interested in better drm logging
> infra. That should help that things are moving in a direction that's
> actually useful, even when it's not yet entirely complete.
>

yes, please.  Now posted at

https://lore.kernel.org/lkml/20231012172137.3286566-1-jim.cro...@gmail.com/T/#t

Lukas, I managed to miss your email in the send phase.
please consider yourself a direct recipient :-)

thanks everyone

> Cheers, Sima
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

2023-10-12 Thread Ray Strode

Hi,

On Mon, Oct 09, 2023 at 02:36:17PM +0200, Christian König wrote:
> > > > To be clear, my take is, if driver code is running in process context
> > > > and needs to wait for periods of time on the order of or in excess of
> > > > a typical process time slice it should be sleeping during the waiting.
> > > > If the operation is at a point where it can be cancelled without side
> > > > effects, the sleeping should be INTERRUPTIBLE. If it's past the point
> > > > of no return, sleeping should be UNINTERRUPTIBLE. At no point, in my
> > > > opinion, should kernel code busy block a typical process for dozens of
> > > > milliseconds while keeping the process RUNNING. I don't think this is
> > > > a controversial take.
> > > Exactly that's what I completely disagree on.

Okay if we can't agree that it's not okay for user space (or the
kernel running in the context of user space) to busy loop a cpu core
at 100% utilization throughout and beyond the process's entire
scheduled time slice then we really are at an impasse. I gotta say i'm
astonished that this seemingly indefensible behavior is somehow a
point of contention, but I'm not going to keep arguing about it beyond
this email.

I mean we're not talking about scientific computing, or code
compilation, or seti@home. We're talking about nearly the equivalent
of `while (1) __asm__ ("nop");`

> > The key point here is that the patch puts the work into the background just
> > to avoid that it is accounted to the thread issuing it, and that in turn is
> > not valid as far as I can see.
>
> Yeah it's that aspect I'm really worried about, because we essentially
> start to support some gurantees that a) most drivers can't uphold without
> a huge amount of work, some of the DC state recomputations are _really_
> expensive b) without actually making the semantics clear, it's just
> duct-tape.

If DC plane state computation (or whatever) is really taking 50ms or
200ms, then it probably should be done in chunks so it doesn't get
preempted at an inopportune point? Look, this is not my wheelhouse,
this is your wheelhouse, and I don't want to keep debating forever. It
seems there is a discrepancy between our understandings of implied
acceptable behavior.

> Yes compositors want to run kms in real-time, and yes that results in fun
> if you try to strictly account for cpu time spent. Especially if your
> policy is to just nuke the real time thread instead of demoting it to
> SCHED_NORMAL for a time.

So I ended up going with this suggestion for blocking modesets:

https://gitlab.gnome.org/GNOME/mutter/-/commit/5d3e31a49968fc0da04e98c0f9d624ea5095c9e0

But *this* feels like duct tape: You've already said there's no
guarantee the problem won't also happen during preliminary computation
during non-blocking commits or via other drm entry points. So it
really does seem like a fix that won't age well. I won't be surprised
if in ~3 years (or whatever) in some RHEL release there's a customer
bug leading to the real-time thread getting blocklisted for obscure
server display hardware because it's causing the session to tank on a
production machine.

> I think if we want more than hacks here we need to answer two questions:
> - which parts of the kms api are real time
> - what exactly do we guarantee with that

imo, this isn't just about real-time versus non-real-time. It's no
more acceptable for non-real-time mutter to be using 100% CPU doing
busywaits than it is for real-time mutter to be using 100% cpu doing
busywaits.

Also, both you and Christian have suggested using the non-blocking
modeset api with a fence fd to poll on is equivalent to the blocking
api flushing the commit_tail work before returning from the ioctl, but
that's not actually true. I think we all now agree the EBUSY problem
you mentioned as an issue with my proposed patch wasn't actually a
problem for blocking commits, but that very same issue is a problem
with the non-blocking commits that then block on a fence fd, right? I
guess we'd need to block on a fence fd from the prior non-blocking
commit first before starting the blocking commit (or something)

--Ray

Re: [PATCH] drm/nouveau/dispnv04: fix a possible null pointer dereference

2023-10-12 Thread Danilo Krummrich


On 10/7/23 05:23, Ma Ke wrote:

In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.

Signed-off-by: Ma Ke 


Reviewed-by: Danilo Krummrich 


---
  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index 670c9739e5e1..4a08e61f3336 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -209,6 +209,8 @@ static int nv17_tv_get_ld_modes(struct drm_encoder *encoder,
struct drm_display_mode *mode;
  
  		mode = drm_mode_duplicate(encoder->dev, tv_mode);

+   if (!mode)
+   continue;
  
  		mode->clock = tv_norm->tv_enc_mode.vrefresh *

mode->htotal / 1000 *

Re: [Intel-gfx] [PATCH] drm/i915/guc: Suppress 'ignoring reset notification' message

2023-10-12 Thread John Harrison


On 10/12/2023 03:21, Tvrtko Ursulin wrote:

On 21/09/2023 19:20, john.c.harri...@intel.com wrote:

From: John Harrison 

If an active context has been banned (e.g. Ctrl+C killed) then it is
likely to be reset as part of evicting it from the hardware. That
results in a 'ignoring context reset notification: banned = 1'
message at info level. This confuses/concerns people and makes them
thing something has gone wrong when it hasn't.


Noticed the "confuses/concerns people" part while preparing the 6.7 
pull request, and the fact there is no Fixes: tag. Is this something 
that would be worth sending to stable (manually and if yes could you 
do that please? If there were actual user bugs filed I guess.


No upstream bugs that I am aware of. There were very occasional 
concerned emails from internal test teams (E2E and such rather than 
kernel) and I think one internal bug was logged about it being seen when 
running some automated user interaction stress test thing (monkey runner 
or similar). So not sure that it is worth the effort of a backport to 
older trees. And you can't really call it a bug with an older patch. The 
message was never an error or even a warning, just an info level.


John.



Regards,

Tvrtko


There is already a debug level message with essentially the same
information. So drop the 'ignore' info level one and just add the
'ignore' flag to the debug level one instead (which will therefore not
appear by default but will still show up in CI runs).

Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

index cabdc645fcddb..da7331346df1f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4770,19 +4770,19 @@ static void guc_context_replay(struct 
intel_context *ce)

  static void guc_handle_context_reset(struct intel_guc *guc,
   struct intel_context *ce)
  {
+    bool capture = intel_context_is_schedulable(ce);
+
  trace_intel_context_reset(ce);
  -    guc_dbg(guc, "Got context reset notification: 0x%04X on %s, 
exiting = %s, banned = %s\n",
+    guc_dbg(guc, "%s context reset notification: 0x%04X on %s, 
exiting = %s, banned = %s\n",

+    capture ? "Got" : "Ignoring",
  ce->guc_id.id, ce->engine->name,
  str_yes_no(intel_context_is_exiting(ce)),
  str_yes_no(intel_context_is_banned(ce)));
  -    if (likely(intel_context_is_schedulable(ce))) {
+    if (capture) {
  capture_error_state(guc, ce);
  guc_context_replay(ce);
-    } else {
-    guc_info(guc, "Ignoring context reset notification of 
exiting context 0x%04X on %s",

- ce->guc_id.id, ce->engine->name);
  }
  }

Re: [PATCH v2] drm/nouveau: exec: fix ioctl kernel-doc warning

2023-10-12 Thread Danilo Krummrich


On 10/8/23 16:02, Randy Dunlap wrote:

kernel-doc emits a warning:

include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand  * 
@NOUVEAU_GETPARAM_EXEC_PUSH_MAX
  on line 49 - I thought it was a doc line

We don't have a way to document a macro value via kernel-doc, so
change the "/**" kernel-doc marker to a C comment and format the comment
more like a kernel-doc comment for consistency.

Fixes: d59e75eef52d ("drm/nouveau: exec: report max pushs through getparam")
Signed-off-by: Randy Dunlap 


Thanks for fixing this up, applied to drm-misc-fixes.

- Danilo


Cc: Dave Airlie 
Cc: Danilo Krummrich 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Bragatheswaran Manickavel 
---
v2: update commit text; somehow I sent a version of the patch before
 adding the full text.
v1: https://lore.kernel.org/lkml/20231007005518.32015-1-rdun...@infradead.org/

  include/uapi/drm/nouveau_drm.h |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -45,8 +45,8 @@ extern "C" {
  #define NOUVEAU_GETPARAM_HAS_BO_USAGE15
  #define NOUVEAU_GETPARAM_HAS_PAGEFLIP16
  
-/**

- * @NOUVEAU_GETPARAM_EXEC_PUSH_MAX
+/*
+ * NOUVEAU_GETPARAM_EXEC_PUSH_MAX - query max pushes through getparam
   *
   * Query the maximum amount of IBs that can be pushed through a single
   * &drm_nouveau_exec structure and hence a single &DRM_IOCTL_NOUVEAU_EXEC

[PATCH v7 23/25] drm: use correct ccflags-y spelling

Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:

CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n

Also add subdir-ccflags so that all drivers pick up the addition.

Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory 
macro")
Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 215e78e79125..22b1984cc982 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -3,7 +3,8 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
+ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG)+= 
-DDYNAMIC_DEBUG_MODULE
+subdir-ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
 
 drm-y := \
drm_aperture.o \
-- 
2.41.0

[PATCH v7 25/25] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

Lots of burn-in testing needed before signing, upstreaming.

NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3caa020391c7..708f5e8cb205 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -55,8 +55,7 @@ config DRM_DEBUG_MM
 
 config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
-   default n
-   depends on BROKEN
+   default y
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
-- 
2.41.0

[PATCH v7 24/25] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers

Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files.  For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.

Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its class'd prdbgs stuck in the initial
(disabled, but for DEBUG) state.

The stuck sites are evident in /proc/dynamic_debug/control as:

   class:_UNKNOWN_ _id:N# control's last column

rather than a proper "enumeration":

   class:DRM_UT_CORE

This set of updates was found by choosing M for all DRM-config items I
found (not allmodconfig), building & modprobing them, and grepping
"class unknown," control.  There may yet be others.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++
 drivers/gpu/drm/gud/gud_drv.c  | 2 ++
 drivers/gpu/drm/mgag200/mgag200_drv.c  | 2 ++
 drivers/gpu/drm/qxl/qxl_drv.c  | 2 ++
 drivers/gpu/drm/radeon/radeon_drv.c| 2 ++
 drivers/gpu/drm/udl/udl_main.c | 2 ++
 drivers/gpu/drm/vkms/vkms_drv.c| 2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 ++
 8 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index e435f986cd13..066d906e3199 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 MODULE_IMPORT_NS(DMA_BUF);
 
 /**
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index 9d7bf8ee45f1..5b555045fce4 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -31,6 +31,8 @@
 
 #include "gud_internal.h"
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 /* Only used internally */
 static const struct drm_format_info gud_drm_format_r1 = {
.format = GUD_DRM_FORMAT_R1,
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index abddf37f0ea1..d678eb8e028d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -24,6 +24,8 @@ static int mgag200_modeset = -1;
 MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
 module_param_named(modeset, mgag200_modeset, int, 0400);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 int mgag200_init_pci_options(struct pci_dev *pdev, u32 option, u32 option2)
 {
struct device *dev = &pdev->dev;
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index b30ede1cf62d..91942ffcc2b4 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -65,6 +65,8 @@ module_param_named(modeset, qxl_modeset, int, 0400);
 MODULE_PARM_DESC(num_heads, "Number of virtual crtcs to expose (default 4)");
 module_param_named(num_heads, qxl_num_crtc, int, 0400);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static struct drm_driver qxl_driver;
 static struct pci_driver qxl_pci_driver;
 
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa531493b111..ab29945af657 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -247,6 +247,8 @@ int radeon_cik_support = 1;
 MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 = 
disabled)");
 module_param_named(cik_support, radeon_cik_support, int, 0444);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
 };
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 3ebe2ce55dfd..ba57c14454e5 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -19,6 +19,8 @@
 
 #define NR_USB_REQUEST_CHANNEL 0x12
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
 #define WRITES_IN_FLIGHT (20)
 #define MAX_VENDOR_DESCRIPTOR_SIZE 256
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index dd0af086e7fa..086797c4b82b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -39,6 +39,8 @@
 
 static struct vkms_config *default_config;
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 static bool enable_cursor = true;
 module_param_named(enable_cursor, enable_cursor, bool, 0444);
 MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 8b24ecf60e3e..9cb6be422621 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -275,6 +275,8 @@ static int vmw_probe(struct pci_dev *, const struct 
pci_device_id *);
 static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
  void *ptr);
 
+DRM_CLASSMAP_USE(drm_debug_classes);
+
 MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
 module_param_named(restrict_iommu, vmw_restrict_iommu, int, 06

[PATCH v7 22/25] dyndbg: improve err report in attach_user_module_classes

convert a WARN on 3 conditions, into BUG_ON 2 of them (which don't
happen), and an early return on (!cli->user_mod_name), which *was*
happening, so should be seen going forward.  Maybe this should be a
WARN.

NB: The underlying problem was a missing __align(8) in the
DYNDBG_CLASSMAP_USE, which manifested as a corrupt record with a map
pointer which segv'd.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 974395bf8a83..3dc512fb1d66 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1284,9 +1284,11 @@ static void ddebug_attach_user_module_classes(struct 
ddebug_table *dt,
 */
for_each_boxed_vector(di, class_users, num_class_users, i, cli) {
 
-   if (WARN_ON(!cli || !cli->map || !cli->user_mod_name))
-   continue;
-
+   BUG_ON(!cli || !cli->map);
+   if (!cli->user_mod_name) {
+   pr_warn("class_ref[%d] !user-mod-name looking for 
%s\n", i, dt->mod_name);
+   return;
+   }
if (!strcmp(cli->user_mod_name, dt->mod_name)) {
 
vpr_cm_info(cli->map, "class_ref[%d] %s -> %s", i,
-- 
2.41.0

[PATCH v7 19/25] dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED

Reserve bit 7 to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with one+ of module:function:sourcfile
- was previously called
- was thus saved in the cache. NOT YET.

Its unclear whether any cache fetch would be faster than 2-3 field
fetches, but theres another factor; the 3 columns in the __dyndbg
section are highly redundant and compressible, but to get the
compression, we need field accessors, which will rebalance the
tradeoff.

So, for now, its just the bit reservation.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index f182f95caabb..927cb14f24e0 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -38,6 +38,7 @@ struct _ddebug {
 #define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
 #define _DPRINTK_FLAGS_INCL_TID(1<<4)
 #define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
+#define _DPRINTK_FLAGS_PREFIX_CACHED   (1<<7)
 
 #define _DPRINTK_FLAGS_INCL_ANY\
(_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
-- 
2.41.0

[PATCH v7 20/25] dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP

dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive.

When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY
prefix decorations are sprintf'd into stack-mem for every call.

This string (or part of it) could be cached once its 1st generated,
and retreived thereafter, as long as its deleted any time the
callsite's flags are changed afterwards.

So consider the prefix/decoration flags: 'tmfsl', and what should be
in the cache:

-t  thread-id. not part of the "callsite" info, derived from current.
doesnt belong in the cache. it would be wrong.
can be done in outer: dynamic_emit_prefix()

-l  line number
this could be part of the prefix, but would bloat the cache
can also be done in outer: dynamic_emit_prefix()

-mfs  module, function, source-file
we cache these, composed into a sub-string.
they are "lookups", currently to descriptor fields,
could be accessor macros to "compressed" tables.
cache saves more access work.

All enabled together, they compose a prefix string like:

  # outer   -inner--   outer
  "[tid] module:function:sourcfile:line: "

So this patch extracts _DPRINTK_FLAGS_INCL_LOOKUP macro out of
_DPRINTK_FLAGS_INCL_ANY macro, then redefs latter.

Next re-refactor dynamic_emit_prefix inner/outer fns accordingly.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 927cb14f24e0..2237d454bc19 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -40,10 +40,12 @@ struct _ddebug {
 #define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
 #define _DPRINTK_FLAGS_PREFIX_CACHED   (1<<7)
 
-#define _DPRINTK_FLAGS_INCL_ANY\
-   (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
-_DPRINTK_FLAGS_INCL_LINENO  | _DPRINTK_FLAGS_INCL_TID |\
+#define _DPRINTK_FLAGS_INCL_LOOKUP \
+   (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |   \
 _DPRINTK_FLAGS_INCL_SOURCENAME)
+#define _DPRINTK_FLAGS_INCL_ANY
\
+   (_DPRINTK_FLAGS_INCL_LINENO | _DPRINTK_FLAGS_INCL_TID | \
+_DPRINTK_FLAGS_INCL_LOOKUP)
 
 #if defined DEBUG
 #define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
-- 
2.41.0

[PATCH v7 21/25] dyndbg: refactor *dynamic_emit_prefix

Refactor the split of duties between outer & inner fns.

The outer fn was previously just an inline unlikely forward to inner,
which did all the work.

Now, outer handles +t and +l flags itself, and calls inner only when
_DPRINTK_FLAGS_INCL_LOOKUP is needed.

No functional change.

But it does make the results of the inner-fn more cache-friendly
(fewer entries, reused more often):

1- no spurious [TID] or  noise
2- no LINE-number to bloat the cache (avg 9 pr_debugs/fn)
3- only LOOKUP stuff

Currently LOOKUPs are descriptor-field refs but could be replaced by
accessor functions.  This would allow the __dyndbg_sites section to be
de-duplicated and reclaimed; currently module, filename fields are
~90% repeated.  As the accessors get more expensive, the value of
caching part of the prefix goes up.

Also change inner-fn to return count of extra chars written to the
buffer, and drop "inline" from outer, let the compiler decide.  Maybe
also change name accordingly.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 55 -
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 17eefb35ac96..974395bf8a83 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -777,19 +777,8 @@ static int remaining(int wrote)
return 0;
 }
 
-static char *__dynamic_emit_prefix(const struct _ddebug *desc, char *buf)
+static int __dynamic_emit_prefix(const struct _ddebug *desc, char *buf, int 
pos)
 {
-   int pos_after_tid;
-   int pos = 0;
-
-   if (desc->flags & _DPRINTK_FLAGS_INCL_TID) {
-   if (in_interrupt())
-   pos += snprintf(buf + pos, remaining(pos), " ");
-   else
-   pos += snprintf(buf + pos, remaining(pos), "[%d] ",
-   task_pid_vnr(current));
-   }
-   pos_after_tid = pos;
if (desc->flags & _DPRINTK_FLAGS_INCL_MODNAME)
pos += snprintf(buf + pos, remaining(pos), "%s:",
desc->modname);
@@ -799,22 +788,38 @@ static char *__dynamic_emit_prefix(const struct _ddebug 
*desc, char *buf)
if (desc->flags & _DPRINTK_FLAGS_INCL_SOURCENAME)
pos += snprintf(buf + pos, remaining(pos), "%s:",
trim_prefix(desc->filename));
-   if (desc->flags & _DPRINTK_FLAGS_INCL_LINENO)
-   pos += snprintf(buf + pos, remaining(pos), "%d:",
-   desc->lineno);
-   if (pos - pos_after_tid)
-   pos += snprintf(buf + pos, remaining(pos), " ");
-   if (pos >= PREFIX_SIZE)
-   buf[PREFIX_SIZE - 1] = '\0';
-
-   return buf;
+   return pos;
 }
 
-static inline char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
+static char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
 {
-   if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_ANY))
-   return __dynamic_emit_prefix(desc, buf);
-   return buf;
+int pos_after_tid;
+int pos = 0;
+
+if (likely(!(desc->flags & _DPRINTK_FLAGS_INCL_ANY)))
+return buf;
+
+if (desc->flags & _DPRINTK_FLAGS_INCL_TID) {
+if (in_interrupt())
+pos += snprintf(buf + pos, remaining(pos), " ");
+else
+pos += snprintf(buf + pos, remaining(pos), "[%d] ",
+task_pid_vnr(current));
+}
+pos_after_tid = pos;
+
+if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_LOOKUP))
+pos += __dynamic_emit_prefix(desc, buf, pos);
+
+if (desc->flags & _DPRINTK_FLAGS_INCL_LINENO)
+pos += snprintf(buf + pos, remaining(pos), "%d:",
+desc->lineno);
+if (pos - pos_after_tid)
+pos += snprintf(buf + pos, remaining(pos), " ");
+if (pos >= PREFIX_SIZE)
+buf[PREFIX_SIZE - 1] = '\0';
+
+return buf;
 }
 
 void __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
-- 
2.41.0

[PATCH v7 16/25] dyndbg: refactor ddebug_classparam_clamp_input

Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former.  It takes kernel-param arg, so it can complain
about "foo: bad input".

Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to validate inputs from parent's params, just like our own.
To support that reuse, alter ddebug_sync_classbits() and caller to
pass kp instead of kp->arg.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 70 ++---
 1 file changed, 47 insertions(+), 23 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index c11feca70d6f..17eefb35ac96 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -656,6 +656,30 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
 
 #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
 
+static void ddebug_class_param_clamp_input(unsigned long *inrep, const struct 
kernel_param *kp)
+{
+   const struct ddebug_class_param *dcp = kp->arg;
+   const struct ddebug_class_map *map = dcp->map;
+
+   switch (map->map_type) {
+   case DD_CLASS_TYPE_DISJOINT_BITS:
+   /* expect bits. mask and warn if too many */
+   if (*inrep & ~CLASSMAP_BITMASK(map->length)) {
+   pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, 
masking\n",
+   KP_NAME(kp), *inrep, 
CLASSMAP_BITMASK(map->length));
+   *inrep &= CLASSMAP_BITMASK(map->length);
+   }
+   break;
+   case DD_CLASS_TYPE_LEVEL_NUM:
+   /* input is bitpos, of highest verbosity to be enabled */
+   if (*inrep > map->length) {
+   pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
+   KP_NAME(kp), *inrep, map->length);
+   *inrep = map->length;
+   }
+   break;
+   }
+}
 static int param_set_dyndbg_module_classes(const char *instr,
   const struct kernel_param *kp,
   const char *modnm)
@@ -674,26 +698,15 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
pr_err("expecting numeric input, not: %s > %s\n", instr, 
KP_NAME(kp));
return -EINVAL;
}
+   ddebug_class_param_clamp_input(&inrep, kp);
 
switch (map->map_type) {
case DD_CLASS_TYPE_DISJOINT_BITS:
-   /* expect bits. mask and warn if too many */
-   if (inrep & ~CLASSMAP_BITMASK(map->length)) {
-   pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx, 
masking\n",
-   KP_NAME(kp), inrep, 
CLASSMAP_BITMASK(map->length));
-   inrep &= CLASSMAP_BITMASK(map->length);
-   }
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
totct += ddebug_apply_class_bitmap(dcp, &inrep, *dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
-   /* input is bitpos, of highest verbosity to be enabled */
-   if (inrep > map->length) {
-   pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
-   KP_NAME(kp), inrep, map->length);
-   inrep = map->length;
-   }
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
@@ -1160,16 +1173,27 @@ static const char * const ddebug_classmap_typenames[] = 
{
  ddebug_classmap_typenames[_cm->map_type]);\
})
 
-static void ddebug_sync_classbits(const struct ddebug_class_param *dcp, const 
char *modname)
+static void ddebug_sync_classbits(const struct kernel_param *kp, const char 
*modname)
 {
-   /* clamp initial bitvec, mask off hi-bits */
-   if (*dcp->bits & ~CLASSMAP_BITMASK(dcp->map->length)) {
-   *dcp->bits &= CLASSMAP_BITMASK(dcp->map->length);
-   v2pr_info("preset classbits: %lx\n", *dcp->bits);
+   struct ddebug_class_param *dcp = kp->arg;
+   unsigned long new_bits;
+
+   ddebug_class_param_clamp_input(dcp->bits, kp);
+
+   switch (dcp->map->map_type) {
+   case DD_CLASS_TYPE_DISJOINT_BITS:
+   v2pr_info("  %s: classbits: 0x%lx\n", KP_NAME(kp), *dcp->bits);
+   ddebug_apply_class_bitmap(dcp, dcp->bits, 0UL, modname);
+   break;
+   case DD_CLASS_TYPE_LEVEL_NUM:
+   new_bits = CLASSMAP_BITMASK(*dcp->lvl);
+   v2pr_info("  %s: lvl:%ld bits:0x%lx\n", KP_NAME(kp), *dcp->lvl, 
new_bits);
+   ddebug_apply_class_bitmap(dcp, &new_bits, 0UL, modname);
+   break;
+   default:
+

[PATCH v7 18/25] dyndbg-doc: add classmap info to howto

Add some basic info on classmap usage and api

Signed-off-by: Jim Cromie 
---
v5- adjustments per Randy Dunlap, me
---
 .../admin-guide/dynamic-debug-howto.rst   | 59 ++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst 
b/Documentation/admin-guide/dynamic-debug-howto.rst
index 0b3d39c610d9..d8813dcc394a 100644
--- a/Documentation/admin-guide/dynamic-debug-howto.rst
+++ b/Documentation/admin-guide/dynamic-debug-howto.rst
@@ -225,7 +225,6 @@ the ``p`` flag has meaning, other flags are ignored.
 Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification.
 To clear all flags at once, use ``=_`` or ``-fslmpt``.
 
-
 Debug messages during Boot Process
 ==
 
@@ -375,3 +374,61 @@ just a shortcut for ``print_hex_dump(KERN_DEBUG)``.
 For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is
 its ``prefix_str`` argument, if it is constant string; or ``hexdump``
 in case ``prefix_str`` is built dynamically.
+
+Dynamic Debug classmaps
+===
+
+Dyndbg allows selection/grouping of *prdbg* callsites using structural
+info: module, file, function, line.  Classmaps allow authors to add
+their own domain-oriented groupings using class-names.  Classmaps are
+exported, so they referencable from other modules.
+
+  # enable classes individually
+  :#> ddcmd class DRM_UT_CORE +p
+  :#> ddcmd class DRM_UT_KMS +p
+  # or more selectively
+  :#> ddcmd class DRM_UT_CORE module drm +p
+
+The "class FOO" syntax protects class'd prdbgs from generic overwrite::
+
+  # IOW this doesn't wipe any DRM.debug settings
+  :#> ddcmd -p
+
+To support the DRM.debug parameter, DYNDBG_CLASSMAP_PARAM* updates all
+classes in a classmap, mapping param-bits 0..N onto the classes:
+DRM_UT_<*> for the DRM use-case.
+
+Dynamic Debug Classmap API
+==
+
+DYNDBG_CLASSMAP_DEFINE - modules use this to create classmaps, naming
+each of the classes (stringified enum-symbols: "DRM_UT_<*>"), and
+type, and mapping the class-names to consecutive _class_ids.
+
+By doing so, modules tell dyndbg that they are have prdbgs with those
+class_ids, and they authorize dyndbg to accept "class FOO" for module
+defining that classname.
+
+There are 2 types of classmaps:
+
+ DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, like DRM.debug
+ DD_CLASS_TYPE_LEVEL_NUM: classes are relative, ordered (V3 > V2)
+
+DYNDBG_CLASSMAP_PARAM - refers to a DEFINEd classmap, exposing the set
+of defined classes to manipulation as a group.  This interface
+enforces the relatedness of classes of DD_CLASS_TYPE_LEVEL_NUM typed
+classmaps; all classes are independent in the >control parser itself.
+
+DYNDBG_CLASSMAP_USE - drm drivers invoke this to ref the the CLASSMAP
+that drm DEFINEs.  This shares the classmap definition, and authorizes
+dyndbg to apply changes to the using modules class'd pr_debugs.  It
+also tells dyndbg how to initialize the user's prdbgs at modprobe.
+
+Modules or module-groups (drm & drivers) can define multiple
+classmaps, as long as they share the limited 0..62 per-module-group
+_class_id range, without overlap.
+
+``#define DEBUG`` will enable all pr_debugs in scope, including any
+class'd ones.  This won't be reflected in the PARAM readback value,
+but the pr_debug callsites can be toggled into agreement with the
+param.
-- 
2.41.0

[PATCH v7 15/25] dyndbg: add for_each_boxed_vector

Add a for_each iterator to walk a counted vector member in a struct
(ie the box), and use it to replace 8 open-coded loops.

Signed-off-by: Jim Cromie 
---
v5- parens-on-box-force-precedence
---
 lib/dynamic_debug.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index be49e104ec76..c11feca70d6f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -158,6 +158,9 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  _dt->num_class_users);\
})
 
+#define for_each_boxed_vector(_box, _vec, _len, _ct, _curs)\
+   for (_ct = 0, _curs = (_box)->_vec; _ct < (_box)->_len; _ct++, _curs++)
+
 #define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
const char 
*class_string,
@@ -167,7 +170,7 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
struct ddebug_class_user *cli;
int i, idx;
 
-   for (i = 0, map = dt->classes; i < dt->num_classes; i++, map++) {
+   for_each_boxed_vector(dt, classes, num_classes, i, map) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -175,7 +178,7 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return map;
}
}
-   for (i = 0, cli = dt->class_users; i < dt->num_class_users; i++, cli++) 
{
+   for_each_boxed_vector(dt, class_users, num_class_users, i, cli) {
idx = match_string(cli->map->class_names, cli->map->length, 
class_string);
if (idx >= 0) {
*class_id = idx + cli->map->base;
@@ -1058,11 +1061,11 @@ static const char *ddebug_class_name(struct 
ddebug_table *dt, struct _ddebug *dp
struct ddebug_class_user *cli = dt->class_users;
int i;
 
-   for (i = 0; i < dt->num_classes; i++, map++)
+   for_each_boxed_vector(dt, classes, num_classes, i, map)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
-   for (i = 0; i < dt->num_class_users; i++, cli++)
+   for_each_boxed_vector(dt, class_users, num_class_users, i, cli)
if (class_in_range(dp->class_id, cli->map))
return cli->map->class_names[dp->class_id - 
cli->map->base];
 
@@ -1216,7 +1219,7 @@ static void ddebug_attach_module_classes(struct 
ddebug_table *dt, struct _ddebug
struct ddebug_class_map *cm;
int i, nc = 0;
 
-   for (i = 0, cm = di->classes; i < di->num_classes; i++, cm++) {
+   for_each_boxed_vector(di, classes, num_classes, i, cm) {
 
if (!strcmp(cm->mod_name, dt->mod_name)) {
vpr_cm_info(cm, "classes[%d]:", i);
@@ -1230,7 +1233,7 @@ static void ddebug_attach_module_classes(struct 
ddebug_table *dt, struct _ddebug
vpr_info("module:%s attached %d classes\n", dt->mod_name, nc);
dt->num_classes = nc;
 
-   for (i = 0, cm = dt->classes; i < dt->num_classes; i++, cm++)
+   for_each_boxed_vector(di, classes, num_classes, i, cm)
ddebug_apply_params(cm, cm->mod_name);
 }
 
@@ -1250,7 +1253,7 @@ static void ddebug_attach_user_module_classes(struct 
ddebug_table *dt,
 * module's refs, save to dt.  For loadables, this is the
 * whole array.
 */
-   for (i = 0, cli = di->class_users; i < di->num_class_users; i++, cli++) 
{
+   for_each_boxed_vector(di, class_users, num_class_users, i, cli) {
 
if (WARN_ON(!cli || !cli->map || !cli->user_mod_name))
continue;
@@ -1268,8 +1271,7 @@ static void ddebug_attach_user_module_classes(struct 
ddebug_table *dt,
 
dt->num_class_users = nc;
 
-   /* now iterate dt */
-   for (i = 0, cli = dt->class_users; i < dt->num_class_users; i++, cli++)
+   for_each_boxed_vector(di, class_users, num_class_users, i, cli)
ddebug_apply_params(cli->map, cli->user_mod_name);
 
vpr_dt_info(dt, "attach-client-module: ");
-- 
2.41.0

[PATCH v7 14/25] dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression

DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K&R
rule: "define once, refer many times".

When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together when DRM.debug
categories are enabled.

Worse, it causes the CONFIG_DRM_USE_DYNAMIC_DEBUG=Y regression; 1st
drm.ko loads, and dyndbg initializes its DRM.debug callsites, then a
drm-driver loads, but too late - it missed the DRM.debug enablement.

So replace it with 2 macros:
  DYNDBG_CLASSMAP_DEFINE - invoked once from core - drm.ko
  DYNDBG_CLASSMAP_USE- from all drm drivers and helpers.

DYNDBG_CLASSMAP_DEFINE: based on DECLARE_DYNDBG_CLASSMAP, but now it
drops the static on the constructed classmap variable, and exports it
instead.

DYNDBG_CLASSMAP_USE: then refers to the exported var by name:
* used from drivers, helper-mods
* lets us drop the repetitive "classname" args
* fixes 2nd-defn problem
* creates a ddebug_class_user record in new __dyndbg_class_users section
  this allows ddebug_add_module(etal) to handle them per-module.

The distinction, and the usage record, allows dyndbg to initialize the
driver's DRM.debug callsites separately after it is modprobed.

Since DRM now needs updates to use the new macros, it also gets 2
wrappers: DRM_CLASSMAP_DEFINE, DRM_CLASSMAP_USE which declutter the
users by hiding the ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG.

To review, dyndbg's existing __dyndbg_classes[] section does:

. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.
. DYNDBG_CLASSMAP_DEFINE(and old one) creates classmaps in this section.

This patch adds __dyndbg_class_users[] section:

. catalogs uses/references to the classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. DYNDBG_CLASSMAP_USE() creates classmap-user records in this section.

Now ddebug_add_module(etal) can handle classmap-uses like (and after)
classmaps; when a dependent module is loaded, its parent's kernel
params are scanned to find the param wired to dyndbg-param-ops, whose
classmap matches the one ref'd by the client.

To support this, theres a few data/header changes:

. new struct ddebug_class_user
  contains: user-module-name, &classmap-defn
  it records drm-driver's use of a classmap in the section, allowing lookup

struct ddebug_info gets 2 new fields to encapsulate the new section:
  class_users, num_class_users.
  set by dynamic_debug_init() for builtins.
  or by kernel/module/main:load_info() for loadable modules.

vmlinux.lds.h: new BOUNDED_SECTION for __dyndbg_class_users

dynamic_debug.c has 2 changes in ddebug_add_module(), ddebug_change():

ddebug_add_module() already calls ddebug_attach_module_classes()
to handle classmaps DEFINEd by a module, now it also calls
ddebug_attach_user_module_classes() to handle USEd classmaps.  To
avoid this work when possible, 1st scan the module's descriptors and
count the number of class'd pr_debugs.

ddebug_attach_user_module_classes() scans the module's class_users
section, follows the refs to the parent's classmap, and calls
ddebug_apply_params() on each.  It also avoids work by checking the
module's class-ct.

ddebug_apply_params(new fn):

It scans module's/builtin kernel-params, calls ddebug_match_apply_kparam
for each to find the params/sysfs-nodes which may be wired to a classmap.

ddebug_match_apply_kparam(new fn):

1st, it tests the kernel-param.ops is dyndbg's; this guarantees that
the attached arg is a struct ddebug_class_param, which has a ref to
the param's state, and to the classmap defining the param's handling.

2nd, it requires that the classmap ref'd by the kparam is the one
we're called for; modules can use many separate classmaps (as
test_dynamic_debug does).

Then apply the "parent" kparam's setting to the dependent module,
using ddebug_apply_class_bitmap().

ddebug_change(and callees) also gets adjustments:

ddebug_find_valid_class(): This does a search over the module's
classmaps, looking for the class FOO echo'd to >control.  So now it
searches over __dyndbg_class_users[] after __dyndbg_classes[].

ddebug_class_name(): return class-names for defined AND used classes.

test_dynamic_debug.c, test_dynamic_debug_submod.c:

This (already) demonstrates the 2 types of classmaps & sysfs-params,
following the 4-part recipe:

1. define an enum for the classmap: DRM.debug has DRM_UT_{CORE,KMS,...}
   multiple classes must share 0-62 classid space.
2. DYNDBG_CLASSMAP_DEFINE(.. DRM_UT_{CORE,KMS,...})
3. DYNDBG_CLASSMAP_PARAM* (classmap)
4. DYNDBG_CLASSMAP_USE()
   by _submod only, skipping 2,3

Move all the enum declarations together, to better explain how they
share the 0..62 class-id space available to a module (non-overlapping
subranges).

reorg macros 2,3 by name.  This gives a tabular format, making it easy
to see the pattern of repetition, and the points

[PATCH v7 17/25] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API

move macro from test-dynamic-debug.c into header, and refine it.

Distinguish the 2 use cases of DYNDBG_CLASSMAP_PARAM*

1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before

2.DYNDBG_CLASSMAP_PARAM
new user (test_dynamic_debug) doesn't need to share state,
decls a static long unsigned int to store the bitvec.

__DYNDBG_CLASSMAP_PARAM
   bottom layer - allocate,init a ddebug-class-param, module-param-cb.

Also clean up and improve comments in test-code, and add
MODULE_DESCRIPTIONs.

Signed-off-by: Jim Cromie 
---
v5b - parens-on-PARAM
---
 drivers/gpu/drm/drm_print.c |  8 ++---
 include/drm/drm_print.h |  6 ++--
 include/linux/dynamic_debug.h   | 37 -
 lib/test_dynamic_debug.c| 58 +
 lib/test_dynamic_debug_submod.c |  9 -
 5 files changed, 73 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index dabcfa0dd279..8f4b609353a5 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -69,12 +69,8 @@ DRM_CLASSMAP_DEFINE(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS,
"DRM_UT_DP",
"DRM_UT_DRMRES");
 
-static struct ddebug_class_param drm_debug_bitmap = {
-   .bits = &__drm_debug,
-   .flags = "p",
-   .map = &drm_debug_classes,
-};
-module_param_cb(debug, ¶m_ops_dyndbg_classes, &drm_debug_bitmap, 0600);
+DRM_CLASSMAP_PARAM_REF(debug, __drm_debug, drm_debug_classes, p);
+
 #endif
 
 void __drm_puts_coredump(struct drm_printer *p, const char *str)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 706afc97c79c..94d4f5500030 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -322,11 +322,13 @@ enum drm_debug_category {
 };
 
 #ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
-#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
-#define DRM_CLASSMAP_USE(name)   DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_DEFINE(...)   DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
+#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)DYNDBG_CLASSMAP_PARAM_REF(__VA_ARGS__)
 #else
 #define DRM_CLASSMAP_DEFINE(...)
 #define DRM_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)
 #endif
 
 static inline bool drm_debug_enabled_raw(enum drm_debug_category category)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 1b027be2cdc4..f182f95caabb 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -91,7 +91,7 @@ struct ddebug_class_map {
  * used to validate a "class FOO .." >control command on the module
  */
 #define DYNDBG_CLASSMAP_DEFINE(_var, _maptype, _base, ...) \
-   const char *_var##_classnames[] = { __VA_ARGS__ };  \
+   static const char *_var##_classnames[] = { __VA_ARGS__ };   \
struct ddebug_class_map __aligned(8) __used \
__section("__dyndbg_classes") _var = {  \
.mod = THIS_MODULE, \
@@ -145,6 +145,41 @@ struct ddebug_class_param {
const struct ddebug_class_map *map;
 };
 
+/**
+ * DYNDBG_CLASSMAP_PARAM - wrap a dyndbg-classmap with a controlling sys-param
+ * @_name  sysfs node name
+ * @_var   name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classes defined by the
+ * classmap.  Keeps bits in a private/static
+ */
+#define DYNDBG_CLASSMAP_PARAM(_name, _var, _flags) \
+   static unsigned long _name##_bvec;  \
+   __DYNDBG_CLASSMAP_PARAM(_name, _name##_bvec, _var, _flags)
+
+/**
+ * DYNDBG_CLASSMAP_PARAM_REF - wrap a dyndbg-classmap with a controlling 
sys-param
+ * @_name  sysfs node name
+ * @_bits  name of the module's unsigned long bit-vector, ex: __drm_debug
+ * @_var   name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classmap, keeping bitvec in user 
@_bits.
+ * This lets drm use __drm_debug elsewhere too.
+ */
+#define DYNDBG_CLASSMAP_PARAM_REF(_name, _bits, _var, _flags)  \
+   __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)
+
+#define __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)\
+   static struct ddebug_class_param _name##_##_flags = {   \
+   .bits = &(_bits),   \
+   .flags = #_flags,   \
+   .map = &(_var), \
+   };  \
+   module_param_cb(_name, ¶m_ops_dyndbg_classes,

[PATCH v7 13/25] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code

Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:

  echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names

The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things for now.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  19 ++-
 lib/dynamic_debug.c   | 103 +++---
 lib/test_dynamic_debug.c  |  12 
 3 files changed, 12 insertions(+), 122 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 8116d0a0d33a..8eaf8eabdc8d 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -61,24 +61,13 @@ struct _ddebug {
 enum class_map_type {
DD_CLASS_TYPE_DISJOINT_BITS,
/**
-* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, one per bit.
-* expecting hex input. Built for drm.debug, basis for other types.
+* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, mapped to 
bits[0..N].
+* Expects hex input. Built for drm.debug, basis for other types.
 */
DD_CLASS_TYPE_LEVEL_NUM,
/**
-* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N.
-* N turns on just bits N-1 .. 0, so N=0 turns all bits off.
-*/
-   DD_CLASS_TYPE_DISJOINT_NAMES,
-   /**
-* DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* classes are independent, like _DISJOINT_BITS.
-*/
-   DD_CLASS_TYPE_LEVEL_NAMES,
-   /**
-* DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* intended for names like: INFO,DEBUG,TRACE, with a module prefix
-* avoid EMERG,ALERT,CRIT,ERR,WARNING: they're not debug
+* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0..N.
+* Input N turns on bits 0..N-1
 */
 };
 
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 45870a699507..91c8b67fd8f8 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -632,77 +632,6 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
 
 #define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
 
-/* accept comma-separated-list of [+-] classnames */
-static int param_set_dyndbg_classnames(const char *instr, const struct 
kernel_param *kp)
-{
-   const struct ddebug_class_param *dcp = kp->arg;
-   const struct ddebug_class_map *map = dcp->map;
-   unsigned long curr_bits, old_bits;
-   char *cl_str, *p, *tmp;
-   int cls_id, totct = 0;
-   bool wanted;
-
-   cl_str = tmp = kstrdup(instr, GFP_KERNEL);
-   p = strchr(cl_str, '\n');
-   if (p)
-   *p = '\0';
-
-   /* start with previously set state-bits, then modify */
-   curr_bits = old_bits = *dcp->bits;
-   vpr_info("\"%s\" > %s:0x%lx\n", cl_str, KP_NAME(kp), curr_bits);
-
-   for (; cl_str; cl_str = p) {
-   p = strchr(cl_str, ',');
-   if (p)
-   *p++ = '\0';
-
-   if (*cl_str == '-') {
-   wanted = false;
-   cl_str++;
-   } else {
-   wanted = true;
-   if (*cl_str == '+')
-   cl_str++;
-   }
-   cls_id = match_string(map->class_names, map->length, cl_str);
-   if (cls_id < 0) {
-   pr_err("%s unknown to %s\n", cl_str, KP_NAME(kp));
-   continue;
-   }
-
-   /* have one or more valid class_ids of one *_NAMES type */
-   switch (map->map_type) {
-   case DD_CLASS_TYPE_DISJOINT_NAMES:
-   /* the +/- pertains to a single bit */
-   if (test_bit(cls_id, &curr_bits) == wanted) {
-   v3pr_info("no change on %s\n", cl_str);
-   continue;
-   }
-   curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
*dcp->bits, NULL);
-   *dcp->bits = curr_bits;
-   v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
- map->class_names[cls_id]);
-   break;
-   case DD_CLASS_TYPE_LEVEL_NAMES:
-   /* cls_id = N in 0..max. wanted +/- determines N or N-1 
*/
-   old_bits = CLASSMAP_BITMASK(*dcp->lvl);
-   curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
-
-   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
old_bits, NULL);
-   *dcp->lvl = (cls_id + (wanted ? 1 : 0));
-   v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
- map->class

[PATCH v7 12/25] dyndbg: reduce verbose=3 messages in ddebug_add_module

The fn currently says "add-module", then "skipping" if the module has
no prdbgs.  Just check 1st and return quietly.

no functional change

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8beb98a831f5..45870a699507 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1242,11 +1242,10 @@ static int ddebug_add_module(struct _ddebug_info *di, 
const char *modname)
 {
struct ddebug_table *dt;
 
-   v3pr_info("add-module: %s.%d sites\n", modname, di->num_descs);
-   if (!di->num_descs) {
-   v3pr_info(" skip %s\n", modname);
+   if (!di->num_descs)
return 0;
-   }
+
+   v3pr_info("add-module: %s %d sites\n", modname, di->num_descs);
 
dt = kzalloc(sizeof(*dt), GFP_KERNEL);
if (dt == NULL) {
-- 
2.41.0

[PATCH v7 11/25] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap

old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn.  Disallow this.
And constify new_bits while here.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8158943b350d..8beb98a831f5 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -593,7 +593,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new class-param setting */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits,
+const unsigned long *new_bits,
+const unsigned long old_bits,
 const char *query_modname)
 {
 #define QUERY_SIZE 128
@@ -602,12 +603,12 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   if (*new_bits != *old_bits)
+   if (*new_bits != old_bits)
v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
 
for (bi = 0; bi < map->length; bi++) {
-   if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
+   if (test_bit(bi, new_bits) == test_bit(bi, &old_bits))
continue;
 
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
@@ -619,9 +620,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
-   if (*new_bits != *old_bits)
+   if (*new_bits != old_bits)
v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
 
return matches;
 }
@@ -678,7 +679,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
dcp->bits, NULL);
+   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
*dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -688,7 +689,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
&old_bits, NULL);
+   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
old_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -742,7 +743,7 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, &inrep, dcp->bits, 
modnm);
+   totct += ddebug_apply_class_bitmap(dcp, &inrep, *dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -755,7 +756,7 @@ static int param_set_dyndbg_module_classes(const char 
*instr,
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, &new_bits, &old_bits, 
modnm);
+   totct += ddebug_apply_class_bitmap(dcp, &new_bits, old_bits, 
modnm);
*dcp->lvl = inrep;
break;
default:
-- 
2.41.0

[PATCH v7 09/25] dyndbg: silence debugs with no-change updates

check for actual changes before announcing them, declutter logs.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b0e11f6bfaa2..b07aab422604 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -591,7 +591,7 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
return nfound;
 }
 
-/* apply a new bitmap to the sys-knob's current bit-state */
+/* apply a new class-param setting */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
 unsigned long *new_bits, unsigned long 
*old_bits,
 const char *query_modname)
@@ -602,8 +602,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
- query_modname ?: "");
+   if (*new_bits != *old_bits)
+   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
 
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,8 +619,9 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
-   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
- query_modname ?: "");
+   if (*new_bits != *old_bits)
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
 
return matches;
 }
-- 
2.41.0

[PATCH v7 10/25] dyndbg: tighten ddebug_class_name() 1st arg type

Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b07aab422604..8158943b350d 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1117,12 +1117,12 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 #define class_in_range(class_id, map)  \
(class_id >= map->base && class_id < map->base + map->length)
 
-static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
+static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map = iter->table->classes;
-   int i, nc = iter->table->num_classes;
+   struct ddebug_class_map *map = dt->classes;
+   int i;
 
-   for (i = 0; i < nc; i++, map++)
+   for (i = 0; i < dt->num_classes; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1156,7 +1156,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
seq_puts(m, "\"");
 
if (dp->class_id != _DPRINTK_CLASS_DFLT) {
-   class = ddebug_class_name(iter, dp);
+   class = ddebug_class_name(iter->table, dp);
if (class)
seq_printf(m, " class:%s", class);
else
-- 
2.41.0

[PATCH v7 07/25] dyndbg: drop NUM_TYPE_ARRAY

ARRAY_SIZE works here, since array decl is complete.

no functional change

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index b53217e4b711..8116d0a0d33a 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -106,11 +106,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base,  \
.map_type = _maptype,   \
-   .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+   .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames,   \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
 
 /* encapsulate linker provided built-in (or module) dyndbg data */
 struct _ddebug_info {
-- 
2.41.0

[PATCH v7 08/25] dyndbg: reduce verbose/debug clutter

currently, for verbose=3, these are logged (blank lines for clarity):

 dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
 dyndbg: split into words: "class" "DRM_UT_CORE" "+p"

 dyndbg: op='+'
 dyndbg: flags=0x1
 dyndbg: *flagsp=0x1 *maskp=0x

 dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 class=...
 dyndbg: no matches for query
 dyndbg: no-match: func="" file="" module="" format="" lineno=0-0 class=...
 dyndbg: processed 1 queries, with 0 matches, 0 errs

That is excessive, so this patch:
 - shrinks 3 lines of 2nd stanza to single line
 - drops 1st 2 lines of 3rd stanza
   3rd is like 1st, with result, not procedure.
   2nd is just status, retold in 4th, with more info.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b67c9b137447..b0e11f6bfaa2 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -266,9 +266,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(&ddebug_lock);
 
-   if (!nfound && verbose)
-   pr_info("no matches for query\n");
-
return nfound;
 }
 
@@ -497,7 +494,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
pr_err("bad flag-op %c, at start of %s\n", *str, str);
return -EINVAL;
}
-   v3pr_info("op='%c'\n", op);
 
for (; *str ; ++str) {
for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) {
@@ -511,7 +507,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
return -EINVAL;
}
}
-   v3pr_info("flags=0x%x\n", modifiers->flags);
 
/* calculate final flags, mask based upon op */
switch (op) {
@@ -527,7 +522,7 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
modifiers->flags = 0;
break;
}
-   v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags, 
modifiers->mask);
+   v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags, 
modifiers->mask);
 
return 0;
 }
@@ -537,7 +532,7 @@ static int ddebug_exec_query(char *query_string, const char 
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
 #define MAXWORDS 9
-   int nwords, nfound;
+   int nwords;
char *words[MAXWORDS];
 
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -555,10 +550,7 @@ static int ddebug_exec_query(char *query_string, const 
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
-   nfound = ddebug_change(&query, &modifiers);
-   vpr_info_dq(&query, nfound ? "applied" : "no-match");
-
-   return nfound;
+   return ddebug_change(&query, &modifiers);
 }
 
 /* handle multiple queries in query string, continue on error, return
-- 
2.41.0

[PATCH v7 05/25] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it

Add query_module param to ddebug_apply_class_bitmap().  This allows
its caller to update just one module, or all (as currently).  We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.

No functional change.

Signed-off-by: Jim Cromie 
---

after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.

bash-5.2# lsmod
Module  Size  Used by
i915 3133440  0
drm_buddy  20480  1 i915
ttm90112  1 i915
i2c_algo_bit   16384  1 i915
video  61440  1 i915
wmi32768  1 video
drm_display_helper200704  1 i915
drm_kms_helper208896  2 drm_display_helper,i915
drm   606208  5 
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344  2 drm_display_helper,i915
---
 lib/dynamic_debug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a3be2e7c8c84..ba41fdeaaf98 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -601,7 +601,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new bitmap to the sys-knob's current bit-state */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits)
+unsigned long *new_bits, unsigned long 
*old_bits,
+const char *query_modname)
 {
 #define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -609,7 +610,8 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
+   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
 
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,12 +620,15 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
 test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
 
-   ct = ddebug_exec_queries(query, NULL);
+   ct = ddebug_exec_queries(query, query_modname);
matches += ct;
 
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
+
return matches;
 }
 
@@ -679,7 +684,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -689,7 +694,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
&old_bits);
+   totct += ddebug_apply_class_bitmap(dcp, &curr_bits, 
&old_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -752,7 +757,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, &inrep, dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, &inrep, dcp->bits, 
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -765,7 +770,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, &new_bits, &old_bits);
+   totct += ddebug_apply_class_bi

[PATCH v7 04/25] dyndbg: replace classmap list with a vector

Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.

This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.

So this changes:

struct ddebug_class_map drops list-head link.

struct ddebug_table drops the list-head maps, and gets: classes &
num_classes for the start-addy and num_classes, placed to improve
struct packing.

The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.

The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.

Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.

no functional changes

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  1 -
 lib/dynamic_debug.c   | 61 ++-
 2 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 5231aaf361c4..b53217e4b711 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -83,7 +83,6 @@ enum class_map_type {
 };
 
 struct ddebug_class_map {
-   struct list_head link;
struct module *mod;
const char *mod_name;   /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b984ce338921..a3be2e7c8c84 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
 extern struct ddebug_class_map __stop___dyndbg_classes[];
 
 struct ddebug_table {
-   struct list_head link, maps;
+   struct list_head link;
const char *mod_name;
-   unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+   struct ddebug_class_map *classes;
+   unsigned int num_ddebugs, num_classes;
 };
 
 struct ddebug_query {
@@ -147,13 +148,15 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  query->first_lineno, query->last_lineno, query->class_string);
 }
 
+#define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
- const char 
*class_string, int *class_id)
+   const char 
*class_string,
+   __outvar int *class_id)
 {
struct ddebug_class_map *map;
-   int idx;
+   int i, idx;
 
-   list_for_each_entry(map, &dt->maps, link) {
+   for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -164,7 +167,6 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
 }
 
-#define __outvar /* filled by callee */
 /*
  * Search the tables for _ddebug's which match the given `query' and
  * apply the `flags' and `mask' to them.  Returns number of matching
@@ -,9 +1113,10 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 
 static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map;
+   struct ddebug_class_map *map = iter->table->classes;
+   int i, nc = iter->table->num_classes;
 
-   list_for_each_entry(map, &iter->table->maps, link)
+   for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1197,30 +1200,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
 };
 
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
 {
struct ddebug_class_map *cm;
-   int i, j, ct = 0;
+   int i, nc = 0;
 
-   for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+   /*
+* Find this module's classmaps in a subrange/wholerange of
+* the builtin/modular classmap vector/section.  Save the start
+* and length of the

[PATCH v7 06/25] dyndbg: split param_set_dyndbg_classes to module/wrapper fns

rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new.  New arg allows caller to specify that only one module
is affected by a prdbgs update.

Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope of changes
made.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ba41fdeaaf98..b67c9b137447 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -708,18 +708,9 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
return 0;
 }
 
-/**
- * param_set_dyndbg_classes - class FOO >control
- * @instr: string echo>d to sysfs, input depends on map_type
- * @kp:kp->arg has state: bits/lvl, map, map_type
- *
- * Enable/disable prdbgs by their class, as given in the arguments to
- * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
- * levels by bitpos.
- *
- * Returns: 0 or <0 if error.
- */
-int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+static int param_set_dyndbg_module_classes(const char *instr,
+  const struct kernel_param *kp,
+  const char *modnm)
 {
const struct ddebug_class_param *dcp = kp->arg;
const struct ddebug_class_map *map = dcp->map;
@@ -756,8 +747,8 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
KP_NAME(kp), inrep, 
CLASSMAP_BITMASK(map->length));
inrep &= CLASSMAP_BITMASK(map->length);
}
-   v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, &inrep, dcp->bits, 
NULL);
+   v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
+   totct += ddebug_apply_class_bitmap(dcp, &inrep, dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -770,7 +761,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, &new_bits, &old_bits, 
NULL);
+   totct += ddebug_apply_class_bitmap(dcp, &new_bits, &old_bits, 
modnm);
*dcp->lvl = inrep;
break;
default:
@@ -779,6 +770,22 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct);
return 0;
 }
+
+/**
+ * param_set_dyndbg_classes - class FOO >control
+ * @instr: string echo>d to sysfs, input depends on map_type
+ * @kp:kp->arg has state: bits/lvl, map, map_type
+ *
+ * Enable/disable prdbgs by their class, as given in the arguments to
+ * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
+ * levels by bitpos.
+ *
+ * Returns: 0 or <0 if error.
+ */
+int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+{
+   return param_set_dyndbg_module_classes(instr, kp, NULL);
+}
 EXPORT_SYMBOL(param_set_dyndbg_classes);
 
 /**
-- 
2.41.0

[PATCH v7 03/25] dyndbg: make ddebug_class_param union members same size

struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 2 +-
 lib/dynamic_debug.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 4fcbf4d4fd0a..5231aaf361c4 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -124,7 +124,7 @@ struct _ddebug_info {
 struct ddebug_class_param {
union {
unsigned long *bits;
-   unsigned int *lvl;
+   unsigned long *lvl;
};
char flags[8];
const struct ddebug_class_map *map;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ceb3067a5c83..b984ce338921 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -796,7 +796,7 @@ int param_get_dyndbg_classes(char *buffer, const struct 
kernel_param *kp)
 
case DD_CLASS_TYPE_LEVEL_NAMES:
case DD_CLASS_TYPE_LEVEL_NUM:
-   return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
+   return scnprintf(buffer, PAGE_SIZE, "%ld\n", *dcp->lvl);
default:
return -1;
}
-- 
2.41.0

[PATCH v7 02/25] dyndbg: reword "class unknown, " to "class:_UNKNOWN_"

This appears in the control-file to report an unknown class-name, which
indicates that the class_id is not authorized, and dyndbg will ignore
changes to it.  Generally, this means that a DYNDBG_CLASSMAP_DEFINE or
DYNDBG_CLASSMAP_USE is missing.

But the word "unknown" appears in quite a few prdbg formats, so thats
a suboptimal search term to find occurrences of the problem.  Thus
change it to "_UNKNOWN_" which properly shouts the condition.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 6fba6423cc10..ceb3067a5c83 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1151,7 +1151,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
if (class)
seq_printf(m, " class:%s", class);
else
-   seq_printf(m, " class unknown, _id:%d", dp->class_id);
+   seq_printf(m, " class:_UNKNOWN_ _id:%d", dp->class_id);
}
seq_puts(m, "\n");
 
-- 
2.41.0

[PATCH v7 01/25] test-dyndbg: fixup CLASSMAP usage error

more careful reading of test output reveals:

lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing 
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" 
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class 
unknown, _id:13

That last line is wrong, the HI class is declared.

But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param).  So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report.  I intentionally coded in an error, but
forgot to verify its detection and remove it.

RFC:

This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone.  As noted in test-mod comments:

 * Using the CLASSMAP api:
 * - classmaps must have corresponding enum
 * - enum symbols must match/correlate with class-name strings in the map.
 * - base must equal enum's 1st value
 * - multiple maps must set their base to share the 0-62 class_id space !!
 *   (build-bug-on tips welcome)

Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__.  Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.

[1] name changes later to DYNDBG_CLASSMAP_DEFINE

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
 DD_SYS_WRAP(disjoint_bits, T);
 
 /* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
 DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
 DD_SYS_WRAP(disjoint_names, p);
-- 
2.41.0

[PATCH v7 00/25] fix DRM_USE_DYNAMIC_DEBUG=y regression

hi Jason, DRM-folk

This patchest fixes the chicken-egg initialization problem in the 1st
version of ddebug-class-maps, that DRM-CI uncovered.

The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K&R rule:
"define once, refer many".  In patch 14 it is replaced by:

 DYNDBG_CLASSMAP_DEFINE - define and export a struct ddebug_class_map
 DYNDBG_CLASSMAP_USE - ref the exported struct

test-dynamic-debug is also extended with a -submod.ko, in order to
recapitulate the drm & drivers initialization scenario.

They're on v6.6-rc5 now, and apply cleanly to drm-tip/drm-tip.

Ive been running recent revs on rc3+, on my desktop and laptop.

The final blocker was a missing __align(8) on the ddebug_class_user
record inserted by DYNDBG_CLASSMAP_USE.  This caused DRM=y (builtin
only) to have a corrupt record for drm_kms_helper (builtin dependent).
Curiously, a clang build did not exhibit this problem.

Heres a part of dmesg, for a DRM=y kernel, booted with
 dynamic_debug.verbose=3 drm.debug=0x10

[0.466747] dyndbg: add-module: drm 406 sites
[0.467569] dyndbg: classes[0]: module:drm base:0 len:10 type:DISJOINT_BITS
[0.467743] dyndbg: module:drm attached 1 classes
[0.468557] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.468742] dyndbg:  found kp:drm.debug =0x10
[0.468743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.469742] dyndbg:   drm.debug: classbits: 0x10
[0.470573] dyndbg: apply bitmap: 0x10 to: 0x0 for drm
[0.470743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm
[0.471743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.472743] dyndbg: op='+' flags=0x1 maskp=0x
[0.473679] dyndbg: parsed: func="" file="" module="drm" format="" 
lineno=0-0 class=DRM_UT_ATOMIC
[0.473749] dyndbg: processed 1 queries, with 0 matches, 0 errs
[0.474742] dyndbg: bit_4: 0 matches on class: DRM_UT_ATOMIC -> 0x10
[0.475742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm
[0.476686] dyndbg: 406 debug prints in module drm
[0.476743] dyndbg: add-module: drm_kms_helper 93 sites
[0.477727] dyndbg: class_ref[0] drm_kms_helper -> drm module:drm base:0 
len:10 type:DISJOINT_BITS
[0.477743] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.478742] dyndbg:  found kp:drm.debug =0x10
[0.478743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.479743] dyndbg:   drm.debug: classbits: 0x10
[0.480592] dyndbg: apply bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.480743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm_kms_helper
[0.481743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.482743] dyndbg: op='+' flags=0x1 maskp=0x
[0.483743] dyndbg: parsed: func="" file="" module="drm_kms_helper" 
format="" lineno=0-0 class=DRM_UT_ATOMIC
[0.484750] dyndbg: class-ref: drm_kms_helper.DRM_UT_ATOMIC  
module:drm_kms_helper nd:93 nc:0 nu:1
[0.485809] dyndbg: processed 1 queries, with 44 matches, 0 errs
[0.486742] dyndbg: bit_4: 44 matches on class: DRM_UT_ATOMIC -> 0x10
[0.487742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.488743] dyndbg: attach-client-module:  module:drm_kms_helper nd:93 nc:0 
nu:1
[0.489742] dyndbg:  93 debug prints in module drm_kms_helper

Widespread testing is appreciated.
I have scripts if anyone wants them.

I'll forward lkp-robot reports here when I get them.

Jim Cromie (25):
  test-dyndbg: fixup CLASSMAP usage error
  dyndbg: reword "class unknown," to "class:_UNKNOWN_"
  dyndbg: make ddebug_class_param union members same size
  dyndbg: replace classmap list with a vector
  dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
  dyndbg: split param_set_dyndbg_classes to module/wrapper fns
  dyndbg: drop NUM_TYPE_ARRAY
  dyndbg: reduce verbose/debug clutter
  dyndbg: silence debugs with no-change updates
  dyndbg: tighten ddebug_class_name() 1st arg type
  dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
  dyndbg: reduce verbose=3 messages in ddebug_add_module
  dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
  dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression
  dyndbg: add for_each_boxed_vector
  dyndbg: refactor ddebug_classparam_clamp_input
  dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
  dyndbg-doc: add classmap info to howto
  dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED
  dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP
  dyndbg: refactor *dynamic_emit_prefix
  dyndbg: improve err report in attach_user_module_classes
  drm: use correct ccflags-y spelling
  drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
  drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

 .../admin-guide/dynamic-debug-howto.rst   |  59 ++-
 MAINTAINERS   |   2 +-
 drivers/gpu/drm/Kconfig   |   3 +-
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/amd/amdgpu

[PATCH v7 00/25] fix DRM_USE_DYNAMIC_DEBUG=y regression

hi Jason, DRM-folk

This patchest fixes the chicken-egg initialization problem in the 1st
version of ddebug-class-maps, that DRM-CI uncovered.

The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K&R rule:
"define once, refer many".  In patch 14 it is replaced by:

 DYNDBG_CLASSMAP_DEFINE - define and export a struct ddebug_class_map
 DYNDBG_CLASSMAP_USE - ref the exported struct

test-dynamic-debug is also extended with a -submod.ko, in order to
recapitulate the drm & drivers initialization scenario.

They're on v6.6-rc5 now, and apply cleanly to drm-tip/drm-tip.

Ive been running recent revs on rc3+, on my desktop and laptop.

The final blocker was a missing __align(8) on the ddebug_class_user
record inserted by DYNDBG_CLASSMAP_USE.  This caused DRM=y (builtin
only) to have a corrupt record for drm_kms_helper (builtin dependent).
Curiously, a clang build did not exhibit this problem.

Heres a part of dmesg, for a DRM=y kernel, booted with
 dynamic_debug.verbose=3 drm.debug=0x10

[0.466747] dyndbg: add-module: drm 406 sites
[0.467569] dyndbg: classes[0]: module:drm base:0 len:10 type:DISJOINT_BITS
[0.467743] dyndbg: module:drm attached 1 classes
[0.468557] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.468742] dyndbg:  found kp:drm.debug =0x10
[0.468743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.469742] dyndbg:   drm.debug: classbits: 0x10
[0.470573] dyndbg: apply bitmap: 0x10 to: 0x0 for drm
[0.470743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm
[0.471743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.472743] dyndbg: op='+' flags=0x1 maskp=0x
[0.473679] dyndbg: parsed: func="" file="" module="drm" format="" 
lineno=0-0 class=DRM_UT_ATOMIC
[0.473749] dyndbg: processed 1 queries, with 0 matches, 0 errs
[0.474742] dyndbg: bit_4: 0 matches on class: DRM_UT_ATOMIC -> 0x10
[0.475742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm
[0.476686] dyndbg: 406 debug prints in module drm
[0.476743] dyndbg: add-module: drm_kms_helper 93 sites
[0.477727] dyndbg: class_ref[0] drm_kms_helper -> drm module:drm base:0 
len:10 type:DISJOINT_BITS
[0.477743] dyndbg: builtin class: module:drm base:0 len:10 
type:DISJOINT_BITS
[0.478742] dyndbg:  found kp:drm.debug =0x10
[0.478743] dyndbg:   mapped to: module:drm base:0 len:10 type:DISJOINT_BITS
[0.479743] dyndbg:   drm.debug: classbits: 0x10
[0.480592] dyndbg: apply bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.480743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm_kms_helper
[0.481743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p"
[0.482743] dyndbg: op='+' flags=0x1 maskp=0x
[0.483743] dyndbg: parsed: func="" file="" module="drm_kms_helper" 
format="" lineno=0-0 class=DRM_UT_ATOMIC
[0.484750] dyndbg: class-ref: drm_kms_helper.DRM_UT_ATOMIC  
module:drm_kms_helper nd:93 nc:0 nu:1
[0.485809] dyndbg: processed 1 queries, with 44 matches, 0 errs
[0.486742] dyndbg: bit_4: 44 matches on class: DRM_UT_ATOMIC -> 0x10
[0.487742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm_kms_helper
[0.488743] dyndbg: attach-client-module:  module:drm_kms_helper nd:93 nc:0 
nu:1
[0.489742] dyndbg:  93 debug prints in module drm_kms_helper

Widespread testing is appreciated.
I have scripts if anyone wants them.

I'll forward lkp-robot reports here when I get them.

Jim Cromie (25):
  test-dyndbg: fixup CLASSMAP usage error
  dyndbg: reword "class unknown," to "class:_UNKNOWN_"
  dyndbg: make ddebug_class_param union members same size
  dyndbg: replace classmap list with a vector
  dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
  dyndbg: split param_set_dyndbg_classes to module/wrapper fns
  dyndbg: drop NUM_TYPE_ARRAY
  dyndbg: reduce verbose/debug clutter
  dyndbg: silence debugs with no-change updates
  dyndbg: tighten ddebug_class_name() 1st arg type
  dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
  dyndbg: reduce verbose=3 messages in ddebug_add_module
  dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
  dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression
  dyndbg: add for_each_boxed_vector
  dyndbg: refactor ddebug_classparam_clamp_input
  dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
  dyndbg-doc: add classmap info to howto
  dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED
  dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP
  dyndbg: refactor *dynamic_emit_prefix
  dyndbg: improve err report in attach_user_module_classes
  drm: use correct ccflags-y spelling
  drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
  drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

 .../admin-guide/dynamic-debug-howto.rst   |  59 ++-
 MAINTAINERS   |   2 +-
 drivers/gpu/drm/Kconfig   |   3 +-
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/amd/amdgpu

Re: [syzbot] upstream boot error: can't ssh into the instance (15)

2023-10-12 Thread Aleksandr Nogikh

For the record: the problems were solved by switching to qemu v8.

#syz invalid

On Fri, Sep 29, 2023 at 3:36 PM Aleksandr Nogikh  wrote:
>
>
> On Fri, Sep 29, 2023 at 3:29 PM syzbot 
>  wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:9ed22ae6be81 Merge tag 'spi-fix-v6.6-rc3' of git://git.ker..
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14b37a7c68
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=d4bdf71ec9aec6cc
> > dashboard link: https://syzkaller.appspot.com/bug?extid=be9661ba81a9c1cf6b15
> > compiler:   aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld 
> > (GNU Binutils for Debian) 2.40
> > userspace arch: arm64
> >
> > Downloadable assets:
> > disk image (non-bootable): 
> > https://storage.googleapis.com/syzbot-assets/384ffdcca292/non_bootable_disk-9ed22ae6.raw.xz
> > vmlinux: 
> > https://storage.googleapis.com/syzbot-assets/2c3d5eea45bd/vmlinux-9ed22ae6.xz
> > kernel image: 
> > https://storage.googleapis.com/syzbot-assets/5f361432/Image-9ed22ae6.gz.xz
>
> This appears on qemu-system-aarch64 with 
> virt,virtualization=on,mte=on,graphics=on,usb=on.
>
> I've run it locally using the assets above and it seems there are actually 
> two problems behind the report.
>
> 1) For some reason, v7.2 of qemu-system-aarch64 just hangs with "-smp 2" and 
> prints no output.
>
> Interestingly, it all works fine on qemu v8.0.4, so I don't know if it's a 
> qemu or a kernel problem.
> Qemu v8 is unfortunately still too new for many distributions (we use 
> debian:bookworm on syzbot
> and v7.2 is the latest there).
>
> 2) If I set "-smp 1", it begins to boot, but quickly fails with several 
> messages. First with
>
> [0.00][T0] 
> ==
> [0.00][T0] BUG: KASAN: slab-out-of-bounds in 
> __kasan_slab_alloc+0x7c/0xcc
> [0.00][T0] Read at addr fcff02c01008 by task swapper/0
> [0.00][T0] Pointer tag: [fc], memory tag: [f5]
> [0.00][T0]
> [0.00][T0] CPU: 0 PID: 0 Comm: swapper Not tainted 
> 6.6.0-rc3-syzkaller-00055-g9ed22ae6be81 #0
> [0.00][T0] Hardware name: linux,dummy-virt (DT)
> [0.00][T0] Call trace:
> [0.00][T0]  dump_backtrace+0x94/0xec
> [0.00][T0]  show_stack+0x18/0x24
> [0.00][T0]  dump_stack_lvl+0x48/0x60
> [0.00][T0]  print_report+0x108/0x618
> [0.00][T0]  kasan_report+0x88/0xac
> [0.00][T0]  __do_kernel_fault+0x17c/0x1e8
> [0.00][T0]  do_tag_check_fault+0x78/0x8c
> [0.00][T0]  do_mem_abort+0x44/0x94
> [0.00][T0]  el1_abort+0x40/0x60
> [0.00][T0]  el1h_64_sync_handler+0xd8/0xe4
> [0.00][T0]  el1h_64_sync+0x64/0x68
> [0.00][T0]  __kasan_slab_alloc+0x7c/0xcc
> [0.00][T0]  kmem_cache_alloc+0x144/0x290
> [0.00][T0]  bootstrap+0x2c/0x174
> [0.00][T0]  kmem_cache_init+0x144/0x1c8
> [0.00][T0]  mm_core_init+0x240/0x2d4
> [0.00][T0]  start_kernel+0x220/0x5fc
> [0.00][T0]  __primary_switched+0xb4/0xbc
> [0.00][T0]
> [0.00][T0] Allocated by task 0:
> [0.00][T0]  kasan_save_stack+0x3c/0x64
> [0.00][T0]  save_stack_info+0x38/0x118
> [0.00][T0]  kasan_save_alloc_info+0x14/0x20
> [0.00][T0]  __kasan_slab_alloc+0x94/0xcc
> [0.00][T0]  kmem_cache_alloc+0x144/0x290
> [0.00][T0]  bootstrap+0x2c/0x174
> [0.00][T0]  kmem_cache_init+0x134/0x1c8
> [0.00][T0]  mm_core_init+0x240/0x2d4
> [0.00][T0]  start_kernel+0x220/0x5fc
> [0.00][T0]  __primary_switched+0xb4/0xbc
> [0.00][T0]
> [0.00][T0] The buggy address belongs to the object at 
> 02c01000
> [0.00][T0]  which belongs to the cache kmem_cache of size 208
> [0.00][T0] The buggy address is located 8 bytes inside of
> [0.00][T0]  208-byte region [02c01000, 02c010d0)
> [0.00][T0]
> [0.00][T0] The buggy address belongs to the physical page:
> [0.00][T0] page:(ptrval) refcount:1 mapcount:0 
> mapping: index:0x0 pfn:0x42c01
> [0.00][T0] flags: 
> 0x1ffc800(slab|node=0|zone=0|lastcpupid=0x7ff|kasantag=0x0)
> [0.00][T0] page_type: 0x()
> [0.00][T0] raw: 01ffc800 fcff02c01000 
> dead0100 dead0122
> [0.00][T0] raw:  80100010 
> 0001 
> [0.00][T0] page dumped because: kasan: bad access detected
> [0.00][T0]
> [0.00][T0] Memory state around the buggy address:
> [0.00][T0]  02c00e00: f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 
>

Re: [PATCH] drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple

Hi,

On Sun, Oct 8, 2023 at 1:52 PM Anton Bambura  wrote:
>
>
> On 10/5/23 21:10, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Sep 26, 2023 at 7:01 AM Doug Anderson  wrote:
> >> Hi,
> >>
> >> On Tue, Sep 26, 2023 at 1:06 AM AngeloGioacchino Del Regno
> >>  wrote:
> >>> Il 26/09/23 00:00, Douglas Anderson ha scritto:
>  In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of
>  panel-simple") I moved a pile of panels out of panel-simple driver
>  into the newly created panel-edp driver. One of those panels, however,
>  shouldn't have been moved.
> 
>  As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO
>  B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in
>  exynos5250-snow and exynos5420-peach-pit where it's clear that the
>  panel is hooked up with LVDS. Furthermore, searching for datasheets I
>  found one that makes it clear that this panel is LVDS.
> 
>  As far as I can tell, I got confused because in commit 88d3457ceb82
>  ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao
>  Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the
>  downstream ChromeOS trees, it seems like some Mediatek boards are
>  using a panel that they call "auo,b116xw03" that's an eDP panel. The
>  best I can guess is that they actually have a different panel that has
>  similar timing. If so then the proper panel should be used or they
>  should switch to the generic "edp-panel" compatible.
> 
>  When moving this back to panel-edp, I wasn't sure what to use for
>  .bus_flags and .bus_format and whether to add the extra "enable" delay
>  from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash
>  backlight when power on"). I've added formats/flags/delays based on my
>  (inexpert) analysis of the datasheet. These are untested.
> 
>  NOTE: if/when this is backported to stable, we might run into some
>  trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183:
>  jacuzzi: Move panel under aux-bus") this panel was used by
>  "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't
>  know what to suggest for that other than someone making up a bogus
>  panel for jacuzzi that's just for the stable channel.
> 
>  Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when 
>  power on")
>  Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of 
>  panel-simple")
>  Signed-off-by: Douglas Anderson 
>  ---
>  I haven't had a snow or peach-pit hooked up for debugging / testing
>  for years. I presume that they must be broken and hope that this fixes
>  them.
> >>> We could avoid backport breakages by avoiding to backport this to any 
> >>> kernel
> >>> that doesn't contain commit 474c162878ba ("arm64: dts: mt8183: jacuzzi: 
> >>> Move
> >>> panel under aux-bus")... because creating a dummy panel to get two wrongs
> >>> right is definitely not ok.
> >> Sure, except that leaves us with ... a breakage. :-P
> >>
> >> Although I haven't tested it, I have a hard time believing that
> >> exynos5250-snow and exynos5420-peach-pit will work properly with the
> >> panel defined as an eDP panel. That means that they will be broken. If
> >> someone cared to get those fixed in a stable backport then we'd be
> >> stuck deciding who to break. If you have any brilliant ideas then I'm
> >> all ears.
> >>
> >> ...then again, I presume this has been broken since commit
> >> 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power
> >> on"). That was a little over 3 years ago. Maybe I'm wrong and somehow
> >> things still limp along and sorta work even though the panel is
> >> defined incorrectly?
> > I dug out a exynos5250-snow out of my pile and booted postmarket OS on
> > it, which was shockingly easy/pleasant (kudos to those involved!). I
> > found that it was booting a kernel based on 6.1.24. Digging into
> > sysfs, I found that indeed it appeared to be using the "panel-edp"
> > driver, so I guess it is limping along with the wrong driver and wrong
> > flags...
> >
> > It wasn't totally clear for me how to build a new kernel and deploy it
> > for postmarket OS, so I wasn't able to confirm this change. I've CCed
> > the person listed on the postmarket OS wiki though to see if they have
> > any insight.
> Tested it on peach-pit using linux-next with this patch applied. Panel
> still works and "dmesg | grep panel" returns panel_simple instead of
> panel_edp.
>
> Tested-by: Anton Bambura 

Pushed to drm-misc-fixes:

ad3e33fe071d drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple

-Doug

Re: [PATCH] drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device

Hi,

On Thu, Oct 5, 2023 at 10:18 AM Stephen Boyd  wrote:
>
> Quoting Doug Anderson (2023-10-02 17:31:41)
> > Hi,
> >
> > On Mon, Oct 2, 2023 at 4:54 PM Stephen Boyd  wrote:
> > >
> > > The kernel produces a warning splat and the DSI device fails to register
> > > in this driver if the i2c driver probes, populates child auxiliary
> > > devices, and then somewhere in ti_sn_bridge_probe() a function call
> > > returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi
> > > device created by devm_mipi_dsi_device_register_full() is left
> > > registered because the devm managed device used to manage the lifetime
> > > of the DSI device is the parent i2c device, not the auxiliary device
> > > that is being probed.
> > >
> > > Associate the DSI device created and managed by this driver to the
> > > lifetime of the auxiliary device, not the i2c device, so that the DSI
> > > device is removed when the auxiliary driver unbinds. Similarly change
> > > the device pointer used for dev_err_probe() so the deferred probe errors
> > > are associated with the auxiliary device instead of the parent i2c
> > > device so we can narrow down future problems faster.
> > >
> > > Cc: Douglas Anderson 
> > > Cc: Maxime Ripard 
> > > Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI 
> > > device at probe")
> >
> > Even before that commit I think it was using the main "dev" instead of
> > the auxiliary device's "dev" for some "devm" stuff. I guess the
> > difference is that it wouldn't mess with probe deferral? Searching
> > back, I think the first instance of a case that was using "devm_" with
> > the wrong device was commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86:
> > Wrap panel with panel-bridge")? Would it make sense to use that as a
> > Fixes, you think?
>
> The problem for me is that the dsi device is registered twice. That
> happens because probe for the auxiliary device happens twice. I was
> cautious about the fixes tag here because it didn't look like probe
> deferral was happening before commit c3b75d4734cb.
>
> >
> > In any case, this looks reasonable to me:
> >
> > Reviewed-by: Douglas Anderson 
> >
> > I'll give it a week and then apply to "-fixes" if everything is quiet.
>
> Thanks!

Pushed to drm-misc-fixes leaving your existing "Fixes" line:

7b821db95140 drm/bridge: ti-sn65dsi86: Associate DSI device lifetime
with auxiliary device

-Doug

Re: [PATCH] drm/radeon: fix a possible null pointer dereference

2023-10-12 Thread Alex Deucher

On Tue, Oct 10, 2023 at 9:32 PM Ma Ke  wrote:
>
> In radeon_tv_get_modes(), the return value of drm_cvt_mode()
> is assigned to mode, which will lead to a NULL pointer
> dereference on failure of drm_cvt_mode(). Add a check to
> avoid null point dereference.
>
> Signed-off-by: Ma Ke 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_connectors.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index d2f02c3dfce2..b84b58926106 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -1119,6 +1119,8 @@ static int radeon_tv_get_modes(struct drm_connector 
> *connector)
> else {
> /* only 800x600 is supported right now on pre-avivo chips */
> tv_mode = drm_cvt_mode(dev, 800, 600, 60, false, false, 
> false);
> +   if (!tv_mode)
> +   return 0;
> tv_mode->type = DRM_MODE_TYPE_DRIVER | 
> DRM_MODE_TYPE_PREFERRED;
> drm_mode_probed_add(connector, tv_mode);
> }
> --
> 2.37.2
>

Re: linux-next: Tree for Oct 12 (drivers/gpu/drm/msm/adreno/a6xx_gmu.o)

2023-10-12 Thread Randy Dunlap



On 10/11/23 22:43, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20231011:
> 

on powerpc 64BIT:

powerpc64-linux-ld: drivers/gpu/drm/msm/adreno/a6xx_gmu.o: in function 
`a6xx_gmu_resume':
a6xx_gmu.c:(.text+0x6afc): undefined reference to `qmp_send'
powerpc64-linux-ld: drivers/gpu/drm/msm/adreno/a6xx_gmu.o: in function 
`a6xx_gmu_init':
a6xx_gmu.c:(.text+0x8088): undefined reference to `qmp_get'


Full randconfig file is attached.

-- 
~Randy

config-r8758.gz
Description: application/gzip

Re: [PATCH v3 3/6] dt-bindings: display: msm: Add SDM670 MDSS

2023-10-12 Thread Rob Herring



On Mon, 09 Oct 2023 19:33:41 -0400, Richard Acayan wrote:
> Add documentation for the SDM670 display subsystem, adapted from the
> SDM845 and SM6125 documentation.
> 
> Signed-off-by: Richard Acayan 
> ---
>  .../display/msm/qcom,sdm670-mdss.yaml | 292 ++
>  1 file changed, 292 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/msm/qcom,sdm670-mdss.yaml
> 

Reviewed-by: Rob Herring

Re: [v3 2/3] drm/panel: ili9882t: Avoid blurred screen from fast sleep