Re: [PATCH 2/2] dt-bindings: google, cros-ec: drop Enric Balletbo i Serra from maintainers

[Enric Balletbo Serra]

Hi,

Missatge de Krzysztof Kozlowski 
del dia dj., 20 de gen. 2022 a les 11:40:
>
> Enric Balletbo i Serra emails bounce:
>
>   : Recipient address rejected: User unknown in 
>  local recipient table
>
> so drop him from the maintainers, similarly to commit 3119c28634dd
> ("MAINTAINERS: Chrome: Drop Enric Balletbo i Serra").
>
> Signed-off-by: Krzysztof Kozlowski 

I'm fine with the removal as I don't have access anymore to this
hardware so it doesn't really make sense to be there. Sorry for not
sending the patches myself before.

Acked-by: Enric Balletbo i Serra 

Best regards,
  Enric

> ---
>  .../devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml  | 1 -
>  .../devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml   | 1 -
>  .../bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml| 1 -
>  Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml | 1 -
>  Documentation/devicetree/bindings/mfd/google,cros-ec.yaml| 1 -
>  5 files changed, 5 deletions(-)
>
> diff --git 
> a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml 
> b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml
> index 20e1ccfc8630..2d82b44268db 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml
> @@ -8,7 +8,6 @@ title: ChromeOS EC USB Type-C cable and accessories detection
>
>  maintainers:
>- Benson Leung 
> -  - Enric Balletbo i Serra 
>
>  description: |
>On ChromeOS systems with USB Type C ports, the ChromeOS Embedded 
> Controller is
> diff --git 
> a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml 
> b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
> index b386e4128a79..6e1c70e9275e 100644
> --- a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
> +++ b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
> @@ -10,7 +10,6 @@ title: I2C bus that tunnels through the ChromeOS EC 
> (cros-ec)
>  maintainers:
>- Doug Anderson 
>- Benson Leung 
> -  - Enric Balletbo i Serra 
>
>  description: |
>On some ChromeOS board designs we've got a connection to the EC
> diff --git 
> a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
>  
> b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
> index 099b4be927d4..00e3b59641d2 100644
> --- 
> a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
> +++ 
> b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
> @@ -10,7 +10,6 @@ title: ChromeOS EC MKBP Proximity Sensor
>  maintainers:
>- Stephen Boyd 
>- Benson Leung 
> -  - Enric Balletbo i Serra 
>
>  description: |
>Google's ChromeOS EC sometimes has the ability to detect user proximity.
> diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml 
> b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
> index 5377b232fa10..e8f137abb03c 100644
> --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
> +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
> @@ -10,7 +10,6 @@ title: ChromeOS EC Keyboard
>  maintainers:
>- Simon Glass 
>- Benson Leung 
> -  - Enric Balletbo i Serra 
>
>  description: |
>Google's ChromeOS EC Keyboard is a simple matrix keyboard
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml 
> b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index e9c46430fd8a..66a995e9 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -8,7 +8,6 @@ title: ChromeOS Embedded Controller
>
>  maintainers:
>- Benson Leung 
> -  - Enric Balletbo i Serra 
>- Guenter Roeck 
>
>  description:
> --
> 2.32.0
>

Re: [PATCH 1/2] dt-bindings: display: bridge: drop Enric Balletbo i Serra from maintainers

[Enric Balletbo Serra]

Hi,

Missatge de Neil Armstrong  del dia dj., 20
de gen. 2022 a les 11:52:
>
> On 20/01/2022 11:40, Krzysztof Kozlowski wrote:
> > Enric Balletbo i Serra emails bounce:
> >
> >   : Recipient address rejected: User unknown 
> > in  local recipient table
> >
> > so drop him from the maintainers, similarly to commit 3119c28634dd
> > ("MAINTAINERS: Chrome: Drop Enric Balletbo i Serra").  Add generic DRM
> > bridge maintainers to Analogix ANX7814.
> >
> > Signed-off-by: Krzysztof Kozlowski 
> > ---
> >  .../devicetree/bindings/display/bridge/analogix,anx7814.yaml  | 4 +++-
> >  .../bindings/display/bridge/google,cros-ec-anx7688.yaml   | 1 -
> >  Documentation/devicetree/bindings/display/bridge/ps8640.yaml  | 1 -
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> > index 8e13f27b28ed..bce96b5b0db0 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> > @@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> >  title: Analogix ANX7814 SlimPort (Full-HD Transmitter)
> >
> >  maintainers:
> > -  - Enric Balletbo i Serra 
> > +  - Andrzej Hajda 
> > +  - Neil Armstrong 
> > +  - Robert Foss 
> >
> >  properties:
> >compatible:
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
> >  
> > b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
> > index 9f7cc6b757cb..a88a5d8c7ba5 100644
> > --- 
> > a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
> > +++ 
> > b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
> > @@ -8,7 +8,6 @@ title: ChromeOS EC ANX7688 HDMI to DP Converter through 
> > Type-C Port
> >
> >  maintainers:
> >- Nicolas Boichat 
> > -  - Enric Balletbo i Serra 
> >
> >  description: |
> >ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
> > diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
> > index cdaf7a7a8f88..186e17be51fb 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
> > @@ -8,7 +8,6 @@ title: MIPI DSI to eDP Video Format Converter Device Tree 
> > Bindings
> >
> >  maintainers:
> >- Nicolas Boichat 
> > -  - Enric Balletbo i Serra 
> >
> >  description: |
> >The PS8640 is a low power MIPI-to-eDP video format converter supporting
> >
>
> Let's wait for Enric's response, but in any case (removal or new address):
> Acked-by: Neil Armstrong 
>

I'm fine with the removal as I don't have access anymore to this
hardware so it doesn't really make sense to be there. Sorry for not
sending the patches myself before.

Acked-by: Enric Balletbo i Serra 

Best regards,
  Enric

> Neil

Re: [PATCH 0/5] Revert series "CMDQ refinement of Mediatek DRM driver"

[Enric Balletbo Serra]

Hi Chun-Kuang,

Thank you to take time to send this, for full series

Tested-by: Enric Balletbo i Serra 

Display is now working again.

Thanks,
  Enric


Missatge de Chun-Kuang Hu  del dia dv., 8
d’oct. 2021 a les 1:53:
>
> Commit c1ec54b7b5af
> ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
> would cause numerous mtk cmdq mailbox driver warning:
>
> WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
> cmdq_task_exec_done+0xb8/0xe0
>
> So revert that patch and all the patches depend on that patch.
>
> Chun-Kuang Hu (5):
>   Revert "drm/mediatek: Clear pending flag when cmdq packet is done"
>   Revert "drm/mediatek: Add cmdq_handle in mtk_crtc"
>   Revert "drm/mediatek: Detect CMDQ execution timeout"
>   Revert "drm/mediatek: Remove struct cmdq_client"
>   Revert "drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb"
>
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 157 
>  1 file changed, 24 insertions(+), 133 deletions(-)
>
> --
> 2.25.1
>

Re: [v2 PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize

[Enric Balletbo Serra]

Hi Chun-Kuang,

Missatge de Chun-Kuang Hu  del dia dv., 1
d’oct. 2021 a les 17:52:
>
> Hi, Enric:
>
> Enric Balletbo Serra  於 2021年9月30日 週四 下午9:48寫道：
> >
> > Hi Chun-Kuang,
> >
> > Missatge de Chun-Kuang Hu  del dia dj., 30 de
> > set. 2021 a les 15:11:
> > >
> > > Hi, Enric:
> > >
> > > Enric Balletbo Serra  於 2021年9月30日 週四 下午3:12寫道：
> > > >
> > > > Hi Jason,
> > > >
> > > >
> > > > Missatge de jason-jh.lin  del dia dj., 30
> > > > de set. 2021 a les 4:47:
> > > > >
> > > > > Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
> > > > > crash at using pkt->cl->chan in cmdq_pkt_finalize.
> > > > >
> > > > > So add struct cmdq_client and let mtk_drm_crtc instance define
> > > > > cmdq_client as:
> > > > >
> > > > > struct mtk_drm_crtc {
> > > > > /* client instance data */
> > > > > struct cmdq_client cmdq_client;
> > > > > };
> > > > >
> > > > > and in rx_callback function can use pkt->cl to get
> > > > > struct cmdq_client.
> > > > >
> > > > > Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> > > >
> > > > Looking at this patchset looks like you're fixing the above commit by
> > > > reintroducing the 'struct cmdq_client' again, which makes the above
> > > > commit as a non-sense commit. That's confusing and not clear. I'm
> > > > wondering if it wouldn't be more clear if you can just revert that
> > > > patch. Then if there are more changes that need to be done do it with
> > > > a follow up patch and really explain why these changes are needed.
> > >
> > > The patch f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> > > does two things. One is to remove struct cmdq_client, another one is
> > > to embed cmdq_cl
> >
> > Then it should have been two patches, one thing for patch really
> > helps, specially when something breaks and you try to bisect it.
> >
> > > in mtk_drm_crtc (This means the pointer of cmdq_cl could be used to
> > > find the pointer of mtk_drm_crtc). The correct way to fix that patch
> > > is to remove the access to cmdq_client in cmdq_pkt_finalize(), but
> > > that would be a long term process. The simple way is to revert that
> > > patch, but the other patches depend on embedding cmdq_cl in
> > > mtk_drm_crtc. So this patch just revert the removing of struct
> > > cmdq_client but keep embedding cmdq_cl in mtk_drm_crtc.
> > >
> >
> > Yes, I know and I suffered that when bisecting and I ended to revert
> > the full series in my local tree,  although I figured out that the
> > problem was this specific patch.
> >
> > The following series landed during -rc1 cycle and break the Acer Chromebook 
> > R13
> >
> >  9efb16c2fdd6 ("drm/mediatek: Clear pending flag when cmdq packet is done")
> >  bc9241be73d9 ("drm/mediatek: Add cmdq_handle in mtk_crtc")
> >  8cdcb3653424 ("drm/mediatek: Detect CMDQ execution timeout")
> >  f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> >  c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of 
> > cmdq_task_cb")
> >
> > Apart from that it was a pain bisecting and introduced different
> > behaviours between patches, all the above commits have a follow-up
> > patch (see [1] and [2]) as a fix for the landed series. That makes me
> > think that were no stable enough. As we're in the rc, and as you said
> > this is not the correct way to fix it, and the landed patches seems
> > more a cleanup that really solving a real problem I'd consider to just
> > revert the full series and resubmit again for next release with these
> > fixes squashed. IMO that will also help to no miss anything when
> > someone would backport all this to the stable versions and understand
> > better the history.
> >
> > Just my 5 cents. In any case, I can confirm that applying the full
> > series solves the current problems that I have with my Acer Chromebook
> > R13.
>
> OK, that series depend on an WARN_ON fixes in mailbox driver, and need
> a better solution in cmdq helper, so let's revert that series first.
> Would you like to send the revert patches? Or I send the revert
> patches and let you test?
>

I'll let you to send the revert patches :-)

Thank

Re: [PATCH v9, 2/2] soc: mediatek: mmsys: Add mt8192 mmsys routing table

[Enric Balletbo Serra]

Hi Yongqiang,

This patch already have my reviewed tag but I just noticed a small nit


Missatge de Yongqiang Niu  del dia dj., 30
de set. 2021 a les 16:00:
>
> mt8192 has different routing registers than mt8183
>
> Signed-off-by: Yongqiang Niu 
> Reviewed-by: Enric Balletbo i Serra 
> ---
>  drivers/soc/mediatek/mt8192-mmsys.h | 77 +
>  drivers/soc/mediatek/mtk-mmsys.c| 11 +
>  2 files changed, 88 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h
>
> diff --git a/drivers/soc/mediatek/mt8192-mmsys.h 
> b/drivers/soc/mediatek/mt8192-mmsys.h
> new file mode 100644
> index ..7ea1531ee8af
> --- /dev/null
> +++ b/drivers/soc/mediatek/mt8192-mmsys.h
> @@ -0,0 +1,77 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __SOC_MEDIATEK_MT8192_MMSYS_H
> +#define __SOC_MEDIATEK_MT8192_MMSYS_H
> +
> +#define MT8192_MMSYS_OVL_MOUT_EN   0xf04
> +#define MT8192_DISP_OVL1_2L_MOUT_EN0xf08
> +#define MT8192_DISP_OVL0_2L_MOUT_EN0xf18
> +#define MT8192_DISP_OVL0_MOUT_EN   0xf1c
> +#define MT8192_DISP_RDMA0_SEL_IN   0xf2c
> +#define MT8192_DISP_RDMA0_SOUT_SEL 0xf30
> +#define MT8192_DISP_CCORR0_SOUT_SEL0xf34
> +#define MT8192_DISP_AAL0_SEL_IN0xf38
> +#define MT8192_DISP_DITHER0_MOUT_EN0xf3c
> +#define MT8192_DISP_DSI0_SEL_IN0xf40
> +#define MT8192_DISP_OVL2_2L_MOUT_EN0xf4c
> +
> +#define MT8192_DISP_OVL0_GO_BLEND  BIT(0)
> +#define MT8192_DITHER0_MOUT_IN_DSI0BIT(0)
> +#define MT8192_OVL0_MOUT_EN_DISP_RDMA0 BIT(0)
> +#define MT8192_OVL2_2L_MOUT_EN_RDMA4   BIT(0)
> +#define MT8192_DISP_OVL0_GO_BG BIT(1)
> +#define MT8192_DISP_OVL0_2L_GO_BLEND   BIT(2)
> +#define MT8192_DISP_OVL0_2L_GO_BG  BIT(3)
> +#define MT8192_OVL1_2L_MOUT_EN_RDMA1   BIT(4)
> +#define MT8192_OVL0_MOUT_EN_OVL0_2LBIT(4)
> +#define MT8192_RDMA0_SEL_IN_OVL0_2L0x3
> +#define MT8192_RDMA0_SOUT_COLOR0   0x1
> +#define MT8192_CCORR0_SOUT_AAL00x1
> +#define MT8192_AAL0_SEL_IN_CCORR0  0x1
> +#define MT8192_DSI0_SEL_IN_DITHER0 0x1
> +
> +static const struct mtk_mmsys_routes mmsys_mt8192_routing_table[] = {
> +   {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   MT8192_DISP_OVL0_2L_MOUT_EN, MT8192_OVL0_MOUT_EN_DISP_RDMA0,
> +   MT8192_OVL0_MOUT_EN_DISP_RDMA0
> +   }, {
> +   DDP_COMPONENT_OVL_2L2, DDP_COMPONENT_RDMA4,
> +   MT8192_DISP_OVL2_2L_MOUT_EN, MT8192_OVL2_2L_MOUT_EN_RDMA4,
> +   MT8192_OVL2_2L_MOUT_EN_RDMA4
> +   }, {
> +   DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> +   MT8192_DISP_DITHER0_MOUT_EN, MT8192_DITHER0_MOUT_IN_DSI0,
> +   MT8192_DITHER0_MOUT_IN_DSI0
> +   }, {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   MT8192_DISP_RDMA0_SEL_IN, MT8192_RDMA0_SEL_IN_OVL0_2L,
> +   MT8192_RDMA0_SEL_IN_OVL0_2L
> +   }, {
> +   DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
> +   MT8192_DISP_AAL0_SEL_IN, MT8192_AAL0_SEL_IN_CCORR0,
> +   MT8192_AAL0_SEL_IN_CCORR0
> +   }, {
> +   DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> +   MT8192_DISP_DSI0_SEL_IN, MT8192_DSI0_SEL_IN_DITHER0,
> +   MT8192_DSI0_SEL_IN_DITHER0
> +   }, {
> +   DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
> +   MT8192_DISP_RDMA0_SOUT_SEL, MT8192_RDMA0_SOUT_COLOR0,
> +   MT8192_RDMA0_SOUT_COLOR0
> +   }, {
> +   DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
> +   MT8192_DISP_CCORR0_SOUT_SEL, MT8192_CCORR0_SOUT_AAL0,
> +   MT8192_CCORR0_SOUT_AAL0
> +   }, {
> +   DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
> +   MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_GO_BG,
> +   MT8192_DISP_OVL0_GO_BG,
> +   }, {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_2L_GO_BLEND,
> +   MT8192_DISP_OVL0_2L_GO_BLEND,
> +   }
> +};
> +
> +#endif /* __SOC_MEDIATEK_MT8192_MMSYS_H */
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
> b/drivers/soc/mediatek/mtk-mmsys.c
> index a78e88f27b62..6e97d1468183 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -14,6 +14,7 @@
>  #include "mt8167-mmsys.h"
>  #include "mt8183-mmsys.h"
>  #include "mt8365-mmsys.h"
> +#include "mt8192-mmsys.h"
>
>  static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .clk_driver = "clk-mt2701-mm",
> @@ -59,6 +60,12 @@ static const 

Re: [v2 PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize

[Enric Balletbo Serra]

Hi Chun-Kuang,

Missatge de Chun-Kuang Hu  del dia dj., 30 de
set. 2021 a les 15:11:
>
> Hi, Enric:
>
> Enric Balletbo Serra  於 2021年9月30日 週四 下午3:12寫道：
> >
> > Hi Jason,
> >
> >
> > Missatge de jason-jh.lin  del dia dj., 30
> > de set. 2021 a les 4:47:
> > >
> > > Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
> > > crash at using pkt->cl->chan in cmdq_pkt_finalize.
> > >
> > > So add struct cmdq_client and let mtk_drm_crtc instance define
> > > cmdq_client as:
> > >
> > > struct mtk_drm_crtc {
> > > /* client instance data */
> > > struct cmdq_client cmdq_client;
> > > };
> > >
> > > and in rx_callback function can use pkt->cl to get
> > > struct cmdq_client.
> > >
> > > Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> >
> > Looking at this patchset looks like you're fixing the above commit by
> > reintroducing the 'struct cmdq_client' again, which makes the above
> > commit as a non-sense commit. That's confusing and not clear. I'm
> > wondering if it wouldn't be more clear if you can just revert that
> > patch. Then if there are more changes that need to be done do it with
> > a follow up patch and really explain why these changes are needed.
>
> The patch f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> does two things. One is to remove struct cmdq_client, another one is
> to embed cmdq_cl

Then it should have been two patches, one thing for patch really
helps, specially when something breaks and you try to bisect it.

> in mtk_drm_crtc (This means the pointer of cmdq_cl could be used to
> find the pointer of mtk_drm_crtc). The correct way to fix that patch
> is to remove the access to cmdq_client in cmdq_pkt_finalize(), but
> that would be a long term process. The simple way is to revert that
> patch, but the other patches depend on embedding cmdq_cl in
> mtk_drm_crtc. So this patch just revert the removing of struct
> cmdq_client but keep embedding cmdq_cl in mtk_drm_crtc.
>

Yes, I know and I suffered that when bisecting and I ended to revert
the full series in my local tree,  although I figured out that the
problem was this specific patch.

The following series landed during -rc1 cycle and break the Acer Chromebook R13

 9efb16c2fdd6 ("drm/mediatek: Clear pending flag when cmdq packet is done")
 bc9241be73d9 ("drm/mediatek: Add cmdq_handle in mtk_crtc")
 8cdcb3653424 ("drm/mediatek: Detect CMDQ execution timeout")
 f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
 c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")

Apart from that it was a pain bisecting and introduced different
behaviours between patches, all the above commits have a follow-up
patch (see [1] and [2]) as a fix for the landed series. That makes me
think that were no stable enough. As we're in the rc, and as you said
this is not the correct way to fix it, and the landed patches seems
more a cleanup that really solving a real problem I'd consider to just
revert the full series and resubmit again for next release with these
fixes squashed. IMO that will also help to no miss anything when
someone would backport all this to the stable versions and understand
better the history.

Just my 5 cents. In any case, I can confirm that applying the full
series solves the current problems that I have with my Acer Chromebook
R13.

Thanks,
  Enric

[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=555383
[2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=554767



> Regards,
> Chun-Kuang.
>
> >
> > Thanks,
> >   Enric
> >
> >
> > > Signed-off-by: jason-jh.lin 
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 73 +
> > >  1 file changed, 38 insertions(+), 35 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > index 5f81489fc60c..411d99fcbb8f 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > @@ -52,8 +52,7 @@ struct mtk_drm_crtc {
> > > boolpending_async_planes;
> > >
> > >  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > > -   struct mbox_client  cmdq_cl;
> > > -   struct mbox_chan*cmdq_chan;
> > > +   struct cmdq_client  cmdq_client;
> > > struct cmdq_pkt cmdq_handle;
> > > u32   

Re: [v2 PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize

[Enric Balletbo Serra]

Hi Jason,


Missatge de jason-jh.lin  del dia dj., 30
de set. 2021 a les 4:47:
>
> Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
> crash at using pkt->cl->chan in cmdq_pkt_finalize.
>
> So add struct cmdq_client and let mtk_drm_crtc instance define
> cmdq_client as:
>
> struct mtk_drm_crtc {
> /* client instance data */
> struct cmdq_client cmdq_client;
> };
>
> and in rx_callback function can use pkt->cl to get
> struct cmdq_client.
>
> Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")

Looking at this patchset looks like you're fixing the above commit by
reintroducing the 'struct cmdq_client' again, which makes the above
commit as a non-sense commit. That's confusing and not clear. I'm
wondering if it wouldn't be more clear if you can just revert that
patch. Then if there are more changes that need to be done do it with
a follow up patch and really explain why these changes are needed.

Thanks,
  Enric


> Signed-off-by: jason-jh.lin 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 73 +
>  1 file changed, 38 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 5f81489fc60c..411d99fcbb8f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -52,8 +52,7 @@ struct mtk_drm_crtc {
> boolpending_async_planes;
>
>  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> -   struct mbox_client  cmdq_cl;
> -   struct mbox_chan*cmdq_chan;
> +   struct cmdq_client  cmdq_client;
> struct cmdq_pkt cmdq_handle;
> u32 cmdq_event;
> u32 cmdq_vblank_cnt;
> @@ -227,8 +226,8 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct 
> drm_crtc *crtc,
>  }
>
>  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> -static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan, struct cmdq_pkt 
> *pkt,
> -   size_t size)
> +static int mtk_drm_cmdq_pkt_create(struct cmdq_client *client, struct 
> cmdq_pkt *pkt,
> +  size_t size)
>  {
> struct device *dev;
> dma_addr_t dma_addr;
> @@ -239,8 +238,9 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan 
> *chan, struct cmdq_pkt *pkt,
> return -ENOMEM;
> }
> pkt->buf_size = size;
> +   pkt->cl = (void *)client;
>
> -   dev = chan->mbox->dev;
> +   dev = client->chan->mbox->dev;
> dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
>   DMA_TO_DEVICE);
> if (dma_mapping_error(dev, dma_addr)) {
> @@ -255,9 +255,11 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan 
> *chan, struct cmdq_pkt *pkt,
> return 0;
>  }
>
> -static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan *chan, struct cmdq_pkt 
> *pkt)
> +static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
>  {
> -   dma_unmap_single(chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> +   struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> +
> +   dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
>  DMA_TO_DEVICE);
> kfree(pkt->va_base);
> kfree(pkt);
> @@ -265,8 +267,9 @@ static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan 
> *chan, struct cmdq_pkt *pk
>
>  static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
>  {
> -   struct mtk_drm_crtc *mtk_crtc = container_of(cl, struct mtk_drm_crtc, 
> cmdq_cl);
> struct cmdq_cb_data *data = mssg;
> +   struct cmdq_client *cmdq_cl = container_of(cl, struct cmdq_client, 
> client);
> +   struct mtk_drm_crtc *mtk_crtc = container_of(cmdq_cl, struct 
> mtk_drm_crtc, cmdq_client);
> struct mtk_crtc_state *state;
> unsigned int i;
>
> @@ -299,7 +302,7 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void 
> *mssg)
> }
>
> mtk_crtc->cmdq_vblank_cnt = 0;
> -   mtk_drm_cmdq_pkt_destroy(mtk_crtc->cmdq_chan, data->pkt);
> +   mtk_drm_cmdq_pkt_destroy(data->pkt);
>  }
>  #endif
>
> @@ -550,24 +553,24 @@ static void mtk_drm_crtc_update_config(struct 
> mtk_drm_crtc *mtk_crtc,
> mtk_mutex_release(mtk_crtc->mutex);
> }
>  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> -   if (mtk_crtc->cmdq_chan) {
> -   mbox_flush(mtk_crtc->cmdq_chan, 2000);
> +   if (mtk_crtc->cmdq_client.chan) {
> +   mbox_flush(mtk_crtc->cmdq_client.chan, 2000);
> cmdq_handle->cmd_buf_size = 0;
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> -   

Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver

[Enric Balletbo Serra]

Hi Chun-Kuang,

Missatge de Chun-Kuang Hu  del dia dt., 21 de
set. 2021 a les 15:15:
>
> Hi, Enric:
>
> Enric Balletbo Serra  於 2021年9月21日 週二 下午4:36寫道：
> >
> > Hi Chun-Kuang,
> >
> > (again without html format, sorry for the noise)
> >
> > Missatge de Chun-Kuang Hu  del dia dj., 12
> > d’ag. 2021 a les 2:13:
> > >
> > > Chun-Kuang Hu  於 2021年8月9日 週一 上午7:47寫道：
> > > >
> > > > These refinements include using standard mailbox callback interface,
> > > > timeout detection, and a fixed cmdq_handle.
> > >
> > > For this series, applied to mediatek-drm-next [1].
> > >
> > > [1] 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
> > >
> >
> > These patches seem to break the display on the Acer Chromebook R 13
> > (MT8173) in the current mainline. After running a bisection it pointed
> > me to the following commit
> >
> > commit f4be17cd5b14dd73545b0e014a63ebe9ab5ef837
> > Author: Chun-Kuang Hu 
> > Date:   Sun Jul 4 15:36:48 2021 +0800
> >
> > drm/mediatek: Remove struct cmdq_client
> >
> > Reverting this patch alone is not trivial, so I ended up reverting the
> > full series, and I can confirm that reverting the full series makes
> > the display work again.
>
> I think you could not just revert "drm/mediatek: Remove struct
> cmdq_client", you should also revert the patches after it, such as
>
> "drm/mediatek: Clear pending flag when cmdq packet is done"
> "drm/mediatek: Add cmdq_handle in mtk_crtc"
> "drm/mediatek: Detect CMDQ execution timeout"
>

Yes, in fact I reverted:

9efb16c2fdd6 drm/mediatek: Clear pending flag when cmdq packet is done
bc9241be73d9 drm/mediatek: Add cmdq_handle in mtk_crtc
8cdcb3653424 drm/mediatek: Detect CMDQ execution timeout
f4be17cd5b14 drm/mediatek: Remove struct cmdq_client
c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb

Without these patches 5.15-rc2 works again on my platform.

The commit 'c1ec54b7b5af drm/mediatek: Use mailbox rx_callback instead
of cmdq_task_cb' alone introduces lots of warnings in the kernel

WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0

I think is just a leftover or the mentioned warning, but that confused
me a bit doing the bisection. Then, after commit 'f4be17cd5b14
drm/mediatek: Remove struct cmdq_client' my system simply gets stuck.
For now I don't see any obvious mistake but will dig further.

Can I ask you in which platform did you test? And if you can double
check if your platform is broken too in current mainline?

Thanks,
  Enric

> If "drm/mediatek: Remove struct cmdq_client" is the patch cause
> display abnormal, I think you could compare code w/ and w/o this
> patch. Focus on the value accuracy, such as cmdq_cl and cmdq_chan. And
> focus on the flow accuracy, such as mtk_drm_crtc_update_config() and
> ddp_cmdq_cb(). If this could not find the problem, I think the latest
> way is to break this patch into small patches, changes little in each
> small patches and we could finally find out the problem.
>
> Regards,
> Chun-Kuang.
>
> >
> > Unfortunately, after the merge window, different things broke for this
> > device, and I didn't finish isolating them, and it is not clear to me
> > yet whether the logs I'm getting are useful for this specific issue or
> > not. Basically with this series merged the kernel seems to be stuck,
> > and the display is not working. Latest message is
> >
> > [   12.329173] mtk-iommu 10205000.iommu: Partial TLB flush timed out,
> > falling back to full flush
> >
> > Without the series, the kernel goes far and display works, however
> > there are other issues affecting the cros-ec, but I think that's
> > another issue.
> >
> > I'll try to dig a bit more, but, meanwhile, if you have any idea
> > please let me know.
> >
> > Thanks,
> >  Enric
> >
> >
> > > Regards,
> > > Chun-Kuang.
> > >
> > > >
> > > > Changes in v2:
> > > > 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy()
> > > >when CONFIG_MTK_CMDQ is reachable.
> > > >
> > > > Chun-Kuang Hu (4):
> > > >   drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb
> > > >   drm/mediatek: Remove struct cmdq_client
> > > >   drm/mediatek: Detect CMDQ execution timeout
> > > >   drm/mediatek: Add cmdq_handle in mtk_crtc
> > > >
> > > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 110 
> > > >  1 file changed, 91 insertions(+), 19 deletions(-)
> > > >
> > > > --
> > > > 2.25.1
> > > >

Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver

[Enric Balletbo Serra]

Hi Chun-Kuang,

(again without html format, sorry for the noise)

Missatge de Chun-Kuang Hu  del dia dj., 12
d’ag. 2021 a les 2:13:
>
> Chun-Kuang Hu  於 2021年8月9日 週一 上午7:47寫道：
> >
> > These refinements include using standard mailbox callback interface,
> > timeout detection, and a fixed cmdq_handle.
>
> For this series, applied to mediatek-drm-next [1].
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
>

These patches seem to break the display on the Acer Chromebook R 13
(MT8173) in the current mainline. After running a bisection it pointed
me to the following commit

commit f4be17cd5b14dd73545b0e014a63ebe9ab5ef837
Author: Chun-Kuang Hu 
Date:   Sun Jul 4 15:36:48 2021 +0800

drm/mediatek: Remove struct cmdq_client

Reverting this patch alone is not trivial, so I ended up reverting the
full series, and I can confirm that reverting the full series makes
the display work again.

Unfortunately, after the merge window, different things broke for this
device, and I didn't finish isolating them, and it is not clear to me
yet whether the logs I'm getting are useful for this specific issue or
not. Basically with this series merged the kernel seems to be stuck,
and the display is not working. Latest message is

[   12.329173] mtk-iommu 10205000.iommu: Partial TLB flush timed out,
falling back to full flush

Without the series, the kernel goes far and display works, however
there are other issues affecting the cros-ec, but I think that's
another issue.

I'll try to dig a bit more, but, meanwhile, if you have any idea
please let me know.

Thanks,
 Enric


> Regards,
> Chun-Kuang.
>
> >
> > Changes in v2:
> > 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy()
> >when CONFIG_MTK_CMDQ is reachable.
> >
> > Chun-Kuang Hu (4):
> >   drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb
> >   drm/mediatek: Remove struct cmdq_client
> >   drm/mediatek: Detect CMDQ execution timeout
> >   drm/mediatek: Add cmdq_handle in mtk_crtc
> >
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 110 
> >  1 file changed, 91 insertions(+), 19 deletions(-)
> >
> > --
> > 2.25.1
> >

Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver

[Enric Balletbo Serra]

Hi Chun-Kuang,

Missatge de Chun-Kuang Hu  del dia dj., 12 d’ag.
2021 a les 2:13:

> Chun-Kuang Hu  於 2021年8月9日 週一 上午7:47寫道：
> >
> > These refinements include using standard mailbox callback interface,
> > timeout detection, and a fixed cmdq_handle.
>
> For this series, applied to mediatek-drm-next [1].
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
>
>
These patches seem to break the display on the Acer Chromebook R 13
(MT8173) in the current mainline. After running a bisection it pointed me
to the following commit

commit f4be17cd5b14dd73545b0e014a63ebe9ab5ef837
Author: Chun-Kuang Hu 
Date:   Sun Jul 4 15:36:48 2021 +0800

drm/mediatek: Remove struct cmdq_client

Reverting this patch alone is not trivial, so I ended up reverting the full
series, and I can confirm that reverting the full series makes the display
work again.

Unfortunately, after the merge window, different things broke for this
device, and I didn't finish isolating them, and it is not clear to me yet
whether the logs I'm getting are useful for this specific issue or not.
Basically with this series merged the kernel seems to be stuck, and the
display is not working. Latest message is

[   12.329173] mtk-iommu 10205000.iommu: Partial TLB flush timed out,
falling back to full flush

Without the series, the kernel goes far and display works, however there
are other issues affecting the cros-ec, but I think that's another issue.

I'll try to dig a bit more, but, meanwhile, if you have any idea please let
me know.

Thanks,
 Enric



> Regards,
> Chun-Kuang.
>
> >
> > Changes in v2:
> > 1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy()
> >when CONFIG_MTK_CMDQ is reachable.
> >
> > Chun-Kuang Hu (4):
> >   drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb
> >   drm/mediatek: Remove struct cmdq_client
> >   drm/mediatek: Detect CMDQ execution timeout
> >   drm/mediatek: Add cmdq_handle in mtk_crtc
> >
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 110 
> >  1 file changed, 91 insertions(+), 19 deletions(-)
> >
> > --
> > 2.25.1
> >
>

Re: [PATCH v8, 2/2] soc: mediatek: mmsys: Add mt8192 mmsys routing table

[Enric Balletbo Serra]

Hi Yongqiang,

Thank you for your patch

Missatge de Yongqiang Niu  del dia dl., 2
d’ag. 2021 a les 11:00:
>
> mt8192 has different routing registers than mt8183
>

... than mt8183 and other Mediatek SoC's I guess ;-)

> Signed-off-by: Yongqiang Niu 

Reviewed-by: Enric Balletbo i Serra 

Thanks,
   Enric


> ---
>  drivers/soc/mediatek/mt8192-mmsys.h | 67 
> +
>  drivers/soc/mediatek/mtk-mmsys.c| 11 ++
>  2 files changed, 78 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h
>
> diff --git a/drivers/soc/mediatek/mt8192-mmsys.h 
> b/drivers/soc/mediatek/mt8192-mmsys.h
> new file mode 100644
> index 000..0e4b233
> --- /dev/null
> +++ b/drivers/soc/mediatek/mt8192-mmsys.h
> @@ -0,0 +1,67 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __SOC_MEDIATEK_MT8192_MMSYS_H
> +#define __SOC_MEDIATEK_MT8192_MMSYS_H
> +
> +#define MT8192_MMSYS_OVL_MOUT_EN   0xf04
> +#define MT8192_DISP_OVL1_2L_MOUT_EN0xf08
> +#define MT8192_DISP_OVL0_2L_MOUT_EN0xf18
> +#define MT8192_DISP_OVL0_MOUT_EN   0xf1c
> +#define MT8192_DISP_RDMA0_SEL_IN   0xf2c
> +#define MT8192_DISP_RDMA0_SOUT_SEL 0xf30
> +#define MT8192_DISP_CCORR0_SOUT_SEL0xf34
> +#define MT8192_DISP_AAL0_SEL_IN0xf38
> +#define MT8192_DISP_DITHER0_MOUT_EN0xf3c
> +#define MT8192_DISP_DSI0_SEL_IN0xf40
> +#define MT8192_DISP_OVL2_2L_MOUT_EN0xf4c
> +
> +#define MT8192_DISP_OVL0_GO_BLEND  BIT(0)
> +#define MT8192_DITHER0_MOUT_IN_DSI0BIT(0)
> +#define MT8192_OVL0_MOUT_EN_DISP_RDMA0 BIT(0)
> +#define MT8192_OVL2_2L_MOUT_EN_RDMA4   BIT(0)
> +#define MT8192_DISP_OVL0_GO_BG BIT(1)
> +#define MT8192_DISP_OVL0_2L_GO_BLEND   BIT(2)
> +#define MT8192_DISP_OVL0_2L_GO_BG  BIT(3)
> +#define MT8192_OVL1_2L_MOUT_EN_RDMA1   BIT(4)
> +#define MT8192_OVL0_MOUT_EN_OVL0_2LBIT(4)
> +#define MT8192_RDMA0_SEL_IN_OVL0_2L0x3
> +#define MT8192_RDMA0_SOUT_COLOR0   0x1
> +#define MT8192_CCORR0_SOUT_AAL00x1
> +#define MT8192_AAL0_SEL_IN_CCORR0  0x1
> +#define MT8192_DSI0_SEL_IN_DITHER0 0x1
> +
> +static const struct mtk_mmsys_routes mmsys_mt8192_routing_table[] = {
> +   {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   MT8192_DISP_OVL0_2L_MOUT_EN, MT8192_OVL0_MOUT_EN_DISP_RDMA0,
> +   }, {
> +   DDP_COMPONENT_OVL_2L2, DDP_COMPONENT_RDMA4,
> +   MT8192_DISP_OVL2_2L_MOUT_EN, MT8192_OVL2_2L_MOUT_EN_RDMA4
> +   }, {
> +   DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> +   MT8192_DISP_DITHER0_MOUT_EN, MT8192_DITHER0_MOUT_IN_DSI0
> +   }, {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   MT8192_DISP_RDMA0_SEL_IN, MT8192_RDMA0_SEL_IN_OVL0_2L
> +   }, {
> +   DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
> +   MT8192_DISP_AAL0_SEL_IN, MT8192_AAL0_SEL_IN_CCORR0
> +   }, {
> +   DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> +   MT8192_DISP_DSI0_SEL_IN, MT8192_DSI0_SEL_IN_DITHER0
> +   }, {
> +   DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
> +   MT8192_DISP_RDMA0_SOUT_SEL, MT8192_RDMA0_SOUT_COLOR0
> +   }, {
> +   DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
> +   MT8192_DISP_CCORR0_SOUT_SEL, MT8192_CCORR0_SOUT_AAL0
> +   }, {
> +   DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
> +   MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_GO_BG,
> +   }, {
> +   DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> +   MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_2L_GO_BLEND,
> +   }
> +};
> +
> +#endif /* __SOC_MEDIATEK_MT8192_MMSYS_H */
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
> b/drivers/soc/mediatek/mtk-mmsys.c
> index 080660e..de7b122 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -13,6 +13,7 @@
>  #include "mtk-mmsys.h"
>  #include "mt8167-mmsys.h"
>  #include "mt8183-mmsys.h"
> +#include "mt8192-mmsys.h"
>
>  static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .clk_driver = "clk-mt2701-mm",
> @@ -52,6 +53,12 @@
> .num_routes = ARRAY_SIZE(mmsys_mt8183_routing_table),
>  };
>
> +static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
> +   .clk_driver = "clk-mt8192-mm",
> +   .routes = mmsys_mt8192_routing_table,
> +   .num_routes = ARRAY_SIZE(mmsys_mt8192_routing_table),
> +};
> +
>  struct mtk_mmsys {
> void __iomem *regs;
> const struct mtk_mmsys_driver_data *data;
> @@ -157,6 +164,10 @@ static int 

Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

[Enric Balletbo Serra]

Hi Jason,

Missatge de Jason-JH Lin  del dia dt., 27
de jul. 2021 a les 4:53:
>
> Hi Enric,
>
> On Mon, 2021-07-26 at 12:08 +0200, Enric Balletbo Serra wrote:
> > Hi Jason,
> >
> > Missatge de Jason-JH Lin  del dia dl., 26
> > de jul. 2021 a les 9:02:
> > >
> > > On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:
> > > > Hi Jason,
> > > >
> > > > Thank you for your patch.
> > > >
> > > > Missatge de jason-jh.lin  del dia dj.,
> > > > 22
> > > > de jul. 2021 a les 11:26:
> > > > >
> > > > > There are 2 display hardware path in mt8195, namely vdosys0 and
> > > > > vdosys1, so add their definition in mtk-mmsys documentation.
> > > > >
> > > >
> > > > Just having 2 display hardware paths is not a reason to have two
> > > > compatibles, isn't the IP block the same? Why do you need to
> > > > introduce
> > > > the two compatibles?
> > > >
> > > > Thanks,
> > > >   Enric
> > > >
> > >
> > > Hi Enric,
> > >
> > > Thanks for reviewing my patch.
> > >
> > > The reason for using two compatibles is that vdosys0 and vdosys1
> > > are
> > > different IP blocks.
> > >
> >
> > With that there are different IP blocks, what do you mean? Do you
> > mean
> > that there are two completely different blocks with completely
> > different functionalities?
> >
> > Or that there is the same IP block twice? I mean, of course, the
> > registers are different but has exactly the same functionality.
> >
>
> They are not the same IP block twice.
> Although both vdosys0 and vdosys1 will probe meiatek-drm driver, but
> the components on their hardware path are different and their output
> panel are also different.
>
> > > Because mmsys provides clock control, other display function blocks
> > > may
> > > use them as clock provider.
> > >
> > > E.g.
> > > 1. mmsys with compatible="mediatek,mt8195-vdosys0"
> > > [v4,1/6] arm64: dts: mt8195: add display node for vdosys0
> > >
> > >
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.24007-2-jason-jh@mediatek.com/__;!!CTRNKA9wMg0ARbw!xHjKwv34W7ETFcmQPXRViylF2LbV7C7pE8OeJeNvA93jDdzr_ZBRRm8aIUCvAHSD_qGo$
> > >
> > >
> > > ovl0: disp_ovl@1c00 {
> > > ...
> > > clocks = < CLK_VDO0_DISP_OVL0>;
> > > ...
> > > };
> > >
> > > 2. mmsys with compatible="mediatek,mt8195-vdosys1"
> > > [v2,06/14] arm64: dts: mt8195: add display node for vdosys1
> > >
> > >
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.15255-7-nancy@mediatek.com/__;!!CTRNKA9wMg0ARbw!xHjKwv34W7ETFcmQPXRViylF2LbV7C7pE8OeJeNvA93jDdzr_ZBRRm8aIUCvAP0FOfkc$
> > >
> > >
> > > vdo1_rdma0: vdo1_rdma@1c104000 {
> > > ...
> > > clocks = < CLK_VDO1_MDP_RDMA0>;
> > > ...
> > > };
> > >
> >
> > Note that I am talking without knowing the hardware in detail, but I
> > am wondering why I can't have something like this, where every mmsys
> > is a clock and reset controller provider.
> >
> > vdosys0: syscon@1400 {
> >   compatible = "mediatek,mt8195-mmsys", "syscon";
> >   reg = <0 0x1400 0 0x1000>;
> >   #clock-cells = <1>;
> >   #reset-cells = <1>;
> > };
> >
> > vdosys1: syscon@1500 {
> >   compatible = "mediatek,mt8195-mmsys", "syscon";
> >   reg = <0 0x1500 0 0x1000>;
> >   #clock-cells = <1>;
> >   #reset-cells = <1>;
> > };
> >
> > ovl0: disp_ovl@1c00 {
> > ...
> >clocks = < CLK_VDO0_DISP_OVL0>;
> > ...
> > };
> >
> > vdo1_rdma0: vdo1_rdma@1c104000 {
> > ...
> > clocks = < CLK_VDO1_MDP_RDMA0>;
> > ...
> > };
> >
> > What are the differences between vdosys0 and vdosys1 from a hardware
> > point of view?
> >
> > Cheers,
> >   Enric
> >
> > > Regards,
> > > Jason-JH.Lin
> > >
>
> From a hardware point of view, the components and the ouptut panel of
> vdosys0 

Re: [PATCH v2 09/14] soc: mediatek: mmsys: Add reset controller support for MT8195 vdosys1

[Enric Balletbo Serra]

Hi Nancy,

Missatge de Nancy.Lin  del dia dc., 28 de jul.
2021 a les 8:01:
>
> Hi Enric,
>
> Thanks for your review.
>
> On Fri, 2021-07-23 at 12:57 +0200, Enric Balletbo Serra wrote:
> > Hi Nancy,
> >
> > Thank you for your patch.
> >
> > Missatge de Nancy.Lin  del dia dj., 22 de
> > jul.
> > 2021 a les 11:46:
> > >
> > > Among other features the mmsys driver should implement a reset
> > > controller to be able to reset different bits from their space.
> > >
> >
> > I'm working on a series that does the same, it should be nice if we
> > can coordinate [1]
> >
> > [1]
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=515355__;!!CTRNKA9wMg0ARbw!xP6Ko9hF-3KasGgr7-8Aby_tCwiU2M6gFBAngDLVcJjzooj-MEeTcNG8cf2e9wGb$
> >
> >
> OK, I will add this series to my reference base in the next patch
> revision.
>
> > > Signed-off-by: Nancy.Lin 
> > > ---
> > >  drivers/soc/mediatek/mt8195-mmsys.h |  1 +
> > >  drivers/soc/mediatek/mtk-mmsys.c| 77
> > > +
> > >  drivers/soc/mediatek/mtk-mmsys.h|  1 +
> > >  3 files changed, 79 insertions(+)
> > >
> > > diff --git a/drivers/soc/mediatek/mt8195-mmsys.h
> > > b/drivers/soc/mediatek/mt8195-mmsys.h
> > > index 4bdb2087250c..a7f6e275bfe5 100644
> > > --- a/drivers/soc/mediatek/mt8195-mmsys.h
> > > +++ b/drivers/soc/mediatek/mt8195-mmsys.h
> > > @@ -154,6 +154,7 @@
> > >  #define DISP_DP_INTF0_SEL_IN_FROM_VDO0_MERGE_DL_ASYNC_MOUT (1
> > > << 0)
> > >  #define DISP_DP_INTF0_SEL_IN_FROM_VDO0_DSC_DL_ASYNC_MOUT   (2
> > > << 0)
> > >
> > > +#define MT8195_VDO1_SW0_RST_B   0x1d0
> > >  #define MT8195_VDO1_MERGE0_ASYNC_CFG_WD0xe30
> > >  #define MT8195_VDO1_MERGE1_ASYNC_CFG_WD0xe40
> > >  #define MT8195_VDO1_MERGE2_ASYNC_CFG_WD0xe50
> > > diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> > > b/drivers/soc/mediatek/mtk-mmsys.c
> > > index d0f4a407f8f8..1ae04efeadab 100644
> > > --- a/drivers/soc/mediatek/mtk-mmsys.c
> > > +++ b/drivers/soc/mediatek/mtk-mmsys.c
> > > @@ -4,10 +4,12 @@
> > >   * Author: James Liao 
> > >   */
> > >
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >
> > >  #include "mtk-mmsys.h"
> > > @@ -15,6 +17,8 @@
> > >  #include "mt8183-mmsys.h"
> > >  #include "mt8195-mmsys.h"
> > >
> > > +#define MMSYS_SW_RESET_PER_REG 32
> > > +
> > >  static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data
> > > = {
> > > .clk_driver = "clk-mt2701-mm",
> > > .routes = mmsys_default_routing_table,
> > > @@ -65,12 +69,15 @@ static const struct mtk_mmsys_driver_data
> > > mt8195_vdosys1_driver_data = {
> > > .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table),
> > > .config = mmsys_mt8195_config_table,
> > > .num_configs = ARRAY_SIZE(mmsys_mt8195_config_table),
> > > +   .sw_reset_start = MT8195_VDO1_SW0_RST_B,
> >
> > That change is interesting and I think I should also take it into
> > consideration with my series.
> >
> > >  };
> > >
> > >  struct mtk_mmsys {
> > > void __iomem *regs;
> > > struct cmdq_client_reg cmdq_base;
> > > const struct mtk_mmsys_driver_data *data;
> > > +   spinlock_t lock; /* protects mmsys_sw_rst_b reg */
> >
> > Seems that mmsys_sw_rst_b reg has different names for different SoCs?
> > I mean I know that for MT8173 and MT8183 the register is called
> > mmsys_sw0_rst_b but looks like for MT8195 the name is vdo1_sw0_rst_b?
> > So maybe we should update this comment to be more generic.
> >
> Yes, the name of MT8195 vdosys1 sw reset is called VDOSYS1_SW0_RST_B
> and the name of vdosys0 sw reset is called GLOBAL0_SW0_RST_B. They have
> a different name. Maybe we can change the comment to "protects mmsys sw
> reset reg".
>
> > >
>
> > > +   struct reset_controller_dev rcdev;
> > >  };
> > >
> > >  void mtk_mmsys_ddp_connect(struct device *dev,
> > > @@ -148,6 +155,63 @@ void mtk_mmsys_ddp_config(struct device *dev,
> > > enum mtk_mmsys_config_type config,
> >

Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

[Enric Balletbo Serra]

Hi Jason,

Missatge de Jason-JH Lin  del dia dl., 26
de jul. 2021 a les 9:02:
>
> On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:
> > Hi Jason,
> >
> > Thank you for your patch.
> >
> > Missatge de jason-jh.lin  del dia dj., 22
> > de jul. 2021 a les 11:26:
> > >
> > > There are 2 display hardware path in mt8195, namely vdosys0 and
> > > vdosys1, so add their definition in mtk-mmsys documentation.
> > >
> >
> > Just having 2 display hardware paths is not a reason to have two
> > compatibles, isn't the IP block the same? Why do you need to
> > introduce
> > the two compatibles?
> >
> > Thanks,
> >   Enric
> >
>
> Hi Enric,
>
> Thanks for reviewing my patch.
>
> The reason for using two compatibles is that vdosys0 and vdosys1 are
> different IP blocks.
>

With that there are different IP blocks, what do you mean? Do you mean
that there are two completely different blocks with completely
different functionalities?

Or that there is the same IP block twice? I mean, of course, the
registers are different but has exactly the same functionality.

> Because mmsys provides clock control, other display function blocks may
> use them as clock provider.
>
> E.g.
> 1. mmsys with compatible="mediatek,mt8195-vdosys0"
> [v4,1/6] arm64: dts: mt8195: add display node for vdosys0
>
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.24007-2-jason-jh@mediatek.com/
>
> ovl0: disp_ovl@1c00 {
> ...
> clocks = < CLK_VDO0_DISP_OVL0>;
> ...
> };
>
> 2. mmsys with compatible="mediatek,mt8195-vdosys1"
> [v2,06/14] arm64: dts: mt8195: add display node for vdosys1
>
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.15255-7-nancy@mediatek.com/
>
> vdo1_rdma0: vdo1_rdma@1c104000 {
> ...
> clocks = < CLK_VDO1_MDP_RDMA0>;
> ...
> };
>

Note that I am talking without knowing the hardware in detail, but I
am wondering why I can't have something like this, where every mmsys
is a clock and reset controller provider.

vdosys0: syscon@1400 {
  compatible = "mediatek,mt8195-mmsys", "syscon";
  reg = <0 0x1400 0 0x1000>;
  #clock-cells = <1>;
  #reset-cells = <1>;
};

vdosys1: syscon@1500 {
  compatible = "mediatek,mt8195-mmsys", "syscon";
  reg = <0 0x1500 0 0x1000>;
  #clock-cells = <1>;
  #reset-cells = <1>;
};

ovl0: disp_ovl@1c00 {
...
   clocks = < CLK_VDO0_DISP_OVL0>;
...
};

vdo1_rdma0: vdo1_rdma@1c104000 {
...
clocks = < CLK_VDO1_MDP_RDMA0>;
...
};

What are the differences between vdosys0 and vdosys1 from a hardware
point of view?

Cheers,
  Enric

> Regards,
> Jason-JH.Lin
>
> > > Signed-off-by: jason-jh.lin 
> > > ---
> > > this patch is base on [1][2]
> > >
> > > [1] dt-bindings: arm: mediatek: mmsys: convert to YAML format
> > > -
> > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-1-fpar...@baylibre.com/__;!!CTRNKA9wMg0ARbw!ycgPEK4yBDojiiZJC2E9mGwvxJbaLqhyUxzJIq0ckEP-JVteBcjFdc6ixkNbmknH8f2P$
> > >
> > > [2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding
> > > -
> > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-2-fpar...@baylibre.com/__;!!CTRNKA9wMg0ARbw!ycgPEK4yBDojiiZJC2E9mGwvxJbaLqhyUxzJIq0ckEP-JVteBcjFdc6ixkNbmju2GBrD$
> > >
> > > ---
> > >  .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml|
> > > 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > index 2d4ff0ce387b..0789a9614f12 100644
> > > ---
> > > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > +++
> > > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
> > > l
> > > @@ -30,6 +30,8 @@ properties:
> > >- mediatek,mt8173-mmsys
> > >- mediatek,mt8183-mmsys
> > >- mediatek,mt8365-mmsys
> > > +  - mediatek,mt8195-vdosys0
> > > +  - mediatek,mt8195-vdosys1
> > >- const: syscon
> > >- items:
> > >- const: mediatek,mt7623-mmsys
> > > --
> > > 2.18.0
> > >
> --

Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

[Enric Balletbo Serra]

Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin  del dia dj., 22
de jul. 2021 a les 11:26:
>
> There are 2 display hardware path in mt8195, namely vdosys0 and
> vdosys1, so add their definition in mtk-mmsys documentation.
>

Just having 2 display hardware paths is not a reason to have two
compatibles, isn't the IP block the same? Why do you need to introduce
the two compatibles?

Thanks,
  Enric

> Signed-off-by: jason-jh.lin 
> ---
> this patch is base on [1][2]
>
> [1] dt-bindings: arm: mediatek: mmsys: convert to YAML format
> - 
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-1-fpar...@baylibre.com/
> [2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding
> - 
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-2-fpar...@baylibre.com/
> ---
>  .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml| 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml 
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> index 2d4ff0ce387b..0789a9614f12 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> @@ -30,6 +30,8 @@ properties:
>- mediatek,mt8173-mmsys
>- mediatek,mt8183-mmsys
>- mediatek,mt8365-mmsys
> +  - mediatek,mt8195-vdosys0
> +  - mediatek,mt8195-vdosys1
>- const: syscon
>- items:
>- const: mediatek,mt7623-mmsys
> --
> 2.18.0
>

Re: [PATCH v2 04/14] dt-bindings: reset: mt8195: Move reset controller constants into common location

[Enric Balletbo Serra]

Hi Nancy,

Thank you for your patch

Missatge de Nancy.Lin  del dia dj., 22 de jul.
2021 a les 11:46:
>
> The DT binding includes for reset controllers are located in
> include/dt-bindings/reset/. Move the Mediatek reset constants in there.
>

I think that the patch that introduces mt8195-resets.h into the
reset-controller directory didn't land yet, please sync with the
author of that patch and just put it in the correct place the first
time.

Thanks,
  Enric

> Signed-off-by: Nancy.Lin 
> ---
>  include/dt-bindings/{reset-controller => reset}/mt8195-resets.h | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename include/dt-bindings/{reset-controller => reset}/mt8195-resets.h (100%)
>
> diff --git a/include/dt-bindings/reset-controller/mt8195-resets.h 
> b/include/dt-bindings/reset/mt8195-resets.h
> similarity index 100%
> rename from include/dt-bindings/reset-controller/mt8195-resets.h
> rename to include/dt-bindings/reset/mt8195-resets.h
> --
> 2.18.0
>

Re: [PATCH v2 07/14] soc: mediatek: add mtk-mmsys support for mt8195 vdosys1

[Enric Balletbo Serra]

Hi Nancy,

Thank you for your patch.

Missatge de Nancy.Lin  del dia dj., 22 de jul.
2021 a les 11:45:
>
> Add mt8195 vdosys1 clock driver name and routing table to
> the driver data of mtk-mmsys.
>
> Signed-off-by: Nancy.Lin 
> ---
>  drivers/soc/mediatek/mt8195-mmsys.h| 83 --
>  drivers/soc/mediatek/mtk-mmsys.c   | 10 
>  include/linux/soc/mediatek/mtk-mmsys.h |  2 +
>  3 files changed, 90 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mt8195-mmsys.h 
> b/drivers/soc/mediatek/mt8195-mmsys.h
> index 73e9e8286d50..104ba575f765 100644
> --- a/drivers/soc/mediatek/mt8195-mmsys.h
> +++ b/drivers/soc/mediatek/mt8195-mmsys.h
> @@ -64,16 +64,16 @@
>  #define SOUT_TO_VPP_MERGE0_P1_SEL  (1 << 0)
>
>  #define MT8195_VDO1_MERGE0_ASYNC_SOUT_SEL  0xf40
> -#define SOUT_TO_HDR_VDO_FE0(0 << 0)

This definition was introduced in this patch [1] that didn't land yet.
And you're removing it now. Could you sync with Jason and only
introduce the bits that are needed for your patches. Also all the
comments I made to the Jason's patch apply here.

[1] 
https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.24007-3-jason-jh@mediatek.com/

> +#define SOUT_TO_MIXER_IN1_SEL  (1 << 0)
>
>  #define MT8195_VDO1_MERGE1_ASYNC_SOUT_SEL  0xf44
> -#define SOUT_TO_HDR_VDO_FE1(0 << 0)
> +#define SOUT_TO_MIXER_IN2_SEL  (1 << 0)
>
>  #define MT8195_VDO1_MERGE2_ASYNC_SOUT_SEL  0xf48
> -#define SOUT_TO_HDR_GFX_FE0(0 << 0)
> +#define SOUT_TO_MIXER_IN3_SEL  (1 << 0)
>
>  #define MT8195_VDO1_MERGE3_ASYNC_SOUT_SEL  0xf4c
> -#define SOUT_TO_HDR_GFX_FE1(0 << 0)
> +#define SOUT_TO_MIXER_IN4_SEL  (1 << 0)
>
>  #define MT8195_VDO1_MIXER_IN1_SOUT_SEL 0xf58
>  #define MIXER_IN1_SOUT_TO_DISP_MIXER   (0 << 0)
> @@ -88,7 +88,7 @@
>  #define MIXER_IN4_SOUT_TO_DISP_MIXER   (0 << 0)
>
>  #define MT8195_VDO1_MIXER_OUT_SOUT_SEL 0xf34
> -#define MIXER_SOUT_TO_HDR_VDO_BE0  (0 << 0)
> +#define MIXER_SOUT_TO_MERGE4_ASYNC_SEL (1 << 0)
>
>  #define MT8195_VDO1_MERGE4_SOUT_SEL0xf18
>  #define MERGE4_SOUT_TO_VDOSYS0 (0 << 0)
> @@ -185,6 +185,79 @@ static const struct mtk_mmsys_routes 
> mmsys_mt8195_routing_table[] = {
> }, {
> DDP_COMPONENT_DSC0, DDP_COMPONENT_MERGE0,
> MT8195_VDO0_SEL_OUT, SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_VPP_MERGE0_P0_SEL_IN, 
> VPP_MERGE0_P0_SEL_IN_FROM_MDP_RDMA0
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_VPP_MERGE0_P1_SEL_IN, 
> VPP_MERGE0_P1_SEL_IN_FROM_MDP_RDMA1
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_VPP_MERGE1_P0_SEL_IN, 
> VPP_MERGE1_P0_SEL_IN_FROM_MDP_RDMA2
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MERGE0_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN1_SEL
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MERGE1_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN2_SEL
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MERGE2_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN3_SEL
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MERGE3_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN4_SEL
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MIXER_OUT_SOUT_SEL, MIXER_SOUT_TO_MERGE4_ASYNC_SEL
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MIXER_IN1_SEL_IN, 
> MIXER_IN1_SEL_IN_FROM_MERGE0_ASYNC_SOUT
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MIXER_IN2_SEL_IN, 
> MIXER_IN2_SEL_IN_FROM_MERGE1_ASYNC_SOUT
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MIXER_IN3_SEL_IN, 
> MIXER_IN3_SEL_IN_FROM_MERGE2_ASYNC_SOUT
> +   },
> +   {
> +   DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> +   MT8195_VDO1_MIXER_IN4_SEL_IN, 
> 

Re: [PATCH v2 09/14] soc: mediatek: mmsys: Add reset controller support for MT8195 vdosys1

[Enric Balletbo Serra]

Hi Nancy,

Thank you for your patch.

Missatge de Nancy.Lin  del dia dj., 22 de jul.
2021 a les 11:46:
>
> Among other features the mmsys driver should implement a reset
> controller to be able to reset different bits from their space.
>

I'm working on a series that does the same, it should be nice if we
can coordinate [1]

[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=515355

> Signed-off-by: Nancy.Lin 
> ---
>  drivers/soc/mediatek/mt8195-mmsys.h |  1 +
>  drivers/soc/mediatek/mtk-mmsys.c| 77 +
>  drivers/soc/mediatek/mtk-mmsys.h|  1 +
>  3 files changed, 79 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mt8195-mmsys.h 
> b/drivers/soc/mediatek/mt8195-mmsys.h
> index 4bdb2087250c..a7f6e275bfe5 100644
> --- a/drivers/soc/mediatek/mt8195-mmsys.h
> +++ b/drivers/soc/mediatek/mt8195-mmsys.h
> @@ -154,6 +154,7 @@
>  #define DISP_DP_INTF0_SEL_IN_FROM_VDO0_MERGE_DL_ASYNC_MOUT (1 << 0)
>  #define DISP_DP_INTF0_SEL_IN_FROM_VDO0_DSC_DL_ASYNC_MOUT   (2 << 0)
>
> +#define MT8195_VDO1_SW0_RST_B   0x1d0
>  #define MT8195_VDO1_MERGE0_ASYNC_CFG_WD0xe30
>  #define MT8195_VDO1_MERGE1_ASYNC_CFG_WD0xe40
>  #define MT8195_VDO1_MERGE2_ASYNC_CFG_WD0xe50
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
> b/drivers/soc/mediatek/mtk-mmsys.c
> index d0f4a407f8f8..1ae04efeadab 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -4,10 +4,12 @@
>   * Author: James Liao 
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "mtk-mmsys.h"
> @@ -15,6 +17,8 @@
>  #include "mt8183-mmsys.h"
>  #include "mt8195-mmsys.h"
>
> +#define MMSYS_SW_RESET_PER_REG 32
> +
>  static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .clk_driver = "clk-mt2701-mm",
> .routes = mmsys_default_routing_table,
> @@ -65,12 +69,15 @@ static const struct mtk_mmsys_driver_data 
> mt8195_vdosys1_driver_data = {
> .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table),
> .config = mmsys_mt8195_config_table,
> .num_configs = ARRAY_SIZE(mmsys_mt8195_config_table),
> +   .sw_reset_start = MT8195_VDO1_SW0_RST_B,

That change is interesting and I think I should also take it into
consideration with my series.

>  };
>
>  struct mtk_mmsys {
> void __iomem *regs;
> struct cmdq_client_reg cmdq_base;
> const struct mtk_mmsys_driver_data *data;
> +   spinlock_t lock; /* protects mmsys_sw_rst_b reg */

Seems that mmsys_sw_rst_b reg has different names for different SoCs?
I mean I know that for MT8173 and MT8183 the register is called
mmsys_sw0_rst_b but looks like for MT8195 the name is vdo1_sw0_rst_b?
So maybe we should update this comment to be more generic.

> +   struct reset_controller_dev rcdev;
>  };
>
>  void mtk_mmsys_ddp_connect(struct device *dev,
> @@ -148,6 +155,63 @@ void mtk_mmsys_ddp_config(struct device *dev, enum 
> mtk_mmsys_config_type config,
>  }
>  EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_config);
>
> +static int mtk_mmsys_reset_update(struct reset_controller_dev *rcdev, 
> unsigned long id,
> + bool assert)
> +{
> +   struct mtk_mmsys *mmsys = container_of(rcdev, struct mtk_mmsys, 
> rcdev);
> +   unsigned long flags;
> +   u32 reg;
> +   int i;
> +   u32 offset;
> +
> +   offset = (id / MMSYS_SW_RESET_PER_REG) * sizeof(u32);
> +   id = 1 << (id % MMSYS_SW_RESET_PER_REG);
> +
> +   spin_lock_irqsave(>lock, flags);
> +
> +   reg = readl_relaxed(mmsys->regs + mmsys->data->sw_reset_start + 
> offset);
> +
> +   if (assert)
> +   reg &= ~BIT(id);
> +   else
> +   reg |= BIT(id);
> +
> +   writel_relaxed(reg, mmsys->regs + mmsys->data->sw_reset_start + 
> offset);
> +
> +   spin_unlock_irqrestore(>lock, flags);
> +
> +   return 0;
> +}
> +
> +static int mtk_mmsys_reset_assert(struct reset_controller_dev *rcdev, 
> unsigned long id)
> +{
> +   return mtk_mmsys_reset_update(rcdev, id, true);
> +}
> +
> +static int mtk_mmsys_reset_deassert(struct reset_controller_dev *rcdev, 
> unsigned long id)
> +{
> +   return mtk_mmsys_reset_update(rcdev, id, false);
> +}
> +
> +static int mtk_mmsys_reset(struct reset_controller_dev *rcdev, unsigned long 
> id)
> +{
> +   int ret;
> +
> +   ret = mtk_mmsys_reset_assert(rcdev, id);
> +   if (ret)
> +   return ret;
> +
> +   usleep_range(1000, 1100);
> +

One question that I received in my series, and I couldn't answer
because I don't have the datasheet, is if
is this known to be enough for all IP cores that can be reset by this
controller? Is this time specified in the datasheet?

> +   return mtk_mmsys_reset_deassert(rcdev, id);
> +}
> +
> +static const struct reset_control_ops mtk_mmsys_reset_ops = {
> +   .assert = mtk_mmsys_reset_assert,
> +   .deassert = mtk_mmsys_reset_deassert,

Re: [PATCH v4 2/6] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0

[Enric Balletbo Serra]

Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin  del dia dv., 23
de jul. 2021 a les 11:02:
>
> Add mt8195 vdosys0 clock driver name and routing table to
> the driver data of mtk-mmsys.
>
> Signed-off-by: jason-jh.lin 
> ---
> This patch is base on [1]
>
> [1]add mt8195 SoC DRM binding
> - https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
> ---
>  drivers/soc/mediatek/mt8195-mmsys.h| 191 +
>  drivers/soc/mediatek/mtk-mmsys.c   |  11 ++
>  include/linux/soc/mediatek/mtk-mmsys.h |   9 ++
>  3 files changed, 211 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h
>
> diff --git a/drivers/soc/mediatek/mt8195-mmsys.h 
> b/drivers/soc/mediatek/mt8195-mmsys.h
> new file mode 100644
> index ..73e9e8286d50
> --- /dev/null
> +++ b/drivers/soc/mediatek/mt8195-mmsys.h
> @@ -0,0 +1,191 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __SOC_MEDIATEK_MT8195_MMSYS_H
> +#define __SOC_MEDIATEK_MT8195_MMSYS_H
> +
> +#define MT8195_VDO0_OVL_MOUT_EN0xf14
> +#define MOUT_DISP_OVL0_TO_DISP_RDMA0   BIT(0)

This define and the others should use the MT8195_ prefix, as these are
MT8195 afaik


> +#define MOUT_DISP_OVL0_TO_DISP_WDMA0   BIT(1)
> +#define MOUT_DISP_OVL0_TO_DISP_OVL1BIT(2)
> +#define MOUT_DISP_OVL1_TO_DISP_RDMA1   BIT(4)
> +#define MOUT_DISP_OVL1_TO_DISP_WDMA1   BIT(5)
> +#define MOUT_DISP_OVL1_TO_DISP_OVL0BIT(6)
> +
> +#define MT8195_VDO0_SEL_IN 0xf34
> +#define SEL_IN_VPP_MERGE_FROM_DSC_WRAP0_OUT(0 << 0)
> +#define SEL_IN_VPP_MERGE_FROM_DISP_DITHER1 (1 << 0)
> +#define SEL_IN_VPP_MERGE_FROM_VDO1_VIRTUAL0(2 << 0)
> +#define SEL_IN_DSC_WRAP0_IN_FROM_DISP_DITHER0  (0 << 4)
> +#define SEL_IN_DSC_WRAP0_IN_FROM_VPP_MERGE (1 << 4)
> +#define SEL_IN_DSC_WRAP1_IN_FROM_DISP_DITHER1  (0 << 5)
> +#define SEL_IN_DSC_WRAP1_IN_FROM_VPP_MERGE (1 << 5)
> +#define SEL_IN_SINA_VIRTUAL0_FROM_VPP_MERGE(0 << 8)
> +#define SEL_IN_SINA_VIRTUAL0_FROM_DSC_WRAP1_OUT(1 << 
> 8)
> +#define SEL_IN_SINB_VIRTUAL0_FROM_DSC_WRAP0_OUT(0 << 
> 9)
> +#define SEL_IN_DP_INTF0_FROM_DSC_WRAP1_OUT (0 << 12)
> +#define SEL_IN_DP_INTF0_FROM_VPP_MERGE (1 << 12)
> +#define SEL_IN_DP_INTF0_FROM_VDO1_VIRTUAL0 (2 << 12)
> +#define SEL_IN_DSI0_FROM_DSC_WRAP0_OUT (0 << 16)
> +#define SEL_IN_DSI0_FROM_DISP_DITHER0  (1 << 16)
> +#define SEL_IN_DSI1_FROM_DSC_WRAP1_OUT (0 << 17)
> +#define SEL_IN_DSI1_FROM_VPP_MERGE (1 << 17)
> +#define SEL_IN_DISP_WDMA1_FROM_DISP_OVL1   (0 << 20)
> +#define SEL_IN_DISP_WDMA1_FROM_VPP_MERGE   (1 << 20)
> +#define SEL_IN_DSC_WRAP1_OUT_FROM_DSC_WRAP1_IN (0 << 21)
> +#define SEL_IN_DSC_WRAP1_OUT_FROM_DISP_DITHER1 (1 << 21)
> +#define SEL_IN_DISP_WDMA0_FROM_DISP_OVL0   (0 << 22)
> +#define SEL_IN_DISP_WDMA0_FROM_VPP_MERGE   (1 << 22)
> +
> +#define MT8195_VDO0_SEL_OUT0xf38
> +#define SOUT_DISP_DITHER0_TO_DSC_WRAP0_IN  (0 << 0)
> +#define SOUT_DISP_DITHER0_TO_DSI0  (1 << 0)
> +#define SOUT_DISP_DITHER1_TO_DSC_WRAP1_IN  (0 << 1)
> +#define SOUT_DISP_DITHER1_TO_VPP_MERGE (1 << 1)
> +#define SOUT_DISP_DITHER1_TO_DSC_WRAP1_OUT (2 << 1)
> +#define SOUT_VDO1_VIRTUAL0_TO_VPP_MERGE(0 << 
> 4)
> +#define SOUT_VDO1_VIRTUAL0_TO_DP_INTF0 (1 << 4)
> +#define SOUT_VPP_MERGE_TO_DSI1 (0 << 8)
> +#define SOUT_VPP_MERGE_TO_DP_INTF0 (1 << 8)
> +#define SOUT_VPP_MERGE_TO_SINA_VIRTUAL0(2 << 
> 8)
> +#define SOUT_VPP_MERGE_TO_DISP_WDMA1   (3 << 8)
> +#define SOUT_VPP_MERGE_TO_DSC_WRAP0_IN (4 << 8)
> +#define SOUT_VPP_MERGE_TO_DSC_WRAP1_IN (0 << 11)
> +#define SOUT_VPP_MERGE_TO_DISP_WDMA0   (1 << 11)
> +#define SOUT_DSC_WRAP0_OUT_TO_DSI0 (0 << 12)
> +#define SOUT_DSC_WRAP0_OUT_TO_SINB_VIRTUAL0(1 << 12)
> +#define SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE(2 << 
> 12)
> +#define SOUT_DSC_WRAP1_OUT_TO_DSI1 (0 << 16)
> +#define SOUT_DSC_WRAP1_OUT_TO_DP_INTF0 (1 

Re: [PATCH v2 1/1] Fix cursor plane didn't update

[Enric Balletbo Serra]

Hi Jason-jh,

Thank you for your patch. Please prefix this patch with 'drm/mediatek'
so it is clear what the changes are.

Missatge de jason-jh.lin  del dia dl., 19
de jul. 2021 a les 10:24:
>
> The cursor plane should use the current plane state in atomic_async_update
> because it would not be the new plane state in the global atomic state
> since _swap_state happened when those hook are run.
>
> Fix cursor plane issue by below modification:
> 1. Remove plane_helper_funcs->atomic_update(plane, state) in
>mtk_drm_crtc_async_update.
> 2. Add mtk_drm_update_new_state in to mtk_plane_atomic_async_update to
>update the cursor plane by current plan hook and update the normal
>plane by the new_state.
>
> Fixes: 37418bf14c13 ("drm: Use state helper instead of the plane state 
> pointer")
>

Drop this new line

> Signed-off-by: jason-jh.lin 

The patch below fixes the cursor issue on my two boards, one based on
mt8173 and the other on mt8183, so

Tested-by: Enric Balletbo i Serra 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |  1 -
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 60 ++--
>  2 files changed, 34 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 474efb844249..063c75bab3a8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -538,7 +538,6 @@ void mtk_drm_crtc_async_update(struct drm_crtc *crtc, 
> struct drm_plane *plane,
> if (!mtk_crtc->enabled)
> return;
>
> -   plane_helper_funcs->atomic_update(plane, state);
> mtk_drm_crtc_update_config(mtk_crtc, false);
>  }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index b5582dcf564c..e6dcb34d3052 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -110,6 +110,35 @@ static int mtk_plane_atomic_async_check(struct drm_plane 
> *plane,
>true, true);
>  }
>
> +static void mtk_plane_update_new_state(struct drm_plane_state *new_state,
> +  struct mtk_plane_state 
> *mtk_plane_state)
> +{
> +   struct drm_framebuffer *fb = new_state->fb;
> +   struct drm_gem_object *gem;
> +   struct mtk_drm_gem_obj *mtk_gem;
> +   unsigned int pitch, format;
> +   dma_addr_t addr;
> +
> +   gem = fb->obj[0];
> +   mtk_gem = to_mtk_gem_obj(gem);
> +   addr = mtk_gem->dma_addr;
> +   pitch = fb->pitches[0];
> +   format = fb->format->format;
> +
> +   addr += (new_state->src.x1 >> 16) * fb->format->cpp[0];
> +   addr += (new_state->src.y1 >> 16) * pitch;
> +
> +   mtk_plane_state->pending.enable = true;
> +   mtk_plane_state->pending.pitch = pitch;
> +   mtk_plane_state->pending.format = format;
> +   mtk_plane_state->pending.addr = addr;
> +   mtk_plane_state->pending.x = new_state->dst.x1;
> +   mtk_plane_state->pending.y = new_state->dst.y1;
> +   mtk_plane_state->pending.width = drm_rect_width(_state->dst);
> +   mtk_plane_state->pending.height = drm_rect_height(_state->dst);
> +   mtk_plane_state->pending.rotation = new_state->rotation;
> +}
> +
>  static void mtk_plane_atomic_async_update(struct drm_plane *plane,
>   struct drm_atomic_state *state)
>  {
> @@ -126,8 +155,10 @@ static void mtk_plane_atomic_async_update(struct 
> drm_plane *plane,
> plane->state->src_h = new_state->src_h;
> plane->state->src_w = new_state->src_w;
> swap(plane->state->fb, new_state->fb);
> -   new_plane_state->pending.async_dirty = true;
>
> +   mtk_plane_update_new_state(new_state, new_plane_state);
> +   wmb(); /* Make sure the above parameters are set before update */
> +   new_plane_state->pending.async_dirty = true;
> mtk_drm_crtc_async_update(new_state->crtc, plane, state);
>  }
>
> @@ -189,14 +220,8 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
> struct drm_plane_state *new_state = 
> drm_atomic_get_new_plane_state(state,
>
> plane);
> struct mtk_plane_state *mtk_plane_state = 
> to_mtk_plane_state(new_state);
> -   struct drm_crtc *crtc = new_state->crtc;
> -   struct drm_framebuffer *fb = new_state->fb;
> -   struct drm_gem_object *gem;
> -   struct mtk_drm_gem_obj *mtk_gem;
> -   unsigned int pitch, format;
> -   dma_addr_t addr;
>
> -   if (!crtc || WARN_ON(!fb))
> +   if (!new_state->crtc || WARN_ON(!new_state->fb))
> return;
>
> if (!new_state->visible) {
> @@ -204,24 +229,7 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
> return;
> }
>
> -   gem = fb->obj[0];
> -   mtk_gem = 

Re: [PATCH v6 RESEND 3/3] arm64: dts: mt8183: Add panel rotation

[Enric Balletbo Serra]

Hi Hsin-Yi,

Thank you for the patch.

Missatge de Hsin-Yi Wang  del dia dj., 27 de maig
2021 a les 9:42:
>
> krane, kakadu, and kodama boards have a default panel rotation.
>
> Signed-off-by: Hsin-Yi Wang 

It looks good to me, so

Reviewed-by: Enric Balletbo i Serra 

and, on a Lenovo IdeaPad Duet. The display appears well rotated now.

Tested-by: Enric Balletbo i Serra 

Thanks,
  Enric
> ---
>  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index ff56bcfa3370..793cc9501337 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -263,6 +263,7 @@ panel: panel@0 {
> avee-supply = <_lcd>;
> pp1800-supply = <_lcd>;
> backlight = <_lcd0>;
> +   rotation = <270>;
> port {
> panel_in: endpoint {
> remote-endpoint = <_out>;
> --
> 2.31.1.818.g46aad6cb9e-goog
>

Re: [PATCH v6 RESEND 2/3] drm/mediatek: init panel orientation property

[Enric Balletbo Serra]

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang  del dia dj., 24 de juny
2021 a les 12:55:
>
> Init panel orientation property after connector is initialized. Let the
> panel driver decides the orientation value later.
>
> Signed-off-by: Hsin-Yi Wang 
> Acked-by: Chun-Kuang Hu 

Tested-by: Enric Balletbo i Serra 

As together with the other two patches works and I don't see any
problem on the Lenovo IdeaPad Duet, and the panel has the proper
orientation


> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ae403c67cbd92..9da1fd6491319 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -964,6 +964,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
> struct mtk_dsi *dsi)
> ret = PTR_ERR(dsi->connector);
> goto err_cleanup_encoder;
> }
> +
> +   ret = drm_connector_init_panel_orientation_property(dsi->connector);
> +   if (ret) {
> +   DRM_ERROR("Unable to init panel orientation\n");
> +   goto err_cleanup_encoder;
> +   }
> +
> drm_connector_attach_encoder(dsi->connector, >encoder);
>
> return 0;
> --
> 2.32.0.288.g62a8d224e6-goog
>

Re: [PATCH v6 RESEND 1/3] gpu: drm: separate panel orientation property creating and value setting

[Enric Balletbo Serra]

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang  del dia dj., 24 de juny
2021 a les 12:55:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>

In fact, results with the following warning


> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>
> [4.480976] [ cut here ]
> [4.485603] WARNING: CPU: 5 PID: 369 at 
> drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> 
> [4.609772] Call trace:
> [4.612208]  __drm_mode_object_add+0xb4/0xbc
> [4.616466]  drm_mode_object_add+0x20/0x2c
> [4.620552]  drm_property_create+0xdc/0x174
> [4.624723]  drm_property_create_enum+0x34/0x98
> [4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> [4.634716]  boe_panel_get_modes+0x88/0xd8
> [4.638802]  drm_panel_get_modes+0x2c/0x48
> [4.642887]  panel_bridge_get_modes+0x1c/0x28
> [4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> [4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> [4.658266]  drm_mode_getconnector+0x1b4/0x45c
> [4.662699]  drm_ioctl_kernel+0xac/0x128
> [4.11]  drm_ioctl+0x268/0x410
> [4.670002]  drm_compat_ioctl+0xdc/0xf0
> [4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> [4.678436]  el0_svc_common+0xf4/0x1c0
> [4.682174]  do_el0_svc_compat+0x28/0x3c
> [4.686088]  el0_svc_compat+0x10/0x1c
> [4.689738]  el0_sync_compat_handler+0xa8/0xcc
> [4.694171]  el0_sync_compat+0x178/0x180
> [4.698082] ---[ end trace b4f2db9d9c88610b ]---
> [4.702721] [ cut here ]
> [4.707329] WARNING: CPU: 5 PID: 369 at 
> drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> 
> [4.833830] Call trace:
> [4.836266]  drm_object_attach_property+0x48/0xb8
> [4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> [4.846432]  boe_panel_get_modes+0x88/0xd8
> [4.850516]  drm_panel_get_modes+0x2c/0x48
> [4.854600]  panel_bridge_get_modes+0x1c/0x28
> [4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> [4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> [4.869978]  drm_mode_getconnector+0x1b4/0x45c
> [4.874410]  drm_ioctl_kernel+0xac/0x128
> [4.878320]  drm_ioctl+0x268/0x410
> [4.881711]  drm_compat_ioctl+0xdc/0xf0
> [4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> [4.890142]  el0_svc_common+0xf4/0x1c0
> [4.893879]  do_el0_svc_compat+0x28/0x3c
> [4.897791]  el0_svc_compat+0x10/0x1c
> [4.901441]  el0_sync_compat_handler+0xa8/0xcc
> [4.905873]  el0_sync_compat+0x178/0x180
> [4.909783] ---[ end trace b4f2db9d9c88610c ]---
>
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Sean Paul 

And that patch fixes the problem, apart from, not being an expert, but
the change looks reasonable to me, there is already some reviewed tags
and I'm not sure I am the appropriate to review it but I can

Tested-by: Enric Balletbo i Serra 

As together with the other two patches works and I don't see any
problem on the Lenovo IdeaPad Duet.

> ---
>  drivers/gpu/drm/drm_connector.c | 58 ++---
>  drivers/gpu/drm/i915/display/icl_dsi.c  |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c |  1 +
>  drivers/gpu/drm/i915/display/vlv_dsi.c  |  1 +
>  include/drm/drm_connector.h |  2 +
>  5 files changed, 47 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f345..7189baaabf416 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] 
> = {
>   * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   * coordinates, so if userspace rotates the picture to adjust for
>   * the orientation it must also apply the same transformation to the
> - * touchscreen input coordinates. This property is initialized by calling
> + * touchscreen input coordinates. This property value is set by calling
>   * drm_connector_set_panel_orientation() or
>   * drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the 
> property
> + * doesn't 

Re: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)

[Enric Balletbo Serra]

Hi Frank,

Missatge de Frank Wunderlich  del dia dv., 9
de jul. 2021 a les 12:02:
>
> Hi,
>
> i've found it :)
>
> hdmi-problem is caused by
>
> commit 440147639ac79f699a4eb9811d0bc39d3cc815f4
> Author: CK Hu 
> Date:   Wed Mar 17 19:17:10 2021 +0100
>
> soc: mediatek: mmsys: Use an array for setting the routing registers
>
> but i cannot revert it alone, but after reverting all mmsys-patches hdmi 
> works (ovl irq-handler called)
>

If this is the offending commit, could you try if the following patch
fixes the issue for you?

https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.13-next/fixes=db39994e0bd852c6612a9709e63c09b98b161e00

If not, and that patch is the offending commit, it probably means that
the default routing table doesn't work for mt7623. Needs a specific
soc table.

Thanks,
  Enric.

> $ git logone v5.12..v5.13-rc1 -- drivers/ | grep 'mtk\|mediatek' | grep mmsys
> 060f7875bd23 2021-04-05 soc: mediatek: mmsys: Add support for MT8167 SoC
> 1ff1270fca33 2021-03-30 soc: mediatek: mmsys: Add mt8183 mmsys routing table
> 440147639ac7 2021-03-17 soc: mediatek: mmsys: Use an array for setting the 
> routing registers
> ce15e7faa2fc 2021-03-17 soc: mediatek: mmsys: Create struct mtk_mmsys to 
> store context data
>
> git revert 060f7875bd23 1ff1270fca33 440147639ac7 ce15e7faa2fc
>
> and after reapplying them one-by-one it stops working on commit above 
> (440147639ac7)
>
> @Dafna can you confirm it solves your issue too?
>
> btw. watchdog issue is caused by
>
> commit bbece05c0d3a96817483e0b249ad1e302ba95117
> watchdog: mtk_wdt: Remove mtk_wdt_stop() in probe() to prevent the system 
> freeze and it doesn't reboot by watchdog problem
>
> have already contacted author
>
> regards Frank

Re: [PATCH v5, 2/4] soc: mediatek: mmsys: add component POSTMASK

[Enric Balletbo Serra]

Hi Yongqiang,

Thank you for your patch.

Missatge de Yongqiang Niu  del dia dl., 12
d’abr. 2021 a les 16:05:
>
> This patch add component POSTMASK
>
> Signed-off-by: Yongqiang Niu 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  include/linux/soc/mediatek/mtk-mmsys.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index f6b58f9..7718cd6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -31,6 +31,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL_2L1,
> DDP_COMPONENT_OVL_2L2,
> DDP_COMPONENT_OVL1,
> +   DDP_COMPONENT_POSTMASK0,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> DDP_COMPONENT_PWM2,
> --
> 1.8.1.1.dirty
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5, 1/4] soc: mediatek: mmsys: add component OVL_2L2

[Enric Balletbo Serra]

Hi Yongqiang,

Thank you for your patch.

Missatge de Yongqiang Niu  del dia dl., 12
d’abr. 2021 a les 16:04:
>
> This patch add component OVL_2L2
>
> Signed-off-by: Yongqiang Niu 
> Reviewed-by: Chun-Kuang Hu 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  include/linux/soc/mediatek/mtk-mmsys.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 2228bf6..f6b58f9 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL_2L0,
> DDP_COMPONENT_OVL_2L1,
> +   DDP_COMPONENT_OVL_2L2,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> --
> 1.8.1.1.dirty
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4, 01/10] soc: mediatek: mmsys: create mmsys folder

[Enric Balletbo Serra]

Hi Yongqiang Niu,

Thank you for your patch.

Missatge de Yongqiang Niu  del dia dt., 5
de gen. 2021 a les 4:07:
>
> the mmsys will more and more complicated after support
> more and more SoCs, add an independent folder will be
> more clear
>
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/soc/mediatek/Makefile  |   2 +-

It will not apply cleanly anymore after the below commit that is
already queued. Maybe you could rebase the patches and resend them
again?

commit e1e4f7fea37572f0ccf3887430e52c491e9accb6
Author: CK Hu 
Date:   Tue Jul 21 15:46:06 2020 +0800

soc / drm: mediatek: Move mtk mutex driver to soc folder

mtk mutex is used by DRM and MDP driver, and its function is SoC-specific,
so move it to soc folder.

With that fixed,

Reviewed-by: Enric Balletbo i Serra 

Thanks,
  Enric

>  drivers/soc/mediatek/mmsys/Makefile|   2 +
>  drivers/soc/mediatek/mmsys/mtk-mmsys.c | 373 
> +
>  drivers/soc/mediatek/mtk-mmsys.c   | 373 
> -
>  4 files changed, 376 insertions(+), 374 deletions(-)
>  create mode 100644 drivers/soc/mediatek/mmsys/Makefile
>  create mode 100644 drivers/soc/mediatek/mmsys/mtk-mmsys.c
>  delete mode 100644 drivers/soc/mediatek/mtk-mmsys.c
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index b6908db..eca9774 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -5,4 +5,4 @@ obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
>  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
>  obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
> -obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> +obj-$(CONFIG_MTK_MMSYS) += mmsys/
> diff --git a/drivers/soc/mediatek/mmsys/Makefile 
> b/drivers/soc/mediatek/mmsys/Makefile
> new file mode 100644
> index 000..f44eadc
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c 
> b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> new file mode 100644
> index 000..18f9397
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
> @@ -0,0 +1,373 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + * Author: James Liao 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN  0x040
> +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN  0x044
> +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c
> +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN  0x050
> +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4
> +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8
> +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8
> +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
> +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
> +#define DISP_REG_CONFIG_MMSYS_CG_CON0  0x100
> +
> +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN   0x030
> +#define DISP_REG_CONFIG_OUT_SEL0x04c
> +#define DISP_REG_CONFIG_DSI_SEL0x050
> +#define DISP_REG_CONFIG_DPI_SEL0x064
> +
> +#define OVL0_MOUT_EN_COLOR00x1
> +#define OD_MOUT_EN_RDMA0   0x1
> +#define OD1_MOUT_EN_RDMA1  BIT(16)
> +#define UFOE_MOUT_EN_DSI0  0x1
> +#define COLOR0_SEL_IN_OVL0 0x1
> +#define OVL1_MOUT_EN_COLOR10x1
> +#define GAMMA_MOUT_EN_RDMA10x1
> +#define RDMA0_SOUT_DPI00x2
> +#define RDMA0_SOUT_DPI10x3
> +#define RDMA0_SOUT_DSI10x1
> +#define RDMA0_SOUT_DSI20x4
> +#define RDMA0_SOUT_DSI30x5
> +#define RDMA1_SOUT_DPI00x2
> +#define RDMA1_SOUT_DPI10x3
> +#define RDMA1_SOUT_DSI10x1
> +#define RDMA1_SOUT_DSI20x4
> +#define RDMA1_SOUT_DSI30x5
> +#define RDMA2_SOUT_DPI00x2
> +#define RDMA2_SOUT_DPI10x3
> +#define RDMA2_SOUT_DSI10x1
> +#define RDMA2_SOUT_DSI20x4
> +#define RDMA2_SOUT_DSI30x5
> +#define DPI0_SEL_IN_RDMA1  0x1
> +#define DPI0_SEL_IN_RDMA2  0x3
> +#define DPI1_SEL_IN_RDMA1   

Re: [PATCH v13 7/8] soc: mediatek: add mtk mutex support for MT8183

[Enric Balletbo Serra]

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang  del dia dv., 29 de gen.
2021 a les 10:23:
>
> From: Yongqiang Niu 
>
> Add mtk mutex support for MT8183 SoC.
>
> Signed-off-by: Yongqiang Niu 
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: CK Hu 

Reviewed-by: Enric Balletbo i Serra 

FWIW this patch is required to have the display working on the
Chromebook IdeaPad Duet, so

Tested-by: Enric Balletbo i Serra 

Matthias, If I am not wrong, this patch is the only one that is not
applied for this series. I know that is too late for 5.12, but If
you're fine with it, could you pick this patch directly or do you
prefer a resend of this patch alone once you will start to accept
patches for the next release?

Thanks,
  Enric

> ---
>  drivers/soc/mediatek/mtk-mutex.c | 50 
>  1 file changed, 50 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-mutex.c 
> b/drivers/soc/mediatek/mtk-mutex.c
> index f531b119da7a9..718a41beb6afb 100644
> --- a/drivers/soc/mediatek/mtk-mutex.c
> +++ b/drivers/soc/mediatek/mtk-mutex.c
> @@ -14,6 +14,8 @@
>
>  #define MT2701_MUTEX0_MOD0 0x2c
>  #define MT2701_MUTEX0_SOF0 0x30
> +#define MT8183_MUTEX0_MOD0 0x30
> +#define MT8183_MUTEX0_SOF0 0x2c
>
>  #define DISP_REG_MUTEX_EN(n)   (0x20 + 0x20 * (n))
>  #define DISP_REG_MUTEX(n)  (0x24 + 0x20 * (n))
> @@ -37,6 +39,18 @@
>  #define MT8167_MUTEX_MOD_DISP_DITHER   15
>  #define MT8167_MUTEX_MOD_DISP_UFOE 16
>
> +#define MT8183_MUTEX_MOD_DISP_RDMA00
> +#define MT8183_MUTEX_MOD_DISP_RDMA11
> +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> +#define MT8183_MUTEX_MOD_DISP_OVL0_2L  10
> +#define MT8183_MUTEX_MOD_DISP_OVL1_2L  11
> +#define MT8183_MUTEX_MOD_DISP_WDMA012
> +#define MT8183_MUTEX_MOD_DISP_COLOR0   13
> +#define MT8183_MUTEX_MOD_DISP_CCORR0   14
> +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> +#define MT8183_MUTEX_MOD_DISP_GAMMA0   16
> +#define MT8183_MUTEX_MOD_DISP_DITHER0  17
> +
>  #define MT8173_MUTEX_MOD_DISP_OVL0 11
>  #define MT8173_MUTEX_MOD_DISP_OVL1 12
>  #define MT8173_MUTEX_MOD_DISP_RDMA013
> @@ -87,6 +101,11 @@
>  #define MT2712_MUTEX_SOF_DSI3  6
>  #define MT8167_MUTEX_SOF_DPI0  2
>  #define MT8167_MUTEX_SOF_DPI1  3
> +#define MT8183_MUTEX_SOF_DSI0  1
> +#define MT8183_MUTEX_SOF_DPI0  2
> +
> +#define MT8183_MUTEX_EOF_DSI0  (MT8183_MUTEX_SOF_DSI0 << 6)
> +#define MT8183_MUTEX_EOF_DPI0  (MT8183_MUTEX_SOF_DPI0 << 6)
>
>  struct mtk_mutex {
> int id;
> @@ -181,6 +200,20 @@ static const unsigned int 
> mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
>  };
>
> +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> +   [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> +   [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> +   [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> +   [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> +   [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> +   [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> +   [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> +   [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> +   [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> +   [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> +   [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> +};
> +
>  static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> @@ -198,6 +231,13 @@ static const unsigned int 
> mt8167_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
>  };
>
> +/* Add EOF setting so overlay hardware can receive frame done irq */
> +static const unsigned int mt8183_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> +   [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> +   [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
> +   [MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
> +};
> +
>  static const struct mtk_mutex_data mt2701_mutex_driver_data = {
> .mutex_mod = mt2701_mutex_mod,
> .mutex_sof = mt2712_mutex_sof,
> @@ -227,6 +267,14 @@ static const struct mtk_mutex_data 
> mt8173_mutex_driver_data = {
> .mutex_sof_reg = MT2701_MUTEX0_SOF0,
>  };
>
> +static const struct mtk_mutex_data mt8183_mutex_driver_data = {
> +   .mutex_mod = mt8183_mutex_mod,
> +   .mutex_sof = mt8183_mutex_sof,
> +   .mutex_mod_reg = MT8183_MUTEX0_MOD0,
> +   .mutex_sof_reg = MT8183_MUTEX0_SOF0,
> +   

Re: [PATCH v11 1/9] arm64: dts: mt8183: rename rdma fifo size

[Enric Balletbo Serra]

Hi Hsin-Yi,

Thank you for the patch.

Missatge de Hsin-Yi Wang  del dia dj., 28 de gen.
2021 a les 8:28:
>
> From: Yongqiang Niu 
>
> property name must include only lowercase and '-'
>

This is a leftover while I forward ported the patch, the
rdma_fifo_size only existed on the downstream kernels, in mainline it
is with '-', so we should probably add the fixes tag here.

Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")

> Signed-off-by: Yongqiang Niu 
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Chun-Kuang Hu 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7e..6c84ccb709af6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1011,7 +1011,7 @@ rdma0: rdma@1400b000 {
> clocks = < CLK_MM_DISP_RDMA0>;
> iommus = < M4U_PORT_DISP_RDMA0>;
> mediatek,larb = <>;
> -   mediatek,rdma_fifo_size = <5120>;
> +   mediatek,rdma-fifo-size = <5120>;
> mediatek,gce-client-reg = < SUBSYS_1400 
> 0xb000 0x1000>;
> };
>
> @@ -1023,7 +1023,7 @@ rdma1: rdma@1400c000 {
> clocks = < CLK_MM_DISP_RDMA1>;
> iommus = < M4U_PORT_DISP_RDMA1>;
> mediatek,larb = <>;
> -   mediatek,rdma_fifo_size = <2048>;
> +   mediatek,rdma-fifo-size = <2048>;
> mediatek,gce-client-reg = < SUBSYS_1400 
> 0xc000 0x1000>;
> };
>
> --
> 2.30.0.280.ga3ce27912f-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v11 2/9] arm64: dts: mt8183: refine gamma compatible name

[Enric Balletbo Serra]

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang  del dia dj., 28 de gen.
2021 a les 8:28:
>
> From: Yongqiang Niu 
>
> mt8183 gamma is different with mt8173
> remove mt8173 compatible name for mt8183 gamma
>

Should this patch contain?

Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")

> Signed-off-by: Yongqiang Niu 
> Signed-off-by: Hsin-Yi Wang 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 6c84ccb709af6..9c0073cfad452 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1055,8 +1055,7 @@ aal0: aal@1401 {
> };
>
> gamma0: gamma@14011000 {
> -   compatible = "mediatek,mt8183-disp-gamma",
> -"mediatek,mt8173-disp-gamma";
> +   compatible = "mediatek,mt8183-disp-gamma";
> reg = <0 0x14011000 0 0x1000>;
> interrupts = ;
> power-domains = < MT8183_POWER_DOMAIN_DISP>;
> --
> 2.30.0.280.ga3ce27912f-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data

[Enric Balletbo Serra]

Hi Yongqiang,

Missatge de Yongqiang Niu  del dia ds., 25
de jul. 2020 a les 5:29:
>
> On Thu, 2020-07-23 at 11:32 +0200, Enric Balletbo Serra wrote:
> > Hi Yongqiang Niu,
> >
> > Thank you for your patch.
> >
> > Missatge de Yongqiang Niu  del dia dj., 23
> > de jul. 2020 a les 4:05:
> > >
> > > add mmsys private data
> > >
> >
> > I think this change requires a better explanation of what you are
> > doing. Although I'm really uncomfortable with this change, why you
> > need to create a new mt2701-mmsys file?
>
> reason:
> 1.there will more and more Mediatek Soc upstream, and the display path
> connection function mtk_mmsys_ddp_mout_en, mtk_mmsys_ddp_sel_in and
> mtk_mmsys_ddp_sout_sel will complicated more and more,
> 2. many of the connection are only used in some SoC, and useless for
> other SoC and not readable,
> 3. if we add a new SoC connection, we need check is this affect other
> Soc,
> >
> > > Feature: drm/mediatek
> >
> > Remove this.
> next version will remove this
> >
> > > Signed-off-by: Yongqiang Niu 
> > > ---
> > >  drivers/soc/mediatek/Makefile |   1 +
> > >  drivers/soc/mediatek/mmsys/Makefile   |   2 +
> > >  drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 
> > > +++
> > >  drivers/soc/mediatek/mtk-mmsys.c  | 271 
> > > +-
> > >  include/linux/soc/mediatek/mtk-mmsys.h|  15 ++
> > >  5 files changed, 314 insertions(+), 225 deletions(-)
> > >  create mode 100644 drivers/soc/mediatek/mmsys/Makefile
> > >  create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c
> > >
> > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> > > index 2afa7b9..b37ac2c 100644
> > > --- a/drivers/soc/mediatek/Makefile
> > > +++ b/drivers/soc/mediatek/Makefile
> > > @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
> > >  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> > >  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> > >  obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> > > +obj-$(CONFIG_MTK_MMSYS) += mmsys/
> > > diff --git a/drivers/soc/mediatek/mmsys/Makefile 
> > > b/drivers/soc/mediatek/mmsys/Makefile
> > > new file mode 100644
> > > index 000..33b0dab
> > > --- /dev/null
> > > +++ b/drivers/soc/mediatek/mmsys/Makefile
> > > @@ -0,0 +1,2 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only
> > > +obj-y += mt2701-mmsys.o
> > > diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c 
> > > b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
> > > new file mode 100644
> > > index 000..b8e53b0
> > > --- /dev/null
> > > +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
> > > @@ -0,0 +1,250 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +//
> > > +// Copyright (c) 2020 MediaTek Inc.
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN  0x040
> > > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN  0x044
> > > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> > > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c
> > > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN  0x050
> > > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> > > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> > > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4
> > > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8
> > > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> > > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8
> > > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
> > > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
> > > +#define DISP_REG_CONFIG_MMSYS_CG_CON0  0x100
> > > +
> > > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN   0x030
> > > +#define DISP_REG_CONFIG_OUT_SEL0x04c
> > > +#define DISP_REG_CONFIG_DSI_SEL0x050
> > > +#define DISP_REG_CONFIG_DPI_SEL0x064
> > > +
> > > +#define OVL0_MOUT_EN_COLOR00x1
> > > +#define OD_MOUT_EN_RDMA0   0x1
> > > +#define OD1_MOUT_EN_RDMA1  BIT(16)
> > > +#define UFOE_MOUT_EN_DSI0

Re: [v7, PATCH 1/7] drm/mediatek: move ddp component defint into mtk_mmsys.h

[Enric Balletbo Serra]

Hi Yongqian Niu,

Thank you for your patch

Missatge de Yongqiang Niu  del dia dj., 23
de jul. 2020 a les 4:05:
>
> move ddp component defint into mtk_mmsys.h
>

There is a typo, should be "defines". But why you should move these
defines to mtk-mmsys?



> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34 
> +
>  drivers/soc/mediatek/mtk-mmsys.c|  4 +---
>  include/linux/soc/mediatek/mtk-mmsys.h  | 33 
>  3 files changed, 35 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index debe363..161201f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -7,6 +7,7 @@
>  #define MTK_DRM_DDP_COMP_H
>
>  #include 
> +#include 
>
>  struct device;
>  struct device_node;
> @@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
> MTK_DDP_COMP_TYPE_MAX,
>  };
>
> -enum mtk_ddp_comp_id {
> -   DDP_COMPONENT_AAL0,
> -   DDP_COMPONENT_AAL1,
> -   DDP_COMPONENT_BLS,
> -   DDP_COMPONENT_CCORR,
> -   DDP_COMPONENT_COLOR0,
> -   DDP_COMPONENT_COLOR1,
> -   DDP_COMPONENT_DITHER,
> -   DDP_COMPONENT_DPI0,
> -   DDP_COMPONENT_DPI1,
> -   DDP_COMPONENT_DSI0,
> -   DDP_COMPONENT_DSI1,
> -   DDP_COMPONENT_DSI2,
> -   DDP_COMPONENT_DSI3,
> -   DDP_COMPONENT_GAMMA,
> -   DDP_COMPONENT_OD0,
> -   DDP_COMPONENT_OD1,
> -   DDP_COMPONENT_OVL0,
> -   DDP_COMPONENT_OVL_2L0,
> -   DDP_COMPONENT_OVL_2L1,
> -   DDP_COMPONENT_OVL1,
> -   DDP_COMPONENT_PWM0,
> -   DDP_COMPONENT_PWM1,
> -   DDP_COMPONENT_PWM2,
> -   DDP_COMPONENT_RDMA0,
> -   DDP_COMPONENT_RDMA1,
> -   DDP_COMPONENT_RDMA2,
> -   DDP_COMPONENT_UFOE,
> -   DDP_COMPONENT_WDMA0,
> -   DDP_COMPONENT_WDMA1,
> -   DDP_COMPONENT_ID_MAX,
> -};
> -
>  struct mtk_ddp_comp;
>  struct cmdq_pkt;
>  struct mtk_ddp_comp_funcs {
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
> b/drivers/soc/mediatek/mtk-mmsys.c
> index a55f255..36ad66b 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -5,13 +5,11 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
> -
>  #define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN  0x040
>  #define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN  0x044
>  #define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 7bab5d9..2228bf6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -9,6 +9,39 @@
>  enum mtk_ddp_comp_id;
>  struct device;
>
> +enum mtk_ddp_comp_id {
> +   DDP_COMPONENT_AAL0,
> +   DDP_COMPONENT_AAL1,
> +   DDP_COMPONENT_BLS,
> +   DDP_COMPONENT_CCORR,
> +   DDP_COMPONENT_COLOR0,
> +   DDP_COMPONENT_COLOR1,
> +   DDP_COMPONENT_DITHER,
> +   DDP_COMPONENT_DPI0,
> +   DDP_COMPONENT_DPI1,
> +   DDP_COMPONENT_DSI0,
> +   DDP_COMPONENT_DSI1,
> +   DDP_COMPONENT_DSI2,
> +   DDP_COMPONENT_DSI3,
> +   DDP_COMPONENT_GAMMA,
> +   DDP_COMPONENT_OD0,
> +   DDP_COMPONENT_OD1,
> +   DDP_COMPONENT_OVL0,
> +   DDP_COMPONENT_OVL_2L0,
> +   DDP_COMPONENT_OVL_2L1,
> +   DDP_COMPONENT_OVL1,
> +   DDP_COMPONENT_PWM0,
> +   DDP_COMPONENT_PWM1,
> +   DDP_COMPONENT_PWM2,
> +   DDP_COMPONENT_RDMA0,
> +   DDP_COMPONENT_RDMA1,
> +   DDP_COMPONENT_RDMA2,
> +   DDP_COMPONENT_UFOE,
> +   DDP_COMPONENT_WDMA0,
> +   DDP_COMPONENT_WDMA1,
> +   DDP_COMPONENT_ID_MAX,
> +};
> +
>  void mtk_mmsys_ddp_connect(struct device *dev,
>enum mtk_ddp_comp_id cur,
>enum mtk_ddp_comp_id next);
> --
> 1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data

[Enric Balletbo Serra]

Hi Yongqiang Niu,

Thank you for your patch.

Missatge de Yongqiang Niu  del dia dj., 23
de jul. 2020 a les 4:05:
>
> add mmsys private data
>

I think this change requires a better explanation of what you are
doing. Although I'm really uncomfortable with this change, why you
need to create a new mt2701-mmsys file?

> Feature: drm/mediatek

Remove this.

> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/soc/mediatek/Makefile |   1 +
>  drivers/soc/mediatek/mmsys/Makefile   |   2 +
>  drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 +++
>  drivers/soc/mediatek/mtk-mmsys.c  | 271 
> +-
>  include/linux/soc/mediatek/mtk-mmsys.h|  15 ++
>  5 files changed, 314 insertions(+), 225 deletions(-)
>  create mode 100644 drivers/soc/mediatek/mmsys/Makefile
>  create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 2afa7b9..b37ac2c 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
>  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
>  obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> +obj-$(CONFIG_MTK_MMSYS) += mmsys/
> diff --git a/drivers/soc/mediatek/mmsys/Makefile 
> b/drivers/soc/mediatek/mmsys/Makefile
> new file mode 100644
> index 000..33b0dab
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-y += mt2701-mmsys.o
> diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c 
> b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
> new file mode 100644
> index 000..b8e53b0
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
> @@ -0,0 +1,250 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN  0x040
> +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN  0x044
> +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c
> +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN  0x050
> +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4
> +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8
> +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8
> +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
> +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
> +#define DISP_REG_CONFIG_MMSYS_CG_CON0  0x100
> +
> +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN   0x030
> +#define DISP_REG_CONFIG_OUT_SEL0x04c
> +#define DISP_REG_CONFIG_DSI_SEL0x050
> +#define DISP_REG_CONFIG_DPI_SEL0x064
> +
> +#define OVL0_MOUT_EN_COLOR00x1
> +#define OD_MOUT_EN_RDMA0   0x1
> +#define OD1_MOUT_EN_RDMA1  BIT(16)
> +#define UFOE_MOUT_EN_DSI0  0x1
> +#define COLOR0_SEL_IN_OVL0 0x1
> +#define OVL1_MOUT_EN_COLOR10x1
> +#define GAMMA_MOUT_EN_RDMA10x1
> +#define RDMA0_SOUT_DPI00x2
> +#define RDMA0_SOUT_DPI10x3
> +#define RDMA0_SOUT_DSI10x1
> +#define RDMA0_SOUT_DSI20x4
> +#define RDMA0_SOUT_DSI30x5
> +#define RDMA1_SOUT_DPI00x2
> +#define RDMA1_SOUT_DPI10x3
> +#define RDMA1_SOUT_DSI10x1
> +#define RDMA1_SOUT_DSI20x4
> +#define RDMA1_SOUT_DSI30x5
> +#define RDMA2_SOUT_DPI00x2
> +#define RDMA2_SOUT_DPI10x3
> +#define RDMA2_SOUT_DSI10x1
> +#define RDMA2_SOUT_DSI20x4
> +#define RDMA2_SOUT_DSI30x5
> +#define DPI0_SEL_IN_RDMA1  0x1
> +#define DPI0_SEL_IN_RDMA2  0x3
> +#define DPI1_SEL_IN_RDMA1  (0x1 << 8)
> +#define DPI1_SEL_IN_RDMA2  (0x3 << 8)
> +#define DSI0_SEL_IN_RDMA1  0x1
> +#define DSI0_SEL_IN_RDMA2  0x4
> +#define DSI1_SEL_IN_RDMA1  0x1
> +#define DSI1_SEL_IN_RDMA2  0x4
> +#define DSI2_SEL_IN_RDMA1  (0x1 << 16)
> +#define DSI2_SEL_IN_RDMA2  (0x4 << 16)
> +#define DSI3_SEL_IN_RDMA1  (0x1 << 

Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

[Enric Balletbo Serra]

Hi Chun-Kuang,

Missatge de Chun-Kuang Hu  del dia ds., 16 de
maig 2020 a les 12:11:
>
> Hi, Enric:
>
> Enric Balletbo i Serra  於 2020年5月15日 週五 
> 上午1:35寫道：
> >
> > Hi again,
> >
> > On 14/5/20 19:12, Enric Balletbo i Serra wrote:
> > > Hi Chun-Kuang,
> > >
> > > On 14/5/20 18:44, Chun-Kuang Hu wrote:
> > >> Hi, Enric:
> > >>
> > >> Enric Balletbo i Serra  於 2020年5月14日 週四 
> > >> 下午11:42寫道：
> > >>>
> > >>> Hi Chun-Kuang,
> > >>>
> > >>> On 14/5/20 16:28, Chun-Kuang Hu wrote:
> > >>>> Hi, Enric:
> > >>>>
> > >>>> Enric Balletbo Serra  於 2020年5月14日 週四 上午12:41寫道：
> > >>>>>
> > >>>>> Hi Chun-Kuang,
> > >>>>>
> > >>>>> Missatge de Enric Balletbo i Serra  del
> > >>>>> dia dv., 1 de maig 2020 a les 17:25:
> > >>>>>>
> > >>>>>> Use the drm_bridge_connector helper to create a connector for 
> > >>>>>> pipelines
> > >>>>>> that use drm_bridge. This allows splitting connector operations 
> > >>>>>> across
> > >>>>>> multiple bridges when necessary, instead of having the last bridge in
> > >>>>>> the chain creating the connector and handling all connector 
> > >>>>>> operations
> > >>>>>> internally.
> > >>>>>>
> > >>>>>> Signed-off-by: Enric Balletbo i Serra 
> > >>>>>> Acked-by: Sam Ravnborg 
> > >>>>>
> > >>>>> A gentle ping on this, I think that this one is the only one that
> > >>>>> still needs a review in the series.
> > >>>>
> > >>>> This is what I reply in patch v3:
> > >>>>
> > >>>
> > >>> Sorry for missing this.
> > >>>
> > >>>> I think the panel is wrapped into next_bridge here,
> > >>>>
> > >>>
> > >>> Yes, you can have for example:
> > >>>
> > >>> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> 
> > >>> drm_panel_bridge
> > >>> (edp panel)
> > >>>
> > >>> or a
> > >>>
> > >>> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
> > >>>
> > >>> The _first_ one is my use case
> > >>>
> > >>>> if (panel) {
> > >>>
> > >>> This handles the second case, where you attach a dsi panel.
> > >>>
> > >>>> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
> > >>>>
> > >>>> so the next_bridge is a panel_bridge, in its attach function
> > >>>> panel_bridge_attach(),
> > >>>> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
> > >>>> it would create connector and attach connector to panel.
> > >>>>
> > >>>> I'm not sure this flag would exist or not, but for both case, it's 
> > >>>> strange.
> > >>>> If exist, you create connector in this patch but no where to attach
> > >>>> connector to panel.
> > >>>
> > >>> Yes, in fact, this is transitional patch needed, as once I converted 
> > >>> mtk_dpi,
> > >>> mtk_dsi and mtk_hdmi to the new drm_bridge API the 
> > >>> drm_bridge_connector_init()
> > >>> will be done in mtk_drm_drv. We will need to call 
> > >>> drm_bridge_connector_init for
> > >>> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi 
> > >>> drivers. The
> > >>> graphic controller driver should create connectors and CRTCs, as 
> > >>> example you can
> > >>> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
> > >>>
> > >>
> > >> I have such question because I've reviewed omap's driver. In omap's
> > >> driver, after it call drm_bridge_connector_init(), it does this:
> > >>
> > >> if (pipe->output->panel) {
> > >> ret = drm_panel_attach(pipe->output->panel,
> > >>   pipe->connector);
> > >> if (ret < 0)
> > >> return ret;
> > >> }
> > >>
>

Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

[Enric Balletbo Serra]

Hi Chun-Kuang,

Missatge de Enric Balletbo i Serra  del
dia dv., 1 de maig 2020 a les 17:25:
>
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.
>
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Sam Ravnborg 

A gentle ping on this, I think that this one is the only one that
still needs a review in the series.

Thanks,
 Enric

> ---
>
> Changes in v4: None
> Changes in v3:
> - Move the bridge.type line to the patch that adds drm_bridge support. 
> (Laurent Pinchart)
>
> Changes in v2: None
>
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 4f3bd095c1ee..471fcafdf348 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -17,6 +17,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -183,6 +184,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
> +   struct drm_connector *connector;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, 
> struct mtk_dsi *dsi)
>  */
> dsi->encoder.possible_crtcs = 1;
>
> -   ret = drm_bridge_attach(>encoder, >bridge, NULL, 0);
> +   ret = drm_bridge_attach(>encoder, >bridge, NULL,
> +   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret)
> goto err_cleanup_encoder;
>
> +   dsi->connector = drm_bridge_connector_init(drm, >encoder);
> +   if (IS_ERR(dsi->connector)) {
> +   DRM_ERROR("Unable to create bridge connector\n");
> +   ret = PTR_ERR(dsi->connector);
> +   goto err_cleanup_encoder;
> +   }
> +   drm_connector_attach_encoder(dsi->connector, >encoder);
> +
> return 0;
>
>  err_cleanup_encoder:
> --
> 2.26.2
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/8] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure

[Enric Balletbo Serra]

Hi Adrian,

[snip]

> >>
> >> +static void dw_mipi_dsi_get_hw_version(struct dw_mipi_dsi
> >> *dsi) +{ +   regmap_read(dsi->regs, DSI_VERSION,
> >> >hw_version); +   dsi->hw_version &= VERSION; +
> >> if (!dsi->hw_version) +   dev_err(dsi->dev, "Failed
> >> to read DSI hw version register\n");
> >
> > Is this an error that should be ignored? If you can't get the HW
> > version, probably, there is something wrong with your hardware
> > so, don't you need to return an error?
> >
>
> After thinking a bit more about it, that error should be a
> warning.
>
> I added it because in some cases (for eg. if the peripheral clock
> is disabled) the reads can return 0 which is obviously an invalid
> version and the bridge will error in the next step when not
> finding a layout.
>

If you'll error anyway, why wait? IIUC at this point the clock *must*
be enabled, and if not, something is wrong with the driver, I don't
see any advantage on delay the error. do you have a use case where
this is called and peripheral clock disabled?

> So I'll make this a warning in v7 and explicitely mention that
> reads version == 0 can be caused by a disabled pclk.
>

-- Enric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver

[Enric Balletbo Serra]

Hi Adrian,

Thank you for your patch.

Missatge de Adrian Ratiu  del dia dt., 14
d’abr. 2020 a les 17:19:
>
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
>
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
>
> - drm: imx: Support Synopsys DesignWare MIPI DSI host controller
>   Signed-off-by: Liu Ying 
>
> Cc: Fabio Estevam 
> Reviewed-by: Emil Velikov 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Martyn Welch 
> Signed-off-by: Adrian Ratiu 
> ---
> Changes since v5:
>   - Reword to remove unrelated device tree patch mention (Fabio)
>   - Move pllref_clk enable/disable to bind/unbind (Ezequiel)
>   - Fix freescale.com -> nxp.com email addresses (Fabio)
>   - Also added myself as module author (Fabio)
>   - Use DRM_DEV_* macros for consistency, print more error msg
>
> Changes since v4:
>   - Split off driver-specific configuration of phy timings due
>   to new upstream API.
>   - Move regmap infrastructure logic to separate commit (Ezequiel)
>   - Move dsi v1.01 layout addition to a separate commit (Ezequiel)
>   - Minor warnings and driver name fixes
>
> Changes since v3:
>   - Renamed platform driver to reflect it's i.MX6 only. (Fabio)
>
> Changes since v2:
>   - Fixed commit tags. (Emil)
>
> Changes since v1:
>   - Moved register definitions & regmap initialization into bridge
>   module. Platform drivers get the regmap via plat_data after
>   calling the bridge probe. (Emil)
> ---
>  drivers/gpu/drm/imx/Kconfig|   7 +
>  drivers/gpu/drm/imx/Makefile   |   1 +
>  drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 409 +
>  3 files changed, 417 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
>
> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> index 207bf7409dfb..b49e70e7f0fd 100644
> --- a/drivers/gpu/drm/imx/Kconfig
> +++ b/drivers/gpu/drm/imx/Kconfig
> @@ -39,3 +39,10 @@ config DRM_IMX_HDMI
> depends on DRM_IMX
> help
>   Choose this if you want to use HDMI on i.MX6.
> +
> +config DRM_IMX6_MIPI_DSI
> +   tristate "Freescale i.MX6 DRM MIPI DSI"
> +   select DRM_DW_MIPI_DSI
> +   depends on DRM_IMX

Should it depend on CONFIG_OF too? I suspect you'll get build errors
if OF is not selected

> +   help
> + Choose this if you want to use MIPI DSI on i.MX6.
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> index 21cdcc2faabc..9a7843c59347 100644
> --- a/drivers/gpu/drm/imx/Makefile
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
>  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>
>  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o
> diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c 
> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> new file mode 100644
> index ..6914db8ce8cb
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> @@ -0,0 +1,409 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX6 drm driver - MIPI DSI Host Controller
> + *
> + * Copyright (C) 2011-2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019-2020 Collabora, Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-drm.h"
> +
> +#define DSI_PWR_UP 0x04
> +#define RESET  0
> +#define POWERUPBIT(0)
> +
> +#define DSI_PHY_IF_CTRL0x5c
> +#define PHY_IF_CTRL_RESET  0x0
> +
> +#define DSI_PHY_TST_CTRL0  0x64
> +#define PHY_TESTCLKBIT(1)
> +#define PHY_UNTESTCLK  0
> +#define PHY_TESTCLRBIT(0)
> +#define PHY_UNTESTCLR  0
> +
> +#define DSI_PHY_TST_CTRL1  0x68
> +#define PHY_TESTEN BIT(16)
> +#define PHY_UNTESTEN   0
> +#define PHY_TESTDOUT(n)(((n) & 0xff) << 8)
> +#define PHY_TESTDIN(n) (((n) & 0xff) << 0)
> +
> +struct imx_mipi_dsi {
> +   struct drm_encoder encoder;
> +   struct device *dev;
> +   struct regmap *mux_sel;
> +   struct dw_mipi_dsi *mipi_dsi;
> +   struct clk *pllref_clk;
> +
> +   void __iomem *base;
> +   unsigned int lane_mbps;
> +};
> +
> +struct dphy_pll_testdin_map {
> +   unsigned int max_mbps;
> +   u8 testdin;
> +};
> +
> +/* The table is based on 27MHz DPHY pll reference clock. */
> +static const struct dphy_pll_testdin_map dptdin_map[] = {
> +   {160, 0x04}, {180, 0x24}, {200, 0x44}, {210, 0x06},
> +   {240, 0x26}, {250, 0x46}, {270, 0x08}, {300, 0x28},
> +   {330, 0x48}, {360, 0x2a}, 

Re: [PATCH v6 1/8] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure

[Enric Balletbo Serra]

Hi Adrian,

Some few comments/nits below,

Missatge de Adrian Ratiu  del dia dt., 14
d’abr. 2020 a les 17:19:
>
> In order to support multiple versions of the Synopsis MIPI DSI host
> controller, which have different register layouts but almost identical
> HW protocols, we add a regmap infrastructure which can abstract away
> register accesses for platform drivers using the bridge.
>
> The controller HW revision is detected during bridge probe which will
> be used in future commits to load the relevant register layout which
> the bridge will use transparently to the platform drivers.
>
> Suggested-by: Ezequiel Garcia 
> Tested-by: Adrian Pop 
> Tested-by: Arnaud Ferraris 
> Signed-off-by: Adrian Ratiu 
> ---
> New in v5.
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 208 ++
>  1 file changed, 117 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 5ef0f154aa7b..6d9e2f21c9cc 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Should Kconfig select REGMAP for this driver?

>  #include 
>
>  #include 
> @@ -227,6 +228,7 @@ struct dw_mipi_dsi {
> struct drm_bridge *panel_bridge;
> struct device *dev;
> void __iomem *base;
> +   struct regmap *regs;
>
> struct clk *pclk;
>
> @@ -235,6 +237,7 @@ struct dw_mipi_dsi {
> u32 lanes;
> u32 format;
> unsigned long mode_flags;
> +   u32 hw_version;
>
>  #ifdef CONFIG_DEBUG_FS
> struct dentry *debugfs;
> @@ -249,6 +252,13 @@ struct dw_mipi_dsi {
> const struct dw_mipi_dsi_plat_data *plat_data;
>  };
>
> +static const struct regmap_config dw_mipi_dsi_regmap_cfg = {
> +   .reg_bits = 32,
> +   .val_bits = 32,
> +   .reg_stride = 4,
> +   .name = "dw-mipi-dsi",
> +};
> +
>  /*
>   * Check if either a link to a master or slave is present
>   */
> @@ -280,16 +290,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct 
> drm_bridge *bridge)
> return container_of(bridge, struct dw_mipi_dsi, bridge);
>  }
>
> -static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
> -{
> -   writel(val, dsi->base + reg);
> -}
> -
> -static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
> -{
> -   return readl(dsi->base + reg);
> -}
> -
>  static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
>struct mipi_dsi_device *device)
>  {
> @@ -366,29 +366,29 @@ static void dw_mipi_message_config(struct dw_mipi_dsi 
> *dsi,
> if (lpm)
> val |= CMD_MODE_ALL_LP;
>
> -   dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> -   dsi_write(dsi, DSI_CMD_MODE_CFG, val);
> +   regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
> +   regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
>  }
>
>  static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 
> hdr_val)
>  {
> int ret;
> -   u32 val, mask;
> +   u32 val = 0, mask;
>

I think that this change is not needed, `val` is an input variable
that will be overwritten inside the regmap_read_poll_timeout.
Initialize here is not needed.

> -   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> -val, !(val & GEN_CMD_FULL), 1000,
> -CMD_PKT_STATUS_TIMEOUT_US);
> +   ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
> +  val, !(val & GEN_CMD_FULL), 1000,
> +  CMD_PKT_STATUS_TIMEOUT_US);
> if (ret) {
> dev_err(dsi->dev, "failed to get available command FIFO\n");
> return ret;
> }
>
> -   dsi_write(dsi, DSI_GEN_HDR, hdr_val);
> +   regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
>
> mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
> -   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> -val, (val & mask) == mask,
> -1000, CMD_PKT_STATUS_TIMEOUT_US);
> +   ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
> +  val, (val & mask) == mask,
> +  1000, CMD_PKT_STATUS_TIMEOUT_US);
> if (ret) {
> dev_err(dsi->dev, "failed to write command FIFO\n");
> return ret;
> @@ -403,24 +403,26 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> const u8 *tx_buf = packet->payload;
> int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
> __le32 word;
> -   u32 val;
> +   u32 val = 0;
>

The same here, 'val' is used for the regmap_read_poll_timeout and will
be overwritten, no need to 

Re: [PATCH v11 3/5] soc: mediatek: Move mt8173 MMSYS to platform driver

[Enric Balletbo Serra]

Hi Stephen,

Missatge de Stephen Boyd  del dia dv., 6 de març
2020 a les 22:37:
>
> Quoting Enric Balletbo i Serra (2020-03-06 08:30:16)
> > Hi Stephen,
> >
> > On 5/3/20 22:01, Stephen Boyd wrote:
> > > Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
> > >> From: Matthias Brugger 
> > >>
> > >> There is no strong reason for this to use CLK_OF_DECLARE instead of
> > >> being a platform driver.
> > >
> > > Cool.
> > >
> > >> Plus, this driver provides clocks but also
> > >> a shared register space for the mediatek-drm and the mediatek-mdp
> > >> driver. So move to drivers/soc/mediatek as a platform driver.
> > >>
> > >> Signed-off-by: Matthias Brugger 
> > >> Signed-off-by: Enric Balletbo i Serra 
> > >> Reviewed-by: CK Hu 
> > >> ---
> > >>
> > >> Changes in v11: None
> > >> Changes in v10:
> > >> - Renamed to be generic mtk-mmsys
> > >> - Add driver data support to be able to support diferent SoCs
> > >>
> > >> Changes in v9:
> > >> - Move mmsys to drivers/soc/mediatek (CK)
> > >>
> > >> Changes in v8:
> > >> - Be a builtin_platform_driver like other mediatek mmsys drivers.
> > >>
> > >> Changes in v7:
> > >> - Free clk_data->clks as well
> > >> - Get rid of private data structure
> > >>
> > >>  drivers/clk/mediatek/clk-mt8173.c | 104 
> > >>  drivers/soc/mediatek/Kconfig  |   7 ++
> > >>  drivers/soc/mediatek/Makefile |   1 +
> > >>  drivers/soc/mediatek/mtk-mmsys.c  | 154 ++
> > >
> > > Can you generate with -M so that we can see what has actually changed?
> > >
> >
> > Sure, sorry about that.
> >
> > >>  4 files changed, 162 insertions(+), 104 deletions(-)
> > >>  create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
> > >>
> > >> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> > >> index 2114b563478c..7a156944d50e 100644
> > >> --- a/drivers/soc/mediatek/Kconfig
> > >> +++ b/drivers/soc/mediatek/Kconfig
> > >> @@ -44,4 +44,11 @@ config MTK_SCPSYS
> > >>   Say yes here to add support for the MediaTek SCPSYS power 
> > >> domain
> > >>   driver.
> > >>
> > >> +config MTK_MMSYS
> > >> +   bool "MediaTek MMSYS Support"
> > >> +   depends on COMMON_CLK_MT8173
> > >
> > > Does it need some default so that defconfig updates don't break things?
> > >
> >
> > Right.
> >
> > >> +   help
> > >> + Say yes here to add support for the MediaTek Multimedia
> > >> + Subsystem (MMSYS).
> > >> +
> > >>  endmenu
> > >> diff --git a/drivers/soc/mediatek/Makefile 
> > >> b/drivers/soc/mediatek/Makefile
> > >> index b01733074ad6..01f9f873634a 100644
> > >> --- a/drivers/soc/mediatek/Makefile
> > >> +++ b/drivers/soc/mediatek/Makefile
> > >> @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
> > >>  obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> > >>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> > >>  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> > >> +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> > >> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
> > >> b/drivers/soc/mediatek/mtk-mmsys.c
> > >> new file mode 100644
> > >> index ..473cdf732fb5
> > >> --- /dev/null
> > >> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> > >> @@ -0,0 +1,154 @@
> > >> +// SPDX-License-Identifier: GPL-2.0-only
> > >> +/*
> > >> + * Copyright (c) 2014 MediaTek Inc.
> > >> + * Author: James Liao 
> > >> + */
> > >> +
> > >> +#include 
> > >> +#include 
> > >> +#include 
> > >> +
> > >> +#include "../../clk/mediatek/clk-gate.h"
> > >> +#include "../../clk/mediatek/clk-mtk.h"
> > >
> > > Why not use include/linux/clk/?
> > >
> >
> > I can move these files to include, this will impact a lot more of drivers 
> > but,
> > yes, I think is the right way.
> >
> > > But I also don't understand why the clk driver is moved outside of
> > > drivers/clk/ into drivers/soc/. Commit text saying that it has shared
> > > registers doesn't mean it can't still keep the clk driver part in the
> > > drivers/clk/ area.
> > >
> >
> > Actually moving this to the soc directory has been requested by CK 
> > (mediatek) as
> > a change in v8. You can see the discussion in [1]
> >
>
> I can reply there in that thread if necessary, but we shouldn't need to
> force simple-mfd into DT bindings to support this. Match the compatible
> string in drivers/soc/ and register devices in software for the
> different pieces of this overall hardware block. If necessary, pass down
> the ioremapped addresss down through device data to each logical driver
> in the respective subsystem.
>
> So yes, it looks like an MFD, but that doesn't mean we have to change
> the DT binding or put it in drivers/mfd to support that. And we don't
> have to fix any problems with allowing two drivers to probe the same
> compatible string.
>

That thread maybe has too much information and things evolved since
then. Note that the final solution is not an MFD neither we change the
bindings. I pointed to that thread just because CK (CK please correct
me if I'm wrong) thought 

Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support

[Enric Balletbo Serra]

Hi Vasily,

Missatge de Vasily Khoruzhick  del dia dv., 14 de
febr. 2020 a les 23:17:
>
> On Fri, Feb 14, 2020 at 1:53 PM Enric Balletbo Serra
>  wrote:
> >
> > Hi Vasily,
> >
> > Missatge de Vasily Khoruzhick  del dia dv., 14 de
> > febr. 2020 a les 22:36:
> > >
> > > On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra
> > >  wrote:
> > > >
> > > > From: Nicolas Boichat 
> > > >
> > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> > > > that has an internal microcontroller.
> > > >
> > > > The only reason a Linux kernel driver is necessary is to reject
> > > > resolutions that require more bandwidth than what is available on
> > > > the DP side. DP bandwidth and lane count are reported by the bridge
> > > > via 2 registers on I2C.
> > >
> > > It is true only for your particular platform where usb-c part is
> > > managed by firmware. Pinephone has the same anx7688 but linux will
> > > need a driver that manages usb-c in addition to DP.
> > >
> > > I'd suggest making it MFD driver from the beginning, or at least make
> > > proper bindings so we don't have to rework it and introduce binding
> > > incompatibilities in future.
> > >
> >
> > Do you have example code on how the ANX7866 is used in pinephone?
> > There is a repo somewhere?
>
> I don't think it's implemented yet. I've CCed Icenowy in case if she
> has anything.
>

It would be good to join the effort. Just because I am curious, there
are public schematics for the pinephone that is using that bridge?

> > Thanks,
> >  Enric
> >
> > > > Signed-off-by: Nicolas Boichat 
> > > > Signed-off-by: Hsin-Yi Wang 
> > > > Signed-off-by: Enric Balletbo i Serra 
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Move driver to drivers/gpu/drm/bridge/analogix.
> > > > - Make the driver OF only so we can reduce the ifdefs.
> > > > - Update the Copyright to 2020.
> > > > - Use probe_new so we can get rid of the i2c_device_id table.
> > > >
> > > >  drivers/gpu/drm/bridge/analogix/Kconfig   |  12 ++
> > > >  drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
> > > >  .../drm/bridge/analogix/analogix-anx7688.c| 188 ++
> > > >  3 files changed, 201 insertions(+)
> > > >  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
> > > > b/drivers/gpu/drm/bridge/analogix/Kconfig
> > > > index e1fa7d820373..af7c2939403c 100644
> > > > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > > > @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> > > >   ANX6345 transforms the LVTTL RGB output of an
> > > >   application processor to eDP or DisplayPort.
> > > >
> > > > +config DRM_ANALOGIX_ANX7688
> > > > +   tristate "Analogix ANX7688 bridge"
> > > > +   depends on OF
> > > > +   select DRM_KMS_HELPER
> > > > +   select REGMAP_I2C
> > > > +   help
> > > > + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> > > > + mobile HD transmitter designed for portable devices. The
> > > > + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> > > > + including an intelligent crosspoint switch to support
> > > > + USB Type-C.
> > > > +
> > > >  config DRM_ANALOGIX_ANX78XX
> > > > tristate "Analogix ANX78XX bridge"
> > > > select DRM_ANALOGIX_DP
> > > > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> > > > b/drivers/gpu/drm/bridge/analogix/Makefile
> > > > index 97669b374098..27cd73635c8c 100644
> > > > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > > > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > > > @@ -1,5 +1,6 @@
> > > >  # SPDX-License-Identifier: GPL-2.0-only
> > > >  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o 
> > > > analogix-i2c-dptx.o
> > > >  obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> > > >  obj-$(CONFIG_DRM_ANALOGIX

Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support

[Enric Balletbo Serra]

Hi Vasily,

Missatge de Vasily Khoruzhick  del dia dv., 14 de
febr. 2020 a les 22:36:
>
> On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra
>  wrote:
> >
> > From: Nicolas Boichat 
> >
> > ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> > that has an internal microcontroller.
> >
> > The only reason a Linux kernel driver is necessary is to reject
> > resolutions that require more bandwidth than what is available on
> > the DP side. DP bandwidth and lane count are reported by the bridge
> > via 2 registers on I2C.
>
> It is true only for your particular platform where usb-c part is
> managed by firmware. Pinephone has the same anx7688 but linux will
> need a driver that manages usb-c in addition to DP.
>
> I'd suggest making it MFD driver from the beginning, or at least make
> proper bindings so we don't have to rework it and introduce binding
> incompatibilities in future.
>

Do you have example code on how the ANX7866 is used in pinephone?
There is a repo somewhere?

Thanks,
 Enric

> > Signed-off-by: Nicolas Boichat 
> > Signed-off-by: Hsin-Yi Wang 
> > Signed-off-by: Enric Balletbo i Serra 
> > ---
> >
> > Changes in v2:
> > - Move driver to drivers/gpu/drm/bridge/analogix.
> > - Make the driver OF only so we can reduce the ifdefs.
> > - Update the Copyright to 2020.
> > - Use probe_new so we can get rid of the i2c_device_id table.
> >
> >  drivers/gpu/drm/bridge/analogix/Kconfig   |  12 ++
> >  drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
> >  .../drm/bridge/analogix/analogix-anx7688.c| 188 ++
> >  3 files changed, 201 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
> > b/drivers/gpu/drm/bridge/analogix/Kconfig
> > index e1fa7d820373..af7c2939403c 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> >   ANX6345 transforms the LVTTL RGB output of an
> >   application processor to eDP or DisplayPort.
> >
> > +config DRM_ANALOGIX_ANX7688
> > +   tristate "Analogix ANX7688 bridge"
> > +   depends on OF
> > +   select DRM_KMS_HELPER
> > +   select REGMAP_I2C
> > +   help
> > + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> > + mobile HD transmitter designed for portable devices. The
> > + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> > + including an intelligent crosspoint switch to support
> > + USB Type-C.
> > +
> >  config DRM_ANALOGIX_ANX78XX
> > tristate "Analogix ANX78XX bridge"
> > select DRM_ANALOGIX_DP
> > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> > b/drivers/gpu/drm/bridge/analogix/Makefile
> > index 97669b374098..27cd73635c8c 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > @@ -1,5 +1,6 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o 
> > analogix-i2c-dptx.o
> >  obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> >  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> >  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c 
> > b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > new file mode 100644
> > index ..10a7cd0f9126
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * ANX7688 HDMI->DP bridge driver
> > + *
> > + * Copyright 2020 Google LLC
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Register addresses */
> > +#define VENDOR_ID_REG 0x00
> > +#define DEVICE_ID_REG 0x02
> > +
> > +#define FW_VERSION_REG 0x80
> > +
> > +#define DP_BANDWIDTH_REG 0x85
> > +#define DP_LANE_COUNT_REG 0x86
> > +
> > +#define VENDOR_ID 0x1f29
> > +#define DEVICE_ID 0x7688
> > +
> > +/* First supported firmware version (0.85) */
> > +#define MINIMUM_FW_VERSION 0x0085
> > +
> > +struct anx7688 {
> > +   struct drm_bridge bridge;
> > +   struct i2c_client *client;
> > +   struct regmap *regmap;
> > +
> > +   bool filter;
> > +};
> > +
> > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
> > +{
> > +   return container_of(bridge, struct anx7688, bridge);
> > +}
> > +
> > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode,
> > + struct drm_display_mode 
> > *adjusted_mode)
> > +{
> > +   struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
> > +   int totalbw, requiredbw;
> > +   u8 dpbw, lanecount;
> > +   u8 

Re: [PATCH 2/2] drm/mediatek: add fb swap in async_update

[Enric Balletbo Serra]

Hi,

Missatge de CK Hu  del dia dj., 13 de febr. 2020 a les 5:06:
>
> Hi, Bibby:
>
> On Thu, 2020-02-13 at 09:23 +0800, Bibby Hsieh wrote:
> > Besides x, y position, width and height,
> > fb also need updating in async update.
> >
>
> Reviewed-by: CK Hu 
>
> > Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic 
> > update")
> >
> > Signed-off-by: Bibby Hsieh 
> > ---

This patch actually fixes two issues as explained in [1], I send the
patch without seeing that another one was already sent. Both do the
same thing. So,

Tested-by: Enric Balletbo i Serra 

[1] https://lkml.org/lkml/2020/2/13/286

> >  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > index d32b494ff1de..e084c36fdd8a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > @@ -122,6 +122,7 @@ static void mtk_plane_atomic_async_update(struct 
> > drm_plane *plane,
> >   plane->state->src_y = new_state->src_y;
> >   plane->state->src_h = new_state->src_h;
> >   plane->state->src_w = new_state->src_w;
> > + swap(plane->state->fb, new_state->fb);
> >   state->pending.async_dirty = true;
> >
> >   mtk_drm_crtc_async_update(new_state->crtc, plane, new_state);
>
> --
> CK Hu 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/mediatek: reduce the hbp and hfp for phy timing

[Enric Balletbo Serra]

Hi all,

Missatge de Hsin-Yi Wang  del dia dl., 16 de des.
2019 a les 3:42:
>
> On Fri, Dec 13, 2019 at 9:52 AM Jitao Shi  wrote:
> >
> > There are some extra data transfer in dsi.
> > ex. LPX, hs_prepare, hs_zero, hs_exit and the sof/eof of dsi packet.
> > This signal will enlarge the line time. So the real frame on dsi bus
> > will be lower than calc by video timing.
> >
> > So dsi driver reduces the hbp and hfp to keep the line time.
> >

This patch not only reduces the hbp and hfp for phy timing, it also
fixes an actual issue for MT8173 boards (i.e. Acer Chromebook R 13)
which is that the display is not working anymore (black screen) after
7a5bc4e22ecfd74dc3662342beaa909770a3b786 "drm/mediatek: change the dsi
phytiming calculate method". So the patch is probably missing a:

Fixes: 7a5bc4e22ecf ("drm/mediatek: change the dsi phytiming calculate method")

And would be nice to have this patch applied for 5.5

> > Signed-off-by: Jitao Shi 
> Tested-by: Hsin-Yi Wang 

If it helps, you can also add my

Tested-by: Enric Balletbo i Serra 

Thanks,
 Enric

> > ---
>
> Tested on mt8183 and mt8173
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 7/9] drm/mediatek: change the dsi phytiming calculate method

[Enric Balletbo Serra]

Hi,

Missatge de CK Hu  del dia dj., 26 de set. 2019 a les 10:51:
>
> Hi, Jitao:
>
> On Thu, 2019-09-19 at 14:58 +0800, Jitao Shi wrote:
> > Change the method of frame rate calc which can get more accurate
> > frame rate.
> >
> > data rate = pixel_clock * bit_per_pixel / lanes
> > Adjust hfp_wc to adapt the additional phy_data
> >
> > if MIPI_DSI_MODE_VIDEO_BURST
> >   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> > else
> >   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
> >
> > Note:
> > //(2: 1 for sync, 1 for phy idle)
> > data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
> >
> > bpp: bit per pixel
>
> Reviewed-by: CK Hu 
>
> >
> > Signed-off-by: Jitao Shi 
> > Tested-by: Ryan Case 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dsi.c | 118 -

I didn't look in detail yet because looks like there is a lot of maths
involved, but this patch introduces a regression for MT8173 or my
board (Acer Chromebook R 13 - ELM). I need to revert this patch in
order to make the display working, basically, I don't see any error
but I only get a black screen. Reverting this patch fixes the issue
for me. If anyone knows what could be the problem I'd appreciate.

Thanks,
 Enric

> >  1 file changed, 81 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index b3676426aeb5..b02373b04848 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -136,12 +136,6 @@
> >  #define DATA_0   (0xff << 16)
> >  #define DATA_1   (0xff << 24)
> >
> > -#define T_LPX5
> > -#define T_HS_PREP6
> > -#define T_HS_TRAIL   8
> > -#define T_HS_EXIT7
> > -#define T_HS_ZERO10
> > -
> >  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
> >
> >  #define MTK_DSI_HOST_IS_READ(type) \
> > @@ -150,6 +144,25 @@
> >   (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> >   (type == MIPI_DSI_DCS_READ))
> >
> > +struct mtk_phy_timing {
> > + u32 lpx;
> > + u32 da_hs_prepare;
> > + u32 da_hs_zero;
> > + u32 da_hs_trail;
> > +
> > + u32 ta_go;
> > + u32 ta_sure;
> > + u32 ta_get;
> > + u32 da_hs_exit;
> > +
> > + u32 clk_hs_zero;
> > + u32 clk_hs_trail;
> > +
> > + u32 clk_hs_prepare;
> > + u32 clk_hs_post;
> > + u32 clk_hs_exit;
> > +};
> > +
> >  struct phy;
> >
> >  struct mtk_dsi_driver_data {
> > @@ -180,6 +193,7 @@ struct mtk_dsi {
> >   enum mipi_dsi_pixel_format format;
> >   unsigned int lanes;
> >   struct videomode vm;
> > + struct mtk_phy_timing phy_timing;
> >   int refcount;
> >   bool enabled;
> >   u32 irq_data;
> > @@ -213,17 +227,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
> >  {
> >   u32 timcon0, timcon1, timcon2, timcon3;
> >   u32 ui, cycle_time;
> > + struct mtk_phy_timing *timing = >phy_timing;
> > +
> > + ui = DIV_ROUND_UP(10, dsi->data_rate);
> > + cycle_time = div_u64(80ULL, dsi->data_rate);
> > +
> > + timing->lpx = NS_TO_CYCLE(60, cycle_time);
> > + timing->da_hs_prepare = NS_TO_CYCLE(50 + 5 * ui, cycle_time);
> > + timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
> > + timing->da_hs_trail = NS_TO_CYCLE(77 + 4 * ui, cycle_time);
> >
> > - ui = 1000 / dsi->data_rate + 0x01;
> > - cycle_time = 8000 / dsi->data_rate + 0x01;
> > + timing->ta_go = 4 * timing->lpx;
> > + timing->ta_sure = 3 * timing->lpx / 2;
> > + timing->ta_get = 5 * timing->lpx;
> > + timing->da_hs_exit = 2 * timing->lpx;
> >
> > - timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> > - timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> > -   T_HS_EXIT << 24;
> > - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > -   (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > - timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> > -   NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
> > + timing->clk_hs_zero = NS_TO_CYCLE(336, cycle_time);
> > + timing->clk_hs_trail = NS_TO_CYCLE(100, cycle_time) + 10;
> > +
> > + timing->clk_hs_prepare = NS_TO_CYCLE(64, cycle_time);
> > + timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
> > + timing->clk_hs_exit = 2 * timing->lpx;
> > +
> > + timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> > +   timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
> > + timcon1 = timing->ta_go | timing->ta_sure << 8 |
> > +   timing->ta_get << 16 | timing->da_hs_exit << 24;
> > + timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
> > +   timing->clk_hs_trail << 24;
> > + timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
> > +   timing->clk_hs_exit << 16;
> >
> >   

Re: [PATCH v20 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Enric Balletbo Serra]

Hi,

cc'ing  the drm/bridge maintainers which I think are missing (Andrzej
Hajda and Neil Armstrong)

Missatge de Matthias Brugger  del dia dl., 7
d’oct. 2019 a les 13:04:
>
>
>
> On 07/10/2019 10:22, Ulrich Hecht wrote:
> > From: Jitao Shi 
> >
> > This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
> >
> > Signed-off-by: Jitao Shi 
> > Reviewed-by: Daniel Kurtz 
> > Reviewed-by: Enric Balletbo i Serra 
> > [uli: followed API changes, removed FW update feature]
> > Signed-off-by: Ulrich Hecht 
>
> Now it works, thanks for pushing this forward :)
>
> Tested-by: Matthias Brugger 
>

This bridge is really needed in case you have an Acer Chromebook R13,
otherwise, you don't have the display working. Would be nice have it
upstream :-), If it helps, I tested this patch on top of current
5.4-rc8 and I get the display working, so

Tested-by: Enric Balletbo i Serra 

Thanks,
 Enric

> > ---
> >
> > Changes since v19:
> >  - fixed return value of ps8640_probe() when no panel is found
> >
> > Changes since v18:
> >  - followed DRM API changes
> >  - use DEVICE_ATTR_RO()
> >  - remove firmware update code
> >  - add SPDX identifier
> >
> > Changes since v17:
> >  - remove some unused head files.
> >  - add macros for ps8640 pages.
> >  - remove ddc_i2c client
> >  - add mipi_dsi_device_register_full
> >  - remove the manufacturer from the name and i2c_device_id
> >
> > Changes since v16:
> >  - Disable ps8640 DSI MCS Function.
> >  - Rename gpios name more clearly.
> >  - Tune the ps8640 power on sequence.
> >
> > Changes since v15:
> >  - Drop drm_connector_(un)register calls from parade ps8640.
> >The main DRM driver mtk_drm_drv now calls
> >drm_connector_register_all() after drm_dev_register() in the
> >mtk_drm_bind() function. That function should iterate over all
> >connectors and call drm_connector_register() for each of them.
> >So, remove drm_connector_(un)register calls from parade ps8640.
> >
> > Changes since v14:
> >  - update copyright info.
> >  - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
> >  - fix some coding style.
> >  - use sizeof as array counter.
> >  - use drm_get_edid when read edid.
> >  - add mutex when firmware updating.
> >
> > Changes since v13:
> >  - add const on data, ps8640_write_bytes(struct i2c_client *client, const 
> > u8 *data, u16 data_len)
> >  - fix PAGE2_SW_REST tyro.
> >  - move the buf[3] init to entrance of the function.
> >
> > Changes since v12:
> >  - fix hw_chip_id build warning
> >
> > Changes since v11:
> >  - Remove depends on I2C, add DRM depends
> >  - Reuse ps8640_write_bytes() in ps8640_write_byte()
> >  - Use timer check for polling like the routines in 
> >  - Fix no drm_connector_unregister/drm_connector_cleanup when 
> > ps8640_bridge_attach fail
> >  - Check the ps8640 hardware id in ps8640_validate_firmware
> >  - Remove fw_version check
> >  - Move ps8640_validate_firmware before ps8640_enter_bl
> >  - Add ddc_i2c unregister when probe fail and ps8640_remove
> >
> >
> >  drivers/gpu/drm/bridge/Kconfig |  12 +
> >  drivers/gpu/drm/bridge/Makefile|   1 +
> >  drivers/gpu/drm/bridge/parade-ps8640.c | 672 
> > +
> >  3 files changed, 685 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 1cc9f50..61c6415 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -82,6 +82,18 @@ config DRM_PARADE_PS8622
> >   ---help---
> > Parade eDP-LVDS bridge chip driver.
> >
> > +config DRM_PARADE_PS8640
> > + tristate "Parade PS8640 MIPI DSI to eDP Converter"
> > + depends on DRM
> > + depends on OF
> > + select DRM_KMS_HELPER
> > + select DRM_MIPI_DSI
> > + select DRM_PANEL
> > + help
> > +   Choose this option if you have PS8640 for display
> > +   The PS8640 is a high-performance and low-power
> > +   MIPI DSI to eDP converter
> > +
> >  config DRM_SIL_SII8620
> >   tristate "Silicon Image SII8620 HDMI/MHL bridge"
> >   depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf..14660ab 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> >  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> > megachips-stdp-ge-b850v3-fw.o
> >  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> >  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> >  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> >  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> >  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > new file mode 100644
> > index 

Re: [PATCH 2/2 v2] drm/atomic: clear new_state pointers at hw_done

[Enric Balletbo Serra]

Hi Rob,

Missatge de Rob Clark  del dia dl., 4 de nov.
2019 a les 18:42:
>
> From: Rob Clark 
>
> The new state should not be accessed after this point.  Clear the
> pointers to make that explicit.
>
> Signed-off-by: Rob Clark 

While looking to another issue I applied this patch on top of 5.4-rc7
and my display stopped working. The system gets stuck with the
messages below

...
[   17.558689] rockchip-vop ff8f.vop: Adding to iommu group 1
[   17.566014] rk3399-gru-sound sound: ASoC: failed to init link DP: -517
[   17.567618] rockchip-vop ff90.vop: Adding to iommu group 2
[   17.580671] rk3399-gru-sound sound: ASoC: failed to init link DP: -517
[   17.585996] rockchip-drm display-subsystem: bound ff8f.vop (ops
vop_component_ops [rockchipdrm])
[   17.589294] rk3399-gru-sound sound: ASoC: failed to init link DP: -517
[   17.599899] rockchip-drm display-subsystem: bound ff90.vop (ops
vop_component_ops [rockchipdrm])
[   17.615846] rockchip-dp ff97.edp: no DP phy configured
[   17.622495] rockchip-drm display-subsystem: bound ff97.edp (ops
rockchip_dp_component_ops [rockchipdrm])
[   17.633688] rockchip-drm display-subsystem: bound fec0.dp (ops
cdn_dp_component_ops [rockchipdrm])
[   17.644141] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   17.651548] [drm] No driver support for vblank timestamp query.

Not really useful information at this point, but I am wondering if
could be that the rockchip driver is doing something wrong more than
this patch is wrong?

Thanks,
 Enric

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 30 +
>  1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 648494c813e5..aec9759d9df2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2246,12 +2246,42 @@ EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
>   */
>  void drm_atomic_helper_commit_hw_done(struct drm_atomic_state *old_state)
>  {
> +   struct drm_connector *connector;
> +   struct drm_connector_state *old_conn_state, *new_conn_state;
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> +   struct drm_plane *plane;
> +   struct drm_plane_state *old_plane_state, *new_plane_state;
> struct drm_crtc_commit *commit;
> +   struct drm_private_obj *obj;
> +   struct drm_private_state *old_obj_state, *new_obj_state;
> int i;
>
> +   /*
> +* After this point, drivers should not access the permanent modeset
> +* state, so we also clear the new_state pointers to make this
> +* restriction explicit.
> +*
> +* For the CRTC state, we do this in the same loop where we signal
> +* hw_done, since we still need to new_crtc_state to fish out the
> +* commit.
> +*/
> +
> +   for_each_oldnew_connector_in_state(old_state, connector, 
> old_conn_state, new_conn_state, i) {
> +   old_state->connectors[i].new_state = NULL;
> +   }
> +
> +   for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, 
> new_plane_state, i) {
> +   old_state->planes[i].new_state = NULL;
> +   }
> +
> +   for_each_oldnew_private_obj_in_state(old_state, obj, old_obj_state, 
> new_obj_state, i) {
> +   old_state->private_objs[i].new_state = NULL;
> +   }
> +
> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> +   old_state->crtcs[i].new_state = NULL;
> +
> commit = new_crtc_state->commit;
> if (!commit)
> continue;
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] drm: Measure Self Refresh Entry/Exit times to avoid thrashing

[Enric Balletbo Serra]

Missatge de Enric Balletbo Serra  del dia dc., 30
d’oct. 2019 a les 17:59:
>
> Hi Sean,
>
> Since 5.4-rc1 my Samsung Chromebook Plus (kevin) doesn't
> suspend/resume correctly, at least once every ten suspend/resume
> cycles the display doesn't turn on, and when this happens the kernel
> log message reports:
>
> [   60.420230] PM: suspend exit
> [   60.463866] rockchip-dp ff97.edp: AUX CH cmd reply timeout!
> [   60.971653] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   61.478668] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   61.985661] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   62.492644] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   62.999617] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   63.506595] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   64.013678] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   64.522856] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   60.463866] rockchip-dp ff97.edp: AUX CH cmd reply timeout!
> [   60.971653] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   61.478668] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   61.985661] rockchip-dp ff97.edp: AUX CH enable timeout!
> [   62.492644] rockchip-dp ff97.edp: AUX CH enable timeout!
> ...
>
> Today I bisected the problem and pointed me to this commit. Reverting
> the commit fixes the issue, but from I quick look I don't see any
> obvious problem. I'll spend more time tomorrow looking at this but any
> idea will be welcome.
>

Update for the record. After looking a bit more I don't think this
patch is problematic. I think the problem was already there but after
this patch is easier to reproduce just because the PSR entry code work
is delayed a bit (before was called every 100ms). I think the problem
is more related with the current enable/disable path when panel is in
SR mode or not after a suspend/resume.

Anyway, I will continue the discussion on another thread when I find
the root cause.

Thanks,
 Enric

> Thanks,
>  Enric
>
> Missatge de Sean Paul  del dia dj., 19 de set. 2019 a
> les 16:14:
> >
> > On Wed, Sep 18, 2019 at 04:07:29PM -0400, Sean Paul wrote:
> > > From: Sean Paul 
> > >
> > > Currently the self refresh idle timer is a const set by the crtc. This
> > > is fine if the self refresh entry/exit times are well-known for all
> > > panels used on that crtc. However panels and workloads can vary quite a
> > > bit, and a timeout which works well for one doesn't work well for
> > > another.
> > >
> > > In the extreme, if the timeout is too short we could get in a situation
> > > where the self refresh exits are taking so long we queue up a self refresh
> > > entry before the exit commit is even finished.
> > >
> > > This patch changes the idle timeout to a moving average of the entry
> > > times + a moving average of exit times + the crtc constant.
> > >
> > > This patch was tested on rockchip, with a kevin CrOS panel the idle
> > > delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On
> > > the same board, the bob panel idle delay lands around ~340ms (90 entry
> > > + 150 exit + 100 const).
> > >
> > > WRT the dedicated mutex in self_refresh_data, it would be nice if we
> > > could rely on drm_crtc.mutex to protect the average times, but there are
> > > a few reasons why a separate lock is a better choice:
> > > - We can't rely on drm_crtc.mutex being held if we're doing a nonblocking
> > >   commit
> > > - We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us
> > >   whether the lock was already held in the acquire context (it eats
> > >   -EALREADY), so we can't tell if we should drop it or not
> > > - We don't need such a heavy-handed lock for what we're trying to do,
> > >   commit ordering doesn't matter, so a point-of-use lock will be less
> > >   contentious
> > >
> > > Reviewed-by: Daniel Vetter 
> >
> > Pushed the first 2 to drm-misc-next-fixes to fix the gru-bob regression. 
> > I'll
> > fix up the 3rd patch separately.
> >
> > Thank you for the reviews!
> >
> > Sean
> >
> > > Signed-off-by: Sean Paul 
> > > Link to v1: 
> > > https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-s...@poorly.run
> > >
> > > Changes in v2:
> > > - Migrate locking explanation from comment to commit msg (Daniel)
> > > - Turf constant entry delay and multiply the avg times by 2 (Daniel)
> > > ---
> > >  drivers/gpu/drm/drm_atomic_he

Re: [PATCH v2 2/3] drm: Measure Self Refresh Entry/Exit times to avoid thrashing

[Enric Balletbo Serra]

Hi Sean,

Since 5.4-rc1 my Samsung Chromebook Plus (kevin) doesn't
suspend/resume correctly, at least once every ten suspend/resume
cycles the display doesn't turn on, and when this happens the kernel
log message reports:

[   60.420230] PM: suspend exit
[   60.463866] rockchip-dp ff97.edp: AUX CH cmd reply timeout!
[   60.971653] rockchip-dp ff97.edp: AUX CH enable timeout!
[   61.478668] rockchip-dp ff97.edp: AUX CH enable timeout!
[   61.985661] rockchip-dp ff97.edp: AUX CH enable timeout!
[   62.492644] rockchip-dp ff97.edp: AUX CH enable timeout!
[   62.999617] rockchip-dp ff97.edp: AUX CH enable timeout!
[   63.506595] rockchip-dp ff97.edp: AUX CH enable timeout!
[   64.013678] rockchip-dp ff97.edp: AUX CH enable timeout!
[   64.522856] rockchip-dp ff97.edp: AUX CH enable timeout!
[   60.463866] rockchip-dp ff97.edp: AUX CH cmd reply timeout!
[   60.971653] rockchip-dp ff97.edp: AUX CH enable timeout!
[   61.478668] rockchip-dp ff97.edp: AUX CH enable timeout!
[   61.985661] rockchip-dp ff97.edp: AUX CH enable timeout!
[   62.492644] rockchip-dp ff97.edp: AUX CH enable timeout!
...

Today I bisected the problem and pointed me to this commit. Reverting
the commit fixes the issue, but from I quick look I don't see any
obvious problem. I'll spend more time tomorrow looking at this but any
idea will be welcome.

Thanks,
 Enric

Missatge de Sean Paul  del dia dj., 19 de set. 2019 a
les 16:14:
>
> On Wed, Sep 18, 2019 at 04:07:29PM -0400, Sean Paul wrote:
> > From: Sean Paul 
> >
> > Currently the self refresh idle timer is a const set by the crtc. This
> > is fine if the self refresh entry/exit times are well-known for all
> > panels used on that crtc. However panels and workloads can vary quite a
> > bit, and a timeout which works well for one doesn't work well for
> > another.
> >
> > In the extreme, if the timeout is too short we could get in a situation
> > where the self refresh exits are taking so long we queue up a self refresh
> > entry before the exit commit is even finished.
> >
> > This patch changes the idle timeout to a moving average of the entry
> > times + a moving average of exit times + the crtc constant.
> >
> > This patch was tested on rockchip, with a kevin CrOS panel the idle
> > delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On
> > the same board, the bob panel idle delay lands around ~340ms (90 entry
> > + 150 exit + 100 const).
> >
> > WRT the dedicated mutex in self_refresh_data, it would be nice if we
> > could rely on drm_crtc.mutex to protect the average times, but there are
> > a few reasons why a separate lock is a better choice:
> > - We can't rely on drm_crtc.mutex being held if we're doing a nonblocking
> >   commit
> > - We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us
> >   whether the lock was already held in the acquire context (it eats
> >   -EALREADY), so we can't tell if we should drop it or not
> > - We don't need such a heavy-handed lock for what we're trying to do,
> >   commit ordering doesn't matter, so a point-of-use lock will be less
> >   contentious
> >
> > Reviewed-by: Daniel Vetter 
>
> Pushed the first 2 to drm-misc-next-fixes to fix the gru-bob regression. I'll
> fix up the 3rd patch separately.
>
> Thank you for the reviews!
>
> Sean
>
> > Signed-off-by: Sean Paul 
> > Link to v1: 
> > https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-s...@poorly.run
> >
> > Changes in v2:
> > - Migrate locking explanation from comment to commit msg (Daniel)
> > - Turf constant entry delay and multiply the avg times by 2 (Daniel)
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 20 ++
> >  drivers/gpu/drm/drm_self_refresh_helper.c   | 72 +++--
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  5 +-
> >  include/drm/drm_self_refresh_helper.h   |  6 +-
> >  4 files changed, 90 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 9d7e4da6c292..3f13fa9a9e24 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -26,6 +26,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -1570,9 +1571,23 @@ static void commit_tail(struct drm_atomic_state 
> > *old_state)
> >  {
> >   struct drm_device *dev = old_state->dev;
> >   const struct drm_mode_config_helper_funcs *funcs;
> > + ktime_t start;
> > + s64 commit_time_ms;
> >
> >   funcs = dev->mode_config.helper_private;
> >
> > + /*
> > +  * We're measuring the _entire_ commit, so the time will vary 
> > depending
> > +  * on how many fences and objects are involved. For the purposes of 
> > self
> > +  * refresh, this is desirable since it'll give us an idea of how
> > +  * congested things are. This will inform our decision on how often we
> > +  * should enter 

Re: [PATCH v3 5/7] drm/bridge: Add Analogix anx6345 support

[Enric Balletbo Serra]

Hi,

Missatge de Vasily Khoruzhick  del dia dl., 22 de
jul. 2019 a les 20:50:
>
> On Mon, Jul 22, 2019 at 8:11 AM Torsten Duwe  wrote:
> >
> > From: Icenowy Zheng 
> >
> > The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
> > for portable devices. This driver adds initial support for RGB to eDP
> > mode, without HPD and interrupts.
> >
> > This is a configuration usually seen in eDP applications.
> >
> > Signed-off-by: Icenowy Zheng 
> > Signed-off-by: Vasily Khoruzhick 
> > Signed-off-by: Torsten Duwe 
> > ---
> >  drivers/gpu/drm/bridge/analogix/Kconfig|  12 +
> >  drivers/gpu/drm/bridge/analogix/Makefile   |   1 +
> >  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 797 
> > +
> >  3 files changed, 810 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> >
> > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -1,6 +1,18 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> > +config DRM_ANALOGIX_ANX6345
> > +   tristate "Analogix ANX6345 bridge"
> > +   select DRM_ANALOGIX_DP
> > +   select DRM_KMS_HELPER
> > +   select REGMAP_I2C
> > +   help
> > + ANX6345 is an ultra-low Full-HD DisplayPort/eDP
> > + transmitter designed for portable devices. The
> > + ANX6345 transforms the LVTTL RGB output of an
> > + application processor to eDP or DisplayPort.
> > +
> >  config DRM_ANALOGIX_ANX78XX
> > tristate "Analogix ANX78XX bridge"
> > +   select DRM_ANALOGIX_DP
> > select DRM_KMS_HELPER
> > select REGMAP_I2C
> > help
> > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > @@ -1,4 +1,5 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> >  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o 
> > analogix-i2c-dptx.o
> > +obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> >  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> >  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> > @@ -0,0 +1,793 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright(c) 2016, Analogix Semiconductor.
> > + * Copyright(c) 2017, Icenowy Zheng 
> > + *
> > + * Based on anx7808 driver obtained from chromeos with copyright:
> > + * Copyright(c) 2013, Google Inc.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "analogix-i2c-dptx.h"
> > +#include "analogix-i2c-txcommon.h"
> > +
> > +#define POLL_DELAY 5 /* us */
> > +#define POLL_TIMEOUT   500 /* us */
> > +
> > +#define I2C_IDX_DPTX   0
> > +#define I2C_IDX_TXCOM  1
> > +
> > +static const u8 anx6345_i2c_addresses[] = {
> > +   [I2C_IDX_DPTX]  = ANALOGIX_I2C_DPTX,
> > +   [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON,
> > +};
> > +#define I2C_NUM_ADDRESSES  ARRAY_SIZE(anx6345_i2c_addresses)
> > +
> > +struct anx6345 {
> > +   struct drm_dp_aux aux;
> > +   struct drm_bridge bridge;
> > +   struct i2c_client *client;
> > +   struct edid *edid;
> > +   struct drm_connector connector;
> > +   struct drm_dp_link link;
> > +   struct drm_panel *panel;
> > +   struct regulator *dvdd12;
> > +   struct regulator *dvdd25;
> > +   struct gpio_desc *gpiod_reset;
> > +   struct mutex lock;  /* protect EDID access */
> > +
> > +   /* I2C Slave addresses of ANX6345 are mapped as DPTX and SYS */
> > +   struct i2c_client *i2c_clients[I2C_NUM_ADDRESSES];
> > +   struct regmap *map[I2C_NUM_ADDRESSES];
> > +
> > +   u16 chipid;
> > +   u8 dpcd[DP_RECEIVER_CAP_SIZE];
> > +
> > +   bool powered;
> > +};
> > +
> > +static inline struct anx6345 *connector_to_anx6345(struct drm_connector *c)
> > +{
> > +   return container_of(c, struct anx6345, connector);
> > +}
> > +
> > +static inline struct anx6345 *bridge_to_anx6345(struct drm_bridge *bridge)
> > +{
> > +   return container_of(bridge, struct anx6345, bridge);
> > +}
> > +
> > +static int anx6345_set_bits(struct regmap *map, u8 reg, u8 mask)
> > +{
> > +   return regmap_update_bits(map, reg, mask, mask);
> > +}
> > +
> > +static int anx6345_clear_bits(struct regmap *map, u8 reg, u8 mask)
> > +{
> > +   return regmap_update_bits(map, reg, mask, 0);
> > +}
> > +
> > +static ssize_t anx6345_aux_transfer(struct drm_dp_aux *aux,
> > +   struct drm_dp_aux_msg *msg)
> > +{
> > +   struct anx6345 *anx6345 = container_of(aux, struct anx6345, aux);
> > +
> > +   return 

Re: [PATCH v3] backlight: pwm_bl: Fix brightness levels for non-DT case.

[Enric Balletbo Serra]

Hi,
Missatge de Enric Balletbo i Serra  del
dia dc., 7 de nov. 2018 a les 9:56:
>
> Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> linearly to human eye")' allows the possibility to compute a default
> brightness table when there isn't the brightness-levels property in the
> DT. Unfortunately the changes made broke the pwm backlight for the
> non-DT boards.
>
> Usually, the non-DT boards don't pass the brightness levels via platform
> data, instead, it sets the max_brightness in their platform data and the
> driver calculates the level without a table. The offending patch assumed
> that when there is no brightness levels table we should create one, but this
> is clearly wrong for the non-DT case.
>
> After this patch the code handles the DT and the non-DT case taking in
> consideration also if max_brightness is set or not.
>
> Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly 
> to human eye")
> Cc: 
> Reported-by: Robert Jarzmik 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Robert Jarzmik 
> Acked-by: Daniel Thompson 
> ---
>
> Changes in v3:
> - Fixed some typos in commit message.
> - Removed ' in Fixes tag.
>
> Changes in v2:
> - Rebase on top of mainline
> - Add Tested-by and Acked-by tags.
>
>  drivers/video/backlight/pwm_bl.c | 41 +++-
>  1 file changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index 678b27063198..f9ef0673a083 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -562,7 +562,30 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
> goto err_alloc;
> }
>
> -   if (!data->levels) {
> +   if (data->levels) {
> +   /*
> +* For the DT case, only when brightness levels is defined
> +* data->levels is filled. For the non-DT case, data->levels
> +* can come from platform data, however is not usual.
> +*/
> +   for (i = 0; i <= data->max_brightness; i++) {
> +   if (data->levels[i] > pb->scale)
> +   pb->scale = data->levels[i];
> +
> +   pb->levels = data->levels;
> +   }
> +   } else if (!data->max_brightness) {
> +   /*
> +* If no brightness levels are provided and max_brightness is
> +* not set, use the default brightness table. For the DT case,
> +* max_brightness is set to 0 when brightness levels is not
> +* specified. For the non-DT case, max_brightness is usually
> +* set to some value.
> +*/
> +
> +   /* Get the PWM period (in nanoseconds) */
> +   pwm_get_state(pb->pwm, );
> +
> ret = pwm_backlight_brightness_default(>dev, data,
>state.period);
> if (ret < 0) {
> @@ -570,13 +593,19 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
> "failed to setup default brightness table\n");
> goto err_alloc;
> }
> -   }
>
> -   for (i = 0; i <= data->max_brightness; i++) {
> -   if (data->levels[i] > pb->scale)
> -   pb->scale = data->levels[i];
> +   for (i = 0; i <= data->max_brightness; i++) {
> +   if (data->levels[i] > pb->scale)
> +   pb->scale = data->levels[i];
>
> -   pb->levels = data->levels;
> +   pb->levels = data->levels;
> +   }
> +   } else {
> +   /*
> +* That only happens for the non-DT case, where platform data
> +* sets the max_brightness value.
> +*/
> +   pb->scale = data->max_brightness;
> }
>
> pb->lth_brightness = data->lth_brightness * (state.period / 
> pb->scale);
> --
> 2.19.1
>

A gentle ping on this patch.

Best regards,
 Enric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/rockchip: update cursors asynchronously through atomic.

[Enric Balletbo Serra]

Hi Tomasz,

cc'ing Helen as she will continue the work.

Missatge de Tomasz Figa  del dia dc., 14 de nov.
2018 a les 9:49:
>
> Hi Enric,
>
> On Fri, Sep 28, 2018 at 5:27 PM Enric Balletbo i Serra
>  wrote:
> >
> > Add support to async updates of cursors by using the new atomic
> > interface for that.
> >
> > Signed-off-by: Enric Balletbo i Serra 
> > ---
> > Hi,
> >
> > This is a second version of the patch to add async-plane update support
> > to the Rockchip driver.
> >
>
> I'm really sorry for the super late reply. I couldn't get cycles to
> look at this earlier. :(
>

No problem, many thanks for looking at it.

> > The patch was tested on a Samsung Chromebook Plus in two ways.
> >
> >  1. Running all igt kms_cursor_legacy and kms_atomic tests and see that
> > there is no regression after the patch.
> > Note that before the patch, the following igt tests failed:
> > - basic-flip-before-cursor-legacy
> > - basic-flip-before-cursor-atomic
> > - cursor-vs-flip-legacy
> > - cursor-vs-flip-toggle
> > - flip-vs-cursor-atomic
> > - flip-vs-cursor-crc-atomic
> > - flip-vs-cursor-crc-legacy
> > - flip-vs-cursor-legacy
> > - flip-vs-cursor-crc-atomic
> > - flip-vs-cursor-crc-legacy
>
> Are the last 2 tests repeated?
>
Right, are repeated sorry.

> >
> > With the patch applied only two tests don't fail (these two are
> > expexted to not pass right now):
> > - flip-vs-cursor-crc-atomic
> > - flip-vs-cursor-crc-legac
>
> Did you mean "don't pass"?
>

Yes, the only two tests that don't pass are the cursor-crc ones.

> >
> > You can check full IGT test report here:
> > - Before the patch:
> > 
> > https://people.collabora.com/~eballetbo/tests/igt/samsung-chromebook-plus/igt-1.23/4.19-rc5/index.html
> > - With the patch applied:
> > 
> > https://people.collabora.com/~eballetbo/tests/igt/samsung-chromebook-plus/igt-1.23/4.19-rc5-async-update/index.html
> >
> >  2. Running weston using the atomic API.
> >
> > Best regards,
> >   Enric
> >
> > Changes in v2:
> > - Change the framebuffer as well to cover jumpy cursor when hovering
> >   text boxes or hyperlink. (Tomasz)
> > - Use the PSR inhibit mechanism when accessing VOP hardware instead of
> >   PSR flushing (Tomasz)
> >
> > Changes in v1:
> > - Rebased on top of drm-misc
> > - In async_check call drm_atomic_helper_check_plane_state to check that
> >   the desired plane is valid and update various bits of derived state
> >   (clipped coordinates etc.)
> > - In async_check allow to configure new scaling in the fast path.
> > - In async_update force to flush all registered PSR encoders.
> > - In async_update call atomic_update directly.
> > - In async_update call vop_cfg_done needed to set the vop registers and 
> > take effect.
> >
> >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 36 
> >  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 37 
> >  drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  3 +
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 62 +
> >  4 files changed, 102 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > index 7b6f7227d476..aec9a997de13 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > @@ -128,24 +128,6 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
> > drm_file *file_priv,
> > return ERR_PTR(ret);
> >  }
> >
> > -static void
> > -rockchip_drm_psr_inhibit_get_state(struct drm_atomic_state *state)
> > -{
> > -   struct drm_crtc *crtc;
> > -   struct drm_crtc_state *crtc_state;
> > -   struct drm_encoder *encoder;
> > -   u32 encoder_mask = 0;
> > -   int i;
> > -
> > -   for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
> > -   encoder_mask |= crtc_state->encoder_mask;
> > -   encoder_mask |= crtc->state->encoder_mask;
> > -   }
> > -
> > -   drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
> > -   rockchip_drm_psr_inhibit_get(encoder);
> > -}
> > -
> >  uint32_t rockchip_drm_get_vblank_ns(struct drm_display_mode *mode)
> >  {
> > uint64_t vblank_time = mode->vtotal - mode->vdisplay;
> > @@ -156,24 +138,6 @@ uint32_t rockchip_drm_get_vblank_ns(struct 
> > drm_display_mode *mode)
> > return vblank_time;
> >  }
> >
> > -static void
> > -rockchip_drm_psr_inhibit_put_state(struct drm_atomic_state *state)
> > -{
> > -   struct drm_crtc *crtc;
> > -   struct drm_crtc_state *crtc_state;
> > -   struct drm_encoder *encoder;
> > -   u32 encoder_mask = 0;
> > -   int i;
> > -
> > -   for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
> > -   encoder_mask |= crtc_state->encoder_mask;
> > -   encoder_mask |= crtc->state->encoder_mask;
> > -   }
> > -
> > -   drm_for_each_encoder_mask(encoder, 

Re: [PATCH v2] drm/rockchip: fix coding style and incorrect description

[Enric Balletbo Serra]

Missatge de Sandy Huang  del dia dt., 28 d’ag.
2018 a les 9:45:
>
> Align with other drivers, tab + 2 space key for description.
> and edp/hdmi/dsi can be used on both rk3288 and rk3399.
>
> Signed-off-by: Sandy Huang 
> ---
>  drivers/gpu/drm/rockchip/Kconfig | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0ccc762..0534dc1 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -23,7 +23,7 @@ config ROCKCHIP_ANALOGIX_DP
> help
>   This selects support for Rockchip SoC specific extensions
>   for the Analogix Core DP driver. If you want to enable DP
> - on RK3288 based SoC, you should selet this option.
> + on RK3288 or RK3399 based SoC, you should select this option.
>
>  config ROCKCHIP_CDN_DP
>  bool "Rockchip cdn DP"
> @@ -39,16 +39,16 @@ config ROCKCHIP_DW_HDMI
>  help
>   This selects support for Rockchip SoC specific extensions
>   for the Synopsys DesignWare HDMI driver. If you want to
> - enable HDMI on RK3288 based SoC, you should selet this
> - option.
> + enable HDMI on RK3288 or RK3399 based SoC, you should select
> + this option.
>
>  config ROCKCHIP_DW_MIPI_DSI
> bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
> help
> -This selects support for Rockchip SoC specific extensions
> -for the Synopsys DesignWare HDMI driver. If you want to
> -enable MIPI DSI on RK3288 based SoC, you should selet this
> -option.
> + This selects support for Rockchip SoC specific extensions
> + for the Synopsys DesignWare HDMI driver. If you want to
> + enable MIPI DSI on RK3288 or RK3399 based SoC, you should
> + select this option.
>
>  config ROCKCHIP_INNO_HDMI
> bool "Rockchip specific extensions for Innosilicon HDMI"
> --
> 2.7.4

If it helps...

Reviewed-by: Enric Balletbo i Serra 

>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: fix coding style and incorrect description

[Enric Balletbo Serra]

Hi Sandy,

Just noticed a typo that I think will be good fix also
Missatge de Sandy Huang  del dia dl., 27 d’ag.
2018 a les 8:31:
>
> Align with other drivers, tab + 2 space key for description.
> and this option should be enabled on both rk3288 and rk3399.
>
> Signed-off-by: Sandy Huang 
> ---
>  drivers/gpu/drm/rockchip/Kconfig | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0ccc762..601234b 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -45,10 +45,10 @@ config ROCKCHIP_DW_HDMI
>  config ROCKCHIP_DW_MIPI_DSI
> bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
> help
> -This selects support for Rockchip SoC specific extensions
> -for the Synopsys DesignWare HDMI driver. If you want to
> -enable MIPI DSI on RK3288 based SoC, you should selet this
> -option.
> + This selects support for Rockchip SoC specific extensions
> + for the Synopsys DesignWare HDMI driver. If you want to
> + enable MIPI DSI on RK3288 or RK3399 based SoC, you should
> + selet this option.

s/selet/select/

Cheers,
 Enric

>
>  config ROCKCHIP_INNO_HDMI
> bool "Rockchip specific extensions for Innosilicon HDMI"
> --
> 2.7.4
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 03/10] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.

[Enric Balletbo Serra]

Hi Chanwoo,

I'll send a new version soon, just wanted to ask some questions here. See below.

Missatge de Chanwoo Choi  del dia dt., 15 de
maig 2018 a les 0:21:
>
> Hi,
>
> On 2018년 05월 15일 06:16, Enric Balletbo i Serra wrote:
> > Trusted Firmware-A (TF-A) for rk3399 implements a SiP call to get the
> > on-die termination (ODT) and auto power down parameters from kernel,
> > this patch adds the functionality to do this. Also, if DDR clock
> > frequency is lower than the on-die termination (ODT) disable frequency
> > this driver should disable the DDR ODT.
>
> I have a question.
> 'disable frequency' is the same meaning of 'disable the DDR ODT'?
>

Yes, the DT defines an odt_dis_freq parameter, when the DDR frequency
is less than the value in this parameter we disable the ODT on the
DRAM.

> >
> > Signed-off-by: Enric Balletbo i Serra 
> > ---
> >
> >  drivers/devfreq/rk3399_dmc.c| 50 -
> >  include/soc/rockchip/rockchip_sip.h |  1 +
> >  2 files changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> > index d5c03e5abe13..cc1bbca3fb15 100644
> > --- a/drivers/devfreq/rk3399_dmc.c
> > +++ b/drivers/devfreq/rk3399_dmc.c
> > @@ -18,14 +18,17 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >
> > +#include 
> >  #include 
> >
> >  struct dram_timing {
> > @@ -69,8 +72,11 @@ struct rk3399_dmcfreq {
> >   struct mutex lock;
> >   struct dram_timing timing;
> >   struct regulator *vdd_center;
> > + struct regmap *regmap_pmu;
> >   unsigned long rate, target_rate;
> >   unsigned long volt, target_volt;
> > + unsigned int odt_dis_freq;
> > + int odt_pd_arg0, odt_pd_arg1;
> >  };
> >
> >  static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
> > @@ -80,6 +86,8 @@ static int rk3399_dmcfreq_target(struct device *dev, 
> > unsigned long *freq,
> >   struct dev_pm_opp *opp;
> >   unsigned long old_clk_rate = dmcfreq->rate;
> >   unsigned long target_volt, target_rate;
> > + struct arm_smccc_res res;
> > + int dram_flag;
> >   int err;
> >
> >   opp = devfreq_recommended_opp(dev, freq, flags);
> > @@ -95,6 +103,15 @@ static int rk3399_dmcfreq_target(struct device *dev, 
> > unsigned long *freq,
> >
> >   mutex_lock(>lock);
> >
> > + dram_flag = 0;
>
> Also, if dram_flag is 0, it mean that disable ODT frequency?

Yes, not a good name, maybe I should just rename it to odt_enable to
be more clear.

> If it's right, you better to define the precise variables as following
> instead of just integer(0 or 1).
> For example,
> - ROCKCHIP_SIP_DRAM_FREQ_ENABLE
> - ROCKCHIP_SIP_DRAM_FREQ_DISABLE
>
> > + if (target_rate >= dmcfreq->odt_dis_freq)
> > + dram_flag = 1;
> > +
> > + arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
> > +   dmcfreq->odt_pd_arg1,
> > +   ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
> > +   dram_flag, 0, 0, 0, );
> > +
>
> This operation is special for only rk3399_dmc. It is difficult
> to understand what to do. I recommend you better to add the detailed comment
> with code.

Will do.

>
> >   /*
> >* If frequency scaling from low to high, adjust voltage first.
> >* If frequency scaling from high to low, adjust frequency first.
> > @@ -294,11 +311,13 @@ static int rk3399_dmcfreq_probe(struct 
> > platform_device *pdev)
> >  {
> >   struct arm_smccc_res res;
> >   struct device *dev = >dev;
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = pdev->dev.of_node, *node;
> >   struct rk3399_dmcfreq *data;
> >   int ret, index, size;
> >   uint32_t *timing;
> >   struct dev_pm_opp *opp;
> > + u32 ddr_type;
> > + u32 val;
> >
> >   data = devm_kzalloc(dev, sizeof(struct rk3399_dmcfreq), GFP_KERNEL);
> >   if (!data)
> > @@ -334,6 +353,29 @@ static int rk3399_dmcfreq_probe(struct platform_device 
> > *pdev)
> >   return ret;
> >   }
> >
> > + /* Try to find the optional reference to the pmu syscon */
> > + node = of_parse_phandle(np, "rockchip,pmu", 0);
> > + if (node) {
> > + data->regmap_pmu = syscon_node_to_regmap(node);
> > + if (IS_ERR(data->regmap_pmu))
> > + return PTR_ERR(data->regmap_pmu);
> > + }
> > +
> > + /* Get DDR type */
> > + regmap_read(data->regmap_pmu, RK3399_PMUGRF_OS_REG2, );
> > + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> > + RK3399_PMUGRF_DDRTYPE_MASK;
> > +
> > + /* Get the odt_dis_freq parameter in function of the DDR type */
> > + if (ddr_type == RK3399_PMUGRF_DDRTYPE_DDR3)
> > + data->odt_dis_freq = data->timing.ddr3_odt_dis_freq;
> > + else if (ddr_type == 

Re: [PATCH v7 5/5] drm/rockchip: support dp training outside dp firmware

[Enric Balletbo Serra]

2018-05-23 9:42 GMT+02:00 Lin Huang :
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> Reviewed-by: Sean Paul 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() 
> follow Sean suggest
> Changes in v5:
> - fix some whitespcae issue
> Changes in v6:
> - None
> Changes in v7:
> - None
>
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 505 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>
>  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> +   cdn-dp-link-training.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index cce64c1..783d57a 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
> goto out;
> }
> }
> -
> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> -   if (ret) {
> -   DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> -   goto out;
> +   if (dp->use_fw_training) {
> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> +   if (ret) {
> +   DRM_DEV_ERROR(dp->dev,
> + "Failed to idle video %d\n", ret);
> +   goto out;
> +   }
> }
>
> ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
> goto out;
> }
>
> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> -   if (ret) {
> -   DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> -   goto out;
> +   if (dp->use_fw_training) {
> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> +   if (ret) {
> +   DRM_DEV_ERROR(dp->dev,
> +   "Failed to valid video %d\n", ret);
> +   goto out;
> +   }
> }
> +
>  out:
> mutex_unlock(>lock);
>  }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..77a9793 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
> bool connected;
> bool active;
> bool suspended;
> +   bool use_fw_training;
>
> const struct firmware *fw;  /* cdn dp firmware */
> unsigned int fw_version;/* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
> u8 ports;
> u8 lanes;
> int active_port;
> +   u8 train_set[4];
>
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 000..73c3290
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou 

Re: [PATCH v7 4/5] phy: rockchip-typec: support variable phy config value

[Enric Balletbo Serra]

2018-05-23 9:42 GMT+02:00 Lin Huang :
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - delete need_software_training variable
> - add default phy config value, if dts do not define phy config value, use 
> these value
> Changes in v4:
> - rename variable config to tcphy_default_config
> Changes in v5:
> - None
> Changes in v6:
> - split the header file to new patch
> Changes in v7:
> - add default case when check link rate
> - move struct rockchip_typec_phy new element to this patch
>
>  drivers/phy/rockchip/phy-rockchip-typec.c | 263 
> --
>  include/soc/rockchip/rockchip_phy_typec.h |   8 +
>  2 files changed, 218 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 795055f..69af90e 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
> @@ -324,21 +324,29 @@
>   * clock 0: PLL 0 div 1
>   * clock 1: PLL 1 div 2
>   */
> -#define CLK_PLL_CONFIG 0X30
> +#define CLK_PLL1_DIV1  0x20
> +#define CLK_PLL1_DIV2  0x30
>  #define CLK_PLL_MASK   0x33
>
>  #define CMN_READY  BIT(0)
>
> +#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
>  #define DP_PLL_CLOCK_ENABLEBIT(2)
> +#define DP_PLL_ENABLE_ACK  BIT(1)
>  #define DP_PLL_ENABLE  BIT(0)
>  #define DP_PLL_DATA_RATE_RBR   ((2 << 12) | (4 << 8))
>  #define DP_PLL_DATA_RATE_HBR   ((2 << 12) | (4 << 8))
>  #define DP_PLL_DATA_RATE_HBR2  ((1 << 12) | (2 << 8))
> +#define DP_PLL_DATA_RATE_MASK  0xff00
>
> -#define DP_MODE_A0 BIT(4)
> -#define DP_MODE_A2 BIT(6)
> -#define DP_MODE_ENTER_A0   0xc101
> -#define DP_MODE_ENTER_A2   0xc104
> +#define DP_MODE_MASK   0xf
> +#define DP_MODE_ENTER_A0   BIT(0)
> +#define DP_MODE_ENTER_A2   BIT(2)
> +#define DP_MODE_ENTER_A3   BIT(3)
> +#define DP_MODE_A0_ACK BIT(4)
> +#define DP_MODE_A2_ACK BIT(6)
> +#define DP_MODE_A3_ACK BIT(7)
> +#define DP_LINK_RESET_DEASSERTED   BIT(8)
>
>  #define PHY_MODE_SET_TIMEOUT   10
>
> @@ -350,6 +358,8 @@
>  #define MODE_DFP_USB   BIT(1)
>  #define MODE_DFP_DPBIT(2)
>
> +#define DP_DEFAULT_RATE162000
> +
>  struct phy_reg {
> u16 value;
> u32 addr;
> @@ -372,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
> { 0x8,  CMN_DIAG_PLL0_LF_PROG },
>  };
>
> -struct phy_reg dp_pll_cfg[] = {
> +struct phy_reg dp_pll_rbr_cfg[] = {
> { 0xf0, CMN_PLL1_VCOCAL_INIT },
> { 0x18, CMN_PLL1_VCOCAL_ITER },
> { 0x30b9,   CMN_PLL1_VCOCAL_START },
> -   { 0x21c,CMN_PLL1_INTDIV },
> +   { 0x87, CMN_PLL1_INTDIV },
> { 0,CMN_PLL1_FRACDIV },
> -   { 0x5,  CMN_PLL1_HIGH_THR },
> -   { 0x35, CMN_PLL1_SS_CTRL1 },
> -   { 0x7f1e,   CMN_PLL1_SS_CTRL2 },
> +   { 0x22, CMN_PLL1_HIGH_THR },
> +   { 0x8000,   CMN_PLL1_SS_CTRL1 },
> +   { 0,CMN_PLL1_SS_CTRL2 },
> { 0x20, CMN_PLL1_DSM_DIAG },
> { 0,CMN_PLLSM1_USER_DEF_CTRL },
> { 0,CMN_DIAG_PLL1_OVRD },
> @@ -391,9 +401,52 @@ struct phy_reg dp_pll_cfg[] = {
> { 0x8,  CMN_DIAG_PLL1_LF_PROG },
> { 0x100,CMN_DIAG_PLL1_PTATIS_TUNE1 },
> { 0x7,  CMN_DIAG_PLL1_PTATIS_TUNE2 },
> -   { 0x4,  CMN_DIAG_PLL1_INCLK_CTRL },
> +   { 0x1,  CMN_DIAG_PLL1_INCLK_CTRL },
>  };
>
> +struct phy_reg dp_pll_hbr_cfg[] = {
> +   { 0xf0, CMN_PLL1_VCOCAL_INIT },
> +   { 0x18, CMN_PLL1_VCOCAL_ITER },
> +   { 0x30b4,   CMN_PLL1_VCOCAL_START },
> +   { 0xe1, CMN_PLL1_INTDIV },
> +   { 0,CMN_PLL1_FRACDIV },
> +   { 0x5,  CMN_PLL1_HIGH_THR },
> +   { 0x8000,   CMN_PLL1_SS_CTRL1 },
> +   { 0,CMN_PLL1_SS_CTRL2 },
> +   { 0x20, CMN_PLL1_DSM_DIAG },
> +   { 0x1000,   CMN_PLLSM1_USER_DEF_CTRL },
> +   { 0,CMN_DIAG_PLL1_OVRD },
> +   { 0,CMN_DIAG_PLL1_FBH_OVRD },
> +   { 0,CMN_DIAG_PLL1_FBL_OVRD },
> +   { 0x7,  CMN_DIAG_PLL1_V2I_TUNE },
> +   { 0x45, CMN_DIAG_PLL1_CP_TUNE },
> +   { 0x8,  CMN_DIAG_PLL1_LF_PROG },
> +   { 

Re: [PATCH v7 3/5] soc: rockchip: split rockchip_typec_phy struct to separate header

[Enric Balletbo Serra]

2018-05-23 9:42 GMT+02:00 Lin Huang :
> we may use rockchip_phy_typec struct in other driver, so split
> it to separate header.
>
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - None
> Changes in v3:
> - None
> Changes in v4:
> - None
> Changes in v5:
> - None
> Changes in v6:
> - new patch here
> Changes in v7:
> - move new element to next patch
>
>  drivers/phy/rockchip/phy-rockchip-typec.c | 47 +-
>  include/soc/rockchip/rockchip_phy_typec.h | 55 
> +++
>  2 files changed, 56 insertions(+), 46 deletions(-)
>  create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 76a4b58..795055f 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
> @@ -63,6 +63,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #define CMN_SSM_BANDGAP(0x21 << 2)
>  #define CMN_SSM_BIAS   (0x22 << 2)
> @@ -349,52 +350,6 @@
>  #define MODE_DFP_USB   BIT(1)
>  #define MODE_DFP_DPBIT(2)
>
> -struct usb3phy_reg {
> -   u32 offset;
> -   u32 enable_bit;
> -   u32 write_enable;
> -};
> -
> -/**
> - * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> - * @reg: the base address for usb3-phy config.
> - * @typec_conn_dir: the register of type-c connector direction.
> - * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> - * @external_psm: the register of type-c phy external psm clock.
> - * @pipe_status: the register of type-c phy pipe status.
> - * @usb3_host_disable: the register of type-c usb3 host disable.
> - * @usb3_host_port: the register of type-c usb3 host port.
> - * @uphy_dp_sel: the register of type-c phy DP select control.
> - */
> -struct rockchip_usb3phy_port_cfg {
> -   unsigned int reg;
> -   struct usb3phy_reg typec_conn_dir;
> -   struct usb3phy_reg usb3tousb2_en;
> -   struct usb3phy_reg external_psm;
> -   struct usb3phy_reg pipe_status;
> -   struct usb3phy_reg usb3_host_disable;
> -   struct usb3phy_reg usb3_host_port;
> -   struct usb3phy_reg uphy_dp_sel;
> -};
> -
> -struct rockchip_typec_phy {
> -   struct device *dev;
> -   void __iomem *base;
> -   struct extcon_dev *extcon;
> -   struct regmap *grf_regs;
> -   struct clk *clk_core;
> -   struct clk *clk_ref;
> -   struct reset_control *uphy_rst;
> -   struct reset_control *pipe_rst;
> -   struct reset_control *tcphy_rst;
> -   const struct rockchip_usb3phy_port_cfg *port_cfgs;
> -   /* mutex to protect access to individual PHYs */
> -   struct mutex lock;
> -
> -   bool flip;
> -   u8 mode;
> -};
> -
>  struct phy_reg {
> u16 value;
> u32 addr;
> diff --git a/include/soc/rockchip/rockchip_phy_typec.h 
> b/include/soc/rockchip/rockchip_phy_typec.h
> new file mode 100644
> index 000..4afe039
> --- /dev/null
> +++ b/include/soc/rockchip/rockchip_phy_typec.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Lin Huang 
> + */
> +
> +#ifndef __SOC_ROCKCHIP_PHY_TYPEC_H
> +#define __SOC_ROCKCHIP_PHY_TYPEC_H
> +
> +struct usb3phy_reg {
> +   u32 offset;
> +   u32 enable_bit;
> +   u32 write_enable;
> +};
> +
> +/**
> + * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> + * @reg: the base address for usb3-phy config.
> + * @typec_conn_dir: the register of type-c connector direction.
> + * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> + * @external_psm: the register of type-c phy external psm clock.
> + * @pipe_status: the register of type-c phy pipe status.
> + * @usb3_host_disable: the register of type-c usb3 host disable.
> + * @usb3_host_port: the register of type-c usb3 host port.
> + * @uphy_dp_sel: the register of type-c phy DP select control.
> + */
> +struct rockchip_usb3phy_port_cfg {
> +   unsigned int reg;
> +   struct usb3phy_reg typec_conn_dir;
> +   struct usb3phy_reg usb3tousb2_en;
> +   struct usb3phy_reg external_psm;
> +   struct usb3phy_reg pipe_status;
> +   struct usb3phy_reg usb3_host_disable;
> +   struct usb3phy_reg usb3_host_port;
> +   struct usb3phy_reg uphy_dp_sel;
> +};
> +
> +struct rockchip_typec_phy {
> +   struct device *dev;
> +   void __iomem *base;
> +   struct extcon_dev *extcon;
> +   struct regmap *grf_regs;
> +   struct clk *clk_core;
> +   struct clk *clk_ref;
> +   struct reset_control *uphy_rst;
> +   struct reset_control *pipe_rst;
> +   struct reset_control *tcphy_rst;
> +   const struct rockchip_usb3phy_port_cfg *port_cfgs;
> +   /* mutex to protect access to individual PHYs */
> +   struct mutex lock;

Re: [PATCH v6 5/5] drm/rockchip: support dp training outside dp firmware

[Enric Balletbo Serra]

Lin,

2018-05-22 9:41 GMT+02:00 Enric Balletbo Serra <eballe...@gmail.com>:
> Hi Lin
>
> 2018-05-22 3:08 GMT+02:00 hl <h...@rock-chips.com>:
>> Hi Enric,
>>
>>
>>
>>
>> On Monday, May 21, 2018 11:22 PM, Enric Balletbo Serra wrote:
>>>
>>> Hi Lin,
>>>
>>> 2018-05-21 11:37 GMT+02:00 Lin Huang <h...@rock-chips.com>:
>>>>
>>>> DP firmware uses fixed phy config values to do training, but some
>>>> boards need to adjust these values to fit for their unique hardware
>>>> design. So get phy config values from dts and use software link training
>>>> instead of relying on firmware, if software training fail, keep firmware
>>>> training as a fallback if sw training fails.
>>>>
>>>> Signed-off-by: Chris Zhong <z...@rock-chips.com>
>>>> Signed-off-by: Lin Huang <h...@rock-chips.com>
>>>> Reviewed-by: Sean Paul <seanp...@chromium.org>
>>>> ---
>>>> Changes in v2:
>>>> - update patch following Enric suggest
>>>> Changes in v3:
>>>> - use variable fw_training instead sw_training_success
>>>> - base on DP SPCE, if training fail use lower link rate to retry training
>>>> Changes in v4:
>>>> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link()
>>>> follow Sean suggest
>>>> Changes in v5:
>>>> - fix some whitespcae issue
>>>> Changes in v6:
>>>> - None
>>>>
>>>>   drivers/gpu/drm/rockchip/Makefile   |   3 +-
>>>>   drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>>>>   drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>>>>   drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420
>>>> 
>>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>>>>   6 files changed, 505 insertions(+), 13 deletions(-)
>>>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>>>>
>>>> diff --git a/drivers/gpu/drm/rockchip/Makefile
>>>> b/drivers/gpu/drm/rockchip/Makefile
>>>> index a314e21..b932f62 100644
>>>> --- a/drivers/gpu/drm/rockchip/Makefile
>>>> +++ b/drivers/gpu/drm/rockchip/Makefile
>>>> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>>>>   rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>>>>
>>>>   rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
>>>> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
>>>> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
>>>> +   cdn-dp-link-training.o
>>>>   rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>>>>   rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>>>>   rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>>>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>>> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>>> index cce64c1..d9d0d4d 100644
>>>> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>>> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct
>>>> drm_encoder *encoder)
>>>>  goto out;
>>>>  }
>>>>  }
>>>> -
>>>> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
>>>> -   if (ret) {
>>>> -   DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
>>>> -   goto out;
>>>> +   if (dp->use_fw_training == true) {
>>>
>>> You don't need to compare to true. Simply do:
>>>
>>> if (dp->use_fw_training)
>>>
>>>> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
>>>> +   if (ret) {
>>>> +   DRM_DEV_ERROR(dp->dev,
>>>> + "Failed to idle video %d\n", ret);
>>>> +   goto out;
>>>> +   }
>>>>  }
>>>>
>>>>  ret = cdn_dp_config_video(dp);
>>>> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct
>>>&g

Re: [PATCH v4 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Enric Balletbo Serra]

Hi Neil,

2018-05-21 16:21 GMT+02:00 Neil Armstrong :
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/platform/chrome/cros_ec_proto.c |  40 ++---
>  include/linux/mfd/cros_ec.h |   2 +-
>  include/linux/mfd/cros_ec_commands.h| 103 
> 
>  3 files changed, 135 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +  struct cros_ec_command *msg,
> +  int version, uint32_t size)
> +{
> +   int ret;
> +
> +   msg->version = version;
> +   msg->command = EC_CMD_GET_NEXT_EVENT;
> +   msg->insize = size;
> +   msg->outsize = 0;
> +
> +   ret = cros_ec_cmd_xfer(ec_dev, msg);
> +   if (ret > 0) {
> +   ec_dev->event_size = ret - 1;
> +   memcpy(_dev->event_data, msg->data, ec_dev->event_size);
> +   }
> +
> +   return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
> u8 buffer[sizeof(struct cros_ec_command) + 
> sizeof(ec_dev->event_data)];
> struct cros_ec_command *msg = (struct cros_ec_command *)
> +   static int cmd_version = 1;
> int ret;
>
> if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
> return -EHOSTDOWN;
> }
>
> -   msg->version = 0;
> -   msg->command = EC_CMD_GET_NEXT_EVENT;
> -   msg->insize = sizeof(ec_dev->event_data);
> -   msg->outsize = 0;
> +   if (cmd_version == 1) {
> +   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +   sizeof(struct ec_response_get_next_event_v1));
> +   if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> +   return ret;
>

Thinking a bit more, there is a command to ask supported command
versions (EC_CMD_GET_CMD_VERSION). So, i theory you should be able to
ask for the versions supported by the command, see for example what is
done in [1], [2] and [3]. Anyway I am fine with this for now, and
after do some test seems that nothing breaks, so

Tested-by: Enric Balletbo i Serra 

Thanks,
 Enric

[1] 
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/misc_util.c#98
[2] 
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/misc_util.c#131
[3] 
https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/ectool.c#786


> -   ret = cros_ec_cmd_xfer(ec_dev, msg);
> -   if (ret > 0) {
> -   ec_dev->event_size = ret - 1;
> -   memcpy(_dev->event_data, msg->data,
> -  sizeof(ec_dev->event_data));
> +   /* Fallback to version 0 for future send attempts */
> +   cmd_version = 0;
> }
>
> +   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event));
> +
> return ret;
>  }
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
> bool mkbp_event_supported;
> struct blocking_notifier_head event_notifier;
>
> -   struct ec_response_get_next_event event_data;
> +   struct ec_response_get_next_event_v1 event_data;
> int event_size;
> u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..9b8bc4a 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> +   /* EC supports CEC commands */
> +   EC_FEATURE_CEC = 35,
>  };
>
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> 

Re: [PATCH v6 5/5] drm/rockchip: support dp training outside dp firmware

[Enric Balletbo Serra]

Hi Lin

2018-05-22 3:08 GMT+02:00 hl <h...@rock-chips.com>:
> Hi Enric,
>
>
>
>
> On Monday, May 21, 2018 11:22 PM, Enric Balletbo Serra wrote:
>>
>> Hi Lin,
>>
>> 2018-05-21 11:37 GMT+02:00 Lin Huang <h...@rock-chips.com>:
>>>
>>> DP firmware uses fixed phy config values to do training, but some
>>> boards need to adjust these values to fit for their unique hardware
>>> design. So get phy config values from dts and use software link training
>>> instead of relying on firmware, if software training fail, keep firmware
>>> training as a fallback if sw training fails.
>>>
>>> Signed-off-by: Chris Zhong <z...@rock-chips.com>
>>> Signed-off-by: Lin Huang <h...@rock-chips.com>
>>> Reviewed-by: Sean Paul <seanp...@chromium.org>
>>> ---
>>> Changes in v2:
>>> - update patch following Enric suggest
>>> Changes in v3:
>>> - use variable fw_training instead sw_training_success
>>> - base on DP SPCE, if training fail use lower link rate to retry training
>>> Changes in v4:
>>> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link()
>>> follow Sean suggest
>>> Changes in v5:
>>> - fix some whitespcae issue
>>> Changes in v6:
>>> - None
>>>
>>>   drivers/gpu/drm/rockchip/Makefile   |   3 +-
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>>>   drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420
>>> 
>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>>>   drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>>>   6 files changed, 505 insertions(+), 13 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/Makefile
>>> b/drivers/gpu/drm/rockchip/Makefile
>>> index a314e21..b932f62 100644
>>> --- a/drivers/gpu/drm/rockchip/Makefile
>>> +++ b/drivers/gpu/drm/rockchip/Makefile
>>> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>>>   rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>>>
>>>   rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
>>> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
>>> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
>>> +   cdn-dp-link-training.o
>>>   rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>>>   rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>>>   rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>> index cce64c1..d9d0d4d 100644
>>> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>>> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct
>>> drm_encoder *encoder)
>>>  goto out;
>>>  }
>>>  }
>>> -
>>> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
>>> -   if (ret) {
>>> -   DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
>>> -   goto out;
>>> +   if (dp->use_fw_training == true) {
>>
>> You don't need to compare to true. Simply do:
>>
>> if (dp->use_fw_training)
>>
>>> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
>>> +   if (ret) {
>>> +   DRM_DEV_ERROR(dp->dev,
>>> + "Failed to idle video %d\n", ret);
>>> +   goto out;
>>> +   }
>>>  }
>>>
>>>  ret = cdn_dp_config_video(dp);
>>> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct
>>> drm_encoder *encoder)
>>>  goto out;
>>>  }
>>>
>>> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
>>> -   if (ret) {
>>> -   DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n",
>>> ret);
>>> -   goto out;
>>> +   if (dp->use_fw_training == true) {
>>
>> if (dp->use_fw_

Re: [PATCH v6 5/5] drm/rockchip: support dp training outside dp firmware

[Enric Balletbo Serra]

Hi Lin,

2018-05-21 11:37 GMT+02:00 Lin Huang :
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> Reviewed-by: Sean Paul 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() 
> follow Sean suggest
> Changes in v5:
> - fix some whitespcae issue
> Changes in v6:
> - None
>
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 505 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>
>  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> +   cdn-dp-link-training.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index cce64c1..d9d0d4d 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
> goto out;
> }
> }
> -
> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> -   if (ret) {
> -   DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> -   goto out;
> +   if (dp->use_fw_training == true) {

You don't need to compare to true. Simply do:

if (dp->use_fw_training)

> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> +   if (ret) {
> +   DRM_DEV_ERROR(dp->dev,
> + "Failed to idle video %d\n", ret);
> +   goto out;
> +   }
> }
>
> ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
> goto out;
> }
>
> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> -   if (ret) {
> -   DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> -   goto out;
> +   if (dp->use_fw_training == true) {

if (dp->use_fw_training)

> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> +   if (ret) {
> +   DRM_DEV_ERROR(dp->dev,
> +   "Failed to valid video %d\n", ret);
> +   goto out;
> +   }
> }
> +
>  out:
> mutex_unlock(>lock);
>  }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..77a9793 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
> bool connected;
> bool active;
> bool suspended;
> +   bool use_fw_training;
>
> const struct firmware *fw;  /* cdn dp firmware */
> unsigned int fw_version;/* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
> u8 ports;
> u8 lanes;
> int active_port;
> +   u8 train_set[4];
>
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 000..73c3290
> --- /dev/null
> +++ 

Re: [PATCH v6 4/5] phy: rockchip-typec: support variable phy config value

[Enric Balletbo Serra]

Hi Lin,

2018-05-21 11:37 GMT+02:00 Lin Huang :
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - delete need_software_training variable
> - add default phy config value, if dts do not define phy config value, use 
> these value
> Changes in v4:
> - rename variable config to tcphy_default_config
> Changes in v5:
> - None
> Changes in v6:
> - split the header file to new patch
>
>  drivers/phy/rockchip/phy-rockchip-typec.c | 261 
> --
>  1 file changed, 208 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 795055f..4c4b925 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
> @@ -324,21 +324,29 @@
>   * clock 0: PLL 0 div 1
>   * clock 1: PLL 1 div 2
>   */
> -#define CLK_PLL_CONFIG 0X30
> +#define CLK_PLL1_DIV1  0x20
> +#define CLK_PLL1_DIV2  0x30
>  #define CLK_PLL_MASK   0x33
>
>  #define CMN_READY  BIT(0)
>
> +#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
>  #define DP_PLL_CLOCK_ENABLEBIT(2)
> +#define DP_PLL_ENABLE_ACK  BIT(1)
>  #define DP_PLL_ENABLE  BIT(0)
>  #define DP_PLL_DATA_RATE_RBR   ((2 << 12) | (4 << 8))
>  #define DP_PLL_DATA_RATE_HBR   ((2 << 12) | (4 << 8))
>  #define DP_PLL_DATA_RATE_HBR2  ((1 << 12) | (2 << 8))
> +#define DP_PLL_DATA_RATE_MASK  0xff00
>
> -#define DP_MODE_A0 BIT(4)
> -#define DP_MODE_A2 BIT(6)
> -#define DP_MODE_ENTER_A0   0xc101
> -#define DP_MODE_ENTER_A2   0xc104
> +#define DP_MODE_MASK   0xf
> +#define DP_MODE_ENTER_A0   BIT(0)
> +#define DP_MODE_ENTER_A2   BIT(2)
> +#define DP_MODE_ENTER_A3   BIT(3)
> +#define DP_MODE_A0_ACK BIT(4)
> +#define DP_MODE_A2_ACK BIT(6)
> +#define DP_MODE_A3_ACK BIT(7)
> +#define DP_LINK_RESET_DEASSERTED   BIT(8)
>
>  #define PHY_MODE_SET_TIMEOUT   10
>
> @@ -350,6 +358,8 @@
>  #define MODE_DFP_USB   BIT(1)
>  #define MODE_DFP_DPBIT(2)
>
> +#define DP_DEFAULT_RATE162000
> +
>  struct phy_reg {
> u16 value;
> u32 addr;
> @@ -372,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
> { 0x8,  CMN_DIAG_PLL0_LF_PROG },
>  };
>
> -struct phy_reg dp_pll_cfg[] = {
> +struct phy_reg dp_pll_rbr_cfg[] = {
> { 0xf0, CMN_PLL1_VCOCAL_INIT },
> { 0x18, CMN_PLL1_VCOCAL_ITER },
> { 0x30b9,   CMN_PLL1_VCOCAL_START },
> -   { 0x21c,CMN_PLL1_INTDIV },
> +   { 0x87, CMN_PLL1_INTDIV },
> { 0,CMN_PLL1_FRACDIV },
> -   { 0x5,  CMN_PLL1_HIGH_THR },
> -   { 0x35, CMN_PLL1_SS_CTRL1 },
> -   { 0x7f1e,   CMN_PLL1_SS_CTRL2 },
> +   { 0x22, CMN_PLL1_HIGH_THR },
> +   { 0x8000,   CMN_PLL1_SS_CTRL1 },
> +   { 0,CMN_PLL1_SS_CTRL2 },
> { 0x20, CMN_PLL1_DSM_DIAG },
> { 0,CMN_PLLSM1_USER_DEF_CTRL },
> { 0,CMN_DIAG_PLL1_OVRD },
> @@ -391,9 +401,52 @@ struct phy_reg dp_pll_cfg[] = {
> { 0x8,  CMN_DIAG_PLL1_LF_PROG },
> { 0x100,CMN_DIAG_PLL1_PTATIS_TUNE1 },
> { 0x7,  CMN_DIAG_PLL1_PTATIS_TUNE2 },
> -   { 0x4,  CMN_DIAG_PLL1_INCLK_CTRL },
> +   { 0x1,  CMN_DIAG_PLL1_INCLK_CTRL },
>  };
>
> +struct phy_reg dp_pll_hbr_cfg[] = {
> +   { 0xf0, CMN_PLL1_VCOCAL_INIT },
> +   { 0x18, CMN_PLL1_VCOCAL_ITER },
> +   { 0x30b4,   CMN_PLL1_VCOCAL_START },
> +   { 0xe1, CMN_PLL1_INTDIV },
> +   { 0,CMN_PLL1_FRACDIV },
> +   { 0x5,  CMN_PLL1_HIGH_THR },
> +   { 0x8000,   CMN_PLL1_SS_CTRL1 },
> +   { 0,CMN_PLL1_SS_CTRL2 },
> +   { 0x20, CMN_PLL1_DSM_DIAG },
> +   { 0x1000,   CMN_PLLSM1_USER_DEF_CTRL },
> +   { 0,CMN_DIAG_PLL1_OVRD },
> +   { 0,CMN_DIAG_PLL1_FBH_OVRD },
> +   { 0,CMN_DIAG_PLL1_FBL_OVRD },
> +   { 0x7,  CMN_DIAG_PLL1_V2I_TUNE },
> +   { 0x45, CMN_DIAG_PLL1_CP_TUNE },
> +   { 0x8,  CMN_DIAG_PLL1_LF_PROG },
> +   { 0x1,  CMN_DIAG_PLL1_PTATIS_TUNE1 },
> +   { 0x1,  CMN_DIAG_PLL1_PTATIS_TUNE2 },
> +   { 0x1,  CMN_DIAG_PLL1_INCLK_CTRL },
> +};
> +
> 

Re: [PATCH v6 3/5] soc: rockchip: split rockchip_typec_phy struct to separate header

[Enric Balletbo Serra]

Hi Lin,

2018-05-21 11:37 GMT+02:00 Lin Huang :
> we may use rockchip_phy_typec struct in other driver, so split
> it to separate header.
>

That patch does more than just split some structs to a public header,
it also introduces new structs and new parameters related to the
phy_config feature. IMHO you should first move the current structs and
introduce the new phy_config stuff in the following patch (4/5). I am
not sure about the maintainer preferences, but at least, if the
maintainer is fine like is now, I'd explain that you introduce new
elements in the commit message.

Best regards,
 Enric

> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - None
> Changes in v3:
> - None
> Changes in v4:
> - None
> Changes in v5:
> - None
> Changes in v6:
> - new patch here
>
>  drivers/phy/rockchip/phy-rockchip-typec.c | 47 +--
>  include/soc/rockchip/rockchip_phy_typec.h | 63 
> +++
>  2 files changed, 64 insertions(+), 46 deletions(-)
>  create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 76a4b58..795055f 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
> @@ -63,6 +63,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #define CMN_SSM_BANDGAP(0x21 << 2)
>  #define CMN_SSM_BIAS   (0x22 << 2)
> @@ -349,52 +350,6 @@
>  #define MODE_DFP_USB   BIT(1)
>  #define MODE_DFP_DPBIT(2)
>
> -struct usb3phy_reg {
> -   u32 offset;
> -   u32 enable_bit;
> -   u32 write_enable;
> -};
> -
> -/**
> - * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> - * @reg: the base address for usb3-phy config.
> - * @typec_conn_dir: the register of type-c connector direction.
> - * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> - * @external_psm: the register of type-c phy external psm clock.
> - * @pipe_status: the register of type-c phy pipe status.
> - * @usb3_host_disable: the register of type-c usb3 host disable.
> - * @usb3_host_port: the register of type-c usb3 host port.
> - * @uphy_dp_sel: the register of type-c phy DP select control.
> - */
> -struct rockchip_usb3phy_port_cfg {
> -   unsigned int reg;
> -   struct usb3phy_reg typec_conn_dir;
> -   struct usb3phy_reg usb3tousb2_en;
> -   struct usb3phy_reg external_psm;
> -   struct usb3phy_reg pipe_status;
> -   struct usb3phy_reg usb3_host_disable;
> -   struct usb3phy_reg usb3_host_port;
> -   struct usb3phy_reg uphy_dp_sel;
> -};
> -
> -struct rockchip_typec_phy {
> -   struct device *dev;
> -   void __iomem *base;
> -   struct extcon_dev *extcon;
> -   struct regmap *grf_regs;
> -   struct clk *clk_core;
> -   struct clk *clk_ref;
> -   struct reset_control *uphy_rst;
> -   struct reset_control *pipe_rst;
> -   struct reset_control *tcphy_rst;
> -   const struct rockchip_usb3phy_port_cfg *port_cfgs;
> -   /* mutex to protect access to individual PHYs */
> -   struct mutex lock;
> -
> -   bool flip;
> -   u8 mode;
> -};
> -
>  struct phy_reg {
> u16 value;
> u32 addr;
> diff --git a/include/soc/rockchip/rockchip_phy_typec.h 
> b/include/soc/rockchip/rockchip_phy_typec.h
> new file mode 100644
> index 000..be6af0e
> --- /dev/null
> +++ b/include/soc/rockchip/rockchip_phy_typec.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Lin Huang 
> + */
> +
> +#ifndef __SOC_ROCKCHIP_PHY_TYPEC_H
> +#define __SOC_ROCKCHIP_PHY_TYPEC_H
> +
> +struct usb3phy_reg {
> +   u32 offset;
> +   u32 enable_bit;
> +   u32 write_enable;
> +};
> +
> +/**
> + * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> + * @reg: the base address for usb3-phy config.
> + * @typec_conn_dir: the register of type-c connector direction.
> + * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> + * @external_psm: the register of type-c phy external psm clock.
> + * @pipe_status: the register of type-c phy pipe status.
> + * @usb3_host_disable: the register of type-c usb3 host disable.
> + * @usb3_host_port: the register of type-c usb3 host port.
> + * @uphy_dp_sel: the register of type-c phy DP select control.
> + */
> +struct rockchip_usb3phy_port_cfg {
> +   unsigned int reg;
> +   struct usb3phy_reg typec_conn_dir;
> +   struct usb3phy_reg usb3tousb2_en;
> +   struct usb3phy_reg external_psm;
> +   struct usb3phy_reg pipe_status;
> +   struct usb3phy_reg usb3_host_disable;
> +   struct usb3phy_reg usb3_host_port;
> +   struct usb3phy_reg uphy_dp_sel;
> +};
> +
> +struct phy_config {
> +   int swing;
> +   int pe;
> +};
> +
> +struct 

Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Enric Balletbo Serra]

Hi Neil,

2018-05-18 15:05 GMT+02:00 Neil Armstrong :
> The EC can expose a CEC bus, this patch adds the CEC related definitions
> needed by the cros-ec-cec driver.
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 40 +
>  include/linux/mfd/cros_ec.h |  2 +-
>  include/linux/mfd/cros_ec_commands.h| 80 
> +
>  3 files changed, 112 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device 
> *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +  struct cros_ec_command *msg,
> +  int version, uint32_t size)
> +{
> +   int ret;
> +
> +   msg->version = version;
> +   msg->command = EC_CMD_GET_NEXT_EVENT;
> +   msg->insize = size;
> +   msg->outsize = 0;
> +
> +   ret = cros_ec_cmd_xfer(ec_dev, msg);
> +   if (ret > 0) {
> +   ec_dev->event_size = ret - 1;
> +   memcpy(_dev->event_data, msg->data, ec_dev->event_size);
> +   }
> +
> +   return ret;
> +}
> +
>  static int get_next_event(struct cros_ec_device *ec_dev)
>  {
> u8 buffer[sizeof(struct cros_ec_command) + 
> sizeof(ec_dev->event_data)];
> struct cros_ec_command *msg = (struct cros_ec_command *)
> +   static int cmd_version = 1;

Personal opinion, but I don't like this static here, and also I don't
think this is scalable. Could we ask for the command version?

> int ret;
>
> if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
> return -EHOSTDOWN;
> }
>
> -   msg->version = 0;
> -   msg->command = EC_CMD_GET_NEXT_EVENT;
> -   msg->insize = sizeof(ec_dev->event_data);
> -   msg->outsize = 0;
> +   if (cmd_version == 1) {
> +   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> +   sizeof(struct ec_response_get_next_event_v1));
> +   if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> +   return ret;
>
> -   ret = cros_ec_cmd_xfer(ec_dev, msg);
> -   if (ret > 0) {
> -   ec_dev->event_size = ret - 1;
> -   memcpy(_dev->event_data, msg->data,
> -  sizeof(ec_dev->event_data));
> +   /* Fallback to version 0 for future send attempts */
> +   cmd_version = 0;
> }
>

So we always do a failed transfer on all these EC devices that does
not support CEC. I am wondering if wouldn't be better pass the command
version to the cros_ec_get_next_event function. The driver should know
which version to use, just a random idea.

> +   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event));
> +
> return ret;
>  }
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
> bool mkbp_event_supported;
> struct blocking_notifier_head event_notifier;
>
> -   struct ec_response_get_next_event event_data;
> +   struct ec_response_get_next_event_v1 event_data;
> int event_size;
> u32 host_event_wake_mask;
>  };
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..16c3a2b 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h

This file is going to be very big and as requested by Lee I plan to
convert this file to the kernel-doc format, this patch introduces some
new structs so could you document the new structs in the suggested
format?

> @@ -804,6 +804,8 @@ enum ec_feature_code {
> EC_FEATURE_MOTION_SENSE_FIFO = 24,
> /* EC has RTC feature that can be controlled by host commands */
> EC_FEATURE_RTC = 27,
> +   /* EC supports CEC commands */
> +   EC_FEATURE_CEC = 35,
>  };
>
>  #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> @@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
> /* EC sent a sysrq command */
> EC_MKBP_EVENT_SYSRQ = 6,
>
> +   /* Notify the AP that something happened on CEC */
> + 

Re: [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

[Enric Balletbo Serra]

Hi Neil,

2018-05-18 15:05 GMT+02:00 Neil Armstrong :
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the

A minor nit, there is a "consensus" on tell cros-ec as "ChromeOS
Embedded Controller" or "ChromeOS EC". Yes, I know that you can see in
the kernel many other ways to refer to the ChromeOS EC, but to
standardize a little bit, could you replace all occurrences s/Chrome
OS/ChromeOS/. Thanks.

> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/media/platform/Kconfig   |  11 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/cros-ec-cec/Makefile  |   1 +
>  drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 
> +++
>  4 files changed, 361 insertions(+)
>  create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
>  create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..e55a8ed2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
>  if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> +   tristate "Chrome OS EC CEC driver"

here

> +   depends on MFD_CROS_EC || COMPILE_TEST
> +   select CEC_CORE
> +   select CEC_NOTIFIER
> +   ---help---
> + If you say yes here you will get support for the
> + Chrome OS Embedded Controller's CEC.

here

> + The CEC bus is present in the HDMI connector and enables 
> communication
> + between compatible devices.
> +
>  config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..830696f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
> qcom/camss-8x16/
>  obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
>  obj-y  += meson/
> +
> +obj-y  += cros-ec-cec/
> diff --git a/drivers/media/platform/cros-ec-cec/Makefile 
> b/drivers/media/platform/cros-ec-cec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c 
> b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> new file mode 100644
> index 000..7e1e275
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> @@ -0,0 +1,347 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for Chrome OS Embedded Controller

and here

> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRV_NAME   "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rx_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> +   struct cros_ec_device *cros_ec;
> +   struct notifier_block notifier;
> +   struct cec_adapter *adap;
> +   struct cec_notifier *notify;
> +   struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> +   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> +   uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> +   unsigned int len = cros_ec->event_size;
> +
> +   cros_ec_cec->rx_msg.len = len;
> +   memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> +   cec_received_msg(cros_ec_cec->adap, _ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> +   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> +   uint32_t events = cros_ec->event_data.data.cec_events;
> +
> +   if (events & EC_MKBP_CEC_SEND_OK)
> +   cec_transmit_attempt_done(cros_ec_cec->adap,
> + 

Re: [PATCH v2 0/5] Add ChromeOS EC CEC Support

[Enric Balletbo Serra]

Hi Neil,

2018-05-18 15:04 GMT+02:00 Neil Armstrong :
> Hi All,
>
> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
> through it's Embedded Controller, to enable the Linux CEC Core to communicate
> with it and get the CEC Physical Address from the correct HDMI Connector, the
> following must be added/changed:
> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
> - Add the CEC related commands and events definitions into the EC MFD driver
> - Add a way to get a CEC notifier with it's (optional) connector name
> - Add the CEC notifier to the i915 HDMI driver
> - Add the proper ChromeOS EC CEC Driver
>
> The CEC notifier with the connector name is the tricky point, since even on
> Device-Tree platforms, there is no way to distinguish between multiple HDMI
> connectors from the same DRM driver. The solution I implemented is pretty
> simple and only adds an optional connector name to eventually distinguish
> an HDMI connector notifier from another if they share the same device.
>
> Feel free to comment this patchset !
>
> Changes since v2:
>  - Add i915 port_identifier() and use this stable name as cec_notifier conn 
> name
>  - Fixed and cleaned up the CEC commands and events handling
>  - Rebased the CEC sub-device registration on top of Enric's serie
>  - Fixed comments typo on cec driver
>  - Protected the DMI match only with PCI and DMI Kconfigs
>

Just because I got confused when I saw two v2 in my inbox. This is v3, right?

> Changes since v1:
>  - Added cec_notifier_put to intel_hdmi
>  - Fixed all small reported issues on the EC CEC driver
>  - Moved the cec_notifier_get out of the #if .. #else .. #endif
>
> Changes since RFC:
>  - Moved CEC sub-device registration after CEC commands and events 
> definitions patch
>  - Removed get_notifier_get_byname
>  - Added CEC_CORE select into i915 Kconfig
>  - Removed CEC driver fallback if notifier is not configured on HW, added 
> explicit warn
>  - Fixed CEC core return type on error
>  - Moved to cros-ec-cec media platform directory
>  - Use bus_find_device() to find the pci i915 device instead of 
> get_notifier_get_byname()
>  - Fix Logical Address setup
>  - Added comment about HW support
>  - Removed memset of msg structures
>
> Neil Armstrong (5):
>   media: cec-notifier: Get notifier by device and connector name
>   drm/i915: hdmi: add CEC notifier to intel_hdmi
>   mfd: cros-ec: Introduce CEC commands and events definitions.
>   mfd: cros_ec_dev: Add CEC sub-device registration
>   media: platform: Add Chrome OS EC CEC driver
>
>  drivers/gpu/drm/i915/Kconfig |   1 +
>  drivers/gpu/drm/i915/intel_display.h |  20 ++
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_hdmi.c|  13 +
>  drivers/media/cec/cec-notifier.c |  11 +-
>  drivers/media/platform/Kconfig   |  11 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/cros-ec-cec/Makefile  |   1 +
>  drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 
> +++
>  drivers/mfd/cros_ec_dev.c|  16 ++
>  drivers/platform/chrome/cros_ec_proto.c  |  40 ++-
>  include/linux/mfd/cros_ec.h  |   2 +-
>  include/linux/mfd/cros_ec_commands.h |  80 ++
>  include/media/cec-notifier.h |  27 +-
>  14 files changed, 557 insertions(+), 16 deletions(-)
>  create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
>  create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

[Enric Balletbo Serra]

2018-05-18 15:05 GMT+02:00 Neil Armstrong :
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/mfd/cros_ec_dev.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 1d6dc5c..272969e 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
> *ec)
> kfree(msg);
>  }
>
> +static const struct mfd_cell cros_ec_cec_cells[] = {
> +   { .name = "cros-ec-cec" }
> +};
> +
>  static const struct mfd_cell cros_ec_rtc_cells[] = {
> { .name = "cros-ec-rtc" }
>  };
> @@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
> if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec);
>
> +   /* Check whether this EC instance has CEC host command support */
> +   if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
> +   retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
> +cros_ec_cec_cells,
> +ARRAY_SIZE(cros_ec_cec_cells),
> +NULL, 0, NULL);
> +   if (retval)
> +   dev_err(ec->dev,
> +   "failed to add cros-ec-cec device: %d\n",
> +   retval);
> +   }
> +
> /* Check whether this EC instance has RTC host command support */
> if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
> retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
> --
> 2.7.4
>

Reviewed-by: Enric Balletbo i Serra 

Thanks,
 Enric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

[Enric Balletbo Serra]

Hi Neil,

I suspect that this patch will conflict with some patches that will be
queued for 4.18 that also introduces new devices, well, for now I
don't see these merged in the Lee's tree.

Based on some reviews I got when I send a patch to this file ...

2018-05-15 17:29 GMT+02:00 Hans Verkuil :
> On 05/15/2018 04:42 PM, Neil Armstrong wrote:
>> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
>> when the CEC feature bit is present.
>>
>> Signed-off-by: Neil Armstrong 
>
> For what it is worth (not an MFD expert):
>
> Acked-by: Hans Verkuil 
>
> Thanks!
>
> Hans
>
>> ---
>>  drivers/mfd/cros_ec_dev.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
>> index eafd06f..57064ec 100644
>> --- a/drivers/mfd/cros_ec_dev.c
>> +++ b/drivers/mfd/cros_ec_dev.c
>> @@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
>> *ec)
>>   kfree(msg);
>>  }
>>
>> +static void cros_ec_cec_register(struct cros_ec_dev *ec)
>> +{
>> + int ret;
>> + struct mfd_cell cec_cell = {
>> + .name = "cros-ec-cec",
>> + };
>> +
>> + ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
>> + if (ret)
>> + dev_err(ec->dev, "failed to add EC CEC\n");
>> +}
>> +

Do not create a single function to only call mfd_add_devices, instead
do the following on top:

static const struct mfd_cell cros_ec_cec_cells[] = {
{ .name = "cros-ec-cec" }
};


>>  static int ec_device_probe(struct platform_device *pdev)
>>  {
>>   int retval = -ENOMEM;
>> @@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
>>   if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
>>   cros_ec_sensors_register(ec);
>>
>> + /* check whether this EC handles CEC. */
>> + if (cros_ec_check_features(ec, EC_FEATURE_CEC))
>> + cros_ec_cec_register(ec);
>> +

and use PLATFORM_DEVID_AUTO and the ARRAY_SIZE macro, something like this.

/* Check whether this EC instance handles CEC */
if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
  cros_ec_cec_cells,
  ARRAY_SIZE(cros_ec_cec_cells),
  NULL, 0, NULL);
if (retval)
dev_err(ec->dev, "failed to add cros-ec-cec device: %d\n",
 retval);
}

Best regards,
  Enric

>>   /* Take control of the lightbar from the EC. */
>>   lb_manual_suspend_ctrl(ec, 1);
>>
>>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm/rockchip: add transfer function for cdn-dp

[Enric Balletbo Serra]

Hi Lin,

2018-05-14 11:53 GMT+02:00 Lin Huang :
> From: Chris Zhong 
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> Reviewed-by: Sean Paul 
> Reviewed-by: Enric Balletbo 

If you need to send another version, could you use the following name
and email address instead?

Reviewed-by: Enric Balletbo i Serra 

Thanks :)
 Enric

> ---
> Changes in v2:
> - update patch following Enric suggest
> - None
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++
>  drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 69 
> ++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++-
>  4 files changed, 122 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device 
> *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> -   ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
> -   if (ret)
> +   ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
> +   if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct 
> cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> -   ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> -  DP_RECEIVER_CAP_SIZE);
> -   if (ret) {
> +   ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
> +  sizeof(dp->dpcd));
> +   if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
> *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> -   if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> -DP_LINK_STATUS_SIZE)) {
> +   if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
> +   DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
>  }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> +  struct drm_dp_aux_msg *msg)
> +{
> +   struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, 
> aux);
> +   int ret;
> +   u8 status;
> +
> +   switch (msg->request & ~DP_AUX_I2C_MOT) {
> +   case DP_AUX_NATIVE_WRITE:
> +   case DP_AUX_I2C_WRITE:
> +   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +   ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> +   msg->size);
> +   break;
> +   case DP_AUX_NATIVE_READ:
> +   case DP_AUX_I2C_READ:
> +   ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> +  msg->size);
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   status = cdn_dp_get_aux_status(dp);
> +   if (status == AUX_STATUS_ACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> +   else if (status == AUX_STATUS_NACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> +   else if (status == AUX_STATUS_DEFER)
> +   msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> +   return ret;
> +}
> +
>  static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>  {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct 
> device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> +   dp->aux.name = "DP-AUX";
> +   dp->aux.transfer = cdn_dp_aux_transfer;
> +   dp->aux.dev = dev;
> +
> +   ret = drm_dp_aux_register(>aux);
> +   if (ret)
> +   return ret;
>
> INIT_WORK(>event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct 

Re: [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp

[Enric Balletbo Serra]

Hi Lin,

2018-05-09 12:22 GMT+02:00 Lin Huang :
> From: Chris Zhong 
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
>
> Changes in v2:
> - update patch following Enric suggest
>
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 
>  drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 67 
> ++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++-
>  4 files changed, 120 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device 
> *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> -   ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
> -   if (ret)
> +   ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
> +   if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct 
> cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> -   ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> -  DP_RECEIVER_CAP_SIZE);
> -   if (ret) {
> +   ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
> +  sizeof(dp->dpcd));
> +   if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
> *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> -   if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> -DP_LINK_STATUS_SIZE)) {
> +   if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
> +   DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
>  }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> +  struct drm_dp_aux_msg *msg)
> +{
> +   struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, 
> aux);
> +   int ret;
> +   u8 status;
> +
> +   switch (msg->request & ~DP_AUX_I2C_MOT) {
> +   case DP_AUX_NATIVE_WRITE:
> +   case DP_AUX_I2C_WRITE:
> +   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +   ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> +   msg->size);
> +   break;
> +   case DP_AUX_NATIVE_READ:
> +   case DP_AUX_I2C_READ:
> +   ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> +  msg->size);
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   status = cdn_dp_get_aux_status(dp);
> +   if (status == AUX_STATUS_ACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> +   else if (status == AUX_STATUS_NACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> +   else if (status == AUX_STATUS_DEFER)
> +   msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> +   return ret;
> +}
> +
>  static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>  {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct 
> device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> +   dp->aux.name = "DP-AUX";
> +   dp->aux.transfer = cdn_dp_aux_transfer;
> +   dp->aux.dev = dev;
> +
> +   ret = drm_dp_aux_register(>aux);
> +   if (ret)
> +   return ret;
>
> INIT_WORK(>event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct platform_device *audio_pdev;
> struct work_struct event_work;
> struct edid *edid;
> +   struct drm_dp_aux aux;
>
> struct mutex lock;
> bool connected;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index 

Re: [PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY

[Enric Balletbo Serra]

Hi Lin,

2018-05-11 16:43 GMT+02:00 Sean Paul :
> On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote:
>> If want to do training outside DP Firmware, need phy voltage swing
>> and pre_emphasis value.
>>
>> Signed-off-by: Lin Huang 
>
> Adding Rob Herring so he has a hope of seeing this.
>

And adding the devicetree ML, otherwise Rob will probably ignore the patch.

>> ---
>> Changes in v2:
>> - rebase
>>
>>  Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt 
>> b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> index 960da7f..eda26dd 100644
>> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
>> @@ -17,7 +17,9 @@ Required properties:
>>
>>  Optional properties:
>>   - extcon : extcon specifier for the Power Delivery
>> -
>> + - rockchip,phy_config : That's phy voltage swing and pre_emphasis
>> +  setting, if want to do dp training outside
>> +  dp firmware, need to add these value.
>
> What are the units?
>

Also, I think that will be good add an example or include the property
in the current examples to see how works. It's not clear from the
property description. I suppose it is an array of pairs ?

nit:

-rockchip,phy_config: A list of voltage swing (unit) and pre-emphasis
(unit) pairs. Use this property to enable software link training
instead of hardware link training.

Best regards,
 Enric

> Sean
>
>>  Required nodes : a sub-node is required for each port the phy provides.
>>The sub-node name is used to identify dp or usb3 port,
>>and shall be the following entries:
>> --
>> 2.7.4
>>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] phy: rockchip-typec: support variable phy config value

[Enric Balletbo Serra]

Hi Lin,

Thanks for the patch, apart from the new build warnings introduced
some more comments below.

2018-05-04 10:08 GMT+02:00 Lin Huang :
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
>  drivers/phy/rockchip/phy-rockchip-typec.c | 286 
> +++---
>  include/soc/rockchip/rockchip_phy_typec.h |  72 
>  2 files changed, 259 insertions(+), 99 deletions(-)
>  create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 76a4b58..831a93b 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
> @@ -63,6 +63,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #define CMN_SSM_BANDGAP(0x21 << 2)
>  #define CMN_SSM_BIAS   (0x22 << 2)
> @@ -323,23 +324,31 @@
>   * clock 0: PLL 0 div 1
>   * clock 1: PLL 1 div 2
>   */
> -#define CLK_PLL_CONFIG 0X30
> +#define CLK_PLL1_DIV1  0x20
> +#define CLK_PLL1_DIV2  0x30
>  #define CLK_PLL_MASK   0x33
>
>  #define CMN_READY  BIT(0)
>
> +#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
>  #define DP_PLL_CLOCK_ENABLEBIT(2)
> +#define DP_PLL_ENABLE_ACK  BIT(1)
>  #define DP_PLL_ENABLE  BIT(0)
>  #define DP_PLL_DATA_RATE_RBR   ((2 << 12) | (4 << 8))
>  #define DP_PLL_DATA_RATE_HBR   ((2 << 12) | (4 << 8))
>  #define DP_PLL_DATA_RATE_HBR2  ((1 << 12) | (2 << 8))
> +#define DP_PLL_DATA_RATE_MASK  0xff00
>
> -#define DP_MODE_A0 BIT(4)
> -#define DP_MODE_A2 BIT(6)
> -#define DP_MODE_ENTER_A0   0xc101
> -#define DP_MODE_ENTER_A2   0xc104
> +#define DP_MODE_MASK   0xf
> +#define DP_MODE_ENTER_A0   BIT(0)
> +#define DP_MODE_ENTER_A2   BIT(2)
> +#define DP_MODE_ENTER_A3   BIT(3)
> +#define DP_MODE_A0_ACK BIT(4)
> +#define DP_MODE_A2_ACK BIT(6)
> +#define DP_MODE_A3_ACK BIT(7)
> +#define DP_LINK_RESET_DEASSERTED   BIT(8)
>
> -#define PHY_MODE_SET_TIMEOUT   10
> +#define PHY_MODE_SET_TIMEOUT   100
>

Why do you need to increase this timeout? Is because the software link
training timed out using the old value?


>  #define PIN_ASSIGN_C_E 0x51d9
>  #define PIN_ASSIGN_D_F 0x5100
> @@ -349,51 +358,7 @@
>  #define MODE_DFP_USB   BIT(1)
>  #define MODE_DFP_DPBIT(2)
>
> -struct usb3phy_reg {
> -   u32 offset;
> -   u32 enable_bit;
> -   u32 write_enable;
> -};
> -
> -/**
> - * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
> - * @reg: the base address for usb3-phy config.
> - * @typec_conn_dir: the register of type-c connector direction.
> - * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
> - * @external_psm: the register of type-c phy external psm clock.
> - * @pipe_status: the register of type-c phy pipe status.
> - * @usb3_host_disable: the register of type-c usb3 host disable.
> - * @usb3_host_port: the register of type-c usb3 host port.
> - * @uphy_dp_sel: the register of type-c phy DP select control.
> - */
> -struct rockchip_usb3phy_port_cfg {
> -   unsigned int reg;
> -   struct usb3phy_reg typec_conn_dir;
> -   struct usb3phy_reg usb3tousb2_en;
> -   struct usb3phy_reg external_psm;
> -   struct usb3phy_reg pipe_status;
> -   struct usb3phy_reg usb3_host_disable;
> -   struct usb3phy_reg usb3_host_port;
> -   struct usb3phy_reg uphy_dp_sel;
> -};
> -
> -struct rockchip_typec_phy {
> -   struct device *dev;
> -   void __iomem *base;
> -   struct extcon_dev *extcon;
> -   struct regmap *grf_regs;
> -   struct clk *clk_core;
> -   struct clk *clk_ref;
> -   struct reset_control *uphy_rst;
> -   struct reset_control *pipe_rst;
> -   struct reset_control *tcphy_rst;
> -   const struct rockchip_usb3phy_port_cfg *port_cfgs;
> -   /* mutex to protect access to individual PHYs */
> -   struct mutex lock;
> -
> -   bool flip;
> -   u8 mode;
> -};
> +#define DEFAULT_RATE   162000
>

DEFAULT_RATE seems a very common name for me, maybe add a prefix?


>  struct phy_reg {
> u16 value;
> @@ -417,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
> { 0x8,  CMN_DIAG_PLL0_LF_PROG },
>  };
>
> -struct phy_reg dp_pll_cfg[] = {
> +struct phy_reg dp_pll_rbr_cfg[] = {
> { 0xf0, CMN_PLL1_VCOCAL_INIT },
> { 0x18,

Re: [PATCH 4/4] drm/rockchip: support dp training outside dp firmware

[Enric Balletbo Serra]

Hi Lin,

Thanks for the patch.

2018-05-04 10:08 GMT+02:00 Lin Huang :
> DP firware use fix phy config value to do training, but some

s/fiware/firmware/

> board need to adjust these value to fit for their hardware design,
> so we use new phy config to do training outside firmware to meet
> this situation, if there have new phy config pass from dts, it will
> use training outside firmware.
>

maybe you can rewrite all this in a better way.

ooi, which boards needs this?


> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  23 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 398 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  33 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 480 insertions(+), 17 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>
>  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> +   cdn-dp-link-training.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index 268c190..a2a4208 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
> goto out;
> }
> }
> -
> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> -   if (ret) {
> -   DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> -   goto out;
> +   if (dp->sw_training_success == false) {
> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> +   if (ret) {
> +   DRM_DEV_ERROR(dp->dev,
> + "Failed to idle video %d\n", ret);
> +   goto out;
> +   }
> }
>
> ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,14 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
> goto out;
> }
>
> -   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> -   if (ret) {
> -   DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> -   goto out;
> +   if (dp->sw_training_success == false) {
> +   ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> +   if (ret) {
> +   DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", 
> ret);
> +   goto out;
> +   }
> }
> +
>  out:
> mutex_unlock(>lock);
>  }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..c6050ab 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
> bool connected;
> bool active;
> bool suspended;
> +   bool sw_training_success;
>
> const struct firmware *fw;  /* cdn dp firmware */
> unsigned int fw_version;/* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
> u8 ports;
> u8 lanes;
> int active_port;
> +   u8 train_set[4];
>
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 000..558c945
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,398 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

For a C source file the format is:
(https://www.kernel.org/doc/html/latest/process/license-rules.html)

// SPDX-License-Identifier: 

> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + */
> +
> +#include 

Why you need this include?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: [PATCH 1/4] drm/rockchip: add transfer function for cdn-dp

[Enric Balletbo Serra]

Hi Lin,

I am interested in these patches, could you cc me on newer versions? Thanks.

Some comments below.

2018-05-04 10:08 GMT+02:00 Lin Huang :
> From: Chris Zhong 
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 
>  drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 66 
> +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++--
>  4 files changed, 119 insertions(+), 17 deletions(-)
>

In general, for this patch and all the other patches in the series I
saw that checkpatch spits out some warnings, could you fix these and
ideally run checkpatch with the --strict --subjective option?

> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..268c190 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device 
> *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> -   ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
> -   if (ret)
> +   ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
> +   if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct 
> cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> -   ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> -  DP_RECEIVER_CAP_SIZE);
> -   if (ret) {
> +   ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
> +  sizeof(dp->dpcd));
> +   if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
> *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> -   if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> -DP_LINK_STATUS_SIZE)) {
> +   if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
> +   DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
>  }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> +  struct drm_dp_aux_msg *msg)
> +{
> +   struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, 
> aux);
> +   int ret;
> +   u8 status;
> +
> +   switch (msg->request & ~DP_AUX_I2C_MOT) {
> +   case DP_AUX_NATIVE_WRITE:
> +   case DP_AUX_I2C_WRITE:
> +   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +   ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> +   msg->size);
> +   break;
> +   case DP_AUX_NATIVE_READ:
> +   case DP_AUX_I2C_READ:
> +   ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> +  msg->size);
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   status = cdn_dp_get_aux_status(dp);
> +   if (status == AUX_STAUS_ACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> +   else if (status == AUX_STAUS_NACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> +   else if (status == AUX_STAUS_DEFER)
> +   msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +

I think that you would mean STATUS instead of STAUS on these defines.

What happens if the status is AUX_STATUS_SINK_ERROR or AUX_STATUS_BUS_ERROR?

> +   return ret;
> +}
> +
>  static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>  {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct 
> device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> +   dp->aux.name = "DP-AUX";
> +   dp->aux.transfer = cdn_dp_aux_transfer;
> +   dp->aux.dev = dev;
> +
> +   ret = drm_dp_aux_register(>aux);
> +   if (ret)
> +   return ret;
>
> INIT_WORK(>event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ 

Re: [PATCH v6 28/30] drm/rockchip: Disable PSR from reboot notifier

[Enric Balletbo Serra]

Hi Andrzej, Tomasz

2018-04-16 15:12 GMT+02:00 Tomasz Figa :
> Hi Andrzej,
>
> On Mon, Apr 16, 2018 at 6:57 PM Andrzej Hajda  wrote:
>
>> On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
>> > From: Tomasz Figa 
>> >
>> > It looks like the driver subsystem detaches devices from power domains
>> > at shutdown without consent of the drivers.
>
>> It looks bit strange. Could you elaborate more on it. Could you show the
>> code performing the detach?
>
> It not only looks strange, but it is strange. The code was present in 4.4:
>
> https://elixir.bootlin.com/linux/v4.4.128/source/drivers/base/platform.c#L553
>
> but was apparently removed in 4.5:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/base/platform.c?h=next-20180416=2d30bb0b3889adf09b342722b2ce596c0763bc93
>
> So we might not need this patch anymore.
>

Right, seems that we don't need this patch anymore, I'll do more few
tests and likely remove this patch from this series. Thanks for
catching this.

Best regards,
  Enric

> Best regards,
> Tomasz
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Enric Balletbo Serra]

2018-02-08 18:48 GMT+01:00 Sean Paul :
> This patch adds an override mode for kevin devices. The mode increases
> both back porches to allow a pixel clock of 2kHz as opposed to the
> 'typical' value of 252750kHz. This is needed to avoid interference with
> the touch digitizer on these laptops.
>
> Changes in v2:
>  - Wrap the timing in display-timings node to match binding (Rob/Thierry)
> Changes in v3:
>  - Unwrap the timing from display-timings and rename panel-timing (Rob)
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
> b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> index 191a6bcb1704..658411ce37ea 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> @@ -98,6 +98,20 @@
> backlight = <>;
> power-supply = <_disp>;
>
> +   panel-timing {
> +   clock-frequency = <266604720>;
> +   hactive = <2400>;
> +   hfront-porch = <48>;
> +   hback-porch = <84>;
> +   hsync-len = <32>;
> +   hsync-active = <0>;
> +   vactive = <1600>;
> +   vfront-porch = <3>;
> +   vback-porch = <120>;
> +   vsync-len = <10>;
> +   vsync-active = <0>;
> +   };
> +
> ports {
> panel_in_edp: endpoint {
> remote-endpoint = <_out_panel>;
> --


Tested on top of linux-next on a Samsung Chromebook Plus.

Tested-by: Enric Balletbo i Serra 


> 2.16.0.rc1.238.g530d649a79-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/6] drm/panel: simple: Use display_timing for lq123p1jx31

[Enric Balletbo Serra]

Hi,

2018-02-08 18:48 GMT+01:00 Sean Paul :
> Convert the sharp lq123p1jx31 from using a fixed mode to specifying a
> display timing with min/typ/max values. This allows us to capture the
> timings set forth in the datasheet as well as the additional values that
> we've cleared with the display vendor to avoid interference with the
> digitizer on the Samsung Chromebook Plus (kevin).
>
> A follow-on patch will specify the override mode for kevin devices.
>
> Changes in v2:
>  - None
> Changes in v3:
>  - None
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 27 +--
>  1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 87488392bca1..6de9c39bc182 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1806,23 +1806,22 @@ static const struct panel_desc sharp_lq101k1ly04 = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
>  };
>
> -static const struct drm_display_mode sharp_lq123p1jx31_mode = {
> -   .clock = 252750,
> -   .hdisplay = 2400,
> -   .hsync_start = 2400 + 48,
> -   .hsync_end = 2400 + 48 + 32,
> -   .htotal = 2400 + 48 + 32 + 80,
> -   .vdisplay = 1600,
> -   .vsync_start = 1600 + 3,
> -   .vsync_end = 1600 + 3 + 10,
> -   .vtotal = 1600 + 3 + 10 + 33,
> -   .vrefresh = 60,
> -   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +static const struct display_timing sharp_lq123p1jx31_timing = {
> +   .pixelclock = { 25275, 25275, 266604720 },
> +   .hactive = { 2400, 2400, 2400 },
> +   .hfront_porch = { 48, 48, 48 },
> +   .hback_porch = { 80, 80, 84 },
> +   .hsync_len = { 32, 32, 32 },
> +   .vactive = { 1600, 1600, 1600 },
> +   .vfront_porch = { 3, 3, 3 },
> +   .vback_porch = { 33, 33, 120 },
> +   .vsync_len = { 10, 10, 10 },
> +   .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
>  };
>
>  static const struct panel_desc sharp_lq123p1jx31 = {
> -   .modes = _lq123p1jx31_mode,
> -   .num_modes = 1,
> +   .timings = _lq123p1jx31_timing,
> +   .num_timings = 1,
> .bpc = 8,
> .size = {
> .width = 259,
> --


Tested on top of linux-next on a Samsung Chromebook Plus.

Tested-by: Enric Balletbo i Serra 


> 2.16.0.rc1.238.g530d649a79-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/6] drm/panel: simple: Add ability to override typical timing

[Enric Balletbo Serra]

Hi,

2018-02-08 18:48 GMT+01:00 Sean Paul :
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
>
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
>
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 67 
> +++-
>  1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5591984a392b..87488392bca1 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -34,6 +34,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>  struct panel_desc {
> @@ -87,6 +88,8 @@ struct panel_simple {
> struct i2c_adapter *ddc;
>
> struct gpio_desc *enable_gpio;
> +
> +   struct drm_display_mode override_mode;
>  };
>
>  static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> @@ -99,11 +102,22 @@ static int panel_simple_get_fixed_modes(struct 
> panel_simple *panel)
> struct drm_connector *connector = panel->base.connector;
> struct drm_device *drm = panel->base.drm;
> struct drm_display_mode *mode;
> +   bool has_override = panel->override_mode.type;
> unsigned int i, num = 0;
>
> if (!panel->desc)
> return 0;
>
> +   if (has_override) {
> +   mode = drm_mode_duplicate(drm, >override_mode);
> +   if (mode) {
> +   drm_mode_probed_add(connector, mode);
> +   num++;
> +   } else {
> +   dev_err(drm->dev, "failed to add override mode\n");
> +   }
> +   }
> +
> for (i = 0; i < panel->desc->num_timings; i++) {
> const struct display_timing *dt = >desc->timings[i];
> struct videomode vm;
> @@ -120,7 +134,7 @@ static int panel_simple_get_fixed_modes(struct 
> panel_simple *panel)
>
> mode->type |= DRM_MODE_TYPE_DRIVER;
>
> -   if (panel->desc->num_timings == 1)
> +   if (panel->desc->num_timings == 1 && !has_override)
> mode->type |= DRM_MODE_TYPE_PREFERRED;
>
> drm_mode_probed_add(connector, mode);
> @@ -291,10 +305,58 @@ static const struct drm_panel_funcs panel_simple_funcs 
> = {
> .get_timings = panel_simple_get_timings,
>  };
>
> +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> +   (to_check->field.typ >= bounds->field.min && \
> +to_check->field.typ <= bounds->field.max)
> +static void panel_simple_add_override_mode(struct device *dev,
> +  struct panel_simple *panel,
> +  const struct display_timing *ot)
> +{
> +   const struct panel_desc *desc = panel->desc;
> +   struct videomode vm;
> +   int i;
> +
> +   if (desc->num_modes) {
> +   dev_err(dev, "Reject override mode: panel has a fixed 
> mode\n");
> +   return;
> +   }
> +   if (!desc->num_timings) {
> +   dev_err(dev, "Reject override mode: no timings specified\n");
> +   return;
> +   }
> +
> +   for (i = 0; i < panel->desc->num_timings; i++) {
> +   const struct display_timing *dt = >desc->timings[i];
> +
> +   if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> +   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> +   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> +   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> +   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> +   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> +   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> +   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, 

Re: [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

[Enric Balletbo Serra]

Hi,

2018-02-16 21:54 GMT+01:00 Doug Anderson <diand...@chromium.org>:
> Hi,
>
> On Fri, Feb 16, 2018 at 4:34 AM, Enric Balletbo Serra
> <eballe...@gmail.com> wrote:
>> Hi,
>>
>> 2018-01-31 17:52 GMT+01:00 Doug Anderson <diand...@chromium.org>:
>>> Hi,
>>>
>>>
>>> On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul <seanp...@chromium.org> wrote:
>>>> On Wed, Jan 31, 2018 at 7:54 AM, Lucas Stach <l.st...@pengutronix.de> 
>>>> wrote:
>>>>> Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb Thierry Escande:
>>>>>> From: Sean Paul <seanp...@chromium.org>
>>>>>>
>>>>>> Change the mode for Sharp lq123p1jx31 panel to something more
>>>>>> rockchip-friendly such that we can use the fixed PLLs to
>>>>>> generate the pixel clock
>>>>>
>>>>> This should really switch to a display timing instead of exposing a
>>>>> single mode. The display timing has min, typical, max tuples for all
>>>>> the timings values, which would allow the attached driver to vary the
>>>>> timings inside the allowed bounds if it makes sense.
>>>>>
>>>>> Trying to hit a specific pixel clock to free up a PLL is exactly one of
>>>>> the use cases envisioned for the display timings stuff.
>>>>>
>>>>
>>>> Agreed, I think we had this discussion the first time around. We
>>>> should drop this patch.
>>>>
>>>> Thanks for catching this!
>>>
>>> Are you sure we should drop this?  In order for things to work
>>> properly (not generate noise on the digitizer or other EMI), this
>>> needs to run at a very specific pixel clock with very specific
>>> blanking times.  I know that earlier we had slightly different
>>> blanking times and Samsung came back and said that there was noise on
>>> the digitizer.  I could be wrong, but I don't think there's any way
>>> currently to be able to specify exactly what timings should be used on
>>> a particular board.
>>>
>>> Don't get be wrong--I think a patch such as this one that claims a
>>> single board's timings as the "right" ones for a generic panel is a
>>> bit of a hack.  ...but at the same time there are no other users of
>>> this panel (that I know of) in mainline and the timings presented here
>>> are certainly sane timings for this panel.
>>>
>>> In any case, previous discussion at: 
>>> https://patchwork.kernel.org/patch/9614603/
>>>
>>>
>>> ...oh, and looking at the previous discussion reminds me that the
>>> timings presented in this here patch are actually not the right ones
>>> (they have the right PLL, but the wrong blankings to avoid the noise
>>> issues).  See 
>>>
>>
>> As Thierry no longer has the hardware to test these patch series, I'll
>> take care of these and follow the upstreaming process. I think that
>> doesn't make sense send a v4 version of all 43 patches for this
>> change. Right now, only this patch received comments so I'll wait a
>> bit more for if we can get the other patches reviewed. If the others
>> are fine just and I don't need to send a new version just don't apply
>> this one and I will send a second version of that specific patch. Or
>> even better, is really trivial what needs to be changed, so maybe the
>> maintainer can do it? ;)
>
> Just as a heads up, Sean Paul has a series of patches to replace this
> patch.  The following are IDs from patchwork.kernel.org:
>
> 10207583 New  [v3,1/6] dt-bindings: Clarify timing subnode use
> as panel-timing
> 10207585 New  [v3,2/6] dt-bindings: Add headings to
> simple-panel bindings
> 10207591 New  [v3,3/6] dt-bindings: Add panel-timing subnode
> to simple-panel
> 10207593 New  [v3,4/6] drm/panel: simple: Add ability to
> override typical timing
> 10207595 New  [v3,5/6] drm/panel: simple: Use display_timing
> for lq123p1jx31
> 10207603 New  [v3,6/6] arm64: dts: rockchip: Specify override
> mode for kevin panel
>
> -Doug

Nice, I was not aware of these, I'll test. That means that this patch
can be removed from these series as the Sean solution is a lot better.
Just a note that this patch can be removed without any collateral
impact on the other patches, so just ignore it.

Regards,
 Enric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

[Enric Balletbo Serra]

Hi,

2018-01-31 17:52 GMT+01:00 Doug Anderson :
> Hi,
>
>
> On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul  wrote:
>> On Wed, Jan 31, 2018 at 7:54 AM, Lucas Stach  wrote:
>>> Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb Thierry Escande:
 From: Sean Paul 

 Change the mode for Sharp lq123p1jx31 panel to something more
 rockchip-friendly such that we can use the fixed PLLs to
 generate the pixel clock
>>>
>>> This should really switch to a display timing instead of exposing a
>>> single mode. The display timing has min, typical, max tuples for all
>>> the timings values, which would allow the attached driver to vary the
>>> timings inside the allowed bounds if it makes sense.
>>>
>>> Trying to hit a specific pixel clock to free up a PLL is exactly one of
>>> the use cases envisioned for the display timings stuff.
>>>
>>
>> Agreed, I think we had this discussion the first time around. We
>> should drop this patch.
>>
>> Thanks for catching this!
>
> Are you sure we should drop this?  In order for things to work
> properly (not generate noise on the digitizer or other EMI), this
> needs to run at a very specific pixel clock with very specific
> blanking times.  I know that earlier we had slightly different
> blanking times and Samsung came back and said that there was noise on
> the digitizer.  I could be wrong, but I don't think there's any way
> currently to be able to specify exactly what timings should be used on
> a particular board.
>
> Don't get be wrong--I think a patch such as this one that claims a
> single board's timings as the "right" ones for a generic panel is a
> bit of a hack.  ...but at the same time there are no other users of
> this panel (that I know of) in mainline and the timings presented here
> are certainly sane timings for this panel.
>
> In any case, previous discussion at: 
> https://patchwork.kernel.org/patch/9614603/
>
>
> ...oh, and looking at the previous discussion reminds me that the
> timings presented in this here patch are actually not the right ones
> (they have the right PLL, but the wrong blankings to avoid the noise
> issues).  See 
>

As Thierry no longer has the hardware to test these patch series, I'll
take care of these and follow the upstreaming process. I think that
doesn't make sense send a v4 version of all 43 patches for this
change. Right now, only this patch received comments so I'll wait a
bit more for if we can get the other patches reviewed. If the others
are fine just and I don't need to send a new version just don't apply
this one and I will send a second version of that specific patch. Or
even better, is really trivial what needs to be changed, so maybe the
maintainer can do it? ;)

Regards,
 Enric

>
>
> -Doug
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 00/10] rockchip: kevin: Enable edp display

[Enric Balletbo Serra]

Dear all,

2017-11-01 20:33 GMT+01:00 Sean Paul :
> On Tue, Oct 31, 2017 at 12:37:43PM +0800, JeffyChen wrote:
>> Hi Heiko,
>>
>> On 10/31/2017 07:01 AM, Heiko Stuebner wrote:
>> > As I was just looking at the edp dts change in patch1 again, does this
>> > series also contain a fix for the issue below [0] ?
>> >
>> > I'm still seeing this on 4.14-rc6 with the most recent drm tree merged in.
>> >
>> i saw that too, it should due to our psr code...i think Zain has solved
>> these in chromeos kernel, i will ask Zain if he have time to upstream them,
>> or maybe i'll try to upstream them.
>
> You need the patchset where I've refactored the psr locking/workers. I have a
> version of it based on Heiko's tree at
> https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=rk3399-display
>
> With this kernel, the backlight comes on, but I don't have anything on the
> display (which is why I didn't post it). I'll try putting this set on top and
> see what happens.
>

There is a patch in the ML sent by Emil [1], similar to the Sean
patch, that solves the issue.

And I can confirm that the Jeffy's patches + Emil patch makes the
display work on kevin or current rc8

[1] https://patchwork.kernel.org/patch/9985237/

Enric

> Sean
>
>> >
>> > Heiko
>> >
>> > [0]
>> >
>> > [   27.960120] BUG: scheduling while atomic: kworker/1:1/68/0x0002
>> > [   27.974429] Modules linked in: rockchipdrm dw_hdmi analogix_dp 
>> > drm_kms_helper panel_simple crc32_ce drm crct10dif_ce rockchip_saradc 
>> > pwm_bl pwm_cros_ec rockchip_thermal ip_tables x_tabl
>> > es ipv6 smsc95xx smsc75xx ax88179_178a asix usbnet phy_rockchip_pcie 
>> > pcie_rockchip
>> > [   28.008769] CPU: 1 PID: 68 Comm: kworker/1:1 Tainted: GW   
>> > 4.14.0-rc7-03201-g12490811b353 #559
>> > [   28.008774] Hardware name: Google Kevin (DT)
>> > [   28.008825] Workqueue: events analogix_dp_psr_work [rockchipdrm]
>> > [   28.008828] Call trace:
>> > [   28.008838] [] dump_backtrace+0x0/0x378
>> > [   28.008842] [] show_stack+0x14/0x20
>> > [   28.008847] [] dump_stack+0x9c/0xbc
>> > [   28.008852] [] __schedule_bug+0x4c/0x70
>> > [   28.008856] [] __schedule+0x558/0x5e8
>> > [   28.008859] [] schedule+0x38/0xa0
>> > [   28.008864] [] 
>> > schedule_hrtimeout_range_clock+0x84/0xe8
>> > [   28.008867] [] schedule_hrtimeout_range+0x10/0x18
>> > [   28.008870] [] usleep_range+0x64/0x78
>> > [   28.008882] [] analogix_dp_transfer+0x16c/0xa88 
>> > [analogix_dp]
>> > [   28.008891] [] analogix_dpaux_transfer+0x10/0x18 
>> > [analogix_dp]
>> > [   28.008950] [] drm_dp_dpcd_access+0x4c/0xf8 
>> > [drm_kms_helper]
>> > [   28.008994] [] drm_dp_dpcd_write+0x1c/0x28 
>> > [drm_kms_helper]
>> > [   28.009002] [] analogix_dp_disable_psr+0x60/0xb0 
>> > [analogix_dp]
>> > [   28.009036] [] analogix_dp_psr_work+0x4c/0xc0 
>> > [rockchipdrm]
>> > [   28.009040] [] process_one_work+0x1d4/0x348
>> > [   28.009043] [] worker_thread+0x48/0x470
>> > [   28.009048] [] kthread+0x12c/0x130
>> > [   28.009052] [] ret_from_fork+0x10/0x18
>> >
>> >
>> >
>> >
>>
>>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/41] Chromebook Plus (aka kevin) kernel patches

[Enric Balletbo Serra]

2017-03-14 21:43 GMT+01:00 Sean Paul :
> On Thu, Mar 09, 2017 at 11:32:15PM -0500, Sean Paul wrote:
>> Despite our best intentions (and we did a decent job this time around) of 
>> submitting
>> upstream first for the Chromebook Plus, we had a number of patches slip 
>> through the
>> cracks. This series includes all but one of those patches. The outlier 
>> breaks my
>> veyron board, so I dropped it.
>>
>> The patches have been tested on the Chromebook Plus in our downstream 
>> kernel, and
>> my veyron-jaq board with an upstream kernel. They have also been compile 
>> tested
>> using the drm-misc configs.
>>

Just to add more information. I did some quick tests, I successfully
picked the full series on top of linux-next, build and test on veyron
minnie device and gru device. For the gru device (which needs some
other from list patches to make it wok) there are issues but nothing
related to these patches as it fails whenever the patches are applied
or not. The issue I'm facing is LCD flickering but I repeat this is
NOT related to these patches so I think will be helpful have these
patches upstream to have better support for kevin and any other
gru-based device, so:

Tested-by: Enric Balletbo i Serra 

Sean, if you plan send a second version with the comments received can
you also cc me?

Thanks,
  Enric

>> Sean
>>
>>
>> Douglas Anderson (4):
>>   drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner
>>   drm/bridge: analogix_dp: Split the platform-specific poweron in two
>> parts
>>   drm/bridge: analogix_dp: Properly log AUX CH errors
>>   drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
>>
>> Haixia Shi (1):
>>   drm/rockchip: support prime import sg table
>>
>> Lin Huang (6):
>>   drm/bridge: analogix_dp: Move enable video into config_video()
>>   drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer
>>   drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the
>> panel
>>   drm/bridge: analogix_dp: Extend hpd check time to 100ms
>>   drm/bridge: analogix_dp: Check dpcd write/read status
>>   drm/bridge: analogix_dp: Reset aux channel if an error occurred
>>
>> Mark Yao (1):
>>   drm/rockchip: pre dither down when output bpc is 8bit
>>
>> Sean Paul (3):
>>   drm/panel: simple: Change mode for Sharp lq123p1jx31
>>   drm/rockchip: Don't use atomic constructs for psr
>>   drm/rockchip: Remove analogix psr worker
>
> Hi Mark,
> Hopefully you've seen this series by now. I would really like to get your 
> review
> on my 2 patches above so I can get these into drm-misc.
>
> If you have some time, I would really appreciate it.
>
> Sean
>
>>
>> Tomasz Figa (6):
>>   drm/rockchip: Get rid of some unnecessary code
>>   drm/rockchip: Flush PSR before committing modeset disables/enables
>>   drm/bridge: analogix_dp: Allow master driver to cleanup in unbind
>>   drm/rockchip: analogix_dp: Fix invalid implementation of unbind
>>   drm/bridge: analogix_dp: Add analogix_dp_shutdown
>>   drm/rockchip: analogix_dp: Wire the shutdown callback to disable PSR
>>
>> Yakir Yang (1):
>>   drm/bridge: analogix_dp: detect Sink PSR state after configuring the
>> PSR
>>
>> zain wang (18):
>>   drm/bridge: analogix_dp: set psr activate/deactivate when
>> enable/disable bridge
>>   drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind
>>   drm/bridge: analogix_dp: Don't change psr while bridge is disabled
>>   drm/rockchip: add mutex vop lock
>>   drm/bridge: analogix_dp: add fast link train for eDP
>>   drm/rockchip: Only wait for panel ACK on PSR entry
>>   drm/bridge: analogix_dp: Don't use fast link training when panel just
>> powered up
>>   drm/bridge: analogix_dp: Retry bridge enable when it failed
>>   drm/bridge: analogix_dp: Wait for HPD signal before configuring link
>>   drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy
>>   drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode
>>   drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
>>   drm/rockchip: Restore psr->state when enable/disable psr failed
>>   drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll
>>   drm/bridge: analogix_dp: Fix timeout of video streamclk config
>>   drm/bridge: analogix_dp: Fix incorrect operations with register
>> ANALOGIX_DP_FUNC_EN_1
>>   drm/bridge: analogix_dp: Move fast link training detect to set_bridge
>>   drm/rockchip: Disable VOP windows when PSR is active
>>
>> Ørjan Eide (1):
>>   drm/rockchip: Respect page offset for PRIME mmap calls
>>
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 471 
>> +++--
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  14 +-
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 273 +++-
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |   7 +
>>  drivers/gpu/drm/exynos/exynos_dp.c |   2 +-
>>  drivers/gpu/drm/panel/panel-simple.c   

[v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Enric Balletbo Serra]

Hi Jitao,

2016-08-27 8:44 GMT+02:00 Jitao Shi :
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi 
> Reviewed-by: Daniel Kurtz 
> ---
> Changes since v16:
>  - Disable ps8640 DSI MCS Function.
>  - Rename gpios name more clearly.
>  - Tune the ps8640 power on sequence.
>
> Changes since v15:
>  - Drop drm_connector_(un)register calls from parade ps8640.
>The main DRM driver mtk_drm_drv now calls
>drm_connector_register_all() after drm_dev_register() in the
>mtk_drm_bind() function. That function should iterate over all
>connectors and call drm_connector_register() for each of them.
>So, remove drm_connector_(un)register calls from parade ps8640.
>
> Changes since v14:
>  - update copyright info.
>  - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
>  - fix some coding style.
>  - use sizeof as array counter.
>  - use drm_get_edid when read edid.
>  - add mutex when firmware updating.
>
> Changes since v13:
>  - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 
> *data, u16 data_len)
>  - fix PAGE2_SW_REST tyro.
>  - move the buf[3] init to entrance of the function.
>
> Changes since v12:
>  - fix hw_chip_id build warning
>
> Changes since v11:
>  - Remove depends on I2C, add DRM depends
>  - Reuse ps8640_write_bytes() in ps8640_write_byte()
>  - Use timer check for polling like the routines in 
>  - Fix no drm_connector_unregister/drm_connector_cleanup when 
> ps8640_bridge_attach fail
>  - Check the ps8640 hardware id in ps8640_validate_firmware
>  - Remove fw_version check
>  - Move ps8640_validate_firmware before ps8640_enter_bl
>  - Add ddc_i2c unregister when probe fail and ps8640_remove
> ---
>  drivers/gpu/drm/bridge/Kconfig |   12 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/parade-ps8640.c | 1077 
> 
>  3 files changed, 1090 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index b590e67..c59d043 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -50,6 +50,18 @@ config DRM_PARADE_PS8622
> ---help---
>   Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> +   tristate "Parade PS8640 MIPI DSI to eDP Converter"
> +   depends on DRM
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select DRM_MIPI_DSI
> +   select DRM_PANEL
> +   ---help---
> + Choose this option if you have PS8640 for display
> + The PS8640 is a high-performance and low-power
> + MIPI DSI to eDP converter
> +
>  config DRM_SII902X
> tristate "Silicon Image sii902x RGB/HDMI bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index efdb07e..3360537 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 000..7d67431
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,1077 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PAGE1_VSTART   0x6b
> +#define PAGE2_SPI_CFG3 0x82
> +#define I2C_TO_SPI_RESET   0x20
> +#define PAGE2_ROMADD_BYTE1 0x8e
> +#define PAGE2_ROMADD_BYTE2 0x8f
> +#define PAGE2_SWSPI_WDATA  0x90
> +#define PAGE2_SWSPI_RDATA  0x91
> +#define PAGE2_SWSPI_LEN0x92
> +#define PAGE2_SWSPI_CTL0x93
> +#define TRIGGER_NO_READBACK0x05
> +#define TRIGGER_READBACK   0x01
> +#define PAGE2_SPI_STATUS   0x9e
> +#define SPI_READY  0x0c
> 

[v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Enric Balletbo Serra]

Hi Jitao,

2016-08-27 8:44 GMT+02:00 Jitao Shi :
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi 
> Reviewed-by: Daniel Kurtz 
> ---
> Changes since v16:
>  - Disable ps8640 DSI MCS Function.
>  - Rename gpios name more clearly.
>  - Tune the ps8640 power on sequence.
>
> Changes since v15:
>  - Drop drm_connector_(un)register calls from parade ps8640.
>The main DRM driver mtk_drm_drv now calls
>drm_connector_register_all() after drm_dev_register() in the
>mtk_drm_bind() function. That function should iterate over all
>connectors and call drm_connector_register() for each of them.
>So, remove drm_connector_(un)register calls from parade ps8640.
>
> Changes since v14:
>  - update copyright info.
>  - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
>  - fix some coding style.
>  - use sizeof as array counter.
>  - use drm_get_edid when read edid.
>  - add mutex when firmware updating.
>
> Changes since v13:
>  - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 
> *data, u16 data_len)
>  - fix PAGE2_SW_REST tyro.
>  - move the buf[3] init to entrance of the function.
>
> Changes since v12:
>  - fix hw_chip_id build warning
>
> Changes since v11:
>  - Remove depends on I2C, add DRM depends
>  - Reuse ps8640_write_bytes() in ps8640_write_byte()
>  - Use timer check for polling like the routines in 
>  - Fix no drm_connector_unregister/drm_connector_cleanup when 
> ps8640_bridge_attach fail
>  - Check the ps8640 hardware id in ps8640_validate_firmware
>  - Remove fw_version check
>  - Move ps8640_validate_firmware before ps8640_enter_bl
>  - Add ddc_i2c unregister when probe fail and ps8640_remove
> ---
>  drivers/gpu/drm/bridge/Kconfig |   12 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/parade-ps8640.c | 1077 
> 
>  3 files changed, 1090 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index b590e67..c59d043 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -50,6 +50,18 @@ config DRM_PARADE_PS8622
> ---help---
>   Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> +   tristate "Parade PS8640 MIPI DSI to eDP Converter"
> +   depends on DRM
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select DRM_MIPI_DSI
> +   select DRM_PANEL
> +   ---help---
> + Choose this option if you have PS8640 for display
> + The PS8640 is a high-performance and low-power
> + MIPI DSI to eDP converter
> +
>  config DRM_SII902X
> tristate "Silicon Image sii902x RGB/HDMI bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index efdb07e..3360537 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 000..7d67431
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,1077 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PAGE1_VSTART   0x6b
> +#define PAGE2_SPI_CFG3 0x82
> +#define I2C_TO_SPI_RESET   0x20
> +#define PAGE2_ROMADD_BYTE1 0x8e
> +#define PAGE2_ROMADD_BYTE2 0x8f
> +#define PAGE2_SWSPI_WDATA  0x90
> +#define PAGE2_SWSPI_RDATA  0x91
> +#define PAGE2_SWSPI_LEN0x92
> +#define PAGE2_SWSPI_CTL0x93
> +#define TRIGGER_NO_READBACK0x05
> +#define TRIGGER_READBACK   0x01
> +#define PAGE2_SPI_STATUS   0x9e
> +#define SPI_READY  0x0c
> 

[PATCH V4 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Enric Balletbo Serra]

Hi Peter,

Only one comment below and one nitpick

2016-08-05 0:37 GMT+02:00 Peter Senna Tschudin :
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> firmware made it complicated for this binding to comprise two device
> tree nodes, as the design goal is to configure both bridges based on
> the LVDS signal, which leave the driver powerless to control the video
> processing pipeline. The two bridges behaves as a single bridge, and
> the driver is only needed for telling the host about EDID / HPD, and
> for giving the host powers to ack interrupts. The video signal pipeline
> is as follows:
>
>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
>
> Cc: Daniel Vetter 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> CC: David Airlie 
> CC: Thierry Reding 
> CC: Thierry Reding 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Changes from V3:
>  - 3/4 instead of 4/5
>  - Tested on next-20160804
>
> Changes from V2:
>  - Made it atomic to be applied on next-20160729 on top of Liu Ying changes
>that made imx-ldb atomic
>
> Changes from V1:
>  - New commit message
>  - Removed 3 empty entry points
>  - Removed memory leak from ge_b850v3_lvds_dp_get_modes()
>  - Added a lock for mode setting
>  - Removed a few blank lines
>  - Changed the order at Makefile and Kconfig
>
>  MAINTAINERS|   8 +
>  drivers/gpu/drm/bridge/Kconfig |  11 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 397 
> +
>  4 files changed, 417 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a5b6569..f51123c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5142,6 +5142,14 @@ W:   https://linuxtv.org
>  S: Maintained
>  F: drivers/media/radio/radio-gemtek*
>
> +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
> +M: Peter Senna Tschudin 
> +M: Martin Donnelly 
> +M: Martyn Welch 
> +S: Maintained
> +F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c
> +F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
> +
>  GENERIC GPIO I2C DRIVER
>  M: Haavard Skinnemoen 
>  S: Supported
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index b590e67..b4b70fb 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -32,6 +32,17 @@ config DRM_DW_HDMI_AHB_AUDIO
>   Designware HDMI block.  This is used in conjunction with
>   the i.MX6 HDMI driver.
>
> +config DRM_GE_B850V3_LVDS_DP
> +   tristate "GE B850v3 LVDS to DP++ display bridge"
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select DRM_PANEL
> +   ---help---
> +  This is a driver for the display bridge of
> +  GE B850v3 that convert dual channel LVDS
> +  to DP++. This is used with the i.MX6 imx-ldb
> +  driver.
> +
>  config DRM_NXP_PTN3460
> tristate "NXP PTN3460 DP/LVDS bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index efdb07e..b9606f3 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
> b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> new file mode 100644
> index 000..eee8eac
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> @@ -0,0 +1,397 @@
> +/*
> + * Driver for GE B850v3 DP display bridge
> +
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> +
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> +
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> +
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> +
> + * This driver creates a drm_bridge and a 

[PATCH V4 2/4] Documentation/devicetree/bindings: b850v3_lvds_dp

[Enric Balletbo Serra]

Hi Peter,

2016-08-05 0:36 GMT+02:00 Peter Senna Tschudin :
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
>
> Cc: Javier Martinez Canillas 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> Signed-off-by: Peter Senna Tschudin 

I think your previous version was acked by Rob and this version has no
changes from previous so would be good add here the Acked-by: Rob
Herring 


> ---
> Changes from V3:
>  - 2/4 instead of 3/5
>
> Unchanged from V2
>
> Changes from V1:
>  - Replaced '_' by '-' in node names or compatible strings
>  - Added missing @73 to the example
>
>  .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>
> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt 
> b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> new file mode 100644
> index 000..f05c3e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> @@ -0,0 +1,37 @@
> +Driver for GE B850v3 LVDS/DP++ display bridge
> +
> +Required properties:
> +  - compatible : should be "ge,b850v3-lvds-dp".
> +  - reg : should contain the address used to ack the interrupts.
> +  - interrupt-parent : phandle of the interrupt controller that services
> +interrupts to the device
> +  - interrupts : one interrupt should be described here, as in
> +<0 IRQ_TYPE_LEVEL_HIGH>.
> +  - edid-reg : should contain the address used to read edid information
> +  - port : should describe the video signal connection between the host
> +and the bridge.
> +
> +Example:
> +
> +_i2c2 {
> +   status = "okay";
> +   clock-frequency = <10>;
> +
> +   b850v3-lvds-dp-bridge at 73  {
> +   compatible = "ge,b850v3-lvds-dp";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   reg = <0x73>;
> +   interrupt-parent = <>;
> +   interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> +   edid-reg = <0x72>;
> +
> +   port {
> +   b850v3_dp_bridge_in: endpoint {
> +   remote-endpoint = <_out>;
> +   };
> +   };
> +   };
> +};
> --
> 2.5.5
>

[PATCH 2/2 v16] drm/bridge: Add I2C based driver for ps8640 bridge

[Enric Balletbo Serra]

2016-07-12 12:13 GMT+02:00 Daniel Vetter :
> On Wed, Jun 29, 2016 at 6:31 AM, Daniel Kurtz  wrote:
>> On Fri, Jun 17, 2016 at 3:14 AM, Emil Velikov  
>> wrote:
 +static ssize_t ps8640_update_fw_store(struct device *dev,
 + struct device_attribute *attr,
 + const char *buf, size_t count)
 +{
 +   struct i2c_client *client = to_i2c_client(dev);
 +   struct ps8640 *ps_bridge = i2c_get_clientdata(client);
 +   const struct firmware *fw;
 +   int error;
 +
 +   error = request_firmware(, PS_FW_NAME, dev);
>>> Can the device operate without a firmware ? If not, why is the
>>> firmware loaded so later/after user interaction (via sysfs) ? I don't
>>> recall any other driver in DRM to use such an approach.
>>
>> The PS8640 has internal flash, so it should always already have a
>> working firmware.
>> This sysfs interface is useful for user space initiated field firmware 
>> updates.
>
> Might be better to just do a request_firmware on driver load, and
> simply proceed if it's not there. Adding a sysfs interface (which is
> abi) seems way too much overkill for this imo. If you want to upgrade
> the firmware you can then just drop it into the right directory, with
> no further interaction needed.

IMHO I'm not sure if for this use case request_firmware on driver load
is a good idea. Flash the non-volatile internal chip can be a slow
operation and if you forget to remove the firmware after drop it into
the right directory apart from slow down the driver probe you can
damage the chip depending on the write endurance of the chip.

This sysfs interface is used on other subsystems when there is a
non-volatile memory, as example you can see at [1], [2]. Unfortunately
not all are using the same sysfs interface and maybe this should be
standardized (maybe it's an opportunity to define it)

Regards,
 Enric

[1] 
http://lxr.free-electrons.com/source/drivers/input/touchscreen/wdt87xx_i2c.c#L922
[2] http://lxr.free-electrons.com/source/drivers/scsi/pm8001/pm8001_ctl.c#L732


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2 4/5] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Enric Balletbo Serra]

Hi Peter,

Only a few comments ;)

2016-06-09 18:25 GMT+02:00 Peter Senna Tschudin :
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> firmware made it complicated for this binding to comprise two device
> tree nodes, as the design goal is to configure both bridges based on
> the LVDS signal, which leave the driver powerless to control the video
> processing pipeline. The two bridges behaves as a single bridge, and
> the driver is only needed for telling the host about EDID / HPD, and
> for giving the host powers to ack interrupts. The video signal pipeline
> is as follows:
>
>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
>
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> CC: David Airlie 
> CC: Thierry Reding 
> CC: Thierry Reding 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Changes from V1:
>  - New commit message
>  - Removed 3 empty entry points
>  - Removed memory leak from ge_b850v3_lvds_dp_get_modes()
>  - Added a lock for mode setting
>  - Removed a few blank lines
>  - Changed the order at Makefile and Kconfig
>
>  MAINTAINERS|   8 +
>  drivers/gpu/drm/bridge/Kconfig |  11 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 392 
> +
>  4 files changed, 412 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2ce5e91..2dd3d7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5010,6 +5010,14 @@ W:   https://linuxtv.org
>  S: Maintained
>  F: drivers/media/radio/radio-gemtek*
>
> +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
> +M: Martin Donnelly 
> +M: Peter Senna Tschudin 
> +M: Martyn Welch 
> +S: Maintained
> +F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c
> +F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
> +
>  GENERIC GPIO I2C DRIVER
>  M: Haavard Skinnemoen 
>  S: Supported
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..93dae5bd 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -32,6 +32,17 @@ config DRM_DW_HDMI_AHB_AUDIO
>   Designware HDMI block.  This is used in conjunction with
>   the i.MX6 HDMI driver.
>
> +config DRM_GE_B850V3_LVDS_DP
> +   tristate "GE B850v3 LVDS to DP++ display bridge"
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select DRM_PANEL
> +   ---help---
> +  This is a driver for the display bridge of
> +  GE B850v3 that convert dual channel LVDS
> +  to DP++. This is used with the i.MX6 imx-ldb
> +  driver.
> +
>  config DRM_NXP_PTN3460
> tristate "NXP PTN3460 DP/LVDS bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..47ea6c1 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
> b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> new file mode 100644
> index 000..c73cd77
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> @@ -0,0 +1,392 @@
> +/*
> + * Driver for GE B850v3 DP display bridge
> +
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> +
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> +
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> +
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> +
> + * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
> + * display bridge of the GE B850v3. There are two physical bridges on the 
> video
> + * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). 
> However
> + * the physical bridges are 

[PATCH v5 1/2] drm/bridge: Add sii902x driver

[Enric Balletbo Serra]

Hi Boris,

A few comments below ...

2016-06-02 17:00 GMT+02:00 Boris Brezillon :
> Add basic support for the sii902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
>
> Signed-off-by: Boris Brezillon 
> Tested-by: Nicolas Ferre 
> ---
> Hello,
>
> This patch is only adding basic support for the sii9022 chip.
> As stated in the commit log, there's no audio support, but the
> driver also hardcodes a lot of things (like the RGB input format to
> use).
>
> Best Regards,
>
> Boris
>
> Changes in v5:
> - drop the best_encoder() implementation
>
> Changes in v4:
> - make reset GPIO optional
> - only support attaching to DRM devices supporting atomic updates
>
> Changes in v3:
> - fix get_modes() implementation to avoid turning the screen in power
>   save mode
> - rename the driver (sil902x -> sii902x)
>
> Changes in v2:
> - fix errors reported by the kbuild robot
>
> fixup! drm: bridge: Add sii902x driver
> ---
>  drivers/gpu/drm/bridge/Kconfig   |   8 +
>  drivers/gpu/drm/bridge/Makefile  |   1 +
>  drivers/gpu/drm/bridge/sii902x.c | 469 
> +++
>  3 files changed, 478 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/sii902x.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..a1419214 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -50,6 +50,14 @@ config DRM_PARADE_PS8622
> ---help---
>   Parade eDP-LVDS bridge chip driver.
>
> +config DRM_SII902X
> +   tristate "Silicon Image sii902x RGB/HDMI bridge"
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select REGMAP_I2C
> +   ---help---
> + Silicon Image sii902x bridge chip driver.
> +
>  source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..bfec9f8 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> new file mode 100644
> index 000..0912d2f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -0,0 +1,469 @@
> +/*
> + * Copyright (C) 2014 Atmel
> + *   Bo Shen 
> + *
> + * Authors:  Bo Shen 
> + *   Boris Brezillon 
> + *   Wu, Songjun 
> + *
> + *
> + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SIL902X_TPI_VIDEO_DATA 0x0
> +
> +#define SIL902X_TPI_PIXEL_REPETITION   0x8
> +#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5)
> +#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE   BIT(4)
> +#define SIL902X_TPI_AVI_PIXEL_REP_4X   3
> +#define SIL902X_TPI_AVI_PIXEL_REP_2X   1
> +#define SIL902X_TPI_AVI_PIXEL_REP_NONE 0
> +#define SIL902X_TPI_CLK_RATIO_HALF (0 << 6)
> +#define SIL902X_TPI_CLK_RATIO_1X   (1 << 6)
> +#define SIL902X_TPI_CLK_RATIO_2X   (2 << 6)
> +#define SIL902X_TPI_CLK_RATIO_4X   (3 << 6)
> +
> +#define SIL902X_TPI_AVI_IN_FORMAT  0x9
> +#define SIL902X_TPI_AVI_INPUT_BITMODE_12BITBIT(7)
> +#define SIL902X_TPI_AVI_INPUT_DITHER   BIT(6)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED(2 << 2)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_FULL   (1 << 2)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO   (0 << 2)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK (3 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422(2 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444(1 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB   (0 << 0)
> +
> +#define SIL902X_TPI_AVI_INFOFRAME  0x0c
> +
> +#define SIL902X_SYS_CTRL_DATA  0x1a
> +#define SIL902X_SYS_CTRL_PWR_DWN   BIT(4)
> +#define SIL902X_SYS_CTRL_AV_MUTE   BIT(3)
> 

[PATCH 4/5] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

[Enric Balletbo Serra]

Hi Peter,

Just some comments that I received when I submitted my bridge patches
and that I think can help you ...

2016-05-30 18:39 GMT+02:00 Peter Senna Tschudin :
> This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
> display bridge of the GE B850v3(imx6q-b850v3.dts). There are two physical
> bridges on the video signal pipeline: a STDP4028(LVDS to DP) and a
> STDP2690(DP to DP++). However the physical bridges are automatically
> configured by the input video signal, and the driver has no access to
> the video processing pipeline. The driver is only needed to read EDID
> from the STDP2690 and to handle HPD events from the STDP4028. The driver
> communicates with both bridges over i2c. The video signal pipeline is as
> follows:
>
>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
>
> Signed-off-by: Peter Senna Tschudin 
> ---
>  MAINTAINERS|   8 +
>  drivers/gpu/drm/bridge/Kconfig |   8 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c | 397 
> +
>  4 files changed, 414 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3273ffa..7bb5e89 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5009,6 +5009,14 @@ W:   https://linuxtv.org
>  S: Maintained
>  F: drivers/media/radio/radio-gemtek*
>
> +GENERAL ELECTRIC B850V3 LVDS/DP++ BRIDGE
> +M: Martin Donnelly 
> +M: Peter Senna Tschudin 
> +M: Martyn Welch 
> +S: Maintained
> +F: drivers/gpu/drm/bridge/ge_b850v3_dp2.c
> +F: Documentation/devicetree/bindings/ge/b850v3_dp2_bridge.txt
> +
>  GENERIC GPIO I2C DRIVER
>  M: Haavard Skinnemoen 
>  S: Supported
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8f7423f..e9c32fc 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -52,4 +52,12 @@ config DRM_PARADE_PS8622
>
>  source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> +config DRM_GE_B850V3_LVDS_DP
> +   tristate "LVDS/DP bridge"
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select DRM_PANEL
> +   ---help---
> + Driver for GE B850v3 DP2 LVDS to DP+ Bridge
> +

I think the maintainer prefers the entries ordered alphabetically (by
vendor, then name), so your config should go before "config
DRM_NXP_PTN3460"

>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 96b13b3..ba2e355 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> +obj-$(CONFIG_DRM_GE_B850V3_LVDS_DP) += ge_b850v3_lvds_dp.o

Same here,  this needs to be sorted by vendor, then name as well. Also
I think is preferred use hyphens like the others drivers.

Hmm, I see now that CONFIG_DRM_ANALOGIX_DP is not sorted, but I guess
the preferred is be sorted.

> diff --git a/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c 
> b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> new file mode 100644
> index 000..37a4e7a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ge_b850v3_lvds_dp.c
> @@ -0,0 +1,397 @@
> +/*
> + * Driver for GE B850v3 DP display bridge
> +
> + * Copyright (c) 2016, Collabora Ltd.
> + * Copyright (c) 2016, General Electric Company
> +
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> +
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> +
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> +
> + * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
> + * display bridge of the GE B850v3. There are two physical bridges on the 
> video
> + * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). 
> However
> + * the physical bridges are automatically configured by the input video 
> signal,
> + * and the driver has no access to the video processing pipeline. The driver 
> is
> + * only needed to read EDID from the STDP2690 and to handle HPD events from 
> the
> + * STDP4028. The driver communicates with both bridges over i2c. The video
> + * signal pipeline is as follows:
> + *
> + *   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> +
> + *
> + */
> +#include 
> +#include 
> 

[RESEND PATCH v4 4/4] drm: bridge: anx78xx: Add anx78xx driver support.

[Enric Balletbo Serra]

Hi Thierry,

2016-05-02 16:22 GMT+02:00 Thierry Reding :
> On Mon, May 02, 2016 at 09:54:26AM +0200, Enric Balletbo i Serra wrote:
> [...]
>> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
>> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> [...]
>> +static int anx78xx_init_pdata(struct anx78xx *anx78xx)
>> +{
>> + struct device *dev = >client->dev;
>> + struct anx78xx_platform_data *pdata = >pdata;
>> +
>> + /* 1.0V digital core power regulator (optional) */
>> + pdata->dvdd10 = devm_regulator_get(dev, "dvdd10");
>> + if (IS_ERR(pdata->dvdd10)) {
>> + DRM_INFO("DVDD10 regulator not found\n");
>> + pdata->dvdd10 = NULL;
>> + }
>
> I'm almost sure that this isn't what you want. What if the regulator is
> hooked up but the bridge driver probes before the regulator. I think
> what you really want is to simply propagate the error code via:
>
> return PTR_ERR(pdata->dvdd10);
>
> My understanding is that the regulator core will give you a dummy one if
> there's really nothing hooked up. I think you're also supposed to call
> regulator_get_optional() (or the devm_*() equivalent) if this is truly
> an optional supply. Given that it's the "core power" regulator I doubt
> that it's really optional; it's more likely that you may not be able to
> control it, and that it's therefore always on. In that case you're
> supposed to model it in DT as a fixed regulator that's always on.
>

Yes, I was thinking in the case you're are not able to control it and
I make it as optional, and yes, you have reason so It's fine with me
the above solution.

> This is fairly minor and it's really the only thing I could find, so no
> need to respin just for that. If you're fine with the above solution (to
> propagate the error code) I can make the change manually while applying.
>

It's up to you. Whichever you prefer.


Thanks,
 Enric


> Thierry
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH] [media] hdmi: added functions for MPEG InfoFrames

[Enric Balletbo Serra]

Hello Thierry,

2015-11-19 13:29 GMT+01:00 Enric Balletbo Serra :
> Hello Thierry,
>
> 2015-11-19 12:51 GMT+01:00 Thierry Reding :
>> On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote:
>>> Hello Thierry,
>>>
>>> 2015-11-17 13:55 GMT+01:00 Thierry Reding :
>>> > On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
>>> >> Hello Thierry,
>>> >>
>>> >> Many thanks for your comments.
>>> >>
>>> >> 2015-11-16 12:50 GMT+01:00 Thierry Reding :
>>> >> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>>> >> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes 
>>> >> >> aspects of
>>> >> >> the compressed video stream that were used to produce the uncompressed
>>> >> >> video.
>>> >> >>
>>> >> >> The patch adds functions to work with MPEG InfoFrames.
>>> >> >>
>>> >> >> Signed-off-by: Enric Balletbo i Serra >> >> >> collabora.com>
>>> >> >> ---
>>> >> >>  drivers/video/hdmi.c | 156 
>>> >> >> +++
>>> >> >>  include/linux/hdmi.h |  24 
>>> >> >>  2 files changed, 180 insertions(+)
>>> >> >
>>> >> > According to the CEA specification a source is expected to send this
>>> >> > type of infoframe once per video frame. I'm curious how you envision
>>> >> > this to be ensured. Would hardware provide a mechanism to store this
>>> >> > data and send the infoframe automatically? How would you ensure that
>>> >> > updates sent to the hardware match the upcoming frame?
>>> >> >
>>> >>
>>> >> To be honest I'm not sure if I have the full picture. In the use case
>>> >> I'm trying there is a hardware mechanism to store the data and send
>>> >> the infoframe through a "Packet Send Control Register".
>>> >
>>> > Okay, sounds like the hardware will automatically send out packets at
>>> > the right time. That still leaves open the issue of how to ensure this
>>> > is synchronized with userspace. Perhaps this could be done by attaching
>>> > a property to a framebuffer, so that we'd know what exact frame the meta
>>> > data is attached to and when to update the FIFOs for the infoframe.
>>> >
>>> > Usually it's a good idea to send this type of patch as part of a larger
>>> > series precisely so that people can see how it is used. That should make
>>> > it easier to see if this is good enough or needs some more thought on
>>> > how to synchronize. Do you have any code that you could post that makes
>>> > use of this new infoframe?
>>> >
>>>
>>> I was thinking use this and other helpers in the anx7814 bridge
>>> driver[1], I thought that this patch should go through another tree,
>>> this is the reason why I send it separately, but If you want or you
>>> prefer I can send as part of these patch series.
>>>
>>> [1] https://lkml.org/lkml/2015/11/13/284
>>
>> I haven't seen those patches yet. I should've been Cc'ed on those
>> patches since I'm technically the maintainer of drm/bridge. Did the
>> get_maintainer.pl script not list me?
>>
>
> Mmm, just checked and yes, get_maintainer list you, so probably I did
> something getting the maintainers.
> Sorry.
>
>> In my opinion, it's usually a good idea to keep all dependencies in a
>> single series, just so people get a better picture of what you're
>> submitting. Of course that's just my opinion, somebody else may yell at
>> you because they get Cc'ed on patches that they're not interested in...
>>
>> As for merging patches, it's usually best to let maintainers figure that
>> out once the series is in good shape.
>>
>> Thierry


As you suggested I included this patch series with anx7814 bridge
driver series. So you can see the context. Please feel free to comment
anything.

https://lkml.org/lkml/2015/12/4/66

Regards,

Enric

[PATCHv6 5/5] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

[Enric Balletbo Serra]

Hi Dan,

Many thanks for your comments.

2015-12-07 9:09 GMT+01:00 Dan Carpenter :
> On Fri, Dec 04, 2015 at 09:35:07AM +0100, Enric Balletbo i Serra wrote:
>> +static int sp_wait_aux_op_finish(struct anx78xx *anx78xx)
>> +{
>> + u8 errcnt;
>> + u8 val;
>> + struct device *dev = >client->dev;
>> +
>> + errcnt = 150;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, );
>> + if (!(val & SP_AUX_EN))
>> + break;
>> + usleep_range(2000, 4000);
>> + }
>> +
>> + if (!errcnt) {
>
> This is off by one.  It should be:
>
> while (--errcnt) {
> ...
> }
> if (errcnt == 0)
> return -EWHATEVER;
>
> Or:
>
> while (errcnt--) {
> ...
> }
> if (errcnt == -1)
> return -EWHATEVER;
>
> Also "errcnt" is a bad name, it should be retry_cnt or something (or
> maybe it actually is counting errors?).  Also -1 is never a correct
> error code, please change all the -1 returns to something better.
>

Ok, I renamed to retry_cnt and changed all the -1 values to something better.


>> + /* Buffer size of AUX CH is 16 */
>> + if (count > 16)
>> + return -1;
>
> Just make a define so that you don't need to add comments about why 16
> is correct.
>
> if (count > SIZE_AUX_CH)
> return -EINVAL;
>

Added a define

>> + errcnt = 10;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, );
>> + if (!(val & SP_AUX_EN))
>> + break;
>> + usleep_range(1000, 2000);
>> + }
>> +
>> + if (!errcnt) {
>> + dev_err(dev,
>> + "failed to read DP AUX Channel Control Register 2\n");
>> + sp_reset_aux(anx78xx);
>> + return -1;
>> + }
>
> Off by one again.
>

Ack

>
>> +
>> + sp_reg_write(anx78xx, TX_P0, SP_AUX_ADDR_7_0_REG, SP_I2C_EXTRA_ADDR);
>> + sp_tx_aux_wr(anx78xx, offset);
>> + /* read 16 bytes (MOT = 1) */
>> + sp_tx_aux_rd(anx78xx, 0xf0 | DP_AUX_I2C_MOT | DP_AUX_I2C_READ);
>> +
>> + for (i = 0; i < 16; i++) {
>> + errcnt = 10;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_BUF_DATA_COUNT_REG,
>> + );
>> + if (val & SP_BUF_DATA_COUNT_MASK)
>> + break;
>> + usleep_range(2000, 4000);
>> + }
>> +
>> + if (!errcnt) {
>> + dev_err(dev,
>> + "failed to read DP Buffer Data Count 
>> Register\n");
>> + sp_reset_aux(anx78xx);
>> + return -1;
>> + }
>
> And here.
>

Ack

>> + errcnt = 10;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, );
>> + if (!(val & SP_AUX_EN))
>> + break;
>> + usleep_range(1000, 2000);
>> + }
>> +
>> + if (!errcnt) {
>> + dev_err(dev,
>> + "failed to read DP AUX Channel Control Register 2\n");
>> + sp_reset_aux(anx78xx);
>> + return -1;
>> + }
>
> Here.
>

Ack

>
>> +
>> + return 0;
>> +}
>> +
>> +static int sp_edid_block_checksum(const u8 *raw_edid)
>> +{
>> + int i;
>> + u8 csum = 0;
>> +
>> + for (i = 0; i < EDID_LENGTH; i++)
>> + csum += raw_edid[i];
>> +
>> + return csum;
>> +}
>> +
>> +static int sp_tx_edid_read(struct anx78xx *anx78xx)
>> +{
>> + struct device *dev = >client->dev;
>> + u8 val, last_block, offset = 0;
>> + u8 buf[16];
>> + int i, j, count;
>> +
>> + sp_tx_edid_read_initial(anx78xx);
>> + sp_reg_write(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL1_REG, 0x04);
>> + sp_reg_set_bits(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG,
>> + SP_AUX_EN | SP_ADDR_ONLY);
>> +
>> + if (sp_wait_aux_op_finish(anx78xx))
>> + return -1;
>> +
>> + sp_addronly_set(anx78xx, false);
>> +
>> + /* Read the number of blocks */
>> + sp_tx_aux_wr(anx78xx, 0x7e);
>> + sp_tx_aux_rd(anx78xx, DP_AUX_I2C_READ);
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_BUF_DATA0_REG, _block);
>> + dev_dbg(dev, "last EDID block is %d\n", last_block);
>> +
>> + /* FIXME: Why not just cap to 3 if the reported value is >3 */
>> + if (last_block > 3)
>> + last_block = 1;
>> +
>> + /* for every block */
>> + for (count = 0; count <= last_block; count++) {
>> + switch (count) {
>> + case 0:
>> + case 1:
>> + for (i = 0; i < 8; i++) {
>> + offset = (i + count * 8) * 16;
>> + if (sp_edid_read(anx78xx, offset, buf))
>> + return -1;

[PATCH] [media] hdmi: added functions for MPEG InfoFrames

[Enric Balletbo Serra]

Hello Thierry,

2015-11-19 12:51 GMT+01:00 Thierry Reding :
> On Tue, Nov 17, 2015 at 11:55:53PM +0100, Enric Balletbo Serra wrote:
>> Hello Thierry,
>>
>> 2015-11-17 13:55 GMT+01:00 Thierry Reding :
>> > On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
>> >> Hello Thierry,
>> >>
>> >> Many thanks for your comments.
>> >>
>> >> 2015-11-16 12:50 GMT+01:00 Thierry Reding :
>> >> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>> >> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes 
>> >> >> aspects of
>> >> >> the compressed video stream that were used to produce the uncompressed
>> >> >> video.
>> >> >>
>> >> >> The patch adds functions to work with MPEG InfoFrames.
>> >> >>
>> >> >> Signed-off-by: Enric Balletbo i Serra 
>> >> >> ---
>> >> >>  drivers/video/hdmi.c | 156 
>> >> >> +++
>> >> >>  include/linux/hdmi.h |  24 
>> >> >>  2 files changed, 180 insertions(+)
>> >> >
>> >> > According to the CEA specification a source is expected to send this
>> >> > type of infoframe once per video frame. I'm curious how you envision
>> >> > this to be ensured. Would hardware provide a mechanism to store this
>> >> > data and send the infoframe automatically? How would you ensure that
>> >> > updates sent to the hardware match the upcoming frame?
>> >> >
>> >>
>> >> To be honest I'm not sure if I have the full picture. In the use case
>> >> I'm trying there is a hardware mechanism to store the data and send
>> >> the infoframe through a "Packet Send Control Register".
>> >
>> > Okay, sounds like the hardware will automatically send out packets at
>> > the right time. That still leaves open the issue of how to ensure this
>> > is synchronized with userspace. Perhaps this could be done by attaching
>> > a property to a framebuffer, so that we'd know what exact frame the meta
>> > data is attached to and when to update the FIFOs for the infoframe.
>> >
>> > Usually it's a good idea to send this type of patch as part of a larger
>> > series precisely so that people can see how it is used. That should make
>> > it easier to see if this is good enough or needs some more thought on
>> > how to synchronize. Do you have any code that you could post that makes
>> > use of this new infoframe?
>> >
>>
>> I was thinking use this and other helpers in the anx7814 bridge
>> driver[1], I thought that this patch should go through another tree,
>> this is the reason why I send it separately, but If you want or you
>> prefer I can send as part of these patch series.
>>
>> [1] https://lkml.org/lkml/2015/11/13/284
>
> I haven't seen those patches yet. I should've been Cc'ed on those
> patches since I'm technically the maintainer of drm/bridge. Did the
> get_maintainer.pl script not list me?
>

Mmm, just checked and yes, get_maintainer list you, so probably I did
something getting the maintainers.
Sorry.

> In my opinion, it's usually a good idea to keep all dependencies in a
> single series, just so people get a better picture of what you're
> submitting. Of course that's just my opinion, somebody else may yell at
> you because they get Cc'ed on patches that they're not interested in...
>
> As for merging patches, it's usually best to let maintainers figure that
> out once the series is in good shape.
>
> Thierry

[PATCH] [media] hdmi: added functions for MPEG InfoFrames

[Enric Balletbo Serra]

Hello Thierry,

2015-11-17 13:55 GMT+01:00 Thierry Reding :
> On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
>> Hello Thierry,
>>
>> Many thanks for your comments.
>>
>> 2015-11-16 12:50 GMT+01:00 Thierry Reding :
>> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>> >> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
>> >> the compressed video stream that were used to produce the uncompressed
>> >> video.
>> >>
>> >> The patch adds functions to work with MPEG InfoFrames.
>> >>
>> >> Signed-off-by: Enric Balletbo i Serra 
>> >> ---
>> >>  drivers/video/hdmi.c | 156 
>> >> +++
>> >>  include/linux/hdmi.h |  24 
>> >>  2 files changed, 180 insertions(+)
>> >
>> > According to the CEA specification a source is expected to send this
>> > type of infoframe once per video frame. I'm curious how you envision
>> > this to be ensured. Would hardware provide a mechanism to store this
>> > data and send the infoframe automatically? How would you ensure that
>> > updates sent to the hardware match the upcoming frame?
>> >
>>
>> To be honest I'm not sure if I have the full picture. In the use case
>> I'm trying there is a hardware mechanism to store the data and send
>> the infoframe through a "Packet Send Control Register".
>
> Okay, sounds like the hardware will automatically send out packets at
> the right time. That still leaves open the issue of how to ensure this
> is synchronized with userspace. Perhaps this could be done by attaching
> a property to a framebuffer, so that we'd know what exact frame the meta
> data is attached to and when to update the FIFOs for the infoframe.
>
> Usually it's a good idea to send this type of patch as part of a larger
> series precisely so that people can see how it is used. That should make
> it easier to see if this is good enough or needs some more thought on
> how to synchronize. Do you have any code that you could post that makes
> use of this new infoframe?
>

I was thinking use this and other helpers in the anx7814 bridge
driver[1], I thought that this patch should go through another tree,
this is the reason why I send it separately, but If you want or you
prefer I can send as part of these patch series.

[1] https://lkml.org/lkml/2015/11/13/284

>> >> @@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char 
>> >> *level,
>> >>   frame->downmix_inhibit ? "Yes" : "No");
>> >>  }
>> >>
>> >> +static const char *hdmi_mpeg_picture_get_name(enum 
>> >> hdmi_mpeg_picture_type type)
>> >> +{
>> >> + switch (type) {
>> >> + case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
>> >> + return "Unknown";
>> >> + case HDMI_MPEG_PICTURE_TYPE_I:
>> >> + return "Intra-coded picture";
>> >> + case HDMI_MPEG_PICTURE_TYPE_B:
>> >> + return "Bi-predictive picture";
>> >> + case HDMI_MPEG_PICTURE_TYPE_P:
>> >> + return "Predicted picture";
>> >> + }
>> >
>> > I'd have chosen the slightly more canonical "I-Frame", "P-Frame",
>> > "B-Frame" here, but that's not a strong objection.
>> >
>>
>> I don't have any inconvenient to change, are the following names more
>> canonical ?
>>
>>HDMI_MPEG_UNKNOWN_FRAME = 0x00,
>>HDMI_MPEG_I_FRAME = 0x01,
>>HDMI_MPEG_B_FRAME = 0x02,
>>HDMI_MPEG_P_FRAME = 0x03,
>
> I wasn't very clear. What I meant was the names for the constants. At
> least personally I know immediately what is meant when I see "I-Frame",
> "P-Frame" or "B-Frame", whereas "Bi-predictive picture" needs more
> thinking.
>
Got it, I'll change only the names in next version, then.

> Thierry

Thanks,
Enric

[PATCH] [media] hdmi: added functions for MPEG InfoFrames

[Enric Balletbo Serra]

Hello Thierry,

Many thanks for your comments.

2015-11-16 12:50 GMT+01:00 Thierry Reding :
> On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
>> the compressed video stream that were used to produce the uncompressed
>> video.
>>
>> The patch adds functions to work with MPEG InfoFrames.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>  drivers/video/hdmi.c | 156 
>> +++
>>  include/linux/hdmi.h |  24 
>>  2 files changed, 180 insertions(+)
>
> According to the CEA specification a source is expected to send this
> type of infoframe once per video frame. I'm curious how you envision
> this to be ensured. Would hardware provide a mechanism to store this
> data and send the infoframe automatically? How would you ensure that
> updates sent to the hardware match the upcoming frame?
>

To be honest I'm not sure if I have the full picture. In the use case
I'm trying there is a hardware mechanism to store the data and send
the infoframe through a "Packet Send Control Register".

>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> [...]
>> @@ -435,6 +510,8 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void 
>> *buffer, size_t size)
>>   length = hdmi_vendor_any_infoframe_pack(>vendor,
>>   buffer, size);
>>   break;
>> + case HDMI_INFOFRAME_TYPE_MPEG:
>> + length = hdmi_mpeg_infoframe_pack(>mpeg, buffer, size);
>
> Missing "break;"?
>

Ack.

>> @@ -899,6 +978,41 @@ static void hdmi_audio_infoframe_log(const char *level,
>>   frame->downmix_inhibit ? "Yes" : "No");
>>  }
>>
>> +static const char *hdmi_mpeg_picture_get_name(enum hdmi_mpeg_picture_type 
>> type)
>> +{
>> + switch (type) {
>> + case HDMI_MPEG_PICTURE_TYPE_UNKNOWN:
>> + return "Unknown";
>> + case HDMI_MPEG_PICTURE_TYPE_I:
>> + return "Intra-coded picture";
>> + case HDMI_MPEG_PICTURE_TYPE_B:
>> + return "Bi-predictive picture";
>> + case HDMI_MPEG_PICTURE_TYPE_P:
>> + return "Predicted picture";
>> + }
>
> I'd have chosen the slightly more canonical "I-Frame", "P-Frame",
> "B-Frame" here, but that's not a strong objection.
>

I don't have any inconvenient to change, are the following names more
canonical ?

   HDMI_MPEG_UNKNOWN_FRAME = 0x00,
   HDMI_MPEG_I_FRAME = 0x01,
   HDMI_MPEG_B_FRAME = 0x02,
   HDMI_MPEG_P_FRAME = 0x03,



>> + return "Reserved";
>
> There really can't be another value here, so I think this should either
> return NULL or even go as far as let it crash. There should be no way
> for the invalid value to make it this far.
>

Ok.

>> +static int hdmi_mpeg_infoframe_unpack(struct hdmi_mpeg_infoframe *frame,
>> +  void *buffer)
>> +{
>> + u8 *ptr = buffer;
>> +
>> + if (ptr[0] != HDMI_INFOFRAME_TYPE_MPEG ||
>> + ptr[1] != 1 ||
>> + ptr[2] != HDMI_MPEG_INFOFRAME_SIZE) {
>> + return -EINVAL;
>> + }
>
> There's no need for the braces here.
>
>> @@ -314,6 +336,7 @@ union hdmi_vendor_any_infoframe {
>>   * @spd: spd infoframe
>>   * @vendor: union of all vendor infoframes
>>   * @audio: audio infoframe
>> + * @mpeg: mpeg infoframe
>
> s/mpeg/MPEG/
>

Ok.

> Thierry

I will send v2 after receiving your feedback again.

Best regards,
Enric

[PATCHv5 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

[Enric Balletbo Serra]

Hi Rob,

2015-11-13 15:38 GMT+01:00 Rob Herring :
> On Fri, Nov 13, 2015 at 01:01:02PM +0100, Enric Balletbo i Serra wrote:
>> Analogix Semiconductor develops analog and mixed-signal devices for digital
>> media and communications interconnect applications.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> Acked-by: Rob Herring 
>> ---
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 82d2ac9..8987ee8 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -22,6 +22,7 @@ ampire  Ampire Co., Ltd.
>>  ams  AMS AG
>>  amstaos  AMS-Taos Inc.
>>  apm  Applied Micro Circuits Corporation (APM)
>> +analogix Analogix Semiconductor, Inc.
>
> Not quite alphabetical order.
>

Yep, sorry, I think I introduced this mistake rebasing my patches  ...
I will fix in next version, thanks.

>>  aptina   Aptina Imaging
>>  arasan   Arasan Chip Systems
>>  arm  ARM Ltd.
>> --
>> 2.1.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv3 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Enric Balletbo Serra]

2015-09-10 18:35 GMT+02:00 Enric Balletbo i Serra :
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
>
> You can add support to your board with current binding.
>
> Example:
>
> anx7814: anx7814 at 38 {
> compatible = "analogix,anx7814";
> reg = <0x38>;
> pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
> };
>
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  .../devicetree/bindings/video/bridge/anx7814.txt   | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
>
> diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt 
> b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
> new file mode 100644
> index 000..a8cc746
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
> @@ -0,0 +1,22 @@
> +Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +---
> +
> +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> +designed for portable devices.
> +
> +Required properties:
> +
> + - compatible  : "analogix,anx7814"
> + - reg : I2C address of the device
> + - pd-gpios: Which GPIO to use for power down
> + - reset-gpios : Which GPIO to use for reset
> +
> +Example:
> +
> +   anx7814: anx7814 at 38 {
> +   compatible = "analogix,anx7814";
> +   reg = <0x38>;
> +   pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
> +   reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
> +   };
> +
> --
> 2.1.0
>

I saw after sending the series that there was some discussion here,
let me paste to not forget it.

> > No ports needed for describing data connections?
>
> IMHO I'm not sure if this is applicable here, in this case the bridge
> is transparent so it's not required another device node. For example,
> I've an evaluation board, whre I connect in one side an HDMI input
> signal an in the other side a DP monitor, the driver only configures
> the chip and waits for different events (cable plug, cable unplug, etc
> ..)

But what if the chip is connected to a display controller, for instance to the
HDMI output of an SoC ? Is that a use case for the hardware ?

[PATCHv2 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Enric Balletbo Serra]

Hi Rob,

2015-09-09 2:40 GMT+02:00 Rob Herring :
> On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
>> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
>> designed for portable devices.
>>
>> You can add support to your board with current binding.
>>
>> Example:
>>
>>   anx7814: anx7814 at 38 {
>>   compatible = "analogix,anx7814";
>>   reg = <0x38>;
>>   pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
>>   reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
>>   };
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>  .../devicetree/bindings/video/anx7814.txt  | 22 
>> ++
>>  1 file changed, 22 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/video/anx7814.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/anx7814.txt 
>> b/Documentation/devicetree/bindings/video/anx7814.txt
>> new file mode 100644
>> index 000..a8cc746
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/anx7814.txt
>> @@ -0,0 +1,22 @@
>> +Analogix ANX7814 SlimPort (Full-HD Transmitter)
>> +---
>> +
>> +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
>> +designed for portable devices.
>> +
>> +Required properties:
>> +
>> + - compatible: "analogix,anx7814"
>> + - reg   : I2C address of the device
>> + - pd-gpios  : Which GPIO to use for power down
>> + - reset-gpios   : Which GPIO to use for reset
>> +
>> +Example:
>> +
>> + anx7814: anx7814 at 38 {
>> + compatible = "analogix,anx7814";
>> + reg = <0x38>;
>> + pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
>> + reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
>
> No ports needed for describing data connections?
>

IMHO I'm not sure if this is applicable here, in this case the bridge
is transparent so it's not required another device node. For example,
I've an evaluation board, whre I connect in one side an HDMI input
signal an in the other side a DP monitor, the driver only configures
the chip and waits for different events (cable plug, cable unplug, etc
..)

Cheers,
Enric

> Rob
>
>> + };
>> +
>>
>

[PATCH 3/3] staging: slimport: Add anx7814 driver support by analogix.

[Enric Balletbo Serra]

Hi Dan,

Many thanks for this first review.

2015-09-09 5:38 GMT+02:00 Daniel Kurtz :
> Hi Eric,
>
> Thanks for starting to upstream this Analogix Slimport driver!
> As Greg says, please move this driver to its intended directory, I presume:
> /drivers/gpu/drm/bridge
>

I sent yesterday another version moving the driver. I'm not sure if
you were aware. In the second version I moved the driver to
drivers/gpu/drm/i2c instead of drivers/gpu/drm/bridge. Do you think
bridge is the better place ? If so I'll move to bridge directory. I
had doubts about it.

> And when you submit, use get_maintainer.pl to add the proper reviewers
> and lists.
> At present, you have no DRM folks, nor dri-devel, so you probably
> won't receive any additional feedback on this version, since the
> relevant folks have not seen your emails.
>
> Some more very detailed feedback inline...
>
> On Sep 7, 2015 05:15, "Enric Balletbo i Serra"  wrote:
>>
>> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
>> designed for portable devices.
>>
>> This driver adds initial support and supports HDMI to DP pass-through mode.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>  drivers/staging/Kconfig|2 +
>>  drivers/staging/Makefile   |1 +
>>  drivers/staging/slimport/Kconfig   |7 +
>>  drivers/staging/slimport/Makefile  |4 +
>>  drivers/staging/slimport/slimport.c|  301 +++
>>  drivers/staging/slimport/slimport.h|   49 +
>>  drivers/staging/slimport/slimport_tx_drv.c | 3293 
>> 
>>  drivers/staging/slimport/slimport_tx_drv.h |  254 +++
>>  drivers/staging/slimport/slimport_tx_reg.h |  786 +++
>>  9 files changed, 4697 insertions(+)
>>  create mode 100644 drivers/staging/slimport/Kconfig
>>  create mode 100644 drivers/staging/slimport/Makefile
>>  create mode 100644 drivers/staging/slimport/slimport.c
>>  create mode 100644 drivers/staging/slimport/slimport.h
>>  create mode 100644 drivers/staging/slimport/slimport_tx_drv.c
>>  create mode 100644 drivers/staging/slimport/slimport_tx_drv.h
>>  create mode 100644 drivers/staging/slimport/slimport_tx_reg.h
>>
>> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
>> index e29293c..24ccd7c 100644
>> --- a/drivers/staging/Kconfig
>> +++ b/drivers/staging/Kconfig
>> @@ -110,4 +110,6 @@ source "drivers/staging/wilc1000/Kconfig"
>>
>>  source "drivers/staging/most/Kconfig"
>>
>> +source "drivers/staging/slimport/Kconfig"
>> +
>>  endif # STAGING
>> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
>> index 50824dd..942e886 100644
>> --- a/drivers/staging/Makefile
>> +++ b/drivers/staging/Makefile
>> @@ -47,3 +47,4 @@ obj-$(CONFIG_FB_TFT)  += fbtft/
>>  obj-$(CONFIG_FSL_MC_BUS)   += fsl-mc/
>>  obj-$(CONFIG_WILC1000) += wilc1000/
>>  obj-$(CONFIG_MOST) += most/
>> +obj-$(CONFIG_SLIMPORT_ANX78XX) += slimport/
>> diff --git a/drivers/staging/slimport/Kconfig 
>> b/drivers/staging/slimport/Kconfig
>> new file mode 100644
>> index 000..f5233ef
>> --- /dev/null
>> +++ b/drivers/staging/slimport/Kconfig
>> @@ -0,0 +1,7 @@
>> +config SLIMPORT_ANX78XX
>
> I think the "SLIMPORT_" here is a bit overkill, and just adds to
> confusion over what name to use where.  I'd recommend just
> CONFIG_ANX78XX.
>
> Likewise, for consistency, the rename the files as "anx78xx*" instead
> of "slimport*".
>
>> +   tristate "Analogix Slimport transmitter ANX78XX support"
>> +   help
>> +   Slimport Transmitter is a HD video transmitter chip
>> +   over micro-USB connector for smartphone device.
>> +
>> +
>> diff --git a/drivers/staging/slimport/Makefile 
>> b/drivers/staging/slimport/Makefile
>> new file mode 100644
>> index 000..9bb6ce2
>> --- /dev/null
>> +++ b/drivers/staging/slimport/Makefile
>> @@ -0,0 +1,4 @@
>> +obj-${CONFIG_SLIMPORT_ANX78XX} :=  anx78xx.o
>> +
>> +anx78xx-y := slimport.o
>> +anx78xx-y += slimport_tx_drv.o
>> diff --git a/drivers/staging/slimport/slimport.c 
>> b/drivers/staging/slimport/slimport.c
>> new file mode 100644
>> index 000..95c5114
>> --- /dev/null
>> +++ b/drivers/staging/slimport/slimport.c
>> @@ -0,0 +1,301 @@
>> +/*
>> + * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include