Re: [Freedreno] [v2] drm/msm/disp/dpu1: set default group ID for CTL.

2021-10-29 Thread Stephen Boyd
Quoting Kalyan Thota (2021-10-29 05:30:19)
> New required programming in CTL for SC7280. Group ID informs
> HW of which VM owns that CTL. Force this group ID to
> default/disabled until virtualization support is enabled in SW.
>
> Changes in v1:
>  - Fix documentation and add descritpion for the change (Stephen)
>
> Signed-off-by: Kalyan Thota 
> ---

Reviewed-by: Stephen Boyd 


Re: [Freedreno] [PATCH v3 6/6] drm/msm/dp: Remove the hpd init delay for eDP

2021-10-29 Thread khsieh

On 2021-10-27 23:38, Stephen Boyd wrote:

Quoting Sankeerth Billakanti (2021-10-27 18:54:48)

DP driver needs a 10 second delay before phy_init so that
the usb combo phy initializes and sets up the necessary
clocks for usb devices such as keyboard and mouse.

eDP controller uses a standalone phy and need not wait for
phy initialization from any other component. This change
will remove the delay for eDP controller.

Signed-off-by: Sankeerth Billakanti 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c

index 61385d6..de6a1fd 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1438,7 +1439,15 @@ void msm_dp_irq_postinstall(struct msm_dp 
*dp_display)


dp_hpd_event_setup(dp);

-   dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
+   if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_eDP) {
+   /* eDP does not need any delay before phy init */
+   delay = 0;
+   } else {
+   /* DP needs 10 second delay to let usb combo phy 
initialize */


This seems to be a different approach to the patch Kuogee sent a week 
or

two ago. Can we figure out what's wrong with the DP phy starting before
the USB phy? I suppose this patch is OK as a temporary hack to keep
moving with eDP, but we really need to figure out what's wrong with DP
so this delay can be removed entirely. Has any progress been made on
that?


Sankeerth,
Can you drop this patch for now.
Let's discuss more.


+   delay = 100;
+   }
+
+   dp_add_event(dp, EV_HPD_INIT_SETUP, 0, delay);


Re: [Freedreno] [PATCH v3 12/14] dt-bindings: msm/dp: Add bindings for HDCP registers

2021-10-29 Thread Sean Paul
On Mon, Oct 04, 2021 at 02:58:41PM -0500, Bjorn Andersson wrote:
> On Fri 01 Oct 10:11 CDT 2021, Sean Paul wrote:
> 
> > From: Sean Paul 
> > 
> > This patch adds the bindings for the MSM DisplayPort HDCP registers
> > which are required to write the HDCP key into the display controller as
> > well as the registers to enable HDCP authentication/key
> > exchange/encryption.
> > 
> > We'll use a new compatible string for this since the fields are optional.
> > 
> 
> I don't think you need a new compatible, in particular since I presume
> we should use the hdcp compatible in all platforms? Or is there a reason
> for not picking that one?
> 
> Instead I suggest that you simply do minItems: 1, maxItems: 3 and detect
> which of the two cases you have in the driver.

Thanks for your review, Bjorn! I had done this in v2 (see [1] & [2]), but it was
suggested that a new compatible would be better. I'll change it back to this
method rebased on top of your changes.

Sean

[1]- https://patchwork.freedesktop.org/patch/454066/?series=94712=1
[2]- https://patchwork.freedesktop.org/patch/454068/?series=94712=1


> 
> PS. I hope to get
> https://lore.kernel.org/linux-arm-msm/20211001174400.981707-1-bjorn.anders...@linaro.org/
> landed before we add these new optional regions...
> 
> Regards,
> Bjorn
> 
> > Cc: Rob Herring 
> > Cc: Stephen Boyd 
> > Signed-off-by: Sean Paul 
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-13-s...@poorly.run
> >  #v1
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-13-s...@poorly.run
> >  #v2
> > 
> > Changes in v2:
> > -Drop register range names (Stephen)
> > -Fix yaml errors (Rob)
> > Changes in v3:
> > -Add new compatible string for dp-hdcp
> > -Add descriptions to reg
> > -Add minItems/maxItems to reg
> > -Make reg depend on the new hdcp compatible string
> > ---
> > 
> > Disclaimer: I really don't know if this is the right way to approach
> > this. I tried using examples from other bindings, but feedback would be
> > very much welcome on how I could add the optional register ranges.
> > 
> > 
> >  .../bindings/display/msm/dp-controller.yaml   | 34 ---
> >  1 file changed, 30 insertions(+), 4 deletions(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
> > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> > index 64d8d9e5e47a..a176f97b2f4c 100644
> > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> > @@ -17,9 +17,10 @@ properties:
> >compatible:
> >  enum:
> >- qcom,sc7180-dp
> > +  - qcom,sc7180-dp-hdcp
> >  
> > -  reg:
> > -maxItems: 1
> > +  # See compatible-specific constraints below.
> > +  reg: true
> >  
> >interrupts:
> >  maxItems: 1
> > @@ -89,6 +90,29 @@ required:
> >- power-domains
> >- ports
> >  
> > +allOf:
> > +  - if:
> > +  properties:
> > +compatible:
> > +  contains:
> > +const: qcom,sc7180-dp-hdcp
> > +then:
> > +  properties:
> > +reg:
> > +  minItems: 3
> > +  maxItems: 3
> > +  items:
> > +- description: Registers for base DP functionality
> > +- description: (Optional) Registers for HDCP device key 
> > injection
> > +- description: (Optional) Registers for HDCP TrustZone 
> > interaction
> > +else:
> > +  properties:
> > +reg:
> > +  minItems: 1
> > +  maxItems: 1
> > +  items:
> > +- description: Registers for base DP functionality
> > +
> >  additionalProperties: false
> >  
> >  examples:
> > @@ -99,8 +123,10 @@ examples:
> >  #include 
> >  
> >  displayport-controller@ae9 {
> > -compatible = "qcom,sc7180-dp";
> > -reg = <0xae9 0x1400>;
> > +compatible = "qcom,sc7180-dp-hdcp";
> > +reg = <0 0x0ae9 0 0x1400>,
> > +  <0 0x0aed1000 0 0x174>,
> > +  <0 0x0aee1000 0 0x2c>;
> >  interrupt-parent = <>;
> >  interrupts = <12>;
> >  clocks = < DISP_CC_MDSS_AHB_CLK>,
> > -- 
> > Sean Paul, Software Engineer, Google / Chromium OS
> > 

-- 
Sean Paul, Software Engineer, Google / Chromium OS


Re: [Freedreno] [v2] drm/msm/disp/dpu1: set default group ID for CTL.

2021-10-29 Thread Dmitry Baryshkov
On Fri, 29 Oct 2021 at 15:30, Kalyan Thota  wrote:
>
> New required programming in CTL for SC7280. Group ID informs
> HW of which VM owns that CTL. Force this group ID to
> default/disabled until virtualization support is enabled in SW.
>
> Changes in v1:
>  - Fix documentation and add descritpion for the change (Stephen)
>
> Signed-off-by: Kalyan Thota 

Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 5 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8 
>  3 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index ce6f32a..283605c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -45,7 +45,7 @@
> (PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
>
>  #define CTL_SC7280_MASK \
> -   (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE))
> +   (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) | 
> BIT(DPU_CTL_VM_CFG))
>
>  #define MERGE_3D_SM8150_MASK (0)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index 4ade44b..31af04a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -179,13 +179,16 @@ enum {
>
>  /**
>   * CTL sub-blocks
> - * @DPU_CTL_SPLIT_DISPLAY   CTL supports video mode split display
> + * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
> + * @DPU_CTL_FETCH_ACTIVE:  Active CTL for fetch HW (SSPPs)
> + * @DPU_CTL_VM_CFG:CTL config to support multiple VMs
>   * @DPU_CTL_MAX
>   */
>  enum {
> DPU_CTL_SPLIT_DISPLAY = 0x1,
> DPU_CTL_ACTIVE_CFG,
> DPU_CTL_FETCH_ACTIVE,
> +   DPU_CTL_VM_CFG,
> DPU_CTL_MAX
>  };
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 64740ddb..02da9ec 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -36,6 +36,7 @@
>  #define  MERGE_3D_IDX   23
>  #define  INTF_IDX   31
>  #define CTL_INVALID_BIT 0x
> +#define CTL_DEFAULT_GROUP_ID   0xf
>
>  static const u32 fetch_tbl[SSPP_MAX] = {CTL_INVALID_BIT, 16, 17, 18, 19,
> CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, 0,
> @@ -498,6 +499,13 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl 
> *ctx,
> u32 intf_active = 0;
> u32 mode_sel = 0;
>
> +   /* CTL_TOP[31:28] carries group_id to collate CTL paths
> +* per VM. Explicitly disable it until VM support is
> +* added in SW. Power on reset value is not disable.
> +*/
> +   if ((test_bit(DPU_CTL_VM_CFG, >caps->features)))
> +   mode_sel = CTL_DEFAULT_GROUP_ID  << 28;
> +
> if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
> mode_sel |= BIT(17);
>
> --
> 2.7.4
>


-- 
With best wishes
Dmitry


[Freedreno] [v2] drm/msm/disp/dpu1: set default group ID for CTL.

2021-10-29 Thread Kalyan Thota
New required programming in CTL for SC7280. Group ID informs
HW of which VM owns that CTL. Force this group ID to
default/disabled until virtualization support is enabled in SW.

Changes in v1:
 - Fix documentation and add descritpion for the change (Stephen)

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 8 
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index ce6f32a..283605c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -45,7 +45,7 @@
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
 
 #define CTL_SC7280_MASK \
-   (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE))
+   (BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE) | 
BIT(DPU_CTL_VM_CFG))
 
 #define MERGE_3D_SM8150_MASK (0)
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 4ade44b..31af04a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -179,13 +179,16 @@ enum {
 
 /**
  * CTL sub-blocks
- * @DPU_CTL_SPLIT_DISPLAY   CTL supports video mode split display
+ * @DPU_CTL_SPLIT_DISPLAY: CTL supports video mode split display
+ * @DPU_CTL_FETCH_ACTIVE:  Active CTL for fetch HW (SSPPs)
+ * @DPU_CTL_VM_CFG:CTL config to support multiple VMs
  * @DPU_CTL_MAX
  */
 enum {
DPU_CTL_SPLIT_DISPLAY = 0x1,
DPU_CTL_ACTIVE_CFG,
DPU_CTL_FETCH_ACTIVE,
+   DPU_CTL_VM_CFG,
DPU_CTL_MAX
 };
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 64740ddb..02da9ec 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -36,6 +36,7 @@
 #define  MERGE_3D_IDX   23
 #define  INTF_IDX   31
 #define CTL_INVALID_BIT 0x
+#define CTL_DEFAULT_GROUP_ID   0xf
 
 static const u32 fetch_tbl[SSPP_MAX] = {CTL_INVALID_BIT, 16, 17, 18, 19,
CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, CTL_INVALID_BIT, 0,
@@ -498,6 +499,13 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
u32 intf_active = 0;
u32 mode_sel = 0;
 
+   /* CTL_TOP[31:28] carries group_id to collate CTL paths
+* per VM. Explicitly disable it until VM support is
+* added in SW. Power on reset value is not disable.
+*/
+   if ((test_bit(DPU_CTL_VM_CFG, >caps->features)))
+   mode_sel = CTL_DEFAULT_GROUP_ID  << 28;
+
if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
mode_sel |= BIT(17);
 
-- 
2.7.4



Re: [Freedreno] [PATCH 1/4] dma-buf: add dma_fence_describe and dma_resv_describe

2021-10-29 Thread kernel test robot
Hi "Christian,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20211028]
[cannot apply to drm/drm-next drm-intel/for-linux-next 
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master 
airlied/drm-next v5.15-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/dma-buf-add-dma_fence_describe-and-dma_resv_describe/20211028-171805
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/80ae7cf414dbdb7fa9f48a46cc1bfa25b0a4fda7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/dma-buf-add-dma_fence_describe-and-dma_resv_describe/20211028-171805
git checkout 80ae7cf414dbdb7fa9f48a46cc1bfa25b0a4fda7
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
ARCH=m68k 

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

All errors (new ones prefixed by >>):

   drivers/dma-buf/dma-fence.c: In function 'dma_fence_describe':
>> drivers/dma-buf/dma-fence.c:919:9: error: implicit declaration of function 
>> 'seq_printf'; did you mean 'bstr_printf'? 
>> [-Werror=implicit-function-declaration]
 919 | seq_printf(seq, "%s %s seq %llu %ssignalled\n",
 | ^~
 | bstr_printf
   cc1: all warnings being treated as errors


vim +919 drivers/dma-buf/dma-fence.c

   909  
   910  /**
   911   * dma_fence_describe - Dump fence describtion into seq_file
   912   * @fence: the 6fence to describe
   913   * @seq: the seq_file to put the textual description into
   914   *
   915   * Dump a textual description of the fence and it's state into the 
seq_file.
   916   */
   917  void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq)
   918  {
 > 919  seq_printf(seq, "%s %s seq %llu %ssignalled\n",
   920 fence->ops->get_driver_name(fence),
   921 fence->ops->get_timeline_name(fence), fence->seqno,
   922 dma_fence_is_signaled(fence) ? "" : "un");
   923  }
   924  EXPORT_SYMBOL(dma_fence_describe);
   925  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: [Freedreno] [v6, 02/21] drm/bridge: adv7511: Register and attach our DSI device at probe

2021-10-29 Thread Maxime Ripard
On Fri, Oct 29, 2021 at 10:36:00AM +0200, Marek Szyprowski wrote:
> Hi Mexime,
> 
> On 29.10.2021 10:05, Maxime Ripard wrote:
> > On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
> >> On 25.10.2021 17:15, Maxime Ripard wrote:
> >>> In order to avoid any probe ordering issue, the best practice is to move
> >>> the secondary MIPI-DSI device registration and attachment to the
> >>> MIPI-DSI host at probe time. Let's do this.
> >>>
> >>> Acked-by: Sam Ravnborg 
> >>> Tested-by: John Stultz 
> >>> Signed-off-by: Maxime Ripard 
> >> This patch landed in linux-next as commit 864c49a31d6b ("drm/bridge:
> >> adv7511: Register and attach our DSI device at probe"). Sadly it causes
> >> endless probe-fail-defer loop on DragonBoard 410c board
> >> (arch/arm64/boot/dts/qcom/apq8016-sbc.dts):
> > I'm sorry to hear that (but would have been surprised if it didn't occur)
> >
> > This is supposed to be fixed by 8f59ee9a570c ("drm/msm/dsi: Adjust probe
> > order"). Do you have that patch applied?
> 
> Yes, I did my test directly on linux next-20211028, which also contains 
> it. What might be important in my case, my DragonBoard 410c doesn't have 
> any display attached.
> 
> I've also noticed the following error during boot:
> 
> [   23.847651] msm_mdp 1a01000.mdp: Adding to iommu group 3
> [   23.866044] msm_mdp 1a01000.mdp: No interconnect support may cause 
> display underflows!
> [   23.957949] irq: no irq domain found for mdss@1a0 !
> [   23.958014] msm_dsi 1a98000.dsi: failed to request IRQ0: -22
> [   23.962229] msm_dsi: probe of 1a98000.dsi failed with error -22
> 
> The above errors appeared in next-20211028 for the first time. I assume 
> that they are related.

Yeah, it's likely that the DSI host cannot probe anymore, and the DSI
bridge thus cannot find its DSI host. Rob, do you know what could be
going on?

Maxime


signature.asc
Description: PGP signature


Re: [Freedreno] [v6, 02/21] drm/bridge: adv7511: Register and attach our DSI device at probe

2021-10-29 Thread Marek Szyprowski
Hi Mexime,

On 29.10.2021 10:05, Maxime Ripard wrote:
> On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
>> On 25.10.2021 17:15, Maxime Ripard wrote:
>>> In order to avoid any probe ordering issue, the best practice is to move
>>> the secondary MIPI-DSI device registration and attachment to the
>>> MIPI-DSI host at probe time. Let's do this.
>>>
>>> Acked-by: Sam Ravnborg 
>>> Tested-by: John Stultz 
>>> Signed-off-by: Maxime Ripard 
>> This patch landed in linux-next as commit 864c49a31d6b ("drm/bridge:
>> adv7511: Register and attach our DSI device at probe"). Sadly it causes
>> endless probe-fail-defer loop on DragonBoard 410c board
>> (arch/arm64/boot/dts/qcom/apq8016-sbc.dts):
> I'm sorry to hear that (but would have been surprised if it didn't occur)
>
> This is supposed to be fixed by 8f59ee9a570c ("drm/msm/dsi: Adjust probe
> order"). Do you have that patch applied?

Yes, I did my test directly on linux next-20211028, which also contains 
it. What might be important in my case, my DragonBoard 410c doesn't have 
any display attached.

I've also noticed the following error during boot:

[   23.847651] msm_mdp 1a01000.mdp: Adding to iommu group 3
[   23.866044] msm_mdp 1a01000.mdp: No interconnect support may cause 
display underflows!
[   23.957949] irq: no irq domain found for mdss@1a0 !
[   23.958014] msm_dsi 1a98000.dsi: failed to request IRQ0: -22
[   23.962229] msm_dsi: probe of 1a98000.dsi failed with error -22

The above errors appeared in next-20211028 for the first time. I assume 
that they are related.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland



Re: [Freedreno] [v6, 02/21] drm/bridge: adv7511: Register and attach our DSI device at probe

2021-10-29 Thread Maxime Ripard
Hi Marek,

On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
> Hi,
> 
> On 25.10.2021 17:15, Maxime Ripard wrote:
> > In order to avoid any probe ordering issue, the best practice is to move
> > the secondary MIPI-DSI device registration and attachment to the
> > MIPI-DSI host at probe time. Let's do this.
> >
> > Acked-by: Sam Ravnborg 
> > Tested-by: John Stultz 
> > Signed-off-by: Maxime Ripard 
>
> This patch landed in linux-next as commit 864c49a31d6b ("drm/bridge:
> adv7511: Register and attach our DSI device at probe"). Sadly it causes
> endless probe-fail-defer loop on DragonBoard 410c board
> (arch/arm64/boot/dts/qcom/apq8016-sbc.dts):

I'm sorry to hear that (but would have been surprised if it didn't occur)

This is supposed to be fixed by 8f59ee9a570c ("drm/msm/dsi: Adjust probe
order"). Do you have that patch applied?

Maxime


signature.asc
Description: PGP signature


Re: [Freedreno] [v6, 02/21] drm/bridge: adv7511: Register and attach our DSI device at probe

2021-10-29 Thread Marek Szyprowski
Hi,

On 25.10.2021 17:15, Maxime Ripard wrote:
> In order to avoid any probe ordering issue, the best practice is to move
> the secondary MIPI-DSI device registration and attachment to the
> MIPI-DSI host at probe time. Let's do this.
>
> Acked-by: Sam Ravnborg 
> Tested-by: John Stultz 
> Signed-off-by: Maxime Ripard 

This patch landed in linux-next as commit 864c49a31d6b ("drm/bridge: 
adv7511: Register and attach our DSI device at probe"). Sadly it causes 
endless probe-fail-defer loop on DragonBoard 410c board 
(arch/arm64/boot/dts/qcom/apq8016-sbc.dts):

qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: PMIC 
REV: 1  CODEC Version: 1
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget ADC1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget ADC1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX3 overwritten
debugfs: File 'Capture' in directory 'dapm' already present!
adv7511 3-0039: failed to find dsi host
adv7511 3-0039: supply dvdd not found, using dummy regulator
adv7511 3-0039: supply pvdd not found, using dummy regulator
adv7511 3-0039: supply a2vdd not found, using dummy regulator
debugfs: Directory '7708000.audio-controller' with parent 'DB410c' 
already present!
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: PMIC 
REV: 1  CODEC Version: 1
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget ADC1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget ADC1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX3 overwritten
debugfs: File 'Capture' in directory 'dapm' already present!
adv7511 3-0039: failed to find dsi host
adv7511 3-0039: supply dvdd not found, using dummy regulator
adv7511 3-0039: supply pvdd not found, using dummy regulator
adv7511 3-0039: supply a2vdd not found, using dummy regulator
debugfs: Directory '7708000.audio-controller' with parent 'DB410c' 
already present!
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: PMIC 
REV: 1  CODEC Version: 1
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget ADC1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget ADC1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
sink widget PDM_RX1 overwritten
qcom,pm8916-wcd-spmi-codec 200f000.spmi:pmic@1:audio-codec@f000: ASoC: 
source widget PDM_RX3 overwritten
debugfs: File 'Capture' in directory 'dapm' already present!
adv7511 3-0039: failed to find dsi host
adv7511 3-0039: supply dvdd not found, using dummy regulator
adv7511 3-0039: supply pvdd not found, using dummy regulator
adv7511 3-0039: supply a2vdd not found, using dummy regulator
debugfs: Directory '7708000.audio-controller' with parent 'DB410c' 
already present!

...

Reverting it on top of linux next-20211028 'fixes' this issue.

> ---
>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 ++---
>   1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git