[PATCH v2] dt-bindings: display: bridge: tc358768: Change maintainer information

[Peter Ujfalusi]

My employment with TI is coming to an end and I will not have access to
the board where this bridge is connected to and I will also loose access to
the manual of the chip.

Add the missing copyright information, author and change the maintainer to
Sam Ravnborg (thank you for volenteering!)

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml  | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
index c036a75db8f7..c08fd42be2d0 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Texas Instruments Incorporated
+# Author: Peter Ujfalusi 
 %YAML 1.2
 ---
 $id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
@@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
 
 maintainers:
-  - Peter Ujfalusi 
+  - Sam Ravnborg 
 
 description: |
   The TC358768/TC358778 is bridge device which converts RGB to DSI.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

[Peter Ujfalusi]

Hi Sam,

On 17/12/2020 19.25, Sam Ravnborg wrote:
>>> dtschema/dtc warnings/errors:
>>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>>>  'maintainers' is a required property
>>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>>>  ignoring, error in schema: 
>>> warning: no schema found in file: 
>>> ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>>
>> Right, so it is not that easy to not been able to maintain this... :o
>>
>> Who should be documented as maintainer?
>> Andrzej, Neil, David or Daniel?
> 
> I have no problem being listed as maintainer despite my very limited
> knowledge on the HW. So unless you end up volunteering then just
> add me.

thank you. it is not easy to give up on something one has spent time on,
but without the hardware and manual it would be not right to just move
it to my private email as I did for the DMA and Audio drivers:

https://lore.kernel.org/lkml/20201215130512.8753-1-peter.ujfal...@ti.com/

https://lore.kernel.org/lkml/20201215131348.11282-1-peter.ujfal...@ti.com/

I'll send v2 as may last patch from ti.com

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

[Peter Ujfalusi]

On 15/12/2020 16.26, Rob Herring wrote:
> On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote:
>> My employment with TI is coming to an end and I will not have access to
>> the board where this bridge is connected to.
>>
>> It is better to remove a soon bouncing email address.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml   | 3 ---
>>  1 file changed, 3 deletions(-)
>>
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>  'maintainers' is a required property
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>  ignoring, error in schema: 
> warning: no schema found in file: 
> ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml

Right, so it is not that easy to not been able to maintain this... :o

Who should be documented as maintainer?
Andrzej, Neil, David or Daniel?

I will have no access to the EVM (I no longer have) and the
documentation is going to be wiped along with the disk as well...

> See https://patchwork.ozlabs.org/patch/1416419
> 
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit.
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

[Peter Ujfalusi]

My employment with TI is coming to an end and I will not have access to
the board where this bridge is connected to.

It is better to remove a soon bouncing email address.

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml   | 3 ---
 1 file changed, 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
index c036a75db8f7..454ab8032b97 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -6,9 +6,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 
 title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
 
-maintainers:
-  - Peter Ujfalusi 
-
 description: |
   The TC358768/TC358778 is bridge device which converts RGB to DSI.
 
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH] drm: xlnx: Use dma_request_chan for DMA channel request

[Peter Ujfalusi]

There is no need to use the of_dma_request_slave_channel() directly as
dma_request_chan() is going to try to get the channel via OF as well.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 98bd48f13fd1..a4405d081aca 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1316,8 +1315,7 @@ static int zynqmp_disp_layer_request_dma(struct 
zynqmp_disp *disp,
 
snprintf(dma_channel_name, sizeof(dma_channel_name),
 "%s%u", dma_names[layer->id], i);
-   dma->chan = of_dma_request_slave_channel(disp->dev->of_node,
-dma_channel_name);
+   dma->chan = dma_request_chan(disp->dev, dma_channel_name);
if (IS_ERR(dma->chan)) {
dev_err(disp->dev, "failed to request dma channel\n");
ret = PTR_ERR(dma->chan);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 02/13] backlight: add backlight_is_blank()

[Peter Ujfalusi]

On 01/06/2020 9.51, Sam Ravnborg wrote:
> The backlight support has two properties that express the state:
> - power
> - state
> 
> It is un-documented and easy to get wrong.
> Add backlight_is_blank() helper to make it simpler
> for drivers to get the check of the state correct.
> 
> A lot of drivers also includes checks for fb_blank.
> This check is redundant when the state is checked
> and thus not needed in this helper function.
> But added anyway to avoid introducing subtle bugs
> due to the creative use of fb_blank in some drivers.
> Introducing this helper will for some drivers results in
> added support for fb_blank. This will be a change in
> functionality, which will improve the backlight driver.
> 
> Rolling out this helper to all relevant backlight drivers
> will eliminate almost all accesses to fb_blank.

Reviewed-by: Peter Ujfalusi 

> 
> v3:
>   - Clarified that the fb_blank support in
> backlight_is_blank() may result in functionality
> changes for the users (Emil)
> 
> v2:
>   - Added fb_blank condition (Daniel)
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Daniel Thompson 
> Cc: Emil Velikov 
> Cc: Daniel Vetter 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> ---
>  include/linux/backlight.h | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index c7d6b2e8c3b5..a0a083b35c47 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -175,6 +175,25 @@ static inline void backlight_put(struct backlight_device 
> *bd)
>   put_device(>dev);
>  }
>  
> +/**
> + * backlight_is_blank - Return true if display is expected to be blank
> + * @bd: the backlight device
> + *
> + * Display is expected to be blank if any of these is true::
> + *
> + *   1) if power in not UNBLANK
> + *   2) if fb_blank is not UNBLANK
> + *   3) if state indicate BLANK or SUSPENDED
> + *
> + * Returns true if display is expected to be blank, false otherwise.
> + */
> +static inline bool backlight_is_blank(struct backlight_device *bd)
> +{
> + return bd->props.power != FB_BLANK_UNBLANK ||
> +bd->props.fb_blank != FB_BLANK_UNBLANK ||
> +bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK);
> +}
> +
>  extern struct backlight_device *backlight_device_register(const char *name,
>   struct device *dev, void *devdata, const struct backlight_ops *ops,
>   const struct backlight_properties *props);
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


pEpkey.asc
Description: application/pgp-keys
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 13/13] backlight: use backlight_is_blank() in all backlight drivers

[Peter Ujfalusi]

On 01/06/2020 9.52, Sam Ravnborg wrote:
> Replaces the open-coded checks of the state etc.,
> with the backlight_is_blank() helper.
> This increases readability of the code and align
> the functionality across the drivers.

Reviewed-by: Peter Ujfalusi 

> v3:
>   - Dropped as3711_bl, it will be modified in another patch
> 
> v2:
>   - Fixed so changelog is readable
> 
> Signed-off-by: Sam Ravnborg 
> Reviewed-by: Daniel Thompson 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Cc: Michael Hennerich 
> Cc: Support Opensource 
> Cc: Thierry Reding 
> Cc: "Uwe Kleine-König" 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: patc...@opensource.cirrus.com
> ---
>  drivers/video/backlight/88pm860x_bl.c|  8 +---
>  drivers/video/backlight/adp5520_bl.c |  5 +
>  drivers/video/backlight/adp8860_bl.c |  5 +
>  drivers/video/backlight/adp8870_bl.c |  5 +
>  drivers/video/backlight/bd6107.c |  4 +---
>  drivers/video/backlight/corgi_lcd.c  |  5 +
>  drivers/video/backlight/cr_bllcd.c   | 22 +++---
>  drivers/video/backlight/da903x_bl.c  |  8 +---
>  drivers/video/backlight/ep93xx_bl.c  |  3 +--
>  drivers/video/backlight/gpio_backlight.c |  4 +---
>  drivers/video/backlight/hp680_bl.c   |  4 +---
>  drivers/video/backlight/jornada720_bl.c  |  2 +-
>  drivers/video/backlight/kb3886_bl.c  |  4 +---
>  drivers/video/backlight/led_bl.c |  4 +---
>  drivers/video/backlight/lm3533_bl.c  |  4 +---
>  drivers/video/backlight/locomolcd.c  |  4 +---
>  drivers/video/backlight/lv5207lp.c   |  4 +---
>  drivers/video/backlight/max8925_bl.c |  8 +---
>  drivers/video/backlight/pwm_bl.c |  4 +---
>  drivers/video/backlight/qcom-wled.c  |  4 +---
>  drivers/video/backlight/tps65217_bl.c|  4 +---
>  drivers/video/backlight/wm831x_bl.c  |  8 +---
>  22 files changed, 28 insertions(+), 95 deletions(-)
> 
> diff --git a/drivers/video/backlight/88pm860x_bl.c 
> b/drivers/video/backlight/88pm860x_bl.c
> index 20d96a5ac384..162c83ab0f5a 100644
> --- a/drivers/video/backlight/88pm860x_bl.c
> +++ b/drivers/video/backlight/88pm860x_bl.c
> @@ -123,13 +123,7 @@ static int pm860x_backlight_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.state & BL_CORE_SUSPENDED)
> + if (backlight_is_blank(bl))
>   brightness = 0;
>  
>   return pm860x_backlight_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp5520_bl.c 
> b/drivers/video/backlight/adp5520_bl.c
> index 0f63f76723a5..d817b0d95c9d 100644
> --- a/drivers/video/backlight/adp5520_bl.c
> +++ b/drivers/video/backlight/adp5520_bl.c
> @@ -67,10 +67,7 @@ static int adp5520_bl_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> + if (backlight_is_blank(bl))
>   brightness = 0;
>  
>   return adp5520_bl_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp8860_bl.c 
> b/drivers/video/backlight/adp8860_bl.c
> index 19968104fc47..a0ce2a3701fa 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -363,10 +363,7 @@ static int adp8860_bl_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> + if (backlight_is_blank(bl))
>   brightness = 0;
>  
>   return adp8860_bl_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp8870_bl.c 
> b/drivers/video/backlight/adp8870_bl.c
> index 4c0032010cfe..ae4269fdb189 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -401,10 +401,7 @@ static int adp8870_bl_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> + if (backlight_is_blank(bl))
> 

Re: [PATCH v2 03/16] backlight: add backlight_is_blank()

[Peter Ujfalusi]

On 17/05/2020 22.01, Sam Ravnborg wrote:
> The backlight support has two properties that express the state:
> - power
> - state
> 
> It is un-documented and easy to get wrong.
> Add backlight_is_blank() helper to make it simpler for drivers
> to get the check of the state correct.
> 
> A lot of drivers also includes checks for fb_blank.
> This check is redundant when the state is checked
> and thus not needed in this helper function.
> But added anyway to avoid introducing subtle bug
> due to the creative use in some drivers.
> 
> Rolling out this helper to all relevant backlight drivers
> will eliminate almost all accesses to fb_blank.

Reviewed-by: Peter Ujfalusi 

> v2:
>   - Added fb_blank condition (Daniel)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> ---
>  include/linux/backlight.h | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index c7d6b2e8c3b5..a0a083b35c47 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -175,6 +175,25 @@ static inline void backlight_put(struct backlight_device 
> *bd)
>   put_device(>dev);
>  }
>  
> +/**
> + * backlight_is_blank - Return true if display is expected to be blank
> + * @bd: the backlight device
> + *
> + * Display is expected to be blank if any of these is true::
> + *
> + *   1) if power in not UNBLANK
> + *   2) if fb_blank is not UNBLANK
> + *   3) if state indicate BLANK or SUSPENDED
> + *
> + * Returns true if display is expected to be blank, false otherwise.
> + */
> +static inline bool backlight_is_blank(struct backlight_device *bd)
> +{
> + return bd->props.power != FB_BLANK_UNBLANK ||
> +bd->props.fb_blank != FB_BLANK_UNBLANK ||
> +bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK);
> +}
> +
>  extern struct backlight_device *backlight_device_register(const char *name,
>   struct device *dev, void *devdata, const struct backlight_ops *ops,
>   const struct backlight_properties *props);
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


pEpkey.asc
Description: application/pgp-keys
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 16/16] backlight: use backlight_is_blank() in all backlight drivers

[Peter Ujfalusi]

On 28/05/2020 16.39, Peter Ujfalusi wrote:
> Hi Sam,
> 
> On 17/05/2020 22.01, Sam Ravnborg wrote:
>> Replaces the open-coded checks of the state etc.,
>> with the backlight_is_blank() helper.
>> This increases readability of the code and align
>> the functionality across the drivers.
> 
> Thanks for the cleanup in with the series!
> 
> Checked gpio/pwm/led backlight drivers mostly:
> Reviewed-by: Peter Ujfalusi 

Interesting, I had a typo in my e-mail address :o
Let's try again:
Reviewed-by: Peter Ujfalusi 

> 
>> v2:
>>   - Fixed so changelog is readable
>>
>> Signed-off-by: Sam Ravnborg 
>> Cc: Lee Jones 
>> Cc: Daniel Thompson 
>> Cc: Jingoo Han 
>> Cc: Michael Hennerich 
>> Cc: Support Opensource 
>> Cc: Thierry Reding 
>> Cc: "Uwe Kleine-König" 
>> Cc: Andy Gross 
>> Cc: Bjorn Andersson 
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: patc...@opensource.cirrus.com
>> ---
>>  drivers/video/backlight/88pm860x_bl.c|  8 +---
>>  drivers/video/backlight/adp5520_bl.c |  5 +
>>  drivers/video/backlight/adp8860_bl.c |  5 +
>>  drivers/video/backlight/adp8870_bl.c |  5 +
>>  drivers/video/backlight/as3711_bl.c  |  8 +++-
>>  drivers/video/backlight/bd6107.c |  4 +---
>>  drivers/video/backlight/corgi_lcd.c  |  5 +
>>  drivers/video/backlight/cr_bllcd.c   | 22 +++---
>>  drivers/video/backlight/da903x_bl.c  |  8 +---
>>  drivers/video/backlight/ep93xx_bl.c  |  3 +--
>>  drivers/video/backlight/gpio_backlight.c |  4 +---
>>  drivers/video/backlight/hp680_bl.c   |  4 +---
>>  drivers/video/backlight/jornada720_bl.c  |  2 +-
>>  drivers/video/backlight/kb3886_bl.c  |  4 +---
>>  drivers/video/backlight/led_bl.c |  4 +---
>>  drivers/video/backlight/lm3533_bl.c  |  4 +---
>>  drivers/video/backlight/locomolcd.c  |  4 +---
>>  drivers/video/backlight/lv5207lp.c   |  4 +---
>>  drivers/video/backlight/max8925_bl.c |  8 +---
>>  drivers/video/backlight/pwm_bl.c |  4 +---
>>  drivers/video/backlight/qcom-wled.c  |  4 +---
>>  drivers/video/backlight/tps65217_bl.c|  4 +---
>>  drivers/video/backlight/wm831x_bl.c  |  8 +---
>>  23 files changed, 31 insertions(+), 100 deletions(-)
>>
>> diff --git a/drivers/video/backlight/88pm860x_bl.c 
>> b/drivers/video/backlight/88pm860x_bl.c
>> index 20d96a5ac384..162c83ab0f5a 100644
>> --- a/drivers/video/backlight/88pm860x_bl.c
>> +++ b/drivers/video/backlight/88pm860x_bl.c
>> @@ -123,13 +123,7 @@ static int pm860x_backlight_update_status(struct 
>> backlight_device *bl)
>>  {
>>  int brightness = bl->props.brightness;
>>  
>> -if (bl->props.power != FB_BLANK_UNBLANK)
>> -brightness = 0;
>> -
>> -if (bl->props.fb_blank != FB_BLANK_UNBLANK)
>> -brightness = 0;
>> -
>> -if (bl->props.state & BL_CORE_SUSPENDED)
>> +if (backlight_is_blank(bl))
>>  brightness = 0;
>>  
>>  return pm860x_backlight_set(bl, brightness);
>> diff --git a/drivers/video/backlight/adp5520_bl.c 
>> b/drivers/video/backlight/adp5520_bl.c
>> index 0f63f76723a5..d817b0d95c9d 100644
>> --- a/drivers/video/backlight/adp5520_bl.c
>> +++ b/drivers/video/backlight/adp5520_bl.c
>> @@ -67,10 +67,7 @@ static int adp5520_bl_update_status(struct 
>> backlight_device *bl)
>>  {
>>  int brightness = bl->props.brightness;
>>  
>> -if (bl->props.power != FB_BLANK_UNBLANK)
>> -brightness = 0;
>> -
>> -if (bl->props.fb_blank != FB_BLANK_UNBLANK)
>> +if (backlight_is_blank(bl))
>>  brightness = 0;
>>  
>>  return adp5520_bl_set(bl, brightness);
>> diff --git a/drivers/video/backlight/adp8860_bl.c 
>> b/drivers/video/backlight/adp8860_bl.c
>> index 19968104fc47..a0ce2a3701fa 100644
>> --- a/drivers/video/backlight/adp8860_bl.c
>> +++ b/drivers/video/backlight/adp8860_bl.c
>> @@ -363,10 +363,7 @@ static int adp8860_bl_update_status(struct 
>> backlight_device *bl)
>>  {
>>  int brightness = bl->props.brightness;
>>  
>> -if (bl->props.power != FB_BLANK_UNBLANK)
>> -brightness = 0;
>> -
>> -if (bl->props.fb_blank != FB_BLANK_UNBLANK)
>> +if (backlight_is_blank(bl))
>>  brightness = 0;
>>  
>>  return adp8860_bl_set(bl, brightness);
&g

Re: [PATCH v2 16/16] backlight: use backlight_is_blank() in all backlight drivers

[Peter Ujfalusi]

Hi Sam,

On 17/05/2020 22.01, Sam Ravnborg wrote:
> Replaces the open-coded checks of the state etc.,
> with the backlight_is_blank() helper.
> This increases readability of the code and align
> the functionality across the drivers.

Thanks for the cleanup in with the series!

Checked gpio/pwm/led backlight drivers mostly:
Reviewed-by: Peter Ujfalusi 

> v2:
>   - Fixed so changelog is readable
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Cc: Michael Hennerich 
> Cc: Support Opensource 
> Cc: Thierry Reding 
> Cc: "Uwe Kleine-König" 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: patc...@opensource.cirrus.com
> ---
>  drivers/video/backlight/88pm860x_bl.c|  8 +---
>  drivers/video/backlight/adp5520_bl.c |  5 +
>  drivers/video/backlight/adp8860_bl.c |  5 +
>  drivers/video/backlight/adp8870_bl.c |  5 +
>  drivers/video/backlight/as3711_bl.c  |  8 +++-
>  drivers/video/backlight/bd6107.c |  4 +---
>  drivers/video/backlight/corgi_lcd.c  |  5 +
>  drivers/video/backlight/cr_bllcd.c   | 22 +++---
>  drivers/video/backlight/da903x_bl.c  |  8 +---
>  drivers/video/backlight/ep93xx_bl.c  |  3 +--
>  drivers/video/backlight/gpio_backlight.c |  4 +---
>  drivers/video/backlight/hp680_bl.c   |  4 +---
>  drivers/video/backlight/jornada720_bl.c  |  2 +-
>  drivers/video/backlight/kb3886_bl.c  |  4 +---
>  drivers/video/backlight/led_bl.c |  4 +---
>  drivers/video/backlight/lm3533_bl.c  |  4 +---
>  drivers/video/backlight/locomolcd.c  |  4 +---
>  drivers/video/backlight/lv5207lp.c   |  4 +---
>  drivers/video/backlight/max8925_bl.c |  8 +---
>  drivers/video/backlight/pwm_bl.c |  4 +---
>  drivers/video/backlight/qcom-wled.c  |  4 +---
>  drivers/video/backlight/tps65217_bl.c|  4 +---
>  drivers/video/backlight/wm831x_bl.c  |  8 +---
>  23 files changed, 31 insertions(+), 100 deletions(-)
> 
> diff --git a/drivers/video/backlight/88pm860x_bl.c 
> b/drivers/video/backlight/88pm860x_bl.c
> index 20d96a5ac384..162c83ab0f5a 100644
> --- a/drivers/video/backlight/88pm860x_bl.c
> +++ b/drivers/video/backlight/88pm860x_bl.c
> @@ -123,13 +123,7 @@ static int pm860x_backlight_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.state & BL_CORE_SUSPENDED)
> + if (backlight_is_blank(bl))
>   brightness = 0;
>  
>   return pm860x_backlight_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp5520_bl.c 
> b/drivers/video/backlight/adp5520_bl.c
> index 0f63f76723a5..d817b0d95c9d 100644
> --- a/drivers/video/backlight/adp5520_bl.c
> +++ b/drivers/video/backlight/adp5520_bl.c
> @@ -67,10 +67,7 @@ static int adp5520_bl_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> + if (backlight_is_blank(bl))
>   brightness = 0;
>  
>   return adp5520_bl_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp8860_bl.c 
> b/drivers/video/backlight/adp8860_bl.c
> index 19968104fc47..a0ce2a3701fa 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -363,10 +363,7 @@ static int adp8860_bl_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> + if (backlight_is_blank(bl))
>   brightness = 0;
>  
>   return adp8860_bl_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp8870_bl.c 
> b/drivers/video/backlight/adp8870_bl.c
> index 4c0032010cfe..ae4269fdb189 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -401,10 +401,7 @@ static int adp8870_bl_update_status(struct 
> backlight_device *bl)
>  {
>   int brightness = bl->props.brightness;
>  
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
&g

Re: [PATCH] drm/bridge: sii902x: Select SND_SOC_HDMI_CODEC if SND_SOC is configured

[Peter Ujfalusi]

On 29/11/2019 17.23, Jyri Sarha wrote:
> To enable HDMI audio the SND_SOC_HDMI_CODEC needs to be
> configured. Enable HDMI audio by selecting SND_SOC_HDMI_CODEC if
> SND_SOC is configured. SND_SOC_HDMI_CODEC has no config menu entry and
> should be selected atomatically by the drivers using it.

Reviewed-by: Peter Ujfalusi 

> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/bridge/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 26ff07ad287b..0a60a56ce6dc 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -118,6 +118,7 @@ config DRM_SII902X
>   select DRM_KMS_HELPER
>   select REGMAP_I2C
>   select I2C_MUX
> + select SND_SOC_HDMI_CODEC if SND_SOC
>   ---help---
> Silicon Image sii902x bridge chip driver.
>  
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

[Peter Ujfalusi]

Hi,

Changes since v3:
- bindings/example: Fixed the node name
- bindings/example: Added include for GPIO_ACTIVE_LOW and fixed up the gpio
binding
- driver: Moved the label for goto in tc358768_calc_pll()
- driver: Replaced the refcounting of enabled with a simple bool as hw_enable()
  is only called from one place (tc358768_bridge_pre_enable)
- driver: Added Reviewed-by from Andrzej

Changes since v2:
- Implement pre_enable and post_disbale callbacks and move code from enable and
  disable callbacks.
- hw_enable/disable is removed from tc358768_dsi_host_transfer()
- Defines for DSI_CONFW accesses
- breakout from the loops  (the check for it) is moved one level up in
  tc358768_calc_pll()

Changes since v1:
DT bindings document:
- Removed MaxItems for the regulators
- additionalProperties: false added to port@1

Driver:
- Year is now 2020
- Includes shorted
- The three letter members of the private struct documented 0 they are named as
  in the datasheet
- Error handling for the IO functions is following what sil-sii8620.c does
- regmap regcache is disabled along with refcache_sync() and volatile callback
  for regmap
- The hw enable and disable functions got separated
- Taken the suggested simplifactions from Andrzej for tc358768_calc_pll() and
  tc358768_dsi_host_transfer()
- The driver no longer stores the drm_display_mode, it relies on
  priv->bridge.encoder->crtc->state->adjusted_mode where it needs it
- tc358768_calc_pll() can be used for verification only to not modify the state
- refcounting added for hw enable state as a dsi transfer was shutting down the
  bridge when it was already enabled.

Tested on top of drm-next + LED backlight patches + DT patches on dra7-evm with
osd101t2045 (panel-simple) and osd101t2587 panel drivers.

Cover letter from v1:
TC358768 is a parallel RGB to MIPI DSI bridge.

The initial driver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.

Regards,
Peter
---
Peter Ujfalusi (2):
  dt-bindings: display: bridge: Add documentation for Toshiba tc358768
  drm/bridge: Add tc358768 driver

 .../display/bridge/toshiba,tc358768.yaml  |  159 +++
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/tc358768.c | 1044 +
 4 files changed, 1214 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

[Peter Ujfalusi]

TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.

Signed-off-by: Peter Ujfalusi 
---
 .../display/bridge/toshiba,tc358768.yaml  | 159 ++
 1 file changed, 159 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
new file mode 100644
index ..c036a75db8f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
+
+maintainers:
+  - Peter Ujfalusi 
+
+description: |
+  The TC358768/TC358778 is bridge device which converts RGB to DSI.
+
+properties:
+  compatible:
+enum:
+  - toshiba,tc358768
+  - toshiba,tc358778
+
+  reg:
+maxItems: 1
+description: base I2C address of the device
+
+  reset-gpios:
+maxItems: 1
+description: GPIO connected to active low RESX pin
+
+  vddc-supply:
+description: Regulator for 1.2V internal core power.
+
+  vddmipi-supply:
+description: Regulator for 1.2V for the MIPI.
+
+  vddio-supply:
+description: Regulator for 1.8V - 3.3V IO power.
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: refclk
+
+  ports:
+type: object
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+additionalProperties: false
+
+description: |
+  Video port for RGB input
+
+properties:
+  reg:
+const: 0
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  data-lines:
+enum: [ 16, 18, 24 ]
+
+  remote-endpoint: true
+
+required:
+  - reg
+
+  port@1:
+type: object
+additionalProperties: false
+
+description: |
+  Video port for DSI output (panel or connector).
+
+properties:
+  reg:
+const: 1
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  remote-endpoint: true
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - vddc-supply
+  - vddmipi-supply
+  - vddio-supply
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+i2c1 {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  dsi_bridge: dsi-bridge@e {
+compatible = "toshiba,tc358768";
+reg = <0xe>;
+
+clocks = <_refclk>;
+clock-names = "refclk";
+
+reset-gpios = <_display_board 0 GPIO_ACTIVE_LOW>;
+
+vddc-supply = <_2d>;
+vddmipi-supply = <_2d>;
+vddio-supply = <_3d>;
+
+dsi_bridge_ports: ports {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  port@0 {
+reg = <0>;
+rgb_in: endpoint {
+  remote-endpoint = <_out>;
+  data-lines = <24>;
+};
+  };
+
+  port@1 {
+reg = <1>;
+dsi_out: endpoint {
+  remote-endpoint = <_in>;
+};
+  };
+};
+  };
+};
+
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

Add basic support for the Toshiba TC358768 RGB to DSI bridge.
Not all the features of the TC358768 is implemented by the initial driver:
MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.

Only write is implemented for mipi_dsi_host_ops.transfer.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/tc358768.c | 1044 +
 3 files changed, 1055 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 0b9ca5862455..3fef3513bdd0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767
---help---
  Toshiba TC358767 eDP bridge chip driver.
 
+config DRM_TOSHIBA_TC358768
+   tristate "Toshiba TC358768 MIPI DSI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   help
+ Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver.
+
 config DRM_TI_TFP410
tristate "TI TFP410 DVI/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cd16ce830270..06fc265de0ef 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
new file mode 100644
index ..da7af03256f6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -0,0 +1,1044 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Global (16-bit addressable) */
+#define TC358768_CHIPID0x
+#define TC358768_SYSCTL0x0002
+#define TC358768_CONFCTL   0x0004
+#define TC358768_VSDLY 0x0006
+#define TC358768_DATAFMT   0x0008
+#define TC358768_GPIOEN0x000E
+#define TC358768_GPIODIR   0x0010
+#define TC358768_GPIOIN0x0012
+#define TC358768_GPIOOUT   0x0014
+#define TC358768_PLLCTL0   0x0016
+#define TC358768_PLLCTL1   0x0018
+#define TC358768_CMDBYTE   0x0022
+#define TC358768_PP_MISC   0x0032
+#define TC358768_DSITX_DT  0x0050
+#define TC358768_FIFOSTATUS0x00F8
+
+/* Debug (16-bit addressable) */
+#define TC358768_VBUFCTRL  0x00E0
+#define TC358768_DBG_WIDTH 0x00E2
+#define TC358768_DBG_VBLANK0x00E4
+#define TC358768_DBG_DATA  0x00E8
+
+/* TX PHY (32-bit addressable) */
+#define TC358768_CLW_DPHYCONTTX0x0100
+#define TC358768_D0W_DPHYCONTTX0x0104
+#define TC358768_D1W_DPHYCONTTX0x0108
+#define TC358768_D2W_DPHYCONTTX0x010C
+#define TC358768_D3W_DPHYCONTTX0x0110
+#define TC358768_CLW_CNTRL 0x0140
+#define TC358768_D0W_CNTRL 0x0144
+#define TC358768_D1W_CNTRL 0x0148
+#define TC358768_D2W_CNTRL 0x014C
+#define TC358768_D3W_CNTRL 0x0150
+
+/* TX PPI (32-bit addressable) */
+#define TC358768_STARTCNTRL0x0204
+#define TC358768_DSITXSTATUS   0x0208
+#define TC358768_LINEINITCNT   0x0210
+#define TC358768_LPTXTIMECNT   0x0214
+#define TC358768_TCLK_HEADERCNT0x0218
+#define TC358768_TCLK_TRAILCNT 0x021C
+#define TC358768_THS_HEADERCNT 0x0220
+#define TC358768_TWAKEUP   0x0224
+#define TC358768_TCLK_POSTCNT  0x0228
+#define TC358768_THS_TRAILCNT  0x022C
+#define TC358768_HSTXVREGCNT   0x0230
+#define TC358768_HSTXVREGEN0x0234
+#define TC358768_TXOPTIONCNTRL 0x0238
+#define TC358768_BTACNTRL1 0x023C
+
+/* TX CTRL (32-bit addressable) */
+#define TC358768_DSI_CONTROL   0x040C
+#define TC358768_DSI_STATUS0x0410
+#define TC358768_DSI_INT   0x0414
+#define TC358768_DSI_INT_ENA   0x0418
+#define TC358768_DSICMD_RDFIFO 0x0430
+#define TC358768_DSI_ACKE

Re: [PATCH v3 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

enable failed: %d\n", ret);
>> +tc358768_bridge_disable(bridge);
>> +tc358768_bridge_post_disable(bridge);
>> +}
>> +}
>> +
>> +static const struct drm_bridge_funcs tc358768_bridge_funcs = {
>> +.attach = tc358768_bridge_attach,
>> +.mode_valid = tc358768_bridge_mode_valid,
>> +.pre_enable = tc358768_bridge_pre_enable,
>> +.enable = tc358768_bridge_enable,
>> +.disable = tc358768_bridge_disable,
>> +.post_disable = tc358768_bridge_post_disable,
>> +};
>> +
>> +static const struct drm_bridge_timings default_tc358768_timings = {
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
>> + | DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE
>> + | DRM_BUS_FLAG_DE_HIGH,
>> +};
>> +
>> +static bool tc358768_is_reserved_reg(unsigned int reg)
>> +{
>> +switch (reg) {
>> +case 0x114 ... 0x13f:
>> +case 0x200:
>> +case 0x20c:
>> +case 0x400 ... 0x408:
>> +case 0x41c ... 0x42f:
>> +return true;
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool tc358768_writeable_reg(struct device *dev, unsigned int reg)
>> +{
>> +if (tc358768_is_reserved_reg(reg))
>> +    return false;
>> +
>> +switch (reg) {
>> +case TC358768_CHIPID:
>> +case TC358768_FIFOSTATUS:
>> +case TC358768_DSITXSTATUS ... (TC358768_DSITXSTATUS + 2):
>> +case TC358768_DSI_CONTROL ... (TC358768_DSI_INT_ENA + 2):
>> +case TC358768_DSICMD_RDFIFO ... (TC358768_DSI_ERR_HALT + 2):
>> +return false;
>> +default:
>> +return true;
>> +}
>> +}
>> +
>> +static bool tc358768_readable_reg(struct device *dev, unsigned int reg)
>> +{
>> +if (tc358768_is_reserved_reg(reg))
>> +return false;
>> +
>> +switch (reg) {
>> +case TC358768_STARTCNTRL:
>> +case TC358768_DSI_CONFW ... (TC358768_DSI_CONFW + 2):
>> +case TC358768_DSI_INT_CLR ... (TC358768_DSI_INT_CLR + 2):
>> +case TC358768_DSI_START ... (TC358768_DSI_START + 2):
>> +case TC358768_DBG_DATA:
>> +return false;
>> +default:
>> +return true;
>> +}
>> +}
>> +
>> +static const struct regmap_config tc358768_regmap_config = {
>> +.name = "tc358768",
>> +.reg_bits = 16,
>> +.val_bits = 16,
>> +.max_register = TC358768_DSI_HACT,
>> +.cache_type = REGCACHE_NONE,
>> +.writeable_reg = tc358768_writeable_reg,
>> +.readable_reg = tc358768_readable_reg,
>> +.reg_format_endian = REGMAP_ENDIAN_BIG,
>> +.val_format_endian = REGMAP_ENDIAN_BIG,
>> +};
>> +
>> +static const struct i2c_device_id tc358768_i2c_ids[] = {
>> +{ "tc358768", 0 },
>> +{ "tc358778", 0 },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, tc358768_i2c_ids);
>> +
>> +static const struct of_device_id tc358768_of_ids[] = {
>> +{ .compatible = "toshiba,tc358768", },
>> +{ .compatible = "toshiba,tc358778", },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, tc358768_of_ids);
>> +
>> +static int tc358768_get_regulators(struct tc358768_priv *priv)
>> +{
>> +int i, ret;
>> +
>> +for (i = 0; i < ARRAY_SIZE(priv->supplies); ++i)
>> +priv->supplies[i].supply = tc358768_supplies[i];
>> +
>> +ret = devm_regulator_bulk_get(priv->dev, ARRAY_SIZE(priv->supplies),
>> +  priv->supplies);
>> +if (ret < 0)
>> +dev_err(priv->dev, "failed to get regulators: %d\n", ret);
>> +
>> +return ret;
>> +}
>> +
>> +static int tc358768_i2c_probe(struct i2c_client *client,
>> +  const struct i2c_device_id *id)
>> +{
>> +struct tc358768_priv *priv;
>> +struct device *dev = >dev;
>> +struct device_node *np = dev->of_node;
>> +int ret;
>> +
>> +if (!np)
>> +return -ENODEV;
>> +
>> +priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> +if (!priv)
>> +return -ENOMEM;
>> +
>> +dev_set_drvdata(dev, priv);
>> +priv->dev = dev;
>> +
>> +ret = tc358768_get_regulators(priv);
>> +if (ret)
>> +return ret;
>> +
>> +priv->refclk = devm_clk_get(dev, "refclk");
>> +if (IS_ERR(priv->refclk))
>> +return PTR_ERR(priv->refclk);
>> +
>> +/*
>> + * RESX is low active, to disable tc358768 initially (keep in reset)
>> + * the gpio line must be LOW. This is the ASSERTED state of
>> + * GPIO_ACTIVE_LOW (GPIOD_OUT_HIGH == ASSERTED).
>> + */
>> +priv->reset_gpio  = devm_gpiod_get_optional(dev, "reset",
>> +GPIOD_OUT_HIGH);
>> +if (IS_ERR(priv->reset_gpio))
>> +return PTR_ERR(priv->reset_gpio);
>> +
>> +priv->regmap = devm_regmap_init_i2c(client, _regmap_config);
>> +if (IS_ERR(priv->regmap)) {
>> +dev_err(dev, "Failed to init regmap\n");
>> +return PTR_ERR(priv->regmap);
>> +}
>> +
>> +priv->dsi_host.dev = dev;
>> +priv->dsi_host.ops = _dsi_host_ops;
>> +
>> +priv->bridge.funcs = _bridge_funcs;
>> +priv->bridge.timings = _tc358768_timings;
>> +priv->bridge.of_node = np;
>> +
>> +i2c_set_clientdata(client, priv);
>> +
>> +return mipi_dsi_host_register(>dsi_host);
>> +}
>> +
>> +static int tc358768_i2c_remove(struct i2c_client *client)
>> +{
>> +struct tc358768_priv *priv = i2c_get_clientdata(client);
>> +
>> +mipi_dsi_host_unregister(>dsi_host);
>> +
>> +return 0;
>> +}
>> +
>> +static struct i2c_driver tc358768_driver = {
>> +.driver = {
>> +.name = "tc358768",
>> +.of_match_table = tc358768_of_ids,
>> +},
>> +.id_table = tc358768_i2c_ids,
>> +.probe = tc358768_i2c_probe,
>> +.remove = tc358768_i2c_remove,
>> +};
>> +module_i2c_driver(tc358768_driver);
>> +
>> +MODULE_AUTHOR("Peter Ujfalusi ");
>> +MODULE_DESCRIPTION("TC358768AXBG/TC358778XBG DSI bridge");
>> +MODULE_LICENSE("GPL v2");
> 
> 

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

[Peter Ujfalusi]

Hi Rob,

On 27/01/2020 20.49, Rob Herring wrote:
> On Mon, Jan 27, 2020 at 12:56:33PM +0200, Peter Ujfalusi wrote:
>> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  .../display/bridge/toshiba,tc358768.yaml  | 158 ++
>>  1 file changed, 158 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>> new file mode 100644
>> index ..8dd8cca39a77
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>> +examples:
>> +  - |
>> +i2c1 {
>> +  #address-cells = <1>;
>> +  #size-cells = <0>;
>> +
>> +  dsi_bridge: tc358768@0e {
> 
> Generic node names and no leading 0s:
> 
> dsi-bridge@e

Right, I'll correct it.

>> +compatible = "toshiba,tc358768";
>> +reg = <0x0e>;
>> +
>> +clocks = <_refclk>;
>> +clock-names = "refclk";
>> +
>> +/* GPIO line is inverted before going to the bridge */
>> +reset-gpios = <_display_board 0 1 /* GPIO_ACTIVE_LOW */>;
> 
> You just need to add the include for the define to work.

You are right, it compiles fine with the include added.

Thank you,
- Péter

>> +
>> +vddc-supply = <_2d>;
>> +vddmipi-supply = <_2d>;
>> +vddio-supply = <_3d>;
>> +
>> +dsi_bridge_ports: ports {
>> +  #address-cells = <1>;
>> +  #size-cells = <0>;
>> +
>> +  port@0 {
>> +reg = <0>;
>> +rgb_in: endpoint {
>> +  remote-endpoint = <_out>;
>> +  data-lines = <24>;
>> +};
>> +  };
>> +
>> +  port@1 {
>> +reg = <1>;
>> +dsi_out: endpoint {
>> +  remote-endpoint = <_in>;
>> +};
>> +  };
>> +};
>> +  };
>> +};
>> +
>> -- 
>> Peter
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

On 27/01/2020 12.56, Peter Ujfalusi wrote:
> Add basic support for the Toshiba TC358768 RGB to DSI bridge.
> Not all the features of the TC358768 is implemented by the initial driver:
> MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.
> 
> Only write is implemented for mipi_dsi_host_ops.transfer.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   10 +
>  drivers/gpu/drm/bridge/Makefile   |1 +
>  drivers/gpu/drm/bridge/tc358768.c | 1040 +
>  3 files changed, 1051 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/tc358768.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 0b9ca5862455..3fef3513bdd0 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767
>   ---help---
> Toshiba TC358767 eDP bridge chip driver.
>  
> +config DRM_TOSHIBA_TC358768
> + tristate "Toshiba TC358768 MIPI DSI bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + select DRM_PANEL
> + select DRM_MIPI_DSI
> + help
> +   Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver.
> +
>  config DRM_TI_TFP410
>   tristate "TI TFP410 DVI/HDMI bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index cd16ce830270..06fc265de0ef 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
>  obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> +obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> diff --git a/drivers/gpu/drm/bridge/tc358768.c 
> b/drivers/gpu/drm/bridge/tc358768.c
> new file mode 100644
> index ..244309c1112e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/tc358768.c
> @@ -0,0 +1,1040 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *  Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
> + *  Author: Peter Ujfalusi 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Global (16-bit addressable) */
> +#define TC358768_CHIPID  0x
> +#define TC358768_SYSCTL  0x0002
> +#define TC358768_CONFCTL 0x0004
> +#define TC358768_VSDLY   0x0006
> +#define TC358768_DATAFMT 0x0008
> +#define TC358768_GPIOEN  0x000E
> +#define TC358768_GPIODIR 0x0010
> +#define TC358768_GPIOIN  0x0012
> +#define TC358768_GPIOOUT 0x0014
> +#define TC358768_PLLCTL0 0x0016
> +#define TC358768_PLLCTL1 0x0018
> +#define TC358768_CMDBYTE 0x0022
> +#define TC358768_PP_MISC 0x0032
> +#define TC358768_DSITX_DT0x0050
> +#define TC358768_FIFOSTATUS  0x00F8
> +
> +/* Debug (16-bit addressable) */
> +#define TC358768_VBUFCTRL0x00E0
> +#define TC358768_DBG_WIDTH   0x00E2
> +#define TC358768_DBG_VBLANK  0x00E4
> +#define TC358768_DBG_DATA0x00E8
> +
> +/* TX PHY (32-bit addressable) */
> +#define TC358768_CLW_DPHYCONTTX  0x0100
> +#define TC358768_D0W_DPHYCONTTX  0x0104
> +#define TC358768_D1W_DPHYCONTTX  0x0108
> +#define TC358768_D2W_DPHYCONTTX  0x010C
> +#define TC358768_D3W_DPHYCONTTX  0x0110
> +#define TC358768_CLW_CNTRL   0x0140
> +#define TC358768_D0W_CNTRL   0x0144
> +#define TC358768_D1W_CNTRL   0x0148
> +#define TC358768_D2W_CNTRL   0x014C
> +#define TC358768_D3W_CNTRL   0x0150
> +
> +/* TX PPI (32-bit addressable) */
> +#define TC358768_STARTCNTRL  0x0204
> +#define TC358768_DSITXSTATUS 0x0208
> +#define TC358768_LINEINITCNT 0x0210
> +#define TC358768_LPTXTIMECNT 0x0214
> +#define TC358768_TCLK_HEADERCNT  0x0218
> +#define TC358768_TCLK_TRAILCNT   0x021C
> +#define TC358768_THS_HEADERCNT   0x0220
> +#define TC358768_TWAKEUP 0x0224
> +#define TC

[PATCH v3 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

[Peter Ujfalusi]

Hi,

Changes since v2:
- Implement pre_enable and post_disbale callbacks and move code from enable and
  disable callbacks.
- hw_enable/disable is removed from tc358768_dsi_host_transfer()
- Defines for DSI_CONFW accesses
- breakout from the loops  (the check for it) is moved one level up in
  tc358768_calc_pll()

Changes since v1:
DT bindings document:
- Removed MaxItems for the regulators
- additionalProperties: false added to port@1

Driver:
- Year is now 2020
- Includes shorted
- The three letter members of the private struct documented 0 they are named as
  in the datasheet
- Error handling for the IO functions is following what sil-sii8620.c does
- regmap regcache is disabled along with refcache_sync() and volatile callback
  for regmap
- The hw enable and disable functions got separated
- Taken the suggested simplifactions from Andrzej for tc358768_calc_pll() and
  tc358768_dsi_host_transfer()
- The driver no longer stores the drm_display_mode, it relies on
  priv->bridge.encoder->crtc->state->adjusted_mode where it needs it
- tc358768_calc_pll() can be used for verification only to not modify the state
- refcounting added for hw enable state as a dsi transfer was shutting down the
  bridge when it was already enabled.

Tested on top of drm-next + LED backlight patches + DT patches on dra7-evm with
osd101t2045 (panel-simple) and osd101t2587 panel drivers.

Cover letter from v1:
TC358768 is a parallel RGB to MIPI DSI bridge.

The initial driver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.

Regards,
Peter
---
Peter Ujfalusi (2):
  dt-bindings: display: bridge: Add documentation for Toshiba tc358768
  drm/bridge: Add tc358768 driver

 .../display/bridge/toshiba,tc358768.yaml  |  158 +++
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/tc358768.c | 1040 +
 4 files changed, 1209 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

[Peter Ujfalusi]

TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.

Signed-off-by: Peter Ujfalusi 
---
 .../display/bridge/toshiba,tc358768.yaml  | 158 ++
 1 file changed, 158 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
new file mode 100644
index ..8dd8cca39a77
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
+
+maintainers:
+  - Peter Ujfalusi 
+
+description: |
+  The TC358768/TC358778 is bridge device which converts RGB to DSI.
+
+properties:
+  compatible:
+enum:
+  - toshiba,tc358768
+  - toshiba,tc358778
+
+  reg:
+maxItems: 1
+description: base I2C address of the device
+
+  reset-gpios:
+maxItems: 1
+description: GPIO connected to active low RESX pin
+
+  vddc-supply:
+description: Regulator for 1.2V internal core power.
+
+  vddmipi-supply:
+description: Regulator for 1.2V for the MIPI.
+
+  vddio-supply:
+description: Regulator for 1.8V - 3.3V IO power.
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: refclk
+
+  ports:
+type: object
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+additionalProperties: false
+
+description: |
+  Video port for RGB input
+
+properties:
+  reg:
+const: 0
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  data-lines:
+enum: [ 16, 18, 24 ]
+
+  remote-endpoint: true
+
+required:
+  - reg
+
+  port@1:
+type: object
+additionalProperties: false
+
+description: |
+  Video port for DSI output (panel or connector).
+
+properties:
+  reg:
+const: 1
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  remote-endpoint: true
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - vddc-supply
+  - vddmipi-supply
+  - vddio-supply
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+i2c1 {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  dsi_bridge: tc358768@0e {
+compatible = "toshiba,tc358768";
+reg = <0x0e>;
+
+clocks = <_refclk>;
+clock-names = "refclk";
+
+/* GPIO line is inverted before going to the bridge */
+reset-gpios = <_display_board 0 1 /* GPIO_ACTIVE_LOW */>;
+
+vddc-supply = <_2d>;
+vddmipi-supply = <_2d>;
+vddio-supply = <_3d>;
+
+dsi_bridge_ports: ports {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  port@0 {
+reg = <0>;
+rgb_in: endpoint {
+  remote-endpoint = <_out>;
+  data-lines = <24>;
+};
+  };
+
+  port@1 {
+reg = <1>;
+dsi_out: endpoint {
+  remote-endpoint = <_in>;
+};
+  };
+};
+  };
+};
+
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

Add basic support for the Toshiba TC358768 RGB to DSI bridge.
Not all the features of the TC358768 is implemented by the initial driver:
MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.

Only write is implemented for mipi_dsi_host_ops.transfer.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/tc358768.c | 1040 +
 3 files changed, 1051 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 0b9ca5862455..3fef3513bdd0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767
---help---
  Toshiba TC358767 eDP bridge chip driver.
 
+config DRM_TOSHIBA_TC358768
+   tristate "Toshiba TC358768 MIPI DSI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   help
+ Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver.
+
 config DRM_TI_TFP410
tristate "TI TFP410 DVI/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cd16ce830270..06fc265de0ef 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
new file mode 100644
index ..244309c1112e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -0,0 +1,1040 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Global (16-bit addressable) */
+#define TC358768_CHIPID0x
+#define TC358768_SYSCTL0x0002
+#define TC358768_CONFCTL   0x0004
+#define TC358768_VSDLY 0x0006
+#define TC358768_DATAFMT   0x0008
+#define TC358768_GPIOEN0x000E
+#define TC358768_GPIODIR   0x0010
+#define TC358768_GPIOIN0x0012
+#define TC358768_GPIOOUT   0x0014
+#define TC358768_PLLCTL0   0x0016
+#define TC358768_PLLCTL1   0x0018
+#define TC358768_CMDBYTE   0x0022
+#define TC358768_PP_MISC   0x0032
+#define TC358768_DSITX_DT  0x0050
+#define TC358768_FIFOSTATUS0x00F8
+
+/* Debug (16-bit addressable) */
+#define TC358768_VBUFCTRL  0x00E0
+#define TC358768_DBG_WIDTH 0x00E2
+#define TC358768_DBG_VBLANK0x00E4
+#define TC358768_DBG_DATA  0x00E8
+
+/* TX PHY (32-bit addressable) */
+#define TC358768_CLW_DPHYCONTTX0x0100
+#define TC358768_D0W_DPHYCONTTX0x0104
+#define TC358768_D1W_DPHYCONTTX0x0108
+#define TC358768_D2W_DPHYCONTTX0x010C
+#define TC358768_D3W_DPHYCONTTX0x0110
+#define TC358768_CLW_CNTRL 0x0140
+#define TC358768_D0W_CNTRL 0x0144
+#define TC358768_D1W_CNTRL 0x0148
+#define TC358768_D2W_CNTRL 0x014C
+#define TC358768_D3W_CNTRL 0x0150
+
+/* TX PPI (32-bit addressable) */
+#define TC358768_STARTCNTRL0x0204
+#define TC358768_DSITXSTATUS   0x0208
+#define TC358768_LINEINITCNT   0x0210
+#define TC358768_LPTXTIMECNT   0x0214
+#define TC358768_TCLK_HEADERCNT0x0218
+#define TC358768_TCLK_TRAILCNT 0x021C
+#define TC358768_THS_HEADERCNT 0x0220
+#define TC358768_TWAKEUP   0x0224
+#define TC358768_TCLK_POSTCNT  0x0228
+#define TC358768_THS_TRAILCNT  0x022C
+#define TC358768_HSTXVREGCNT   0x0230
+#define TC358768_HSTXVREGEN0x0234
+#define TC358768_TXOPTIONCNTRL 0x0238
+#define TC358768_BTACNTRL1 0x023C
+
+/* TX CTRL (32-bit addressable) */
+#define TC358768_DSI_CONTROL   0x040C
+#define TC358768_DSI_STATUS0x0410
+#define TC358768_DSI_INT   0x0414
+#define TC358768_DSI_INT_ENA   0x0418
+#define TC358768_DSICMD_RDFIFO 0x0430
+#define TC358768_DSI_ACKERR   

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

[Peter Ujfalusi]

... 0x42f:
>> +return true;
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool tc358768_writeable_reg(struct device *dev, unsigned int reg)
>> +{
>> +    if (tc358768_is_reserved_reg(reg))
>> +return false;
>> +
>> +switch (reg) {
>> +case TC358768_CHIPID:
>> +case TC358768_FIFOSTATUS:
>> +case TC358768_DSITXSTATUS ... (TC358768_DSITXSTATUS + 2):
>> +case TC358768_DSI_CONTROL ... (TC358768_DSI_INT_ENA + 2):
>> +case TC358768_DSICMD_RDFIFO ... (TC358768_DSI_ERR_HALT + 2):
>> +return false;
>> +default:
>> +return true;
>> +}
>> +}
>> +
>> +static bool tc358768_readable_reg(struct device *dev, unsigned int reg)
>> +{
>> +if (tc358768_is_reserved_reg(reg))
>> +return false;
>> +
>> +switch (reg) {
>> +case TC358768_STARTCNTRL:
>> +case TC358768_DSI_CONFW ... (TC358768_DSI_CONFW + 2):
>> +case TC358768_DSI_INT_CLR ... (TC358768_DSI_INT_CLR + 2):
>> +case TC358768_DSI_START ... (TC358768_DSI_START + 2):
>> +case TC358768_DBG_DATA:
>> +return false;
>> +default:
>> +return true;
>> +}
>> +}
>> +
>> +static const struct regmap_config tc358768_regmap_config = {
>> +.name = "tc358768",
>> +.reg_bits = 16,
>> +.val_bits = 16,
>> +.max_register = TC358768_DSI_HACT,
>> +.cache_type = REGCACHE_NONE,
>> +.writeable_reg = tc358768_writeable_reg,
>> +.readable_reg = tc358768_readable_reg,
>> +.reg_format_endian = REGMAP_ENDIAN_BIG,
>> +.val_format_endian = REGMAP_ENDIAN_BIG,
>> +};
>> +
>> +static const struct i2c_device_id tc358768_i2c_ids[] = {
>> +{ "tc358768", 0 },
>> +{ "tc358778", 0 },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, tc358768_i2c_ids);
>> +
>> +static const struct of_device_id tc358768_of_ids[] = {
>> +{ .compatible = "toshiba,tc358768", },
>> +{ .compatible = "toshiba,tc358778", },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, tc358768_of_ids);
>> +
>> +static int tc358768_get_regulators(struct tc358768_priv *priv)
>> +{
>> +int i, ret;
>> +
>> +for (i = 0; i < ARRAY_SIZE(priv->supplies); ++i)
>> +priv->supplies[i].supply = tc358768_supplies[i];
>> +
>> +ret = devm_regulator_bulk_get(priv->dev, ARRAY_SIZE(priv->supplies),
>> +  priv->supplies);
>> +if (ret < 0)
>> +dev_err(priv->dev, "failed to get regulators: %d\n", ret);
>> +
>> +return ret;
>> +}
>> +
>> +static int tc358768_i2c_probe(struct i2c_client *client,
>> +  const struct i2c_device_id *id)
>> +{
>> +struct tc358768_priv *priv;
>> +struct device *dev = >dev;
>> +struct device_node *np = dev->of_node;
>> +int ret;
>> +
>> +if (!np)
>> +return -ENODEV;
>> +
>> +priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> +if (!priv)
>> +return -ENOMEM;
>> +
>> +dev_set_drvdata(dev, priv);
>> +priv->dev = dev;
>> +
>> +ret = tc358768_get_regulators(priv);
>> +if (ret)
>> +return ret;
>> +
>> +priv->refclk = devm_clk_get(dev, "refclk");
>> +if (IS_ERR(priv->refclk))
>> +return PTR_ERR(priv->refclk);
>> +
>> +/*
>> + * RESX is low active, to disable tc358768 initially (keep in reset)
>> + * the gpio line must be LOW. This is the ASSERTED state of
>> + * GPIO_ACTIVE_LOW (GPIOD_OUT_HIGH == ASSERTED).
>> + */
>> +priv->reset_gpio  = devm_gpiod_get_optional(dev, "reset",
>> +GPIOD_OUT_HIGH);
>> +if (IS_ERR(priv->reset_gpio))
>> +return PTR_ERR(priv->reset_gpio);
>> +
>> +priv->regmap = devm_regmap_init_i2c(client, _regmap_config);
>> +if (IS_ERR(priv->regmap)) {
>> +dev_err(dev, "Failed to init regmap\n");
>> +return PTR_ERR(priv->regmap);
>> +}
>> +
>> +priv->dsi_host.dev = dev;
>> +priv->dsi_host.ops = _dsi_host_ops;
>> +
>> +priv->bridge.funcs = _bridge_funcs;
>> +priv->bridge.timings = _tc358768_timings;
>> +priv->bridge.of_node = np;
>> +
>> +i2c_set_clientdata(client, priv);
>> +
>> +ret = mipi_dsi_host_register(>dsi_host);
>> +if (ret)
>> +return ret;
>> +
>> +return 0;
> 
> 
> It could be replaced by:
> 
>     return mipi_dsi_host_register(>dsi_host);
> 
> Matter of taste, up to you.

Sure, I'm not sure why I left it like this to be honest.

> 
> Overall the driver is in good shape, except hw_enable refcounting, which
> I hope we will clarify quickly.

I can take a look at this on Monday, most likely I can send v3 on the
afternoon.

Thank you,
- Péter

> 
> 
> Regards
> 
> Andrzej
> 
> 
>> +}
>> +
>> +static int tc358768_i2c_remove(struct i2c_client *client)
>> +{
>> +struct tc358768_priv *priv = i2c_get_clientdata(client);
>> +
>> +mipi_dsi_host_unregister(>dsi_host);
>> +
>> +return 0;
>> +}
>> +
>> +static struct i2c_driver tc358768_driver = {
>> +.driver = {
>> +.name = "tc358768",
>> +.of_match_table = tc358768_of_ids,
>> +},
>> +.id_table = tc358768_i2c_ids,
>> +.probe = tc358768_i2c_probe,
>> +.remove = tc358768_i2c_remove,
>> +};
>> +module_i2c_driver(tc358768_driver);
>> +
>> +MODULE_AUTHOR("Peter Ujfalusi ");
>> +MODULE_DESCRIPTION("TC358768AXBG/TC358778XBG DSI bridge");
>> +MODULE_LICENSE("GPL v2");
> 
> 

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

[Peter Ujfalusi]

Hi,

Changes since v1:
DT bindings document:
- Removed MaxItems for the regulators
- additionalProperties: false added to port@1

Driver:
- Year is now 2020
- Includes shorted
- The three letter members of the private struct documented 0 they are named as
  in the datasheet
- Error handling for the IO functions is following what sil-sii8620.c does
- regmap regcache is disabled along with refcache_sync() and volatile callback
  for regmap
- The hw enable and disable functions got separated
- Taken the suggested simplifactions from Andrzej for tc358768_calc_pll() and
  tc358768_dsi_host_transfer()
- The driver no longer stores the drm_display_mode, it relies on
  priv->bridge.encoder->crtc->state->adjusted_mode where it needs it
- tc358768_calc_pll() can be used for verification only to not modify the state
- refcounting added for hw enable state as a dsi transfer was shutting down the
  bridge when it was already enabled.

Tested on top of drm-next + LED backlight patches + DT patches on dra7-evm with
osd101t2045 (panel-simple) and osd101t2587 panel drivers.

Cover letter from v1:
TC358768 is a parallel RGB to MIPI DSI bridge.

The initial driver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.

Regards,
Peter
---
Peter Ujfalusi (2):
  dt-bindings: display: bridge: Add documentation for Toshiba tc358768
  drm/bridge: Add tc358768 driver

 .../display/bridge/toshiba,tc358768.yaml  | 158 +++
 drivers/gpu/drm/bridge/Kconfig|  10 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/tc358768.c | 992 ++
 4 files changed, 1161 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

[Peter Ujfalusi]

TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.

Signed-off-by: Peter Ujfalusi 
---
 .../display/bridge/toshiba,tc358768.yaml  | 158 ++
 1 file changed, 158 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
new file mode 100644
index ..8dd8cca39a77
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
+
+maintainers:
+  - Peter Ujfalusi 
+
+description: |
+  The TC358768/TC358778 is bridge device which converts RGB to DSI.
+
+properties:
+  compatible:
+enum:
+  - toshiba,tc358768
+  - toshiba,tc358778
+
+  reg:
+maxItems: 1
+description: base I2C address of the device
+
+  reset-gpios:
+maxItems: 1
+description: GPIO connected to active low RESX pin
+
+  vddc-supply:
+description: Regulator for 1.2V internal core power.
+
+  vddmipi-supply:
+description: Regulator for 1.2V for the MIPI.
+
+  vddio-supply:
+description: Regulator for 1.8V - 3.3V IO power.
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: refclk
+
+  ports:
+type: object
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+additionalProperties: false
+
+description: |
+  Video port for RGB input
+
+properties:
+  reg:
+const: 0
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  data-lines:
+enum: [ 16, 18, 24 ]
+
+  remote-endpoint: true
+
+required:
+  - reg
+
+  port@1:
+type: object
+additionalProperties: false
+
+description: |
+  Video port for DSI output (panel or connector).
+
+properties:
+  reg:
+const: 1
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  remote-endpoint: true
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - vddc-supply
+  - vddmipi-supply
+  - vddio-supply
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+i2c1 {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  dsi_bridge: tc358768@0e {
+compatible = "toshiba,tc358768";
+reg = <0x0e>;
+
+clocks = <_refclk>;
+clock-names = "refclk";
+
+/* GPIO line is inverted before going to the bridge */
+reset-gpios = <_display_board 0 1 /* GPIO_ACTIVE_LOW */>;
+
+vddc-supply = <_2d>;
+vddmipi-supply = <_2d>;
+vddio-supply = <_3d>;
+
+dsi_bridge_ports: ports {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  port@0 {
+reg = <0>;
+rgb_in: endpoint {
+  remote-endpoint = <_out>;
+  data-lines = <24>;
+};
+  };
+
+  port@1 {
+reg = <1>;
+dsi_out: endpoint {
+  remote-endpoint = <_in>;
+};
+  };
+};
+  };
+};
+
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

Add basic support for the Toshiba TC358768 RGB to DSI bridge.
Not all the features of the TC358768 is implemented by the initial driver:
MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.

Only write is implemented for mipi_dsi_host_ops.transfer.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/bridge/Kconfig|  10 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/tc358768.c | 992 ++
 3 files changed, 1003 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 0b9ca5862455..3fef3513bdd0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767
---help---
  Toshiba TC358767 eDP bridge chip driver.
 
+config DRM_TOSHIBA_TC358768
+   tristate "Toshiba TC358768 MIPI DSI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   help
+ Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver.
+
 config DRM_TI_TFP410
tristate "TI TFP410 DVI/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cd16ce830270..06fc265de0ef 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
new file mode 100644
index ..5e12b1390254
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -0,0 +1,992 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Global (16-bit addressable) */
+#define TC358768_CHIPID0x
+#define TC358768_SYSCTL0x0002
+#define TC358768_CONFCTL   0x0004
+#define TC358768_VSDLY 0x0006
+#define TC358768_DATAFMT   0x0008
+#define TC358768_GPIOEN0x000E
+#define TC358768_GPIODIR   0x0010
+#define TC358768_GPIOIN0x0012
+#define TC358768_GPIOOUT   0x0014
+#define TC358768_PLLCTL0   0x0016
+#define TC358768_PLLCTL1   0x0018
+#define TC358768_CMDBYTE   0x0022
+#define TC358768_PP_MISC   0x0032
+#define TC358768_DSITX_DT  0x0050
+#define TC358768_FIFOSTATUS0x00F8
+
+/* Debug (16-bit addressable) */
+#define TC358768_VBUFCTRL  0x00E0
+#define TC358768_DBG_WIDTH 0x00E2
+#define TC358768_DBG_VBLANK0x00E4
+#define TC358768_DBG_DATA  0x00E8
+
+/* TX PHY (32-bit addressable) */
+#define TC358768_CLW_DPHYCONTTX0x0100
+#define TC358768_D0W_DPHYCONTTX0x0104
+#define TC358768_D1W_DPHYCONTTX0x0108
+#define TC358768_D2W_DPHYCONTTX0x010C
+#define TC358768_D3W_DPHYCONTTX0x0110
+#define TC358768_CLW_CNTRL 0x0140
+#define TC358768_D0W_CNTRL 0x0144
+#define TC358768_D1W_CNTRL 0x0148
+#define TC358768_D2W_CNTRL 0x014C
+#define TC358768_D3W_CNTRL 0x0150
+
+/* TX PPI (32-bit addressable) */
+#define TC358768_STARTCNTRL0x0204
+#define TC358768_DSITXSTATUS   0x0208
+#define TC358768_LINEINITCNT   0x0210
+#define TC358768_LPTXTIMECNT   0x0214
+#define TC358768_TCLK_HEADERCNT0x0218
+#define TC358768_TCLK_TRAILCNT 0x021C
+#define TC358768_THS_HEADERCNT 0x0220
+#define TC358768_TWAKEUP   0x0224
+#define TC358768_TCLK_POSTCNT  0x0228
+#define TC358768_THS_TRAILCNT  0x022C
+#define TC358768_HSTXVREGCNT   0x0230
+#define TC358768_HSTXVREGEN0x0234
+#define TC358768_TXOPTIONCNTRL 0x0238
+#define TC358768_BTACNTRL1 0x023C
+
+/* TX CTRL (32-bit addressable) */
+#define TC358768_DSI_CONTROL   0x040C
+#define TC358768_DSI_STATUS0x0410
+#define TC358768_DSI_INT   0x0414
+#define TC358768_DSI_INT_ENA   0x0418
+#define TC358768_DSICMD_RDFIFO 0x0430
+#define TC358768_DSI_ACKERR   

Re: [PATCH 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

Hi Andrzej,

On 22/01/2020 10.46, Andrzej Hajda wrote:
 +struct tc358768_priv {
 +  struct device *dev;
 +  struct regmap *regmap;
 +  struct gpio_desc *reset_gpio;
 +  struct regulator_bulk_data supplies[ARRAY_SIZE(tc358768_supplies)];
 +  struct clk *refclk;
 +
 +  struct mipi_dsi_host dsi_host;
 +  struct drm_bridge bridge;
 +  struct tc358768_dsi_output output;
>>>
>>> Since tc358768_dsi_output is used only here, you can define it here as
>>> well, up to you.
>> I think I have done it like this to avoid thinking about prefixes for
>> what is under the tc358768_dsi_output.
>> I'll take a look if it will look better unpacked here.
> 
> I though rather about in-place anonymous struct definition:
> 
> +    struct tc358768_dsi_output {
> +        struct mipi_dsi_device *dev;
> +        struct drm_panel *panel;
> +        struct drm_bridge *bridge;
> +    } output;
> 
> But, as I said - up to you.

I see. I think I will keep how it was. They are in proximity, so easy to
check.

 +
 +  refclk = clk_get_rate(priv->refclk);
 +
 +  best_diff = UINT_MAX;
 +  best_pll = 0;
 +  best_prd = 0;
 +  best_fbd = 0;
 +
 +  for (prd = 0; prd < 16; ++prd) {
 +  u32 divisor = (prd + 1) * (1 << frs);
 +  u32 fbd;
 +
 +  for (fbd = 0; fbd < 512; ++fbd) {
 +  u32 pll, diff;
 +
 +  pll = (u32)div_u64((u64)refclk * (fbd + 1), divisor);
 +
 +  if (pll >= max_pll || pll < min_pll)
 +  continue;
 +
 +  diff = max(pll, target_pll) - min(pll, target_pll);
 +
 +  if (diff < best_diff) {
 +  best_diff = diff;
 +  best_pll = pll;
 +  best_prd = prd;
 +  best_fbd = fbd;
 +  }
 +
 +  if (best_diff == 0)
 +  break;
 +  }
 +
 +  if (best_diff == 0)
 +  break;
>>> why another check here?
>> To break out from the top for() loop also in case exact match has been
>> found.
> 
> 
> Ahh, OK. So maybe you should put "if (diff == 0) goto found" inside "if
> (diff < best_diff)" block, in such case goto is not considered harmful
> :), and is more readable.

Exactly my thoughts ;)

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

Hi Andrzej,

On 16/01/2020 16.35, Andrzej Hajda wrote:
> On 17.12.2019 11:15, Peter Ujfalusi wrote:
>> Add basic support for the Toshiba TC358768 RGB to DSI bridge.
>> Not all the features of the TC358768 is implemented by the initial driver:
>> MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.
>>
>> Only write is implemented for mipi_dsi_host_ops.transfer.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/gpu/drm/bridge/Kconfig|  10 +
>>  drivers/gpu/drm/bridge/Makefile   |   1 +
>>  drivers/gpu/drm/bridge/tc358768.c | 963 ++
>>  3 files changed, 974 insertions(+)
>>  create mode 100644 drivers/gpu/drm/bridge/tc358768.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index ccc698c44f58..fd65666702e1 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767
>>  ---help---
>>Toshiba TC358767 eDP bridge chip driver.
>>  
>> +config DRM_TOSHIBA_TC358768
>> +tristate "Toshiba TC358768 MIPI DSI bridge"
>> +depends on OF
>> +select DRM_KMS_HELPER
>> +select REGMAP_I2C
>> +select DRM_PANEL
>> +select DRM_MIPI_DSI
>> +help
>> +  Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver.
>> +
>>  config DRM_TI_TFP410
>>  tristate "TI TFP410 DVI/HDMI bridge"
>>  depends on OF
>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>> b/drivers/gpu/drm/bridge/Makefile
>> index a6c7dd7727ea..204696e30572 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
>>  obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>>  obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
>>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>> +obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
>>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>>  obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
>>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>> diff --git a/drivers/gpu/drm/bridge/tc358768.c 
>> b/drivers/gpu/drm/bridge/tc358768.c
>> new file mode 100644
>> index 0000..63571191b1c4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/tc358768.c
>> @@ -0,0 +1,963 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + *  Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
> 
> 
> Just FYI, we have 2020 already, maybe update needed.

Oh, how time flies ;)

> 
> 
>> + *  Author: Peter Ujfalusi 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> 
> alphabetic order

Ok.

>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Global (16-bit addressable) */
>> +#define TC358768_CHIPID 0x
>> +#define TC358768_SYSCTL 0x0002
>> +#define TC358768_CONFCTL0x0004
>> +#define TC358768_VSDLY  0x0006
>> +#define TC358768_DATAFMT0x0008
>> +#define TC358768_GPIOEN 0x000E
>> +#define TC358768_GPIODIR0x0010
>> +#define TC358768_GPIOIN 0x0012
>> +#define TC358768_GPIOOUT0x0014
>> +#define TC358768_PLLCTL00x0016
>> +#define TC358768_PLLCTL10x0018
>> +#define TC358768_CMDBYTE0x0022
>> +#define TC358768_PP_MISC0x0032
>> +#define TC358768_DSITX_DT   0x0050
>> +#define TC358768_FIFOSTATUS 0x00F8
>> +
>> +/* Debug (16-bit addressable) */
>> +#define TC358768_VBUFCTRL   0x00E0
>> +#define TC358768_DBG_WIDTH  0x00E2
>> +#define TC358768_DBG_VBLANK 0x00E4
>> +#define TC358768_DBG_DATA   0x00E8
>> +
>> +/* TX PHY (32-bit addressable) */
>> +#define TC358768_CLW_DPHYCONTTX 0x0100
>> +#define TC358768_D0W_DPHYCONTTX 0x0104
>> +#define TC358768_D1W_DPHYCONTTX 0x0108
>> +#define TC358768_D2W_DPHYCONTTX 0x010C
>> +#define TC358768_D3W_DPHYCONTTX 0x0110
>> +#define TC358768_CLW_CNTRL  0x0140
>> +#define TC358768_D0W_CNTRL  0x0144
>> +#define TC358768_D1W_CNTRL 

Re: [PATCH 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

[Peter Ujfalusi]

On 27/12/2019 0.24, Rob Herring wrote:
> On Tue, Dec 17, 2019 at 12:15:05PM +0200, Peter Ujfalusi wrote:
>> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  .../display/bridge/toshiba,tc358768.yaml  | 158 ++
>>  1 file changed, 158 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>> new file mode 100644
>> index ..8f96867caca0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>> @@ -0,0 +1,158 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
>> +
>> +maintainers:
>> +  - Peter Ujfalusi 
>> +
>> +description: |
>> +  The TC358768/TC358778 is bridge device which converts RGB to DSI.
>> +
>> +properties:
>> +  compatible:
>> +enum:
>> +  - toshiba,tc358768
>> +  - toshiba,tc358778
>> +
>> +  reg:
>> +maxItems: 1
>> +description: base I2C address of the device
>> +
>> +  reset-gpios:
>> +maxItems: 1
>> +description: GPIO connected to active low RESX pin
>> +
>> +  vddc-supply:
>> +maxItems: 1
> 
> Drop this. Not an array. *-supply doesn't need further constraints.

OK.

> 
>> +description: Regulator for 1.2V internal core power.
>> +
>> +  vddmipi-supply:
>> +maxItems: 1
>> +description: Regulator for 1.2V for the MIPI.
>> +
>> +  vddio-supply:
>> +maxItems: 1
>> +description: Regulator for 1.8V - 3.3V IO power.
> 
> Blank line here.

Oops, I'll fix it.

> 
>> +  clocks:
>> +maxItems: 1
>> +
>> +  clock-names:
>> +const: refclk
>> +
>> +  ports:
>> +type: object
>> +
>> +properties:
>> +  "#address-cells":
>> +const: 1
>> +
>> +  "#size-cells":
>> +const: 0
>> +
>> +  port@0:
>> +type: object
>> +additionalProperties: false
>> +
>> +description: |
>> +  Video port for RGB input
>> +
>> +properties:
>> +  reg:
>> +const: 0
>> +
>> +patternProperties:
>> +  endpoint:
>> +type: object
>> +additionalProperties: false
>> +
>> +properties:
>> +  data-lines:
>> +enum: [ 16, 18, 24 ]
>> +
>> +  remote-endpoint: true
>> +
>> +required:
>> +  - reg
>> +
>> +  port@1:
>> +type: object
>> +description: |
>> +  Video port for DSI output (panel or connector).
>> +
>> +properties:
>> +  reg:
>> +const: 1
>> +
>> +patternProperties:
>> +  endpoint:
>> +type: object
>> +additionalProperties: false
>> +
>> +properties:
>> +  remote-endpoint: true
>> +
>> +required:
>> +  - reg
> 
> No additionalProperties on this one?

Correct, I have missed the additionalProperties: false

I'll update the binding documents when I get comments for the driver.

Thank you,
- Péter

> 
>> +
>> +required:
>> +  - "#address-cells"
>> +  - "#size-cells"
>> +  - port@0
>> +  - port@1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - vddc-supply
>> +  - vddmipi-supply
>> +  - vddio-supply
>> +  - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +i2c1 {
>> +  #address-cells = <1>;
>> +  #size-cells = <0>;
>> +
>> +  dsi_bridge: tc358768@0e {
>> +compatible = "toshiba,tc358768";
>> +reg = <0x0e>;
>> +
>> +clocks = <_refclk>;
>> +clock-names = "refclk";
>> +
>> +/*

Re: [PATCH v4 3/5] dt-bindings: display: ti, j721e-dss: Add dt-schema yaml binding

[Peter Ujfalusi]

Hi Jyri,

On 19/12/2019 10.23, Jyri Sarha wrote:
> Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone
> Display SubSystem.
> 
> Version history:
> 
> v2: no change
> 
> v3: - reg-names: "wp" -> "wb"
> - Add ports node
> - Add includes to dts example
> - reindent dts example
> 
> v4: - Add descriptions to reg, clocks, and interrups properties
> - Remove minItems when its value is the same as maxItems value
> 
> Signed-off-by: Jyri Sarha 
> ---
>  .../bindings/display/ti/ti,j721e-dss.yaml | 209 ++
>  1 file changed, 209 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml 
> b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
> new file mode 100644
> index ..cd68c4294f9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
> @@ -0,0 +1,209 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Texas Instruments J721E Display Subsystem
> +
> +maintainers:
> +  - Jyri Sarha 
> +  - Tomi Valkeinen 
> +
> +description: |
> +  The J721E TI Keystone Display SubSystem with four output ports and
> +  four video planes. There is two full video planes and two "lite
> +  planes" without scaling support. The video ports can be connected to
> +  the SoC's DPI pins or to integrated display bridges on the SoC.
> +
> +properties:
> +  compatible:
> +const: ti,j721e-dss
> +
> +  reg:
> +maxItems: 17
> +description: |
> +  Addresses to each DSS memory region described in the SoC's TRM.
> +  The reg-names refer to memory regions as follows:
> +  reg-names: Region Name in TRM: Description:
> +  common_m   DSS0_DISPC_0_COMMON_M   DSS Master common register area
> +  common_s0  DSS0_DISPC_0_COMMON_SO  DSS Shared common register area 0
> +  common_s1  DSS0_DISPC_0_COMMON_S1  DSS Shared common register area 1
> +  common_s2  DSS0_DISPC_0_COMMON_S2  DSS Shared common register area 2
> +  vidl1  DSS0_VIDL1  VIDL1 light video plane 1
> +  vidl2  DSS0_VIDL2  VIDL2 light video plane 2
> +  vid1   DSS0_VID1   VID1 video plane 1
> +  vid2   DSS0_VID2   VID1 video plane 2
> +  ovr1   DSS0_OVR1   OVR1 overlay manager for vp1
> +  ovr2   DSS0_OVR2   OVR2 overlay manager for vp2
> +  ovr3   DSS0_OVR3   OVR1 overlay manager for vp3
> +  ovr4   DSS0_OVR4   OVR2 overlay manager for vp4
> +  vp1DSS0_VP1VP1 video port 1
> +  vp2DSS0_VP2VP1 video port 2
> +  vp3DSS0_VP3VP1 video port 3
> +  vp4DSS0_VP4VP1 video port 4
> +  wp DSS0_WB Write Back registers

'wp' is back ;)

> +
> +  reg-names:
> +items:
> +  - const: common_m
> +  - const: common_s0
> +  - const: common_s1
> +  - const: common_s2
> +  - const: vidl1
> +  - const: vidl2
> +  - const: vid1
> +  - const: vid2
> +  - const: ovr1
> +  - const: ovr2
> +  - const: ovr3
> +  - const: ovr4
> +  - const: vp1
> +  - const: vp2
> +  - const: vp3
> +  - const: vp4
> +  - const: wb

imho the description you put under the 'reg' would be more natural here,
where you actually specifying the names of the register ranges.

> +
> +  clocks:
> +maxItems: 5
> +description:
> +  phandles to clock nodes for DSS functional clock (fck) and video
> +  port 1, 2, 3 and 4 pixel clocks (vp1, vp2, vp3, vp4).
> +
> +  clock-names:
> +items:
> +  - const: fck
> +  - const: vp1
> +  - const: vp2
> +  - const: vp3
> +  - const: vp4

Same comment, it is more natural to have the description coupled with
what you are describing.

> +
> +  interrupts:
> +maxItems: 4
> +description:
> +  Interrupt descriptions for common irq registers in common_m,
> +  common_m0, common_m1, and common_m2, sections.
> +
> +  interrupt-names:
> +items:
> +  - const: common_m
> +  - const: common_s0
> +  - const: common_s1
> +  - const: common_s2
> +
> +  power-domains:
> +maxItems: 1
> +description: phandle to the associated power domain
> +
> +  ports:
> +type: object
> +description:
> +  Ports as described in Documentation/devictree/bindings/graph.txt
> +properties:
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  port@0:
> +type: object
> +description:
> +  The output port node form video port 1
> +

[PATCH 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

[Peter Ujfalusi]

Hi,

TC358768 is a parallel RGB to MIPI DSI bridge.

The initial driver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.

Regards,
Peter
---
Peter Ujfalusi (2):
  dt-bindings: display: bridge: Add documentation for Toshiba tc358768
  drm/bridge: Add tc358768 driver

 .../display/bridge/toshiba,tc358768.yaml  | 158 +++
 drivers/gpu/drm/bridge/Kconfig|  10 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/tc358768.c | 963 ++
 4 files changed, 1132 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 2/2] drm/bridge: Add tc358768 driver

[Peter Ujfalusi]

Add basic support for the Toshiba TC358768 RGB to DSI bridge.
Not all the features of the TC358768 is implemented by the initial driver:
MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.

Only write is implemented for mipi_dsi_host_ops.transfer.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/bridge/Kconfig|  10 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/tc358768.c | 963 ++
 3 files changed, 974 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/tc358768.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index ccc698c44f58..fd65666702e1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767
---help---
  Toshiba TC358767 eDP bridge chip driver.
 
+config DRM_TOSHIBA_TC358768
+   tristate "Toshiba TC358768 MIPI DSI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   help
+ Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver.
+
 config DRM_TI_TFP410
tristate "TI TFP410 DVI/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index a6c7dd7727ea..204696e30572 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
new file mode 100644
index ..63571191b1c4
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -0,0 +1,963 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Global (16-bit addressable) */
+#define TC358768_CHIPID0x
+#define TC358768_SYSCTL0x0002
+#define TC358768_CONFCTL   0x0004
+#define TC358768_VSDLY 0x0006
+#define TC358768_DATAFMT   0x0008
+#define TC358768_GPIOEN0x000E
+#define TC358768_GPIODIR   0x0010
+#define TC358768_GPIOIN0x0012
+#define TC358768_GPIOOUT   0x0014
+#define TC358768_PLLCTL0   0x0016
+#define TC358768_PLLCTL1   0x0018
+#define TC358768_CMDBYTE   0x0022
+#define TC358768_PP_MISC   0x0032
+#define TC358768_DSITX_DT  0x0050
+#define TC358768_FIFOSTATUS0x00F8
+
+/* Debug (16-bit addressable) */
+#define TC358768_VBUFCTRL  0x00E0
+#define TC358768_DBG_WIDTH 0x00E2
+#define TC358768_DBG_VBLANK0x00E4
+#define TC358768_DBG_DATA  0x00E8
+
+/* TX PHY (32-bit addressable) */
+#define TC358768_CLW_DPHYCONTTX0x0100
+#define TC358768_D0W_DPHYCONTTX0x0104
+#define TC358768_D1W_DPHYCONTTX0x0108
+#define TC358768_D2W_DPHYCONTTX0x010C
+#define TC358768_D3W_DPHYCONTTX0x0110
+#define TC358768_CLW_CNTRL 0x0140
+#define TC358768_D0W_CNTRL 0x0144
+#define TC358768_D1W_CNTRL 0x0148
+#define TC358768_D2W_CNTRL 0x014C
+#define TC358768_D3W_CNTRL 0x0150
+
+/* TX PPI (32-bit addressable) */
+#define TC358768_STARTCNTRL0x0204
+#define TC358768_DSITXSTATUS   0x0208
+#define TC358768_LINEINITCNT   0x0210
+#define TC358768_LPTXTIMECNT   0x0214
+#define TC358768_TCLK_HEADERCNT0x0218
+#define TC358768_TCLK_TRAILCNT 0x021C
+#define TC358768_THS_HEADERCNT 0x0220
+#define TC358768_TWAKEUP   0x0224
+#define TC358768_TCLK_POSTCNT  0x0228
+#define TC358768_THS_TRAILCNT  0x022C
+#define TC358768_HSTXVREGCNT   0x0230
+#define TC358768_HSTXVREGEN0x0234
+#define TC358768_TXOPTIONCNTRL 0x0238
+#define TC358768_BTACNTRL1 0x023C
+
+/* TX CTRL (32-bit addressable) */
+#define TC358768_DSI_CONTROL   0x040C
+#define TC358768_DSI_STATUS0x0410
+#define TC358768_DSI_INT   0x0414
+#define TC358768_DSI_INT_ENA   0x0418
+#define TC358768_DSICMD_RDFIFO 0x0430
+#define TC358768_DSI_ACKERR   

[PATCH 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

[Peter Ujfalusi]

TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.

Signed-off-by: Peter Ujfalusi 
---
 .../display/bridge/toshiba,tc358768.yaml  | 158 ++
 1 file changed, 158 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
new file mode 100644
index ..8f96867caca0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
+
+maintainers:
+  - Peter Ujfalusi 
+
+description: |
+  The TC358768/TC358778 is bridge device which converts RGB to DSI.
+
+properties:
+  compatible:
+enum:
+  - toshiba,tc358768
+  - toshiba,tc358778
+
+  reg:
+maxItems: 1
+description: base I2C address of the device
+
+  reset-gpios:
+maxItems: 1
+description: GPIO connected to active low RESX pin
+
+  vddc-supply:
+maxItems: 1
+description: Regulator for 1.2V internal core power.
+
+  vddmipi-supply:
+maxItems: 1
+description: Regulator for 1.2V for the MIPI.
+
+  vddio-supply:
+maxItems: 1
+description: Regulator for 1.8V - 3.3V IO power.
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: refclk
+
+  ports:
+type: object
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+additionalProperties: false
+
+description: |
+  Video port for RGB input
+
+properties:
+  reg:
+const: 0
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  data-lines:
+enum: [ 16, 18, 24 ]
+
+  remote-endpoint: true
+
+required:
+  - reg
+
+  port@1:
+type: object
+description: |
+  Video port for DSI output (panel or connector).
+
+properties:
+  reg:
+const: 1
+
+patternProperties:
+  endpoint:
+type: object
+additionalProperties: false
+
+properties:
+  remote-endpoint: true
+
+required:
+  - reg
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - vddc-supply
+  - vddmipi-supply
+  - vddio-supply
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+i2c1 {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  dsi_bridge: tc358768@0e {
+compatible = "toshiba,tc358768";
+reg = <0x0e>;
+
+clocks = <_refclk>;
+clock-names = "refclk";
+
+/* GPIO line is inverted before going to the bridge */
+reset-gpios = <_display_board 0 1 /* GPIO_ACTIVE_LOW */>;
+
+vddc-supply = <_2d>;
+vddmipi-supply = <_2d>;
+vddio-supply = <_3d>;
+
+dsi_bridge_ports: ports {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  port@0 {
+reg = <0>;
+rgb_in: endpoint {
+  remote-endpoint = <_out>;
+  data-lines = <24>;
+};
+  };
+
+  port@1 {
+reg = <1>;
+dsi_out: endpoint {
+  remote-endpoint = <_in>;
+};
+  };
+};
+  };
+};
+
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH] ARM: dts: am335x-evmsk: Use drm simple-panel instead of tilcdc-panel

[Peter Ujfalusi]

On 04/12/2019 12.55, Jyri Sarha wrote:
> Move to use the new drm panel support in tilcdc together with added
> "newhaven,nhd-4.3-480272ef-atxl"-panel support in drm panel-simple.

Tested-by: Peter Ujfalusi 

> Signed-off-by: Jyri Sarha 
> ---
>  arch/arm/boot/dts/am335x-evmsk.dts | 38 ++
>  1 file changed, 12 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
> b/arch/arm/boot/dts/am335x-evmsk.dts
> index e28a5b82fdf3..b149e48520b4 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -183,36 +183,16 @@
>   };
>  
>   panel {
> - compatible = "ti,tilcdc,panel";
> + compatible = "newhaven,nhd-4.3-480272ef-atxl";
> +
>   pinctrl-names = "default", "sleep";
>   pinctrl-0 = <_pins_default>;
>   pinctrl-1 = <_pins_sleep>;
>   backlight = <_bl>;
> - status = "okay";
> - panel-info {
> - ac-bias = <255>;
> - ac-bias-intrpt  = <0>;
> - dma-burst-sz= <16>;
> - bpp = <32>;
> - fdd = <0x80>;
> - sync-edge   = <0>;
> - sync-ctrl   = <1>;
> - raster-order= <0>;
> - fifo-th = <0>;
> - };
> - display-timings {
> - 480x272 {
> - hactive = <480>;
> - vactive = <272>;
> - hback-porch = <43>;
> - hfront-porch= <8>;
> - hsync-len   = <4>;
> - vback-porch = <12>;
> - vfront-porch= <4>;
> - vsync-len   = <10>;
> - clock-frequency = <900>;
> - hsync-active= <0>;
> - vsync-active= <0>;
> +
> + port {
> + panel_0: endpoint@0 {
> + remote-endpoint = <_0>;
>   };
>   };
>   };
> @@ -750,6 +730,12 @@
>   status = "okay";
>  
>   blue-and-red-wiring = "crossed";
> +
> + port {
> + lcdc_0: endpoint@0 {
> + remote-endpoint = <_0>;
> + };
> + };
>  };
>  
>   {
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH for-5.3] drm/omap: ensure we have a valid dma_mask

[Peter Ujfalusi]

On 09/08/2019 13.00, Tomi Valkeinen wrote:
> Here's my version.
> 
> From c258309e36fc86076db155aead03a3900b96c3d4 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen 
> Date: Fri, 9 Aug 2019 09:54:49 +0300
> Subject: [PATCH] drm/omap: ensure we have a valid dma_mask
> 
> The omapdrm driver uses dma_set_coherent_mask(), but that's not enough
> anymore when LPAE is enabled.
> 
> From Christoph Hellwig :
> 
> The traditional arm DMA code ignores, but the generic dma-direct/swiotlb
> has stricter checks and thus fails mappings without a DMA mask.  As we
> use swiotlb for arm with LPAE now, omapdrm needs to catch up and
> actually set a DMA mask.
> 
> Change the dma_set_coherent_mask() call to
> dma_coerce_mask_and_coherent() so that the dev->dma_mask is also set.

Reviewed-by: Peter Ujfalusi 

> Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
> Reported-by: "H. Nikolaus Schaller" 
> Signed-off-by: Tomi Valkeinen 
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 288c59dae56a..1bad0a2cc5c6 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -669,7 +669,7 @@ static int pdev_probe(struct platform_device *pdev)
>   if (omapdss_is_initialized() == false)
>   return -EPROBE_DEFER;
>  
> - ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> + ret = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
>   if (ret) {
>   dev_err(>dev, "Failed to set the DMA mask\n");
>   return ret;
> 
> 
> 
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tilcdc: Check priv->crtc validity in cpufreq_transition()

[Peter Ujfalusi]

On 02/08/2019 12.35, Jyri Sarha wrote:
> On 02/08/2019 11:39, Peter Ujfalusi wrote:
>> The notifier can be called before we have crtc. With the check we can avoid
>> NULL pointer dereference within tilcdc_crtc_update_clk().
>>
>> Signed-off-by: Peter Ujfalusi 
> 
> Peter, do you have "drm/tilcdc: Register cpufreq notifier after we have
> initialized crtc" [1] in your branch? It was merged in v5.0. If you do
> and still see the crash, then I need to study this more.
> 
> Best regards,
> Jyri
> 
> [1] https://patchwork.freedesktop.org/patch/292412/
> commit 432973fd3a20102840d5f7e61af9f1a03c217a4c

Your patch fixed the issue in a better way. I was just carrying this
since December 2018 and since it still applies I thought that I will
send it...

Just ignore this patch and thanks for the proper fix.

> 
>> ---
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
>> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> index 3046a4a4232d..85093123722d 100644
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> @@ -169,7 +169,7 @@ static int cpufreq_transition(struct notifier_block *nb,
>>  struct tilcdc_drm_private *priv = container_of(nb,
>>  struct tilcdc_drm_private, freq_transition);
>>  
>> -if (val == CPUFREQ_POSTCHANGE)
>> +if (val == CPUFREQ_POSTCHANGE && priv->crtc)
>>  tilcdc_crtc_update_clk(priv->crtc);
>>  
>>  return 0;
>>
> 
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tilcdc: Check priv->crtc validity in cpufreq_transition()

[Peter Ujfalusi]

The notifier can be called before we have crtc. With the check we can avoid
NULL pointer dereference within tilcdc_crtc_update_clk().

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 3046a4a4232d..85093123722d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -169,7 +169,7 @@ static int cpufreq_transition(struct notifier_block *nb,
struct tilcdc_drm_private *priv = container_of(nb,
struct tilcdc_drm_private, freq_transition);
 
-   if (val == CPUFREQ_POSTCHANGE)
+   if (val == CPUFREQ_POSTCHANGE && priv->crtc)
tilcdc_crtc_update_clk(priv->crtc);
 
return 0;
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 1/2] drm/omap: dmm_tiler: Use dmaengine_prep_dma_memcpy() for i878 workaround

[Peter Ujfalusi]

Instead of dma_dev->device_prep_dma_memcpy() use the existing macro to
prepare the memcpy.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 252f5ebb1acc..77728eaa1a6f 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -82,12 +82,11 @@ static const u32 reg[][4] = {
 
 static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
 {
-   struct dma_device *dma_dev = dmm->wa_dma_chan->device;
struct dma_async_tx_descriptor *tx;
enum dma_status status;
dma_cookie_t cookie;
 
-   tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
+   tx = dmaengine_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
if (!tx) {
dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
return -EIO;
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 2/2] drm/omap: dmm_tiler: Remove the dma_async_issue_pending() call

[Peter Ujfalusi]

dma_sync_wait() is calling it so no need to call it in the driver.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 77728eaa1a6f..42ec51bb7b1b 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -98,7 +98,6 @@ static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, 
dma_addr_t dst)
return -EIO;
}
 
-   dma_async_issue_pending(dmm->wa_dma_chan);
status = dma_sync_wait(dmm->wa_dma_chan, cookie);
if (status != DMA_COMPLETE)
dev_err(dmm->dev, "i878 wa DMA copy failure\n");
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 0/2] drm/omap: dmm_tiler: Small fixes for i878 workaround

[Peter Ujfalusi]

Hi,

two small correction on the use of DMAengine API, no functional changes
- Use dmaengine_prep_dma_memcpy() to prepare the memcpy
- do not call dma_async_issue_pending() as it is redundant

Regards,
Peter
---
Peter Ujfalusi (2):
  drm/omap: dmm_tiler: Use dmaengine_prep_dma_memcpy() for i878
workaround
  drm/omap: dmm_tiler: Remove the dma_async_issue_pending() call

 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3] backlight: gpio-backlight: Correct initial power state handling

[Peter Ujfalusi]

The default-on property - or the def_value via legacy pdata) should be
handled as:
if it is 1, the backlight must be enabled (kept enabled)
if it is 0, the backlight must be disabled (kept disabled)

This only works for the case when default-on is set. If it is not set then
the brightness of the backlight is set to 0. Now if the backlight is
enabled by external driver (graphics) the backlight will stay disabled since
the brightness is configured as 0. The backlight will not turn on.

In order to minimize screen flickering during device boot:

The initial brightness should be set to 1.

If booted in non DT mode or no phandle link to the backlight node:
follow the def_value/default-on to select UNBLANK or POWERDOWN

If in DT boot we have phandle link then leave the GPIO in a state which the
bootloader left it and let the user of the backlight to configure it
further.

Signed-off-by: Peter Ujfalusi 
---
Hi,

sorry for the delay, but got distracted a bit with the resend of this...
Let's try again ;)

Changes since v2 (https://lore.kernel.org/patchwork/patch/1002359/):
- Rebased on drm-next

Changes since v1:
- Implement similiar initial power state handling as pwm backlight have

Regards,
Peter

 drivers/video/backlight/gpio_backlight.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index e84f3087e29f..18e053e4716c 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -59,13 +59,11 @@ static int gpio_backlight_probe_dt(struct platform_device 
*pdev,
   struct gpio_backlight *gbl)
 {
struct device *dev = >dev;
-   enum gpiod_flags flags;
int ret;
 
gbl->def_value = device_property_read_bool(dev, "default-on");
-   flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
 
-   gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
+   gbl->gpiod = devm_gpiod_get(dev, NULL, GPIOD_ASIS);
if (IS_ERR(gbl->gpiod)) {
ret = PTR_ERR(gbl->gpiod);
 
@@ -79,6 +77,22 @@ static int gpio_backlight_probe_dt(struct platform_device 
*pdev,
return 0;
 }
 
+static int gpio_backlight_initial_power_state(struct gpio_backlight *gbl)
+{
+   struct device_node *node = gbl->dev->of_node;
+
+   /* Not booted with device tree or no phandle link to the node */
+   if (!node || !node->phandle)
+   return gbl->def_value ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+
+   /* if the enable GPIO is disabled, do not enable the backlight */
+   if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
+   return FB_BLANK_POWERDOWN;
+
+   return FB_BLANK_UNBLANK;
+}
+
+
 static int gpio_backlight_probe(struct platform_device *pdev)
 {
struct gpio_backlight_platform_data *pdata =
@@ -136,7 +150,9 @@ static int gpio_backlight_probe(struct platform_device 
*pdev)
return PTR_ERR(bl);
}
 
-   bl->props.brightness = gbl->def_value;
+   bl->props.power = gpio_backlight_initial_power_state(gbl);
+   bl->props.brightness = 1;
+
backlight_update_status(bl);
 
platform_set_drvdata(pdev, bl);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH] backlight: gpio-backlight: Set power state instead of brightness at probe

[Peter Ujfalusi]

Daniel,

On 20/06/2019 16.56, Daniel Thompson wrote:
> On 18/06/2019 13:58, Paul Kocialkowski wrote:
>> Hi,
>>
>> On Fri, 2019-05-17 at 17:05 +0200, Paul Kocialkowski wrote:
>>> On a trivial gpio-backlight setup with a panel using the backlight but
>>> no boot software to enable it beforehand, we fall in a case where the
>>> backlight is disabled (not just blanked) and thus remains disabled when
>>> the panel gets enabled.
>>>
>>> Setting gbl->def_value via the device-tree prop allows enabling the
>>> backlight in this situation, but it will be unblanked straight away,
>>> in compliance with the binding. This does not work well when there
>>> was no
>>> boot software to display something before, since we really need to
>>> unblank
>>> by the time the panel is enabled, not before.
>>>
>>> Resolve the situation by setting the brightness to 1 at probe and
>>> managing the power state accordingly, a bit like it's done in
>>> pwm-backlight.
>>
>> Any feedback on this? I was under the impression that it could be quite
>> controversial, as it implies that the backlight can no longer be
>> enabled without a bound panel (which IMO makes good sense but could be
>> a matter to debate).
> 
> My apologies. This patch brought on such severe deja-vu I got rather
> confused. Then when I went digging I've also dropped the ball on the
> same feature previously.
> 
> Peter Ujfalusi provided a similar patch to yours but with a slightly
> different implementation:
> https://lore.kernel.org/patchwork/patch/1002359/
> 
> On the whole I think it is important to read the GPIO pin since
> otherwise we swap problems when there bootloader does setup the
> backlight for problems where it does not.
> 
> The thing I don't get is why both patches try to avoid setting the
> backlight brightness from def_value. Simple displays, especially
> monochrome ones are perfectly readable with the backlight off... zero
> brightness is not a "bad" value.

Because we might have non monochrome displays where the display is not
readable when the backlight is off and for the sake of to be consistent?
Flickering backlight is not really a nice thing during boot.

> Not sure if Peter is still willing to rev his version of this code
> (given how badly we neglected him previously) or whether you want to try
> and combine both ideas.

Nothing special, things sometimes got overlooked.
I should have been nagging you about it ;)

I think the v2 patch from me should apply just fine and it has the gpio
read as well, if not, then I might not be able to resend as I'm out of
office for a while

- Péter


> 
> 
> Daniel.
> 
> 
>>
>> Cheers,
>>
>> Paul
>>
>>> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
>>> Signed-off-by: Paul Kocialkowski 
>>> ---
>>>   drivers/video/backlight/gpio_backlight.c | 19 ++-
>>>   1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/backlight/gpio_backlight.c
>>> b/drivers/video/backlight/gpio_backlight.c
>>> index e470da95d806..c9cb97fa13d0 100644
>>> --- a/drivers/video/backlight/gpio_backlight.c
>>> +++ b/drivers/video/backlight/gpio_backlight.c
>>> @@ -57,6 +57,21 @@ static const struct backlight_ops
>>> gpio_backlight_ops = {
>>>   .check_fb    = gpio_backlight_check_fb,
>>>   };
>>>   +static int gpio_backlight_initial_power_state(struct
>>> gpio_backlight *gbl)
>>> +{
>>> +    struct device_node *node = gbl->dev->of_node;
>>> +
>>> +    /* If we absolutely want the backlight enabled at boot. */
>>> +    if (gbl->def_value)
>>> +    return FB_BLANK_UNBLANK;
>>> +
>>> +    /* If there's no panel to unblank the backlight later. */
>>> +    if (!node || !node->phandle)
>>> +    return FB_BLANK_UNBLANK;
>>> +
>>> +    return FB_BLANK_POWERDOWN;
>>> +}
>>> +
>>>   static int gpio_backlight_probe_dt(struct platform_device *pdev,
>>>  struct gpio_backlight *gbl)
>>>   {
>>> @@ -142,7 +157,9 @@ static int gpio_backlight_probe(struct
>>> platform_device *pdev)
>>>   return PTR_ERR(bl);
>>>   }
>>>   -    bl->props.brightness = gbl->def_value;
>>> +    bl->props.brightness = 1;
>>> +    bl->props.power = gpio_backlight_initial_power_state(gbl);
>>> +
>>>   backlight_update_status(bl);
>>>     platform_set_drvdata(pdev, bl);
> 


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

[Peter Ujfalusi]

On 28/05/2019 13.32, Tomi Valkeinen wrote:
> On 28/05/2019 13:18, Tony Lindgren wrote:
>> Strange that this is not affecting other x15? I think timer12 would
>> be blocked on HS devices though?
> 
> I don't know... I can't believe my x15 would be unique =). Can it be
> something in the kernel config? u-boot?
> 
> Peter should have the same A3. Peter, can you try with my config?

It did not boot with your config.
My config boots, I'm using SLUB.
Flipping CONFIG_SLUB_DEBUG_ON to y and the kernel does not boot.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

[Peter Ujfalusi]

Hi Thierry,

On 23/04/2019 14.55, Thierry Reding wrote:
> On Tue, Feb 26, 2019 at 09:55:19AM +0200, Peter Ujfalusi wrote:
>> Hi,
>>
>> Changes since v2:
>> - Added Reviewed-by from Rob to the binding patches
>> - Added help text to Kconfig (osd101t2587-53ts)
>> - Print the error values in dev_err/warn
>> - Added Reviewed-by from Sam to the osd101t2587-53ts patch
>>
>> Changes since v1 (only panel-osd-osd101t2587-53ts changed):
>> - Removed unused members from struct osd101t2587_panel
>> - Use backlight_enable/backlight_disable
>> - Use devm_of_find_backlight()
>> - osd101t2587_of_match table standardized 
>> - osd101t2587_panel_unprepare() added to shutdown and remove callbacks to 
>> turn
>>   power off
>> - Fix probe in case mipi_dsi_attach() would fail
>>
>> Add support for OSD101T2045-53TS and OSD101T2587-53TS from One Stop Displays.
>>
>> The two panel is similar with one big difference: OSD101T2587-53TS requires 
>> the
>> MIPI_DSI_TURN_ON_PERIPHERAL message, thus can not be handled by panel-simple.
>>
>> Regards,
>> Peter
>> ---
>> Peter Ujfalusi (4):
>>   dt-bindings: display: Add bindings for OSD101T2045-53TS
>>   drm/panel: simple: Add support for OSD101T2045-53TS
>>   dt-bindings: display: Add bindings for OSD101T2587-53TS panel
>>   drm/panel: Add OSD101T2587-53TS driver
>>
>>  .../display/panel/osd,osd101t2045-53ts.txt|  11 +
>>  .../display/panel/osd,osd101t2587-53ts.txt|  14 +
>>  drivers/gpu/drm/panel/Kconfig |   9 +
>>  drivers/gpu/drm/panel/Makefile|   1 +
>>  .../drm/panel/panel-osd-osd101t2587-53ts.c| 254 ++
>>  drivers/gpu/drm/panel/panel-simple.c  |  34 +++
>>  6 files changed, 323 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
>>  create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
> 
> Applied all four patches. Note that I had to change the osd vendor
> string to osddisplays, which is the one that is documented in
> vendor-prefixes.txt.

I recall checking the vendor-prefixes.txt and not finding OSD in there.
Odd, as it is indeed there.

> I'm assuming that this is the same vendor, based on the model names. If
> this is a different vendor, do let me know.

Yes it is the same one.

Thank you and sorry for missing it,
- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/bridge: ti-tfp410: Set the bus_format

[Peter Ujfalusi]

Hi Andrzej,

On 12/04/2019 10.40, Andrzej Hajda wrote:
> On 12.04.2019 09:33, Andrzej Hajda wrote:
>> On 01.04.2019 14:41, Peter Ujfalusi wrote:
>>> The TFP410 supports 24 bit, single-edge and 12 bit, dual-edge modes.
>>> Depending on how many wires are used (24/12) the driver can set the correct
>>> bus_format.
>>>
>>> If the information is not available in DT then assume 24 bit, single-edge
>>> setup.
>>>
>>> Signed-off-by: Peter Ujfalusi 
>> Reviewed-by: Andrzej Hajda 
>>
>> The patch does not apply on drm-misc-next. Could you rebase it.
> 
> 
> OK, with HPD patch applied it works, I will queue all three patches to
> drm-misc-next.

Thank you!
- Péter

> 
> 
> Regards
> 
> Andrzej
> 
> 
>>
>>
>>  --
>> Regards
>> Andrzej
>>
>>> ---
>>>  drivers/gpu/drm/bridge/ti-tfp410.c | 17 +
>>>  1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
>>> b/drivers/gpu/drm/bridge/ti-tfp410.c
>>> index 6fc831eb3804..8b0e71bd3ca7 100644
>>> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
>>> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
>>> @@ -29,6 +29,7 @@ struct tfp410 {
>>> struct drm_connectorconnector;
>>> unsigned intconnector_type;
>>>  
>>> +   u32 bus_format;
>>> struct i2c_adapter  *ddc;
>>> struct gpio_desc*hpd;
>>> int hpd_irq;
>>> @@ -139,6 +140,9 @@ static int tfp410_attach(struct drm_bridge *bridge)
>>> return ret;
>>> }
>>>  
>>> +   drm_display_info_set_bus_formats(>connector.display_info,
>>> +>bus_format, 1);
>>> +
>>> drm_connector_attach_encoder(>connector,
>>>   bridge->encoder);
>>>  
>>> @@ -197,6 +201,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, 
>>> bool i2c)
>>> struct drm_bridge_timings *timings = >timings;
>>> struct device_node *ep;
>>> u32 pclk_sample = 0;
>>> +   u32 bus_width = 24;
>>> s32 deskew = 0;
>>>  
>>> /* Start with defaults. */
>>> @@ -221,6 +226,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, 
>>> bool i2c)
>>>  
>>> /* Get the sampling edge from the endpoint. */
>>> of_property_read_u32(ep, "pclk-sample", _sample);
>>> +   of_property_read_u32(ep, "bus-width", _width);
>>> of_node_put(ep);
>>>  
>>> timings->input_bus_flags = DRM_BUS_FLAG_DE_HIGH;
>>> @@ -238,6 +244,17 @@ static int tfp410_parse_timings(struct tfp410 *dvi, 
>>> bool i2c)
>>> return -EINVAL;
>>> }
>>>  
>>> +   switch (bus_width) {
>>> +   case 12:
>>> +   dvi->bus_format = MEDIA_BUS_FMT_RGB888_2X12_LE;
>>> +   break;
>>> +   case 24:
>>> +   dvi->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>>> +   break;
>>> +   default:
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> /* Get the setup and hold time from vendor-specific properties. */
>>> of_property_read_u32(dvi->dev->of_node, "ti,deskew", (u32 *));
>>> if (deskew < -4 || deskew > 3)
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: ti-tfp410: Fall back to HPD polling if HPD irq is not available

[Peter Ujfalusi]

On 02/04/2019 14.21, Laurent Pinchart wrote:
> Hi Peter,
> 
> Thank you for the patch.
> 
> On Mon, Apr 01, 2019 at 03:33:42PM +0300, Peter Ujfalusi wrote:
>> In case either the HPD gpio is not specified or when the HPD gpio can not
>> be used as interrupt we should tell the core that the HPD needs to be
>> polled for detecting hotplug.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/gpu/drm/bridge/ti-tfp410.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
>> b/drivers/gpu/drm/bridge/ti-tfp410.c
>> index 285be4a0f4bd..6fc831eb3804 100644
>> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
>> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
>> @@ -31,6 +31,7 @@ struct tfp410 {
>>  
>>  struct i2c_adapter  *ddc;
>>  struct gpio_desc*hpd;
>> +int hpd_irq;
>>  struct delayed_work hpd_work;
>>  struct gpio_desc*powerdown;
>>  
>> @@ -124,8 +125,10 @@ static int tfp410_attach(struct drm_bridge *bridge)
>>  return -ENODEV;
>>  }
>>  
>> -if (dvi->hpd)
>> +if (dvi->hpd_irq >= 0)
> 
> Do you need a new hpd_irq field ? Can't you just test dvi->hpd as done
> today, simply adding the else clause to this if ?

We can have hpd GPIO, but the GPIO might not be usable for interrupt.

> 
>>  dvi->connector.polled = DRM_CONNECTOR_POLL_HPD;
>> +else
>> +dvi->connector.polled = DRM_CONNECTOR_POLL_CONNECT | 
>> DRM_CONNECTOR_POLL_DISCONNECT;
>>  
>>  drm_connector_helper_add(>connector,
>>   _con_helper_funcs);
>> @@ -324,10 +327,15 @@ static int tfp410_init(struct device *dev, bool i2c)
>>  return PTR_ERR(dvi->powerdown);
>>  }
>>  
>> -if (dvi->hpd) {
>> +if (dvi->hpd)
>> +dvi->hpd_irq = gpiod_to_irq(dvi->hpd);
>> +else
>> +dvi->hpd_irq = -ENXIO;
>> +
>> +if (dvi->hpd_irq >= 0) {
>>  INIT_DELAYED_WORK(>hpd_work, tfp410_hpd_work_func);
>>  
>> -ret = devm_request_threaded_irq(dev, gpiod_to_irq(dvi->hpd),
>> +ret = devm_request_threaded_irq(dev, dvi->hpd_irq,
>>  NULL, tfp410_hpd_irq_thread, IRQF_TRIGGER_RISING |
>>  IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>>  "hdmi-hpd", dvi);
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 5/6] dt-bindings: display: sii902x: Add HDMI audio bindings

[Peter Ujfalusi]

On 02/04/2019 10.29, Jyri Sarha wrote:
> The sii902x chip family supports also HDMI audio. Add binding for
> describing the necessary i2s and mclk wiring for it.

Reviewed-by: Peter Ujfalusi 

> Signed-off-by: Jyri Sarha 
> ---
>  .../bindings/display/bridge/sii902x.txt   | 37 +++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt 
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> index c4c1855ca654..d124a5fedab1 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -9,6 +9,37 @@ Optional properties:
> about hotplug events.
>   - reset-gpios: OF device-tree gpio specification for RST_N pin.
>  
> + HDMI audio properties:
> + - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin
> +is wired, <1> if the both are wired. HDMI audio is
> +configured only if this property is found.
> + - sil,i2s-data-lanes: Array of up to 4 integers with values of 0-3
> +Each integer indicates which i2s pin is connected to which
> +audio fifo. The first integer selects i2s audio pin for the
> +first audio fifo#0 (HDMI channels 1&2), second for fifo#1
> +(HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s
> +pins (SD0 - SD3). Any i2s pin can be connected to any fifo,
> +but there can be no gaps. E.g. an i2s pin must be mapped to
> +fifo#0 and fifo#1 before mapping a channel to fifo#2. Default
> +value is <0>, describing SD0 pin beiging routed to hdmi audio
> +fifo #0.
> + - clocks: phandle and clock specifier for each clock listed in
> +   the clock-names property
> + - clock-names: "mclk"
> +Describes SII902x MCLK input. MCLK is used to produce
> +HDMI audio CTS values. This property is required if
> +"#sound-dai-cells"-property is present. This property follows
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +consumer binding.
> +
> + If HDMI audio is configured the sii902x device becomes an ASoC
> + codec component, that can be used in configuring full audio
> + devices with ASoC simple-card or audio-graph-card. See their
> + binding documents on how to describe how the sii902x device is
> + connected to the rest of the audio system:
> + Documentation/devicetree/bindings/sound/simple-card.txt
> + Documentation/devicetree/bindings/sound/audio-graph-card.txt
> +
>  Optional subnodes:
>   - video input: this subnode can contain a video input port node
> to connect the bridge to a display controller output (See this
> @@ -21,6 +52,12 @@ Example:
>   compatible = "sil,sii9022";
>   reg = <0x39>;
>   reset-gpios = < 1 0>;
> +
> + #sound-dai-cells = <0>;
> + i2s-data-lanes = < 0 1 2 >;
> + clocks = <>;
> + clock-names = "mclk";
> +
>   ports {
>   #address-cells = <1>;
>   #size-cells = <0>;
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 6/6] drm/bridge: sii902x: Implement HDMI audio support

[Peter Ujfalusi]

Hi Jyri,

On 02/04/2019 10.29, Jyri Sarha wrote:
> Implement HDMI audio support by using ASoC HDMI codec. The commit
> implements the necessary callbacks and configuration for the HDMI
> codec and registers a virtual platform device for the codec to attach.

it looks good:

Reviewed-by: Peter Ujfalusi 

> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/bridge/sii902x.c | 467 ++-
>  1 file changed, 461 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 358cf81c5ea4..553f1244f930 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -27,12 +27,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
>  #include 
>  #include 
>  
> +#include 
> +
>  #define SII902X_TPI_VIDEO_DATA   0x0
>  
>  #define SII902X_TPI_PIXEL_REPETITION 0x8
> @@ -74,6 +77,77 @@
>  #define SII902X_AVI_POWER_STATE_MSK  GENMASK(1, 0)
>  #define SII902X_AVI_POWER_STATE_D(l) ((l) & 
> SII902X_AVI_POWER_STATE_MSK)
>  
> +/* Audio  */
> +#define SII902X_TPI_I2S_ENABLE_MAPPING_REG   0x1f
> +#define SII902X_TPI_I2S_CONFIG_FIFO0 (0 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO1 (1 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO2 (2 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO3 (3 << 0)
> +#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP  (1 << 2)
> +#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE  (1 << 3)
> +#define SII902X_TPI_I2S_SELECT_SD0   (0 << 4)
> +#define SII902X_TPI_I2S_SELECT_SD1   (1 << 4)
> +#define SII902X_TPI_I2S_SELECT_SD2   (2 << 4)
> +#define SII902X_TPI_I2S_SELECT_SD3   (3 << 4)
> +#define SII902X_TPI_I2S_FIFO_ENABLE  (1 << 7)
> +
> +#define SII902X_TPI_I2S_INPUT_CONFIG_REG 0x20
> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_YES  (0 << 0)
> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_NO   (1 << 0)
> +#define SII902X_TPI_I2S_SD_DIRECTION_MSB_FIRST   (0 << 1)
> +#define SII902X_TPI_I2S_SD_DIRECTION_LSB_FIRST   (1 << 1)
> +#define SII902X_TPI_I2S_SD_JUSTIFY_LEFT  (0 << 2)
> +#define SII902X_TPI_I2S_SD_JUSTIFY_RIGHT (1 << 2)
> +#define SII902X_TPI_I2S_WS_POLARITY_LOW  (0 << 3)
> +#define SII902X_TPI_I2S_WS_POLARITY_HIGH (1 << 3)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_128  (0 << 4)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_256  (1 << 4)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_384  (2 << 4)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_512  (3 << 4)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_768  (4 << 4)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1024 (5 << 4)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1152 (6 << 4)
> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_192  (7 << 4)
> +#define SII902X_TPI_I2S_SCK_EDGE_FALLING (0 << 7)
> +#define SII902X_TPI_I2S_SCK_EDGE_RISING  (1 << 7)
> +
> +#define SII902X_TPI_I2S_STRM_HDR_BASE0x21
> +#define SII902X_TPI_I2S_STRM_HDR_SIZE5
> +
> +#define SII902X_TPI_AUDIO_CONFIG_BYTE2_REG   0x26
> +#define SII902X_TPI_AUDIO_CODING_STREAM_HEADER   (0 << 0)
> +#define SII902X_TPI_AUDIO_CODING_PCM (1 << 0)
> +#define SII902X_TPI_AUDIO_CODING_AC3 (2 << 0)
> +#define SII902X_TPI_AUDIO_CODING_MPEG1   (3 << 0)
> +#define SII902X_TPI_AUDIO_CODING_MP3 (4 << 0)
> +#define SII902X_TPI_AUDIO_CODING_MPEG2   (5 << 0)
> +#define SII902X_TPI_AUDIO_CODING_AAC (6 << 0)
> +#define SII902X_TPI_AUDIO_CODING_DTS (7 << 0)
> +#define SII902X_TPI_AUDIO_CODING_ATRAC   (8 << 0)
> +#define SII902X_TPI_AUDIO_MUTE_DISABLE   (0 << 4)
> +#define SII902X_TPI_AUDIO_MUTE_ENABLE(1 << 4)
> +#define SII902X_TPI_AUDIO_LAYOUT_2_CHANNELS  (0 << 5)
> +#define SII902X_TPI_AUDIO_LAYOUT_8_CHANNELS  (1 << 5)
> +#define SII902X_TPI_AUDIO_INTERFACE_DISABLE  (0 << 6)
> +#define SII902X_TPI_AUDIO_INTERFACE_SPDIF(1 << 6)
> +#define SII902X_TPI_AUDIO_INTERFACE_I2S  (2 << 6)

[PATCH 1/2] dt-bindings: display: tfp410: Add bus-width parameter property

[Peter Ujfalusi]

tfp410 can be connect to host processor in 24bit, single-edge (24 lines) or
12bit, dual-edge (12 lines).

Add bus-width to the documentation so it can be used to select between the
two connection scheme.

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/display/bridge/ti,tfp410.txt   | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
index 3f903af93949..5ff4f64ef8e8 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
@@ -18,7 +18,14 @@ This device has two video ports. Their connections are 
modeled using the OF
 graph bindings specified in [1]. Each port node shall have a single endpoint.
 
 - Port 0 is the DPI input port. Its endpoint subnode shall contain a
-  pclk-sample property and a remote-endpoint property as specified in [1].
+  pclk-sample and bus-width property and a remote-endpoint property as 
specified
+  in [1].
+  - If pclk-sample is not defined, pclk-sample = 0 should be assumed for
+backward compatibility.
+  - If bus-width is not defined then bus-width = 24 should be assumed for
+backward compatibility.
+bus-width = 24: 24 data lines are connected and single-edge mode
+bus-width = 12: 12 data lines are connected and dual-edge mode
 
 - Port 1 is the DVI output port. Its endpoint subnode shall contain a
   remote-endpoint property is specified in [1].
@@ -43,6 +50,7 @@ tfp410: encoder@0 {
 
tfp410_in: endpoint@0 {
pclk-sample = <1>;
+   bus-width = <24>;
remote-endpoint = <_out>;
};
};
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 2/2] drm/bridge: ti-tfp410: Set the bus_format

[Peter Ujfalusi]

The TFP410 supports 24 bit, single-edge and 12 bit, dual-edge modes.
Depending on how many wires are used (24/12) the driver can set the correct
bus_format.

If the information is not available in DT then assume 24 bit, single-edge
setup.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/bridge/ti-tfp410.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 6fc831eb3804..8b0e71bd3ca7 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -29,6 +29,7 @@ struct tfp410 {
struct drm_connectorconnector;
unsigned intconnector_type;
 
+   u32 bus_format;
struct i2c_adapter  *ddc;
struct gpio_desc*hpd;
int hpd_irq;
@@ -139,6 +140,9 @@ static int tfp410_attach(struct drm_bridge *bridge)
return ret;
}
 
+   drm_display_info_set_bus_formats(>connector.display_info,
+>bus_format, 1);
+
drm_connector_attach_encoder(>connector,
  bridge->encoder);
 
@@ -197,6 +201,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool 
i2c)
struct drm_bridge_timings *timings = >timings;
struct device_node *ep;
u32 pclk_sample = 0;
+   u32 bus_width = 24;
s32 deskew = 0;
 
/* Start with defaults. */
@@ -221,6 +226,7 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool 
i2c)
 
/* Get the sampling edge from the endpoint. */
of_property_read_u32(ep, "pclk-sample", _sample);
+   of_property_read_u32(ep, "bus-width", _width);
of_node_put(ep);
 
timings->input_bus_flags = DRM_BUS_FLAG_DE_HIGH;
@@ -238,6 +244,17 @@ static int tfp410_parse_timings(struct tfp410 *dvi, bool 
i2c)
return -EINVAL;
}
 
+   switch (bus_width) {
+   case 12:
+   dvi->bus_format = MEDIA_BUS_FMT_RGB888_2X12_LE;
+   break;
+   case 24:
+   dvi->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+   break;
+   default:
+   return -EINVAL;
+   }
+
/* Get the setup and hold time from vendor-specific properties. */
of_property_read_u32(dvi->dev->of_node, "ti,deskew", (u32 *));
if (deskew < -4 || deskew > 3)
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 0/2] drm/bridge: ti-tfp410: Handle bus-format for 24/12 lines selection

[Peter Ujfalusi]

Hi,

The TFP410 supports 24 bit, single-edge and 12 bit, dual-edge modes.
Depending on how many wires are used (24/12) the driver can set the correct
bus_format.

In case the bus-width is not specified (old DT blobs) assume 24 lines as the
driver assumed that in the past and all boards using tfp410 uave this setup.

Regards,
Peter
---
Peter Ujfalusi (2):
  dt-bindings: display: tfp410: Add bus-width parameter property
  drm/bridge: ti-tfp410: Set the bus_format

 .../bindings/display/bridge/ti,tfp410.txt   | 10 +-
 drivers/gpu/drm/bridge/ti-tfp410.c  | 17 +
 2 files changed, 26 insertions(+), 1 deletion(-)

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH] drm/bridge: ti-tfp410: Fall back to HPD polling if HPD irq is not available

[Peter Ujfalusi]

In case either the HPD gpio is not specified or when the HPD gpio can not
be used as interrupt we should tell the core that the HPD needs to be
polled for detecting hotplug.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/bridge/ti-tfp410.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 285be4a0f4bd..6fc831eb3804 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -31,6 +31,7 @@ struct tfp410 {
 
struct i2c_adapter  *ddc;
struct gpio_desc*hpd;
+   int hpd_irq;
struct delayed_work hpd_work;
struct gpio_desc*powerdown;
 
@@ -124,8 +125,10 @@ static int tfp410_attach(struct drm_bridge *bridge)
return -ENODEV;
}
 
-   if (dvi->hpd)
+   if (dvi->hpd_irq >= 0)
dvi->connector.polled = DRM_CONNECTOR_POLL_HPD;
+   else
+   dvi->connector.polled = DRM_CONNECTOR_POLL_CONNECT | 
DRM_CONNECTOR_POLL_DISCONNECT;
 
drm_connector_helper_add(>connector,
 _con_helper_funcs);
@@ -324,10 +327,15 @@ static int tfp410_init(struct device *dev, bool i2c)
return PTR_ERR(dvi->powerdown);
}
 
-   if (dvi->hpd) {
+   if (dvi->hpd)
+   dvi->hpd_irq = gpiod_to_irq(dvi->hpd);
+   else
+   dvi->hpd_irq = -ENXIO;
+
+   if (dvi->hpd_irq >= 0) {
INIT_DELAYED_WORK(>hpd_work, tfp410_hpd_work_func);
 
-   ret = devm_request_threaded_irq(dev, gpiod_to_irq(dvi->hpd),
+   ret = devm_request_threaded_irq(dev, dvi->hpd_irq,
NULL, tfp410_hpd_irq_thread, IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
"hdmi-hpd", dvi);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

[Peter Ujfalusi]

On 15/03/2019 15.30, Tomi Valkeinen wrote:
> On 15/03/2019 14:28, Peter Ujfalusi wrote:
>> On 15/03/2019 14.07, Tomi Valkeinen wrote:
>>>> If the pclk-sample is not defined in DT, it will default to 0 which
>>>> selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
>>>>
>>>> But all the boards where I can find schematics with tfp410 have their
>>>> EDGE/HTPLG pin pulled up and according to the documentation when EDGE=1
>>>> then tfp410 will sample on the rising edge.
>>>>
>>>> imho the pclk_sample should be initialized to 1 to avoid regression for
>>>> most of the boards using tfp410.
>>>
>>> Define "regression" =). If the omapdrm driver was always using
>>> DRIVE_POSEDGE, this driver should also be using DRIVE_POSEDGE, no? If it
>>> does the same as the old driver, it can't be a regression. This is, of
>>> course, only considering omapdrm based boards.
>>>
>>> That said, it sounds odd that this would be wrong in the old driver, but
>>> then again, it might well be, as code related to these sync signals has
>>> changed sooo many times, and the related DSS registers are somewhat
>>> confusing.
>>
>> On the boards data skew is enabled as well with maximum delay selected
>> with DK1=DK2=DK3=1, so sampling of data is delayed by 3 * 350 ps, so
>> about 1 ns, not much, but might be enough for the signal to transition
>> on the bus so even if the HW drivers on POSEDGE and tfp410 samples on
>> POSEDGE (+1ns delay from the edge) we don't see corruption?
> 
> Ok. I don't think anyone has looked at it that closely. So, the syncs
> could well be wrong. Still, not a regression if it's the same way as it was.

True.

> If the fixed default works fine (or better) than the wrong ones, I think
> that can be the default. But I'd be careful about changing what the
> default is, if we've had it the old way for a long time.

The HW default in I2C mode is the EDGE=1 so SAMPLE_POSEDGE and it looks
to me that the same default was implemented via hw control on the boards
I can access the schematics.

If it was the other way in the past, then it is safer to not change the
default in the driver, but probably put a comment somewhere that the HW
default is the opposite?

In any case if the i2c control is implemented we will read and/or
configure the tfp410 anyways.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

[Peter Ujfalusi]

On 15/03/2019 14.07, Tomi Valkeinen wrote:
>> If the pclk-sample is not defined in DT, it will default to 0 which
>> selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
>>
>> But all the boards where I can find schematics with tfp410 have their
>> EDGE/HTPLG pin pulled up and according to the documentation when EDGE=1
>> then tfp410 will sample on the rising edge.
>>
>> imho the pclk_sample should be initialized to 1 to avoid regression for
>> most of the boards using tfp410.
> 
> Define "regression" =). If the omapdrm driver was always using
> DRIVE_POSEDGE, this driver should also be using DRIVE_POSEDGE, no? If it
> does the same as the old driver, it can't be a regression. This is, of
> course, only considering omapdrm based boards.
>
> That said, it sounds odd that this would be wrong in the old driver, but
> then again, it might well be, as code related to these sync signals has
> changed sooo many times, and the related DSS registers are somewhat
> confusing.

On the boards data skew is enabled as well with maximum delay selected
with DK1=DK2=DK3=1, so sampling of data is delayed by 3 * 350 ps, so
about 1 ns, not much, but might be enough for the signal to transition
on the bus so even if the HW drivers on POSEDGE and tfp410 samples on
POSEDGE (+1ns delay from the edge) we don't see corruption?

> That gave me an idea, I need to write an rwmem script to print the DSS
> sync flags in plain english...
> 
>  Tomi
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

[Peter Ujfalusi]

On 28/02/2019 12.31, Tomi Valkeinen wrote:
> On 28/02/2019 12:27, Tomi Valkeinen wrote:
>> Hi Laurent,
>>
>> On 11/02/2019 11:46, Laurent Pinchart wrote:
>>
>>> +   /* Get the sampling edge from the endpoint. */
>>> +   of_property_read_u32(ep, "pclk-sample", _sample);
>>> +   of_node_put(ep);
>>> +
>>> +   timings->input_bus_flags = DRM_BUS_FLAG_DE_HIGH;
>>> +
>>> +   switch (pclk_sample) {
>>> +   case 0:
>>> +   timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
>>> +|  DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE;
>>> +   break;
>>> +   case 1:
>>> +   timings->input_bus_flags |= DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
>>> +|  DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE;
>>> +   break;
>>> +   default:
>>> +   return -EINVAL;
>>> +   }
>>
>> The default for pclk_sample is just the opposite of what omapdrm's
>> tfp410 used to do. The dts doc file also says that pclk-sample is
>> required, but the driver works fine without it, defaulting to 0.
>>
>> This means that none of the omap dts files with tfp410 work correctly,
>> instead they silently use the wrong settings which may work but easily
>> also won't...
>>
>> As the bus flags are added in this patch for the first time, maybe we
>> can assume that no one is using them, and the default could be made to
>> be the same as was on omapdrm's tfp410?
> 
> Aaaand never mind. In omapdrm's driver we were using
> DRM_BUS_FLAG_SYNC_DRIVE_* variant, here we have SAMPLE variant. So it's
> fine =).

If the pclk-sample is not defined in DT, it will default to 0 which
selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?

But all the boards where I can find schematics with tfp410 have their
EDGE/HTPLG pin pulled up and according to the documentation when EDGE=1
then tfp410 will sample on the rising edge.

imho the pclk_sample should be initialized to 1 to avoid regression for
most of the boards using tfp410.

> 
> Sorry for the noise.
> 
>  Tomi
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panel: simple: Fix panel_simple_dsi_probe

[Peter Ujfalusi]

In case mipi_dsi_attach() fails remove the registered panel to avoid added
panel without corresponding device.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/panel/panel-simple.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 0337583ffa49..90b4e75381e2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3072,7 +3072,14 @@ static int panel_simple_dsi_probe(struct mipi_dsi_device 
*dsi)
dsi->format = desc->format;
dsi->lanes = desc->lanes;
 
-   return mipi_dsi_attach(dsi);
+   err = mipi_dsi_attach(dsi);
+   if (err) {
+   struct panel_simple *panel = dev_get_drvdata(>dev);
+
+   drm_panel_remove(>base);
+   }
+
+   return err;
 }
 
 static int panel_simple_dsi_remove(struct mipi_dsi_device *dsi)
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Sam Ravnborg 
---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-osd-osd101t2587-53ts.c| 254 ++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e070153ef21..6b6790474c33 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -122,6 +122,15 @@ config DRM_PANEL_ORISETECH_OTM8009A
  Say Y here if you want to enable support for Orise Technology
  otm8009a 480x800 dsi 2dl panel.
 
+config DRM_PANEL_OSD_OSD101T2587_53TS
+   tristate "OSD OSD101T2587-53TS DSI 1920x1200 video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for One Stop Displays
+ OSD101T2587-53TS 10.1" 1920x1200 dsi panel.
+
 config DRM_PANEL_PANASONIC_VVX10F034N00
tristate "Panasonic VVX10F034N00 1920x1200 video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e7ab71968bbf..d9d99956db0c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += 
panel-kingdisplay-kd097d04.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
 obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
+obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
 obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
diff --git a/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c 
b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
new file mode 100644
index ..55974e74aa0a
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct osd101t2587_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+
+   bool prepared;
+   bool enabled;
+
+   const struct drm_display_mode *default_mode;
+};
+
+static inline struct osd101t2587_panel *ti_osd_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct osd101t2587_panel, base);
+}
+
+static int osd101t2587_panel_disable(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = ti_osd_panel(panel);
+   int ret;
+
+   if (!osd101t2587->enabled)
+   return 0;
+
+   backlight_disable(osd101t2587->backlight);
+
+   ret = mipi_dsi_shutdown_peripheral(osd101t2587->dsi);
+
+   osd101t2587->enabled = false;
+
+   return ret;
+}
+
+static int osd101t2587_panel_unprepare(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = ti_osd_panel(panel);
+
+   if (!osd101t2587->prepared)
+   return 0;
+
+   regulator_disable(osd101t2587->supply);
+   osd101t2587->prepared = false;
+
+   return 0;
+}
+
+static int osd101t2587_panel_prepare(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = ti_osd_panel(panel);
+   int ret;
+
+   if (osd101t2587->prepared)
+   return 0;
+
+   ret = regulator_enable(osd101t2587->supply);
+   if (!ret)
+   osd101t2587->prepared = true;
+
+   return ret;
+}
+
+static int osd101t2587_panel_enable(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = ti_osd_panel(panel);
+   int ret;
+
+   if (osd101t2587->enabled)
+   return 0;
+
+   ret = mipi_dsi_turn_on_peripheral(osd101t2587->dsi);
+   if (ret)
+   return ret;
+
+   backlight_enable(osd101t2587->backlight);
+
+   osd101t2587->enabled = true;
+
+   return ret;
+}
+
+static const struct drm_display_mode default_mode_osd101t2587 = {
+   .clock = 164400,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 152,
+   .hsync_end = 1920 + 152 + 52,
+   .htotal = 1

[PATCH v3 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

[Peter Ujfalusi]

Hi,

Changes since v2:
- Added Reviewed-by from Rob to the binding patches
- Added help text to Kconfig (osd101t2587-53ts)
- Print the error values in dev_err/warn
- Added Reviewed-by from Sam to the osd101t2587-53ts patch

Changes since v1 (only panel-osd-osd101t2587-53ts changed):
- Removed unused members from struct osd101t2587_panel
- Use backlight_enable/backlight_disable
- Use devm_of_find_backlight()
- osd101t2587_of_match table standardized 
- osd101t2587_panel_unprepare() added to shutdown and remove callbacks to turn
  power off
- Fix probe in case mipi_dsi_attach() would fail

Add support for OSD101T2045-53TS and OSD101T2587-53TS from One Stop Displays.

The two panel is similar with one big difference: OSD101T2587-53TS requires the
MIPI_DSI_TURN_ON_PERIPHERAL message, thus can not be handled by panel-simple.

Regards,
Peter
---
Peter Ujfalusi (4):
  dt-bindings: display: Add bindings for OSD101T2045-53TS
  drm/panel: simple: Add support for OSD101T2045-53TS
  dt-bindings: display: Add bindings for OSD101T2587-53TS panel
  drm/panel: Add OSD101T2587-53TS driver

 .../display/panel/osd,osd101t2045-53ts.txt|  11 +
 .../display/panel/osd,osd101t2587-53ts.txt|  14 +
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-osd-osd101t2587-53ts.c| 254 ++
 drivers/gpu/drm/panel/panel-simple.c  |  34 +++
 6 files changed, 323 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
 create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 1/4] dt-bindings: display: Add bindings for OSD101T2045-53TS

[Peter Ujfalusi]

This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
1920x1200 panel from One Stop Displays.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Rob Herring 
---
 .../bindings/display/panel/osd,osd101t2045-53ts.txt   | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt 
b/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
new file mode 100644
index ..b3f6df59f7c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
@@ -0,0 +1,11 @@
+One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
+
+Required properties:
+- compatible: should be "osd,osd101t2045-53ts"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 2/4] drm/panel: simple: Add support for OSD101T2045-53TS

[Peter Ujfalusi]

Add support for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop
Displays to the panel-simple driver

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/panel/panel-simple.c | 34 
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..0337583ffa49 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2996,6 +2996,37 @@ static const struct panel_desc_dsi 
panasonic_vvx10f004b00 = {
.lanes = 4,
 };
 
+static const struct drm_display_mode osd101t2045_53ts_mode = {
+   .clock = 154500,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 112,
+   .hsync_end = 1920 + 112 + 16,
+   .htotal = 1920 + 112 + 16 + 32,
+   .vdisplay = 1200,
+   .vsync_start = 1200 + 16,
+   .vsync_end = 1200 + 16 + 2,
+   .vtotal = 1200 + 16 + 2 + 16,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc_dsi osd101t2045_53ts = {
+   .desc = {
+   .modes = _53ts_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_EOT_PACKET,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static const struct of_device_id dsi_of_match[] = {
{
.compatible = "auo,b080uan01",
@@ -3012,6 +3043,9 @@ static const struct of_device_id dsi_of_match[] = {
}, {
.compatible = "panasonic,vvx10f004b00",
.data = _vvx10f004b00
+   }, {
+   .compatible = "osd,osd101t2045-53ts",
+   .data = _53ts
}, {
/* sentinel */
}
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 3/4] dt-bindings: display: Add bindings for OSD101T2587-53TS panel

[Peter Ujfalusi]

This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
1920x1200 panel from One Stop Displays.

Note: the panel is similar to OSD101T2045-53TS, but it needs additional
MIPI_DSI_TURN_ON_PERIPHERAL message from the host.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Rob Herring 
---
 .../display/panel/osd,osd101t2587-53ts.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt 
b/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
new file mode 100644
index ..2082cae1a0e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
@@ -0,0 +1,14 @@
+One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel
+
+The panel is similar to OSD101T2045-53TS, but it needs additional
+MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
+
+Required properties:
+- compatible: should be "osd,osd101t2587-53ts"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v2 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

Hi Sam,

On 23/02/2019 21.38, Sam Ravnborg wrote:
> Hi Peter.
> 
> Driver looks to be in good shape now.
> With the few comments below addressed you can add my:
> Reviewed-by: Sam Ravnborg 
> 
>   Sam
> 
> On Fri, Feb 22, 2019 at 03:16:18PM +0200, Peter Ujfalusi wrote:
>> The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
>> with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
>> message to be sent from the host to be operational and thus can not be
>> handled by panel-simple.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/gpu/drm/panel/Kconfig |   6 +
>>  drivers/gpu/drm/panel/Makefile|   1 +
>>  .../drm/panel/panel-osd-osd101t2587-53ts.c| 254 ++
>>  3 files changed, 261 insertions(+)
>>  create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 3e070153ef21..351661920838 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -122,6 +122,12 @@ config DRM_PANEL_ORISETECH_OTM8009A
>>Say Y here if you want to enable support for Orise Technology
>>otm8009a 480x800 dsi 2dl panel.
>>  
>> +config DRM_PANEL_OSD_OSD101T2587_53TS
>> +tristate "OSD OSD101T2587-53TS DSI 1920x1200 video mode panel"
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +depends on BACKLIGHT_CLASS_DEVICE
> Please add a help-text

Sure, I forgot this.

>> +
>> +static int osd101t2587_panel_unprepare(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +
>> +if (!osd101t2587->prepared)
>> +return 0;
>> +
>> +regulator_disable(osd101t2587->supply);
>> +osd101t2587->prepared = false;
>> +
>> +return 0;
>> +}
>> +
>> +static int osd101t2587_panel_prepare(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +int ret;
>> +
>> +if (osd101t2587->prepared)
>> +return 0;
>> +
>> +ret = regulator_enable(osd101t2587->supply);
>> +if (!ret)
>> +osd101t2587->prepared = true;
> 
> Logic is wrong here. regulator_enable() will return a negative value on error
> and 0 in the good case.
> So osd101t2587->prepared is set to true only in the error case, not in the 
> good case.

It is good as it is:
'if (!0)' == 'if (1)'
'if (!-X)' == 'if (0)'

>> +
>> +ret = mipi_dsi_attach(dsi);
>> +if (ret)
>> +drm_panel_remove(>base);
> 
> I do not see panel-simple.c do a drm_panel_remove() if mipi_dsi_attach() 
> fails.
> Maybe the driver core will call remove() is probe fails?
> Or maybe panel-simple() should call drm_panel_remove()
> 
> Keep the above as is - I just wanted to express that this looks different
> from the panle-simple() driver.

I have a patch for panel-simple as well with the following commit message:
"drm/panel: simple: Fix panel_simple_dsi_probe

In case mipi_dsi_attach() fails remove the registered panel to avoid
added panel without corresponding device."

It has the same bug.

>> +static int osd101t2587_panel_remove(struct mipi_dsi_device *dsi)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = mipi_dsi_get_drvdata(dsi);
>> +int ret;
>> +
>> +ret = osd101t2587_panel_disable(>base);
>> +if (ret < 0)
>> +dev_warn(>dev, "failed to disable panel\n");
> This is already warned in lower layers and I think you could
> drop the dev_warn().

I think there is no warning from lower layer, but not sure as I never
hit this case.

>> +
>> +osd101t2587_panel_unprepare(>base);
>> +
>> +drm_panel_remove(>base);
>> +
>> +ret = mipi_dsi_detach(dsi);
>> +if (ret < 0)
>> +dev_warn(>dev, "failed to detach from DSI host\n");
> Add error code in logging.

OK

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

[Peter Ujfalusi]

Hi Russell,

On 22/02/2019 17.27, Russell King - ARM Linux admin wrote:
>> On BBB McASP is the clock master and as I recall I have tested 44.1, 48
>> KHz at least with 16 and 24 bits.
> 
> Sorry, I wasn't clear enough... is the bus clocked at 32Fs for 16bit
> samples and 64Fs for 24bit samples, or is it 64Fs for both?

Now that I have dug out the board:
Playback of the following formats works w/o plughw conversion:
32KHz/48KHz/96KHz, stereo, 16bit (32fs on bus)
32KHz/48KHz/96KHz, stereo, 24bit (S24_LE or S24_3LE - 48fs on bus)

McASP is only putting the needed amount of bclk on the bus for the given
format - uses params_width() for divider calculation.

>>>> Signed-off-by: Peter Ujfalusi 
>>>> ---
>>>>  drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
>>>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>>>> index 7f34601bb515..72f93802d209 100644
>>>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>>>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>>>> @@ -722,6 +722,9 @@ tda998x_reset(struct tda998x_priv *priv)
>>>>  
>>>>/* Write the default value MUX register */
>>>>reg_write(priv, REG_MUX_VP_VIP_OUT, 0x24);
>>>> +
>>>> +  /* Write the default to I2S_FORMAT register */
>>>> +  reg_write(priv, REG_I2S_FORMAT,   0x00);
>>>>  }
>>>>  
>>>>  /*
>>>> -- 
>>>> Peter
>>>>
>>>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>>>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>>>
>>>>
>>>
>>
>> - Péter
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/3] drm/i2c: tda998x: implement different I2S flavours

[Peter Ujfalusi]

hi Russell,

On 22/02/2019 23.27, Russell King wrote:
> Add support for the left and right justified I2S formats as well as the
> more tranditional "Philips" I2S format.

First of all, thank you for the patch, it works.

Tested-by: Peter Ujfalusi 

There is however one thing I'm not sure about.
the 3.8 kernel configured the page0:0xfc register [1]:
/* select I2S format, and datasize */
reg_write(encoder, REG_I2S_FORMAT, 0x0a);

In theory this should select left_j and set bit3 which does something.
It looks like that the McASP is configured to I2S mode in 3.8 kernel
which would result channel swap at least there (I2S vs left_j).

Do you know what the bit3 is configuring and to what?

[1]
https://github.com/beagleboard/linux/blob/1f2f3402a6e4b8c90148c0ca2fd3acba91738eb3/drivers/gpu/drm/i2c/tda998x_drv.c#L851


> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 57 
> ++-
>  include/drm/i2c/tda998x.h | 11 +---
>  2 files changed, 47 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index a7c39f39793f..645d884fb9e8 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -242,7 +242,9 @@ struct tda998x_priv {
>  # define HVF_CNTRL_1_SEMI_PLANAR  (1 << 6)
>  #define REG_RPT_CNTRL REG(0x00, 0xf0) /* write */
>  #define REG_I2S_FORMATREG(0x00, 0xfc) /* read/write */
> -# define I2S_FORMAT(x)(((x) & 3) << 0)
> +# define I2S_FORMAT_PHILIPS   (0 << 0)
> +# define I2S_FORMAT_LEFT_J(2 << 0)
> +# define I2S_FORMAT_RIGHT_J   (3 << 0)
>  #define REG_AIP_CLKSELREG(0x00, 0xfd) /* write */
>  # define AIP_CLKSEL_AIP_SPDIF  (0 << 3)
>  # define AIP_CLKSEL_AIP_I2S(1 << 3)
> @@ -872,14 +874,14 @@ static int
>  tda998x_configure_audio(struct tda998x_priv *priv,
>   struct tda998x_audio_params *params)
>  {
> - u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
> + u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv, i2s_fmt;
>   u32 n;
>  
>   /* Enable audio ports */
>   reg_write(priv, REG_ENA_AP, params->config);
>  
>   /* Set audio input source */
> - switch (params->format) {
> + switch (params->format & AFMT_MASK) {
>   case AFMT_SPDIF:
>   reg_write(priv, REG_ENA_ACLK, 0);
>   reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
> @@ -907,6 +909,19 @@ tda998x_configure_audio(struct tda998x_priv *priv,
>   cts_n = CTS_N_M(3) | CTS_N_K(3);
>   break;
>   }
> +
> + switch (params->format & AFMT_I2S_MASK) {
> + case AFMT_I2S_LEFT_J:
> + i2s_fmt = I2S_FORMAT_LEFT_J;
> + break;
> + case AFMT_I2S_RIGHT_J:
> + i2s_fmt = I2S_FORMAT_RIGHT_J;
> + break;
> + default:
> + i2s_fmt = I2S_FORMAT_PHILIPS;
> + break;
> + }
> + reg_write(priv, REG_I2S_FORMAT, i2s_fmt);
>   break;
>  
>   default:
> @@ -992,23 +1007,15 @@ static int tda998x_audio_hw_params(struct device *dev, 
> void *data,
>  
>   switch (daifmt->fmt) {
>   case HDMI_I2S:
> - if (daifmt->bit_clk_inv || daifmt->frame_clk_inv ||
> - daifmt->bit_clk_master || daifmt->frame_clk_master) {
> - dev_err(dev, "%s: Bad flags %d %d %d %d\n", __func__,
> - daifmt->bit_clk_inv, daifmt->frame_clk_inv,
> - daifmt->bit_clk_master,
> - daifmt->frame_clk_master);
> - return -EINVAL;
> - }
> - for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> - if (priv->audio_port[i].format == AFMT_I2S)
> - audio.config = priv->audio_port[i].config;
> - audio.format = AFMT_I2S;
> + audio.format = AFMT_I2S | AFMT_I2S_PHILIPS;
> + break;
> + case HDMI_LEFT_J:
> + audio.format = AFMT_I2S | AFMT_I2S_LEFT_J;
> + break;
> + case HDMI_RIGHT_J:
> + audio.format = AFMT_I2S | AFMT_I2S_RIGHT_J;
>   break;
>   case HDMI_SPDIF:
> - for (i = 0; i < ARRAY_SIZE(priv->audio_port); i++)
> - if (priv->audio_port[i].format == AFMT_SPDIF)
> - 

Re: [RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

[Peter Ujfalusi]

Hi Russell,

On 22/02/2019 16.35, Russell King - ARM Linux admin wrote:
> On Fri, Feb 22, 2019 at 03:47:14PM +0200, Peter Ujfalusi wrote:
>> Hi,
>>
>> the original version was sent 14.04.2018:
>> https://patchwork.kernel.org/patch/10344403/
>>
>> Changes since then:
>> - rebased on currentl drm/next
>>
>> The reset value of the register is 0, the soft reset does not reset this
>> register and if other kernel changed this the audio is going to be
>> distorted.
>>
>> It was observed when - accidentally - booted the kernel from eMMC on BBB
>> which is 3.8.13-bone79 and it sets this register to 0x0a. After reboot and
>> tda998x_reset() it remains 0x0a.
> 
> Have you checked whether the input I2S stream is Philips or Left
> Justified?  This is controlled by the LSB two bits.

The am335x-boneblack-common.dtsi configures the link to i2s, which
corresponds to Philips format (the default

> 
> It appears that 3.8.13-bone79 configures the TDA998x for left-
> justified, whereas re-setting these two bits to zero will configure
> it for Philips.

The chip reset value for the register is 0 and software reset will not
reset it if it was modified.

> Bits 3:2 control the data size, but I have no information what their
> values correspond to.

I can not find the register descriptions, can not tell what are the bits
in there.

> Can we nail down what is required for BBB and what it doesn't care
> about.

atm the REG_I2S_FORMAT register needs to be reset to 0.

> and I think we should implement at least setting the I2S
> register format from the hdmi_codec_daifmt data.

Yes, that needs to be done for sure, but without data sheet with
register descriptions I would not attempt to do that.

> It would also be good to know what Fs value(s) BBB uses, and what
> sample sizes you have tested.

On BBB McASP is the clock master and as I recall I have tested 44.1, 48
KHz at least with 16 and 24 bits.

>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>> index 7f34601bb515..72f93802d209 100644
>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -722,6 +722,9 @@ tda998x_reset(struct tda998x_priv *priv)
>>  
>>  /* Write the default value MUX register */
>>  reg_write(priv, REG_MUX_VP_VIP_OUT, 0x24);
>> +
>> +/* Write the default to I2S_FORMAT register */
>> +reg_write(priv, REG_I2S_FORMAT,   0x00);
>>  }
>>  
>>  /*
>> -- 
>> Peter
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
>>
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

[Peter Ujfalusi]

On 22/02/2019 15.47, Peter Ujfalusi wrote:
> Hi,
> 
> the original version was sent 14.04.2018:

17.04.2018

> https://patchwork.kernel.org/patch/10344403/
> 
> Changes since then:
> - rebased on currentl drm/next
> 
> The reset value of the register is 0, the soft reset does not reset this
> register and if other kernel changed this the audio is going to be
> distorted.
> 
> It was observed when - accidentally - booted the kernel from eMMC on BBB
> which is 3.8.13-bone79 and it sets this register to 0x0a. After reboot and
> tda998x_reset() it remains 0x0a.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 7f34601bb515..72f93802d209 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -722,6 +722,9 @@ tda998x_reset(struct tda998x_priv *priv)
>  
>   /* Write the default value MUX register */
>   reg_write(priv, REG_MUX_VP_VIP_OUT, 0x24);
> +
> + /* Write the default to I2S_FORMAT register */
> + reg_write(priv, REG_I2S_FORMAT,   0x00);
>  }
>  
>  /*
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

[Peter Ujfalusi]

Hi,

the original version was sent 14.04.2018:
https://patchwork.kernel.org/patch/10344403/

Changes since then:
- rebased on currentl drm/next

The reset value of the register is 0, the soft reset does not reset this
register and if other kernel changed this the audio is going to be
distorted.

It was observed when - accidentally - booted the kernel from eMMC on BBB
which is 3.8.13-bone79 and it sets this register to 0x0a. After reboot and
tda998x_reset() it remains 0x0a.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 7f34601bb515..72f93802d209 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -722,6 +722,9 @@ tda998x_reset(struct tda998x_priv *priv)
 
/* Write the default value MUX register */
reg_write(priv, REG_MUX_VP_VIP_OUT, 0x24);
+
+   /* Write the default to I2S_FORMAT register */
+   reg_write(priv, REG_I2S_FORMAT,   0x00);
 }
 
 /*
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-osd-osd101t2587-53ts.c| 254 ++
 3 files changed, 261 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e070153ef21..351661920838 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -122,6 +122,12 @@ config DRM_PANEL_ORISETECH_OTM8009A
  Say Y here if you want to enable support for Orise Technology
  otm8009a 480x800 dsi 2dl panel.
 
+config DRM_PANEL_OSD_OSD101T2587_53TS
+   tristate "OSD OSD101T2587-53TS DSI 1920x1200 video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+
 config DRM_PANEL_PANASONIC_VVX10F034N00
tristate "Panasonic VVX10F034N00 1920x1200 video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e7ab71968bbf..d9d99956db0c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += 
panel-kingdisplay-kd097d04.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
 obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
+obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
 obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
diff --git a/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c 
b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
new file mode 100644
index ..196a2a883d17
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct osd101t2587_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+
+   bool prepared;
+   bool enabled;
+
+   const struct drm_display_mode *default_mode;
+};
+
+static inline struct osd101t2587_panel *to_osd101t2587_panel(struct drm_panel 
*panel)
+{
+   return container_of(panel, struct osd101t2587_panel, base);
+}
+
+static int osd101t2587_panel_disable(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+   int ret;
+
+   if (!osd101t2587->enabled)
+   return 0;
+
+   backlight_disable(osd101t2587->backlight);
+
+   ret = mipi_dsi_shutdown_peripheral(osd101t2587->dsi);
+
+   osd101t2587->enabled = false;
+
+   return ret;
+}
+
+static int osd101t2587_panel_unprepare(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+
+   if (!osd101t2587->prepared)
+   return 0;
+
+   regulator_disable(osd101t2587->supply);
+   osd101t2587->prepared = false;
+
+   return 0;
+}
+
+static int osd101t2587_panel_prepare(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+   int ret;
+
+   if (osd101t2587->prepared)
+   return 0;
+
+   ret = regulator_enable(osd101t2587->supply);
+   if (!ret)
+   osd101t2587->prepared = true;
+
+   return ret;
+}
+
+static int osd101t2587_panel_enable(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+   int ret;
+
+   if (osd101t2587->enabled)
+   return 0;
+
+   ret = mipi_dsi_turn_on_peripheral(osd101t2587->dsi);
+   if (ret)
+   return ret;
+
+   backlight_enable(osd101t2587->backlight);
+
+   osd101t2587->enabled = true;
+
+   return ret;
+}
+
+static const struct drm_display_mode default_mode_osd101t2587 = {
+   .clock = 164400,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 152,
+   .hsync_end = 1920 + 152 + 52,
+   .htotal = 1920 + 152 + 52 + 20,
+   .vdisplay = 1200,
+   .vsync_start = 1200 + 24,
+   .vsync_end = 1200 + 24 + 6,
+   .vtota

[PATCH v2 3/4] dt-bindings: display: Add bindings for OSD101T2587-53TS panel

[Peter Ujfalusi]

This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
1920x1200 panel from One Stop Displays.

Note: the panel is similar to OSD101T2045-53TS, but it needs additional
MIPI_DSI_TURN_ON_PERIPHERAL message from the host.

Signed-off-by: Peter Ujfalusi 
---
 .../display/panel/osd,osd101t2587-53ts.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt 
b/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
new file mode 100644
index ..2082cae1a0e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
@@ -0,0 +1,14 @@
+One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel
+
+The panel is similar to OSD101T2045-53TS, but it needs additional
+MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
+
+Required properties:
+- compatible: should be "osd,osd101t2587-53ts"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 2/4] drm/panel: simple: Add support for OSD101T2045-53TS

[Peter Ujfalusi]

Add support for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop
Displays to the panel-simple driver

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/panel/panel-simple.c | 34 
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..0337583ffa49 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2996,6 +2996,37 @@ static const struct panel_desc_dsi 
panasonic_vvx10f004b00 = {
.lanes = 4,
 };
 
+static const struct drm_display_mode osd101t2045_53ts_mode = {
+   .clock = 154500,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 112,
+   .hsync_end = 1920 + 112 + 16,
+   .htotal = 1920 + 112 + 16 + 32,
+   .vdisplay = 1200,
+   .vsync_start = 1200 + 16,
+   .vsync_end = 1200 + 16 + 2,
+   .vtotal = 1200 + 16 + 2 + 16,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc_dsi osd101t2045_53ts = {
+   .desc = {
+   .modes = _53ts_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_EOT_PACKET,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static const struct of_device_id dsi_of_match[] = {
{
.compatible = "auo,b080uan01",
@@ -3012,6 +3043,9 @@ static const struct of_device_id dsi_of_match[] = {
}, {
.compatible = "panasonic,vvx10f004b00",
.data = _vvx10f004b00
+   }, {
+   .compatible = "osd,osd101t2045-53ts",
+   .data = _53ts
}, {
/* sentinel */
}
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

[Peter Ujfalusi]

Hi,

Changes since v1 (only panel-osd-osd101t2587-53ts changed):
- Removed unused members from struct osd101t2587_panel
- Use backlight_enable/backlight_disable
- Use devm_of_find_backlight()
- osd101t2587_of_match table standardized 
- osd101t2587_panel_unprepare() added to shutdown and remove callbacks to turn
  power off
- Fix probe in case mipi_dsi_attach() would fail

Add support for OSD101T2045-53TS and OSD101T2587-53TS from One Stop Displays.

The two panel is similar with one big difference: OSD101T2587-53TS requires the
MIPI_DSI_TURN_ON_PERIPHERAL message, thus can not be handled by panel-simple.

Regards,
Peter
---
Peter Ujfalusi (4):
  dt-bindings: display: Add bindings for OSD101T2045-53TS
  drm/panel: simple: Add support for OSD101T2045-53TS
  dt-bindings: display: Add bindings for OSD101T2587-53TS panel
  drm/panel: Add OSD101T2587-53TS driver

 .../display/panel/osd,osd101t2045-53ts.txt|  11 +
 .../display/panel/osd,osd101t2587-53ts.txt|  14 +
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-osd-osd101t2587-53ts.c| 254 ++
 drivers/gpu/drm/panel/panel-simple.c  |  34 +++
 6 files changed, 320 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
 create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 1/4] dt-bindings: display: Add bindings for OSD101T2045-53TS

[Peter Ujfalusi]

This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
1920x1200 panel from One Stop Displays.

Signed-off-by: Peter Ujfalusi 
---
 .../bindings/display/panel/osd,osd101t2045-53ts.txt   | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt 
b/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
new file mode 100644
index ..b3f6df59f7c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
@@ -0,0 +1,11 @@
+One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
+
+Required properties:
+- compatible: should be "osd,osd101t2045-53ts"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

Hi Sam,

On 20/02/2019 13.52, Sam Ravnborg wrote:
> Hi Peter.
> 
> On Wed, Feb 20, 2019 at 12:39:11PM +0200, Peter Ujfalusi wrote:
>> Hi Sam,
>>
>> On 15/02/2019 20.07, Sam Ravnborg wrote:
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#include 
>>> Please do not use drmP.h in new drivers - we try to get rid of this file.
>>
>> ...
>>
>>>> +static int osd101t2587_panel_get_modes(struct drm_panel *panel)
>>>> +{
>>>> +  struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>>>> +  struct drm_display_mode *mode;
>>>> +
>>>> +  mode = drm_mode_duplicate(panel->drm, osd101t2587->default_mode);
>>>> +  if (!mode) {
>>>> +  dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
>>
>> drm/drmP.h is needed for this dev_err.
> drmP.h is only a set of include files and forwards today.
> So you need to figure out what to replace it with.
> 
> Often removing drmP.h requires you to add more than one extra include file.

Replacing it with
#include 

works perfectly.

Thanks,
- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

Hi Sam,

On 15/02/2019 20.07, Sam Ravnborg wrote:
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
> Please do not use drmP.h in new drivers - we try to get rid of this file.

...

>> +static int osd101t2587_panel_get_modes(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +struct drm_display_mode *mode;
>> +
>> +mode = drm_mode_duplicate(panel->drm, osd101t2587->default_mode);
>> +if (!mode) {
>> +dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",

drm/drmP.h is needed for this dev_err.

Regards,
- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

Hi Sam,

On 15/02/2019 20.07, Sam Ravnborg wrote:
> Hi Peter.
> 
> Good with more panel drivers.
> Some comments in the following, please do not blindly follow them but
> check that this is OK.

First of all, thank you for the review and sorry for the delay!

> 
>   Sam
> 
> On Fri, Feb 15, 2019 at 04:03:15PM +0200, Peter Ujfalusi via dri-devel wrote:
>> The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
>> with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
>> message to be sent from the host to be operational and thus can not be
>> handled by panel-simple.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>> +++ b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
>> @@ -0,0 +1,284 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + *  Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
>> + *  Author: Peter Ujfalusi 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
> Please do not use drmP.h in new drivers - we try to get rid of this file.

OK.

> 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +struct osd101t2587_panel {
>> +struct drm_panel base;
>> +struct mipi_dsi_device *dsi;
>> +
>> +struct backlight_device *backlight;
>> +struct regulator *supply;
>> +
>> +bool prepared;
>> +bool enabled;
>> +
>> +ktime_t earliest_wake;
> earliest_wake is not used, and can be deleted.

Yes, it is leftover.

>> +
>> +const struct drm_display_mode *default_mode;
>> +const struct drm_display_mode *mode;
> Assigned but never used. Drop the assignment and the variable?

Hrm, you are right.

> 
>> +};
>> +
>> +static inline struct osd101t2587_panel *to_osd101t2587_panel(struct 
>> drm_panel *panel)
>> +{
>> +return container_of(panel, struct osd101t2587_panel, base);
>> +}
>> +
>> +static int osd101t2587_panel_disable(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +int ret;
>> +
>> +if (!osd101t2587->enabled)
>> +return 0;
>> +
>> +if (osd101t2587->backlight) {
>> +osd101t2587->backlight->props.power = FB_BLANK_POWERDOWN;
>> +osd101t2587->backlight->props.state |= BL_CORE_FBBLANK;
>> +backlight_update_status(osd101t2587->backlight);
>> +}
> backlight_disable(osd101t2587->backlight);

OK

>> +
>> +ret = mipi_dsi_shutdown_peripheral(osd101t2587->dsi);
>> +
>> +osd101t2587->enabled = false;
>> +
>> +return ret;
>> +}
>> +
>> +static int osd101t2587_panel_unprepare(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +
>> +if (!osd101t2587->prepared)
>> +return 0;
>> +
>> +regulator_disable(osd101t2587->supply);
>> +osd101t2587->prepared = false;
>> +
>> +return 0;
>> +}
>> +
>> +static int osd101t2587_panel_prepare(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +int ret;
>> +
>> +if (osd101t2587->prepared)
>> +return 0;
>> +
>> +ret = regulator_enable(osd101t2587->supply);
>> +if (!ret)
>> +osd101t2587->prepared = true;
>> +
>> +return ret;
>> +}
>> +
>> +static int osd101t2587_panel_enable(struct drm_panel *panel)
>> +{
>> +struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
>> +int ret;
>> +
>> +if (osd101t2587->enabled)
>> +return 0;
>> +
>> +ret = mipi_dsi_turn_on_peripheral(osd101t2587->dsi);
>> +if (ret)
>> +return ret;
>> +
>> +if (osd101t2587->backlight) {
>> +osd101t2587->backlight->props.power = FB_BLANK_UNBLANK;
>> +osd101t2587->backlight->props.state &= ~BL_CORE_FBBLANK;
>> +backlight_update_status(osd101t2587->backlight);
>> +}
> backlight_enable(osd101t2587->backlight);
> can be used here.

Yes, it can be used.

> 
>> +
>> +osd101t2587->enabled = true;
>> +
>> +return ret;
>> +}
>> +
>> +static const struct drm_display_mode default_mode_osd10

[PATCH 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

[Peter Ujfalusi via dri-devel]

Hi,

Add support for OSD101T2045-53TS and OSD101T2587-53TS from One Stop Displays.

The two panel is similar with one big difference: OSD101T2587-53TS requires the
MIPI_DSI_TURN_ON_PERIPHERAL message, thus can not be handled by panel-simple.

Regards,
Peter
---
Peter Ujfalusi (4):
  dt-bindings: display: Add bindings for OSD101T2045-53TS
  drm/panel: simple: Add support for OSD101T2045-53TS
  dt-bindings: display: Add bindings for OSD101T2587-53TS panel
  drm/panel: Add OSD101T2587-53TS driver

 .../display/panel/osd,osd101t2045-53ts.txt|  11 +
 .../display/panel/osd,osd101t2587-53ts.txt|  14 +
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-osd-osd101t2587-53ts.c| 284 ++
 drivers/gpu/drm/panel/panel-simple.c  |  34 +++
 6 files changed, 350 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
 create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 1/4] dt-bindings: display: Add bindings for OSD101T2045-53TS

[Peter Ujfalusi via dri-devel]

This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
1920x1200 panel from One Stop Displays.

Signed-off-by: Peter Ujfalusi 
---
 .../bindings/display/panel/osd,osd101t2045-53ts.txt   | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt 
b/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
new file mode 100644
index ..b3f6df59f7c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/osd,osd101t2045-53ts.txt
@@ -0,0 +1,11 @@
+One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel
+
+Required properties:
+- compatible: should be "osd,osd101t2045-53ts"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi via dri-devel]

The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../drm/panel/panel-osd-osd101t2587-53ts.c| 284 ++
 3 files changed, 291 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e070153ef21..351661920838 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -122,6 +122,12 @@ config DRM_PANEL_ORISETECH_OTM8009A
  Say Y here if you want to enable support for Orise Technology
  otm8009a 480x800 dsi 2dl panel.
 
+config DRM_PANEL_OSD_OSD101T2587_53TS
+   tristate "OSD OSD101T2587-53TS DSI 1920x1200 video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+
 config DRM_PANEL_PANASONIC_VVX10F034N00
tristate "Panasonic VVX10F034N00 1920x1200 video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e7ab71968bbf..d9d99956db0c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += 
panel-kingdisplay-kd097d04.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
 obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
+obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
 obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
diff --git a/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c 
b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
new file mode 100644
index ..6dbdd5b27bfb
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct osd101t2587_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+
+   bool prepared;
+   bool enabled;
+
+   ktime_t earliest_wake;
+
+   const struct drm_display_mode *default_mode;
+   const struct drm_display_mode *mode;
+};
+
+static inline struct osd101t2587_panel *to_osd101t2587_panel(struct drm_panel 
*panel)
+{
+   return container_of(panel, struct osd101t2587_panel, base);
+}
+
+static int osd101t2587_panel_disable(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+   int ret;
+
+   if (!osd101t2587->enabled)
+   return 0;
+
+   if (osd101t2587->backlight) {
+   osd101t2587->backlight->props.power = FB_BLANK_POWERDOWN;
+   osd101t2587->backlight->props.state |= BL_CORE_FBBLANK;
+   backlight_update_status(osd101t2587->backlight);
+   }
+
+   ret = mipi_dsi_shutdown_peripheral(osd101t2587->dsi);
+
+   osd101t2587->enabled = false;
+
+   return ret;
+}
+
+static int osd101t2587_panel_unprepare(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+
+   if (!osd101t2587->prepared)
+   return 0;
+
+   regulator_disable(osd101t2587->supply);
+   osd101t2587->prepared = false;
+
+   return 0;
+}
+
+static int osd101t2587_panel_prepare(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+   int ret;
+
+   if (osd101t2587->prepared)
+   return 0;
+
+   ret = regulator_enable(osd101t2587->supply);
+   if (!ret)
+   osd101t2587->prepared = true;
+
+   return ret;
+}
+
+static int osd101t2587_panel_enable(struct drm_panel *panel)
+{
+   struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
+   int ret;
+
+   if (osd101t2587->enabled)
+   return 0;
+
+   ret = mipi_dsi_turn_on_peripheral(osd101t2587->dsi);
+   if (ret)
+   return ret;
+
+   if (osd101t2587->backlight) {
+   osd101t2587->backlight->props.power = FB_BLANK_UNBLANK;
+   osd101t2587->

[PATCH 3/4] dt-bindings: display: Add bindings for OSD101T2587-53TS panel

[Peter Ujfalusi via dri-devel]

This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
1920x1200 panel from One Stop Displays.

Note: the panel is similar to OSD101T2045-53TS, but it needs additional
MIPI_DSI_TURN_ON_PERIPHERAL message from the host.

Signed-off-by: Peter Ujfalusi 
---
 .../display/panel/osd,osd101t2587-53ts.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt 
b/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
new file mode 100644
index ..2082cae1a0e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/osd,osd101t2587-53ts.txt
@@ -0,0 +1,14 @@
+One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel
+
+The panel is similar to OSD101T2045-53TS, but it needs additional
+MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
+
+Required properties:
+- compatible: should be "osd,osd101t2587-53ts"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 2/4] drm/panel: simple: Add support for OSD101T2045-53TS

[Peter Ujfalusi via dri-devel]

Add support for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop
Displays to the panel-simple driver

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/panel/panel-simple.c | 34 
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..0337583ffa49 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2996,6 +2996,37 @@ static const struct panel_desc_dsi 
panasonic_vvx10f004b00 = {
.lanes = 4,
 };
 
+static const struct drm_display_mode osd101t2045_53ts_mode = {
+   .clock = 154500,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 112,
+   .hsync_end = 1920 + 112 + 16,
+   .htotal = 1920 + 112 + 16 + 32,
+   .vdisplay = 1200,
+   .vsync_start = 1200 + 16,
+   .vsync_end = 1200 + 16 + 2,
+   .vtotal = 1200 + 16 + 2 + 16,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc_dsi osd101t2045_53ts = {
+   .desc = {
+   .modes = _53ts_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   },
+   .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_MODE_EOT_PACKET,
+   .format = MIPI_DSI_FMT_RGB888,
+   .lanes = 4,
+};
+
 static const struct of_device_id dsi_of_match[] = {
{
.compatible = "auo,b080uan01",
@@ -3012,6 +3043,9 @@ static const struct of_device_id dsi_of_match[] = {
}, {
.compatible = "panasonic,vvx10f004b00",
.data = _vvx10f004b00
+   }, {
+   .compatible = "osd,osd101t2045-53ts",
+   .data = _53ts
}, {
/* sentinel */
}
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2] backlight: gpio-backlight: Correct initial power state handling

[Peter Ujfalusi]

The default-on property - or the def_value via legacy pdata) should be
handled as:
if it is 1, the backlight must be enabled (kept enabled)
if it is 0, the backlight must be disabled (kept disabled)

This only works for the case when default-on is set. If it is not set then
the brightness of the backlight is set to 0. Now if the backlight is
enabled by external driver (graphics) the backlight will stay disabled since
the brightness is configured as 0. The backlight will not turn on.

In order to minimize screen flickering during device boot:

The initial brightness should be set to 1.

If booted in non DT mode or no phandle link to the backlight node:
follow the def_value/default-on to select UNBLANK or POWERDOWN

If in DT boot we have phandle link then leave the GPIO in a state which the
bootloader left it and let the user of the backlight to configure it
further.

Signed-off-by: Peter Ujfalusi 
---
Hi,

Changes since v1:
- Implement similiar initial power state handling as pwm backlight have

Regards,
Peter

 drivers/video/backlight/gpio_backlight.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..51c49f03ed83 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -62,13 +62,11 @@ static int gpio_backlight_probe_dt(struct platform_device 
*pdev,
 {
struct device *dev = >dev;
struct device_node *np = dev->of_node;
-   enum gpiod_flags flags;
int ret;
 
gbl->def_value = of_property_read_bool(np, "default-on");
-   flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
 
-   gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
+   gbl->gpiod = devm_gpiod_get(dev, NULL, GPIOD_ASIS);
if (IS_ERR(gbl->gpiod)) {
ret = PTR_ERR(gbl->gpiod);
 
@@ -82,6 +80,22 @@ static int gpio_backlight_probe_dt(struct platform_device 
*pdev,
return 0;
 }
 
+static int gpio_backlight_initial_power_state(struct gpio_backlight *gbl)
+{
+   struct device_node *node = gbl->dev->of_node;
+
+   /* Not booted with device tree or no phandle link to the node */
+   if (!node || !node->phandle)
+   return gbl->def_value ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+
+   /* if the enable GPIO is disabled, do not enable the backlight */
+   if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
+   return FB_BLANK_POWERDOWN;
+
+   return FB_BLANK_UNBLANK;
+}
+
+
 static int gpio_backlight_probe(struct platform_device *pdev)
 {
struct gpio_backlight_platform_data *pdata =
@@ -142,7 +156,9 @@ static int gpio_backlight_probe(struct platform_device 
*pdev)
return PTR_ERR(bl);
}
 
-   bl->props.brightness = gbl->def_value;
+   bl->props.power = gpio_backlight_initial_power_state(gbl);
+   bl->props.brightness = 1;
+
backlight_update_status(bl);
 
platform_set_drvdata(pdev, bl);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH RESEND] backlight: gpio-backlight: Correct initial power state handling

[Peter Ujfalusi]

Daniel,

On 2018-06-13 18:11, Daniel Thompson wrote:
> On 08/05/18 08:04, Peter Ujfalusi wrote:
>> The default-on property - or the def_value via legacy pdata) should be
>> handled as:
>> if it is 1, the backlight must be enabled (kept enabled)
>> if it is 0, the backlight must be disabled (kept disabled)
>>
>> This only works for the case when default-on is set. If it is not set
>> then
>> the brightness of the backlight is set to 0. Now if the backlight is
>> enabled by external driver (graphics) the backlight will stay disabled
>> since
>> the brightness is configured as 0. The backlight will not turn on.
>>
>> The correct action at probe time is to configure the props.power to
>> FB_BLANK_UNBLANK if we want the backlight on by default or to
>> FB_BLANK_POWERDOWN if the backlight should be off by default.
>>
>> The initial brightness should be set to 1.
> 
> Hmnn... I guess this comes down to the definition of "on" for a binary
> 
> Actually I'm a little worried that backlight already has too many
> different behaviors and that this patch introduces another way for them
> to be different!
> 
> Is there any mileage in adopting the same approach as PWM backlight for
> blank/unblank management as a way to get a flicker free boot?

This patch is merely fixing a bug in the driver.

> For PWM the default property controls the initial brightness and the
> initial power state is unblanked *unless* there is a phandle link to the
> node, in which case we inherit whatever the power state the bootloader
> had configured before the driver probed.
> 
> Put another way, what happens is we implement
> gpio_backlight_initial_power_state() to perform a similar task to
> pwm_backlight_initial_power_state().

I agree, but what should we do with the default-on parameter?

non DT boot or DT boot, no phandle link:
default-on ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN

DT boot and phandle link:
if the GPIO was enabled by the bootloader: FB_BLANK_UNBLANK
if the GIOP was not enabled by the bootloader: FB_BLANK_POWERDOWN

I think this will mimic closely what the
pwm_backlight_initial_power_state() does.

- Péter

> 
> 
> Daniel.
> 
> 
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>> Hi,
>>
>> for some reason the original patch got lost:
>> https://patchwork.kernel.org/patch/9445539/
>>
>> But it is still valid, so I'm resending it.
>>
>> Regards,
>> Peter
>>
>>   drivers/video/backlight/gpio_backlight.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/backlight/gpio_backlight.c
>> b/drivers/video/backlight/gpio_backlight.c
>> index e470da95d806..904a4462cefe 100644
>> --- a/drivers/video/backlight/gpio_backlight.c
>> +++ b/drivers/video/backlight/gpio_backlight.c
>> @@ -142,7 +142,9 @@ static int gpio_backlight_probe(struct
>> platform_device *pdev)
>>   return PTR_ERR(bl);
>>   }
>>   -    bl->props.brightness = gbl->def_value;
>> +    bl->props.power = gbl->def_value ? FB_BLANK_UNBLANK :
>> FB_BLANK_POWERDOWN;
>> +    bl->props.brightness = 1;
>> +
>>   backlight_update_status(bl);
>>     platform_set_drvdata(pdev, bl);
>>
> 

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 4/4] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

From: Tomi Valkeinen 

Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.

This patch changes DMM driver to access DMM registers via sDMA. Instead
of doing a normal readl/writel call to read/write a register, we use
sDMA to copy 4 bytes from/to the DMM registers.

This patch provides only a partial workaround for i878, as not only DMM
register reads/writes are affected, but also accesses to the DMM mapped
buffers (framebuffers, usually).

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   7 ++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 149 ++-
 2 files changed, 154 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h 
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index c2785cc98dc9..60bb3f9297bc 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -159,6 +159,7 @@ struct dmm_platform_data {
 
 struct dmm {
struct device *dev;
+   dma_addr_t phys_base;
void __iomem *base;
int irq;
 
@@ -189,6 +190,12 @@ struct dmm {
struct list_head alloc_head;
 
const struct dmm_platform_data *plat_data;
+
+   bool dmm_workaround;
+   spinlock_t wa_lock;
+   u32 *wa_dma_data;
+   dma_addr_t wa_dma_handle;
+   struct dma_chan *wa_dma_chan;
 };
 
 #endif
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index ef9a88c772ed..05723527bec4 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -79,14 +80,138 @@ static const u32 reg[][4] = {
DMM_PAT_DESCR__2, DMM_PAT_DESCR__3},
 };
 
+static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
+{
+   struct dma_device *dma_dev = dmm->wa_dma_chan->device;
+   struct dma_async_tx_descriptor *tx;
+   enum dma_status status;
+   dma_cookie_t cookie;
+
+   tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
+   if (!tx) {
+   dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
+   return -EIO;
+   }
+
+   cookie = tx->tx_submit(tx);
+   if (dma_submit_error(cookie)) {
+   dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
+   return -EIO;
+   }
+
+   dma_async_issue_pending(dmm->wa_dma_chan);
+   status = dma_sync_wait(dmm->wa_dma_chan, cookie);
+   if (status != DMA_COMPLETE)
+   dev_err(dmm->dev, "i878 wa DMA copy failure\n");
+
+   dmaengine_terminate_all(dmm->wa_dma_chan);
+   return 0;
+}
+
+static u32 dmm_read_wa(struct dmm *dmm, u32 reg)
+{
+   dma_addr_t src, dst;
+   int r;
+
+   src = dmm->phys_base + reg;
+   dst = dmm->wa_dma_handle;
+
+   r = dmm_dma_copy(dmm, src, dst);
+   if (r) {
+   dev_err(dmm->dev, "sDMA read transfer timeout\n");
+   return readl(dmm->base + reg);
+   }
+
+   /*
+* As per i878 workaround, the DMA is used to access the DMM registers.
+* Make sure that the readl is not moved by the compiler or the CPU
+* earlier than the DMA finished writing the value to memory.
+*/
+   rmb();
+   return readl(dmm->wa_dma_data);
+}
+
+static void dmm_write_wa(struct dmm *dmm, u32 val, u32 reg)
+{
+   dma_addr_t src, dst;
+   int r;
+
+   writel(val, dmm->wa_dma_data);
+   /*
+* As per i878 workaround, the DMA is used to access the DMM registers.
+* Make sure that the writel is not moved by the compiler or the CPU, so
+* the data will be in place before we start the DMA to do the actual
+* register write.
+*/
+   wmb();
+
+   src = dmm->wa_dma_handle;
+   dst = dmm->phys_base + reg;
+
+   r = dmm_dma_copy(dmm, src, dst);
+   if (r) {
+   dev_err(dmm->dev, "sDMA write transfer timeout\n");
+   writel(val, dmm->base + reg);
+   }
+}
+
 static u32 dmm_read(struct dmm *dmm, u32 reg)
 {
-   return readl(dmm->base + reg);
+   if (dmm->dmm_workaround) {
+   u32 v;
+   unsigned long flags;
+
+   spin_lock_irqsave(>wa_lock, flags);
+   v = dmm_read_wa(dmm, reg);
+   spin_unlock_irqrestore(>wa_lock, flags);
+
+   return v;
+   } else {
+   return readl(dmm->base + reg);
+   }
 }
 
 static void dmm_write(struct dmm *dmm, u32 val, u32 reg)
 {
-   writel(val, dmm->base + reg);
+   if (dmm->dmm_workaround) {
+   unsigned long flags;
+
+

[PATCH v4 0/4] drm/omap: dmm_tiler: fixes and workaround for errata i878

[Peter Ujfalusi]

Hi,

Hi,

Changes since v3:
- Included two fixes for dmm_tiler:
 - fix for memory barrier bug from Tomi
 - correct the ordering of the interrupt request
- dropped the new compatible as the i878 is affecting only dra7 family of SoCs,
  the DMM itself is the same.

Changes since v2:
- Use threaded irq when the i878 workaround is used to avoid unlikely system
  freeze: dma_sync_wait() have 5 second timeout
- Use mutex instead of spinlock as wa_lock
- use the dmaengine_prep_dma_memcpy() wrapper
- do not explicitly call dma_async_issue_pending() as it is done as part of
  dma_sync_wait()
- Use define for the DMM register size (4 bytes)
- Cleanup patch for the remove path: no need to check if the irq is valid. The
  driver would not probe w/o valid interrupt.

Changes since v1:
- rebased on drm-next
- comments for the v1 (https://patchwork.kernel.org/patch/8358741/) addressed
 - u32 -> dma_addr_t when applicable
 - additional wmb()/rmb() added to make sure we have correct behavior

Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.

Regards,
Peter
---
Peter Ujfalusi (2):
  drm/omap: dmm_tiler: No need to check if irq is valid in
omap_dmm_remove
  drm/omap: dmm_tiler: Fix interrupt request/free sequence during
probe/remove

Tomi Valkeinen (2):
  drm/omap: fix memory barrier bug in DMM driver
  drm/omap: partial workaround for DRA7xx DMM errata i878

 drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   7 +
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 201 ---
 2 files changed, 186 insertions(+), 22 deletions(-)

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 2/4] drm/omap: dmm_tiler: No need to check if irq is valid in omap_dmm_remove

[Peter Ujfalusi]

The driver probe would fail if the irq is not available.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index e84871e74615..8671d06c0eb4 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -632,8 +632,7 @@ static int omap_dmm_remove(struct platform_device *dev)
if (omap_dmm->dummy_page)
__free_page(omap_dmm->dummy_page);
 
-   if (omap_dmm->irq > 0)
-   free_irq(omap_dmm->irq, omap_dmm);
+   free_irq(omap_dmm->irq, omap_dmm);
 
iounmap(omap_dmm->base);
kfree(omap_dmm);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 3/4] drm/omap: dmm_tiler: Fix interrupt request/free sequence during probe/remove

[Peter Ujfalusi]

The interrupts should be enabled after the driver initialization to avoid
early interrupts while the driver is not yet ready to handle them.

On removal the interrupts must be disabled before other resources are
released, freed up.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 42 +---
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 8671d06c0eb4..ef9a88c772ed 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -610,6 +610,10 @@ static int omap_dmm_remove(struct platform_device *dev)
unsigned long flags;
 
if (omap_dmm) {
+   /* Disable all enabled interrupts */
+   dmm_write(omap_dmm, 0x7e7e7e7e, DMM_PAT_IRQENABLE_CLR);
+   free_irq(omap_dmm->irq, omap_dmm);
+
/* free all area regions */
spin_lock_irqsave(_lock, flags);
list_for_each_entry_safe(block, _block, _dmm->alloc_head,
@@ -632,8 +636,6 @@ static int omap_dmm_remove(struct platform_device *dev)
if (omap_dmm->dummy_page)
__free_page(omap_dmm->dummy_page);
 
-   free_irq(omap_dmm->irq, omap_dmm);
-
iounmap(omap_dmm->base);
kfree(omap_dmm);
omap_dmm = NULL;
@@ -720,24 +722,6 @@ static int omap_dmm_probe(struct platform_device *dev)
dmm_write(omap_dmm, 0x, DMM_TILER_OR__0);
dmm_write(omap_dmm, 0x, DMM_TILER_OR__1);
 
-   ret = request_irq(omap_dmm->irq, omap_dmm_irq_handler, IRQF_SHARED,
-   "omap_dmm_irq_handler", omap_dmm);
-
-   if (ret) {
-   dev_err(>dev, "couldn't register IRQ %d, error %d\n",
-   omap_dmm->irq, ret);
-   omap_dmm->irq = -1;
-   goto fail;
-   }
-
-   /* Enable all interrupts for each refill engine except
-* ERR_LUT_MISS (which is just advisory, and we don't care
-* about because we want to be able to refill live scanout
-* buffers for accelerated pan/scroll) and FILL_DSC which
-* we just generally don't care about.
-*/
-   dmm_write(omap_dmm, 0x7e7e7e7e, DMM_PAT_IRQENABLE_SET);
-
omap_dmm->dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
if (!omap_dmm->dummy_page) {
dev_err(>dev, "could not allocate dummy page\n");
@@ -829,6 +813,24 @@ static int omap_dmm_probe(struct platform_device *dev)
.p1.y = omap_dmm->container_height - 1,
};
 
+   ret = request_irq(omap_dmm->irq, omap_dmm_irq_handler, IRQF_SHARED,
+   "omap_dmm_irq_handler", omap_dmm);
+
+   if (ret) {
+   dev_err(>dev, "couldn't register IRQ %d, error %d\n",
+   omap_dmm->irq, ret);
+   omap_dmm->irq = -1;
+   goto fail;
+   }
+
+   /* Enable all interrupts for each refill engine except
+* ERR_LUT_MISS (which is just advisory, and we don't care
+* about because we want to be able to refill live scanout
+* buffers for accelerated pan/scroll) and FILL_DSC which
+* we just generally don't care about.
+*/
+   dmm_write(omap_dmm, 0x7e7e7e7e, DMM_PAT_IRQENABLE_SET);
+
/* initialize all LUTs to dummy page entries */
for (i = 0; i < omap_dmm->num_lut; i++) {
area.tcm = omap_dmm->tcm[i];
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 1/4] drm/omap: fix memory barrier bug in DMM driver

[Peter Ujfalusi]

From: Tomi Valkeinen 

A DMM timeout "timed out waiting for done" has been observed on DRA7
devices. The timeout happens rarely, and only when the system is under
heavy load.

Debugging showed that the timeout can be made to happen much more
frequently by optimizing the DMM driver, so that there's almost no code
between writing the last DMM descriptors to RAM, and writing to DMM
register which starts the DMM transaction.

The current theory is that a wmb() does not properly ensure that the
data written to RAM is observable by all the components in the system.

This DMM timeout has caused interesting (and rare) bugs as the error
handling was not functioning properly (the error handling has been fixed
in previous commits):

 * If a DMM timeout happened when a GEM buffer was being pinned for
   display on the screen, a timeout error would be shown, but the driver
   would continue programming DSS HW with broken buffer, leading to
   SYNCLOST floods and possible crashes.

 * If a DMM timeout happened when other user (say, video decoder) was
   pinning a GEM buffer, a timeout would be shown but if the user
   handled the error properly, no other issues followed.

 * If a DMM timeout happened when a GEM buffer was being released, the
   driver does not even notice the error, leading to crashes or hang
   later.

This patch adds wmb() and readl() calls after the last bit is written to
RAM, which should ensure that the execution proceeds only after the data
is actually in RAM, and thus observable by DMM.

The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index f9fa1c90b35c..e84871e74615 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -285,6 +285,17 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
}
 
txn->last_pat->next_pa = 0;
+   /* ensure that the written descriptors are visible to DMM */
+   wmb();
+
+   /*
+* NOTE: the wmb() above should be enough, but there seems to be a bug
+* in OMAP's memory barrier implementation, which in some rare cases may
+* cause the writes not to be observable after wmb().
+*/
+
+   /* read back to ensure the data is in RAM */
+   readl(>last_pat->next_pa);
 
/* write to PAT_DESCR to clear out any pending transaction */
dmm_write(dmm, 0x0, reg[PAT_DESCR][engine->id]);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH] drm/omap: DMM: Fix interrupt request/free sequence during probe/remove

[Peter Ujfalusi]

The interrupts should be enabled after the driver initialization to avoid
early interrupts while the driver is not yet ready to handle them.

On removal the interrupts must be disabled before other resources are
released, freed up.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 45 +---
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index f9fa1c90b35c..b346d1c743e6 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -599,6 +599,12 @@ static int omap_dmm_remove(struct platform_device *dev)
unsigned long flags;
 
if (omap_dmm) {
+   if (omap_dmm->irq > 0) {
+   /* Disable all enabled interrupts */
+   dmm_write(omap_dmm, 0x7e7e7e7e, DMM_PAT_IRQENABLE_CLR);
+   free_irq(omap_dmm->irq, omap_dmm);
+   }
+
/* free all area regions */
spin_lock_irqsave(_lock, flags);
list_for_each_entry_safe(block, _block, _dmm->alloc_head,
@@ -621,9 +627,6 @@ static int omap_dmm_remove(struct platform_device *dev)
if (omap_dmm->dummy_page)
__free_page(omap_dmm->dummy_page);
 
-   if (omap_dmm->irq > 0)
-   free_irq(omap_dmm->irq, omap_dmm);
-
iounmap(omap_dmm->base);
kfree(omap_dmm);
omap_dmm = NULL;
@@ -710,24 +713,6 @@ static int omap_dmm_probe(struct platform_device *dev)
dmm_write(omap_dmm, 0x, DMM_TILER_OR__0);
dmm_write(omap_dmm, 0x, DMM_TILER_OR__1);
 
-   ret = request_irq(omap_dmm->irq, omap_dmm_irq_handler, IRQF_SHARED,
-   "omap_dmm_irq_handler", omap_dmm);
-
-   if (ret) {
-   dev_err(>dev, "couldn't register IRQ %d, error %d\n",
-   omap_dmm->irq, ret);
-   omap_dmm->irq = -1;
-   goto fail;
-   }
-
-   /* Enable all interrupts for each refill engine except
-* ERR_LUT_MISS (which is just advisory, and we don't care
-* about because we want to be able to refill live scanout
-* buffers for accelerated pan/scroll) and FILL_DSC which
-* we just generally don't care about.
-*/
-   dmm_write(omap_dmm, 0x7e7e7e7e, DMM_PAT_IRQENABLE_SET);
-
omap_dmm->dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
if (!omap_dmm->dummy_page) {
dev_err(>dev, "could not allocate dummy page\n");
@@ -819,6 +804,24 @@ static int omap_dmm_probe(struct platform_device *dev)
.p1.y = omap_dmm->container_height - 1,
};
 
+   ret = request_irq(omap_dmm->irq, omap_dmm_irq_handler, IRQF_SHARED,
+   "omap_dmm_irq_handler", omap_dmm);
+
+   if (ret) {
+   dev_err(>dev, "couldn't register IRQ %d, error %d\n",
+   omap_dmm->irq, ret);
+   omap_dmm->irq = -1;
+   goto fail;
+   }
+
+   /* Enable all interrupts for each refill engine except
+* ERR_LUT_MISS (which is just advisory, and we don't care
+* about because we want to be able to refill live scanout
+* buffers for accelerated pan/scroll) and FILL_DSC which
+* we just generally don't care about.
+*/
+   dmm_write(omap_dmm, 0x7e7e7e7e, DMM_PAT_IRQENABLE_SET);
+
/* initialize all LUTs to dummy page entries */
for (i = 0; i < omap_dmm->num_lut; i++) {
area.tcm = omap_dmm->tcm[i];
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH RESEND] backlight: gpio-backlight: Correct initial power state handling

[Peter Ujfalusi]

The default-on property - or the def_value via legacy pdata) should be
handled as:
if it is 1, the backlight must be enabled (kept enabled)
if it is 0, the backlight must be disabled (kept disabled)

This only works for the case when default-on is set. If it is not set then
the brightness of the backlight is set to 0. Now if the backlight is
enabled by external driver (graphics) the backlight will stay disabled since
the brightness is configured as 0. The backlight will not turn on.

The correct action at probe time is to configure the props.power to
FB_BLANK_UNBLANK if we want the backlight on by default or to
FB_BLANK_POWERDOWN if the backlight should be off by default.

The initial brightness should be set to 1.

Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Hi,

for some reason the original patch got lost:
https://patchwork.kernel.org/patch/9445539/

But it is still valid, so I'm resending it.

Regards,
Peter

 drivers/video/backlight/gpio_backlight.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/gpio_backlight.c 
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..904a4462cefe 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -142,7 +142,9 @@ static int gpio_backlight_probe(struct platform_device 
*pdev)
return PTR_ERR(bl);
}
 
-   bl->props.brightness = gbl->def_value;
+   bl->props.power = gbl->def_value ? FB_BLANK_UNBLANK : 
FB_BLANK_POWERDOWN;
+   bl->props.brightness = 1;
+
backlight_update_status(bl);
 
platform_set_drvdata(pdev, bl);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH 0/4] drm/omap: minor fixes

[Peter Ujfalusi]

On 2018-05-02 12:11, Tomi Valkeinen wrote:
> Hi,
> 
> This series has some minor fixes found by a static analysis tool, and one for
> missing linefeeds.  As far as I know, we have never hit any of those errors.

To all:
Reviewed-by: Peter Ujfalusi <peter.ujfal...@ti.com>

> 
>  Tomi
> 
> Tomi Valkeinen (4):
>   drm/omap: check return value from soc_device_match
>   drm/omap: handle error if scale coefs are not found
>   drm/omap: add missing linefeeds to prints
>   drm/omap: handle alloc failures in omap_connector
> 
>  drivers/gpu/drm/omapdrm/dss/dispc.c  | 20 +---
>  drivers/gpu/drm/omapdrm/dss/hdmi4_core.c |  7 ++-
>  drivers/gpu/drm/omapdrm/omap_connector.c | 10 ++
>  3 files changed, 29 insertions(+), 8 deletions(-)
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

[Peter Ujfalusi]

The reset value of the register is 0, the soft reset does not reset this
register and if other kernel changed this the audio is going to be
distorted.

It was observed when - accidentally - booted the kernel from eMMC on BBB
which is 3.8.13-bone79 and it sets this register to 0x0a. After reboot and
tda998x_reset() it remains 0x0a.

Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9e67a7b4e3a4..f1714b270d0e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -588,6 +588,9 @@ tda998x_reset(struct tda998x_priv *priv)
 
/* Write the default value MUX register */
reg_write(priv, REG_MUX_VP_VIP_OUT, 0x24);
+
+   /* Write the default to I2S_FORMAT register */
+   reg_write(priv, REG_I2S_FORMAT,   0x00);
 }
 
 /*
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 2/3] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family

[Peter Ujfalusi]

From: Tomi Valkeinen <tomi.valkei...@ti.com>

Define unique compatible string for the DMM in DRA7xx family.

The new compatible can be used to apply DRA7xx specific workarounds for
ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses)

Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Reviewed-by: Rob Herring <r...@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
 Documentation/devicetree/bindings/arm/omap/dmm.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
index 8bd6d0a238a8..bbbe7cdba30c 100644
--- a/Documentation/devicetree/bindings/arm/omap/dmm.txt
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -8,7 +8,8 @@ translation for initiators which need contiguous dma bus 
addresses.
 
 Required properties:
 - compatible:  Should contain "ti,omap4-dmm" for OMAP4 family
-   Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
+   Should contain "ti,omap5-dmm" for OMAP5 family
+   Should contain "ti,dra7-dmm" for DRA7xx family
 - reg: Contains DMM register address range (base address and length)
 - interrupts:  Should contain an interrupt-specifier for DMM_IRQ.
 - ti,hwmods:   Name of the hwmod associated to DMM, which is typically "dmm"
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 0/3] drm/omap: Workaround for errata i878

[Peter Ujfalusi]

Hi,

Changes since v2:
- Use threaded irq when the i878 workaround is used to avoid unlikely system
  freeze: dma_sync_wait() have 5 second timeout
- Use mutex instead of spinlock as wa_lock
- use the dmaengine_prep_dma_memcpy() wrapper
- do not explicitly call dma_async_issue_pending() as it is done as part of
  dma_sync_wait()
- Use define for the DMM register size (4 bytes)
- Cleanup patch for the remove path: no need to check if the irq is valid. The
  driver would not probe w/o valid interrupt.

Changes since v1:
- rebased on drm-next
- comments for the v1 (https://patchwork.kernel.org/patch/8358741/) addressed
 - u32 -> dma_addr_t when applicable
 - additional wmb()/rmb() added to make sure we have correct behavior

Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.

Regards,
Peter
---
Peter Ujfalusi (1):
  drm/omap: dmm_tiler: No need to check if irq is valid in
omap_dmm_remove

Tomi Valkeinen (2):
  dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family
  drm/omap: partial workaround for DRA7xx DMM errata i878

 .../devicetree/bindings/arm/omap/dmm.txt  |   3 +-
 drivers/gpu/drm/omapdrm/omap_dmm_priv.h   |   8 +
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c  | 164 +-
 3 files changed, 168 insertions(+), 7 deletions(-)

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 1/3] drm/omap: dmm_tiler: No need to check if irq is valid in omap_dmm_remove

[Peter Ujfalusi]

The driver probe would fail if the irq is not available.

Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index e84871e74615..8671d06c0eb4 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -632,8 +632,7 @@ static int omap_dmm_remove(struct platform_device *dev)
if (omap_dmm->dummy_page)
__free_page(omap_dmm->dummy_page);
 
-   if (omap_dmm->irq > 0)
-   free_irq(omap_dmm->irq, omap_dmm);
+   free_irq(omap_dmm->irq, omap_dmm);
 
iounmap(omap_dmm->base);
kfree(omap_dmm);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v3 3/3] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

From: Tomi Valkeinen <tomi.valkei...@ti.com>

Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.

This patch changes:
- DMM driver to access DMM registers via sDMA. Instead of doing a normal
readl/writel call to read/write a register, we use sDMA to copy 4 bytes
from/to the DMM registers.
- When the i878 workaround is needed we use threaded irq. It is not a good
practice to busy loop for completion of the DMA register access in the
interrupt handler. The DMA transfer should not take long time to complete,
but if something prevents the transfer to be completed we might end up
waiting for 5 seconds.

This patch provides only a partial workaround for i878, as not only DMM
register reads/writes are affected, but also accesses to the DMM mapped
buffers (framebuffers, usually).

Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
 drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   8 ++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 161 ++-
 2 files changed, 165 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h 
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index c2785cc98dc9..a0164652db1e 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -155,10 +155,12 @@ struct refill_engine {
 
 struct dmm_platform_data {
u32 cpu_cache_flags;
+   bool errata_i878_wa;
 };
 
 struct dmm {
struct device *dev;
+   dma_addr_t phys_base;
void __iomem *base;
int irq;
 
@@ -189,6 +191,12 @@ struct dmm {
struct list_head alloc_head;
 
const struct dmm_platform_data *plat_data;
+
+   bool dmm_workaround;
+   struct mutex wa_lock;
+   u32 *wa_dma_data;
+   dma_addr_t wa_dma_handle;
+   struct dma_chan *wa_dma_chan;
 };
 
 #endif
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 8671d06c0eb4..fad55f2faa47 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -18,12 +18,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include  /* platform_device() */
 #include 
 #include 
@@ -70,6 +72,7 @@ static const struct {
[TILFMT_PAGE]  = GEOM(SLOT_WIDTH_BITS, SLOT_HEIGHT_BITS, 1),
 };
 
+#define DMM_REG_SIZE   4
 
 /* lookup table for registers w/ per-engine instances */
 static const u32 reg[][4] = {
@@ -79,14 +82,135 @@ static const u32 reg[][4] = {
DMM_PAT_DESCR__2, DMM_PAT_DESCR__3},
 };
 
+static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
+{
+   struct dma_async_tx_descriptor *tx;
+   enum dma_status status;
+   dma_cookie_t cookie;
+
+   tx = dmaengine_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
+   if (!tx) {
+   dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
+   return -EIO;
+   }
+
+   cookie = tx->tx_submit(tx);
+   if (dma_submit_error(cookie)) {
+   dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
+   return -EIO;
+   }
+
+   status = dma_sync_wait(dmm->wa_dma_chan, cookie);
+   if (status != DMA_COMPLETE)
+   dev_err(dmm->dev, "i878 wa DMA copy failure\n");
+
+   dmaengine_terminate_all(dmm->wa_dma_chan);
+   return 0;
+}
+
+static u32 dmm_read_wa(struct dmm *dmm, u32 reg)
+{
+   dma_addr_t src, dst;
+   int r;
+
+   src = dmm->phys_base + reg;
+   dst = dmm->wa_dma_handle;
+
+   r = dmm_dma_copy(dmm, src, dst);
+   if (r) {
+   dev_err(dmm->dev, "sDMA read transfer timeout\n");
+   return readl(dmm->base + reg);
+   }
+
+   /*
+* As per i878 workaround, the DMA is used to access the DMM registers.
+* Make sure that the readl is not moved by the compiler or the CPU
+* earlier than the DMA finished writing the value to memory.
+*/
+   rmb();
+   return readl(dmm->wa_dma_data);
+}
+
+static void dmm_write_wa(struct dmm *dmm, u32 val, u32 reg)
+{
+   dma_addr_t src, dst;
+   int r;
+
+   writel(val, dmm->wa_dma_data);
+   /*
+* As per i878 workaround, the DMA is used to access the DMM registers.
+* Make sure that the writel is not moved by the compiler or the CPU, so
+* the data will be in place before we start the DMA to do the actual
+* register write.
+*/
+   wmb();
+
+   src = dmm->wa_dma_handle;
+   dst = dmm->phys_base + reg;
+
+   r = dmm_dma_copy(dmm, src, dst);
+   if (r) {
+   dev_err(dmm->dev, "sDMA write transfer timeout\

Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

Hi Laurent,

On 2018-04-04 00:11, Laurent Pinchart wrote:
>> +static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
>> +{
>> +struct dma_device *dma_dev = dmm->wa_dma_chan->device;
>> +struct dma_async_tx_descriptor *tx;
>> +enum dma_status status;
>> +dma_cookie_t cookie;
>> +
>> +tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
>> +if (!tx) {
>> +dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
>> +return -EIO;
>> +}
>> +
>> +cookie = tx->tx_submit(tx);
>> +if (dma_submit_error(cookie)) {
>> +dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
>> +return -EIO;
>> +}
>> +
>> +dma_async_issue_pending(dmm->wa_dma_chan);
>> +status = dma_sync_wait(dmm->wa_dma_chan, cookie);
> 
> dma_sync_wait() has a 5s timeout. You're calling this function with a 
> spinlock 
> held. The end result might be slightly better than a complete system lock as 
> caused by the bug described in i878, but only slightly.
> 
> Unless I'm mistaken the reason you can't sleep here is because of the need to 
> access registers in the interrupt handler. Could we use threaded IRQs to 
> solve 
> this ?

You are right that dma_sync_wait() have 5s timeout. But it is theoretical in 
this case as the DMA would finish the transfer way faster. As and experiment I 
have tried this change:

@@ -86,6 +87,7 @@ static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, 
dma_addr_t dst)
struct dma_async_tx_descriptor *tx;
enum dma_status status;
dma_cookie_t cookie;
+   unsigned int tout = 0;
 
tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
if (!tx) {
@@ -99,10 +101,19 @@ static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, 
dma_addr_t dst)
return -EIO;
}
 
+   dev_err(dmm->dev, "i878 dma_async_issue_pending()\n");
dma_async_issue_pending(dmm->wa_dma_chan);
-   status = dma_sync_wait(dmm->wa_dma_chan, cookie);
+   do {
+   status = dmaengine_tx_status(dmm->wa_dma_chan, cookie, NULL);
+   if (status == DMA_COMPLETE)
+   break;
+   cpu_relax();
+   } while (tout++ < 50);
+
if (status != DMA_COMPLETE)
dev_err(dmm->dev, "i878 wa DMA copy failure\n");
+   else
+   dev_err(dmm->dev, "i878 wa DMA copy OK (tout: %u)\n", tout);
 
dmaengine_terminate_all(dmm->wa_dma_chan);
return 0;
@@ -286,6 +298,7 @@ static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
u32 status = dmm_read(dmm, DMM_PAT_IRQSTATUS);
int i;
 
+   dev_err(dmm->dev, "%s - ENTER\n", __func__);
/* ack IRQ */
dmm_write(dmm, status, DMM_PAT_IRQSTATUS);
 
@@ -305,6 +318,7 @@ static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
status >>= 8;
}
 
+   dev_err(dmm->dev, "%s - LEAVE\n", __func__);
return IRQ_HANDLED;
 }

and get:
[   58.690093 <0.005598>] dmm 4e00.dmm: omap_dmm_irq_handler - ENTER
[   58.695601 <0.005508>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.701284 <0.005683>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[   58.706881 <0.005597>] dmm 4e00.dmm: omap_dmm_irq_handler - LEAVE
[   58.712465 <0.005584>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.718150 <0.005685>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 0)
[   58.724575 <0.006425>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.730260 <0.005685>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[   58.735872 <0.005612>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.741554 <0.005682>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 2)
[   58.747174 <0.005620>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.752857 <0.005683>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 2)
[   58.758452 <0.005595>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.764137 <0.005685>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[   58.769731 <0.005594>] dmm 4e00.dmm: omap_dmm_irq_handler - ENTER
[   58.775237 <0.005506>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.780919 <0.005682>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 2)
[   58.786515 <0.005596>] dmm 4e00.dmm: omap_dmm_irq_handler - LEAVE
[   58.786545 <0.30>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.797698 <0.011153>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[   58.811454 <0.013756>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.817149 <0.005695>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 0)
[   58.823160 <0.006011>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   58.828846 <0.005686>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 0)
[   58.834761 <0.005915>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[   

Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

On 2018-03-29 13:18, Tomi Valkeinen wrote:
> On 22/03/18 15:42, Peter Ujfalusi wrote:
>> From: Tomi Valkeinen <tomi.valkei...@ti.com>
>>
>> Errata i878 says that MPU should not be used to access RAM and DMM at
>> the same time. As it's not possible to prevent MPU accessing RAM, we
>> need to access DMM via a proxy.
>>
>> This patch changes DMM driver to access DMM registers via sDMA. Instead
>> of doing a normal readl/writel call to read/write a register, we use
>> sDMA to copy 4 bytes from/to the DMM registers.
>>
>> This patch provides only a partial workaround for i878, as not only DMM
>> register reads/writes are affected, but also accesses to the DMM mapped
>> buffers (framebuffers, usually).
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
>> ---
>>  drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   8 ++
>>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 153 
>> ++-
>>  2 files changed, 159 insertions(+), 2 deletions(-)
>>
> 
> 
>> +dmm->wa_dma_chan = dma_request_channel(mask, NULL, NULL);
>> +if (!dmm->wa_dma_chan) {
>> +dma_free_coherent(dmm->dev, 4, dmm->wa_dma_data, 
>> dmm->wa_dma_handle);
> 
> This and the other free below should use sizeof(u32) as the alloc does.
> And I guess device_prep_dma_memcpy() too. Perhaps a #define would be
> best here. DMM_REG_SIZE? I can do this change when applying, if you agree.

Oh, there were others, I have changed it for dma_alloc_coherent().
I'll wait for couple of days for other comments and will resend with a
#define

> 
>  Tomi
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/6] drm: zpos normalization cleanup and omapdrm to use it

[Peter Ujfalusi]

On 2018-03-28 12:30, Tomi Valkeinen wrote:
> Hi,
> 
> On 06/02/18 14:05, Peter Ujfalusi wrote:
>> Hi,
>>
>> Changes since v3:
>> - Moved the new normalize_zpos bool to be around another bools
>> - Extended the commit message for sti that the drm_atomic_helper_check() is
>>   going to ask for async_update due to the legacy cursor usage.
>>
>> Changes since v2:
>> - Fixed commit messages (s/drm_device/drm_mode_config)
>> - Added ack from Benjamin Gaignard to drm/sti patch
>>
>> Changes since v1:
>> - normalize_zpos flag moved to drm_mode_config
>> - Added comment to note the side effect of normalization and updated the 
>> comment
>>   for normalized_zpos in the header file as well.
>> - Added Acked-by from Daniel to patch 2-6 but not for patch 1 as I'm not 
>> sure if
>>   the comments I have added matches with what is expected to be.
>>
>> The first patch is adding a flag to drm_device that drivers can set if they 
>> want
>> the zpos to be normalized.
>>
>> Then convert exynos, tegra, sti and rcar-du to use this flag instead of
>> re-implementing the drm_atomic_helper_check() locally just to add the call to
>> drm_atomic_normalize_zpos().
>>
>> The last patch is moving omapdrm to use the zpos normalization as well to 
>> comply
>> with the UAPI documentation regarding to zpos.
>>
>> Laurent's note in an earlier thread:
>> https://marc.info/?l=dri-devel=151567355225029=2
>>
>> "The problem is that zpos normalization requires accessing the state of all 
>> enabled planes for a CRTC in order to compute (and store) the normalized 
>> zpos 
>> values. This thus forces all planes to be added to the commit state, even 
>> when 
>> the commit doesn't touch the zpos property. I assume this caused issues 
>> (possibly performance issues) in drivers that then performed hardware setup 
>> of 
>> all planes as a result."
>>
>> can be addressed later in the core for all users of 
>> drm_atomic_normalize_zpos()
> 
> Thanks. I think this looks fine, I'll push via drm-misc.

There is v5 on the list.

> 
>  Tomi
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/omap: fix memory barrier bug in DMM driver

[Peter Ujfalusi]

From: Tomi Valkeinen <tomi.valkei...@ti.com>

A DMM timeout "timed out waiting for done" has been observed on DRA7
devices. The timeout happens rarely, and only when the system is under
heavy load.

Debugging showed that the timeout can be made to happen much more
frequently by optimizing the DMM driver, so that there's almost no code
between writing the last DMM descriptors to RAM, and writing to DMM
register which starts the DMM transaction.

The current theory is that a wmb() does not properly ensure that the
data written to RAM is observable by all the components in the system.

This DMM timeout has caused interesting (and rare) bugs as the error
handling was not functioning properly (the error handling has been fixed
in previous commits):

 * If a DMM timeout happened when a GEM buffer was being pinned for
   display on the screen, a timeout error would be shown, but the driver
   would continue programming DSS HW with broken buffer, leading to
   SYNCLOST floods and possible crashes.

 * If a DMM timeout happened when other user (say, video decoder) was
   pinning a GEM buffer, a timeout would be shown but if the user
   handled the error properly, no other issues followed.

 * If a DMM timeout happened when a GEM buffer was being released, the
   driver does not even notice the error, leading to crashes or hang
   later.

This patch adds wmb() and readl() calls after the last bit is written to
RAM, which should ensure that the execution proceeds only after the data
is actually in RAM, and thus observable by DMM.

The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.

Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index c40f90d2db82..27c67bc36203 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -410,6 +410,17 @@ static int dmm_txn_commit(struct dmm_txn *txn, bool wait)
}
 
txn->last_pat->next_pa = 0;
+   /* ensure that the written descriptors are visible to DMM */
+   wmb();
+
+   /*
+* NOTE: the wmb() above should be enough, but there seems to be a bug
+* in OMAP's memory barrier implementation, which in some rare cases may
+* cause the writes not to be observable after wmb().
+*/
+
+   /* read back to ensure the data is in RAM */
+   readl(>last_pat->next_pa);
 
/* write to PAT_DESCR to clear out any pending transaction */
dmm_write(dmm, 0x0, reg[PAT_DESCR][engine->id]);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v2 1/2] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family

[Peter Ujfalusi]

On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen <tomi.valkei...@ti.com>
> 
> Define unique compatible string for the DMM in DRA7xx family.
> 
> The new compatible can be used to apply DRA7xx specific workarounds for
> ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses)
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>

I have failed to add:
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>

> ---
>  Documentation/devicetree/bindings/arm/omap/dmm.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
> b/Documentation/devicetree/bindings/arm/omap/dmm.txt
> index 8bd6d0a238a8..bbbe7cdba30c 100644
> --- a/Documentation/devicetree/bindings/arm/omap/dmm.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
> @@ -8,7 +8,8 @@ translation for initiators which need contiguous dma bus 
> addresses.
>  
>  Required properties:
>  - compatible:Should contain "ti,omap4-dmm" for OMAP4 family
> - Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
> + Should contain "ti,omap5-dmm" for OMAP5 family
> + Should contain "ti,dra7-dmm" for DRA7xx family
>  - reg:   Contains DMM register address range (base address and 
> length)
>  - interrupts:Should contain an interrupt-specifier for DMM_IRQ.
>  - ti,hwmods: Name of the hwmod associated to DMM, which is typically "dmm"
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen <tomi.valkei...@ti.com>
> 
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a proxy.
> 
> This patch changes DMM driver to access DMM registers via sDMA. Instead
> of doing a normal readl/writel call to read/write a register, we use
> sDMA to copy 4 bytes from/to the DMM registers.
> 
> This patch provides only a partial workaround for i878, as not only DMM
> register reads/writes are affected, but also accesses to the DMM mapped
> buffers (framebuffers, usually).
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>

I have failed to add:
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>

> ---
>  drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   8 ++
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 153 
> ++-
>  2 files changed, 159 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h 
> b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> index c2785cc98dc9..9ce9d1d7039a 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
> @@ -155,10 +155,12 @@ struct refill_engine {
>  
>  struct dmm_platform_data {
>   u32 cpu_cache_flags;
> + bool errata_i878_wa;
>  };
>  
>  struct dmm {
>   struct device *dev;
> + dma_addr_t phys_base;
>   void __iomem *base;
>   int irq;
>  
> @@ -189,6 +191,12 @@ struct dmm {
>   struct list_head alloc_head;
>  
>   const struct dmm_platform_data *plat_data;
> +
> + bool dmm_workaround;
> + spinlock_t wa_lock;
> + u32 *wa_dma_data;
> + dma_addr_t wa_dma_handle;
> + struct dma_chan *wa_dma_chan;
>  };
>  
>  #endif
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index e84871e74615..27c67bc36203 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -79,14 +80,138 @@ static const u32 reg[][4] = {
>   DMM_PAT_DESCR__2, DMM_PAT_DESCR__3},
>  };
>  
> +static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
> +{
> + struct dma_device *dma_dev = dmm->wa_dma_chan->device;
> + struct dma_async_tx_descriptor *tx;
> + enum dma_status status;
> + dma_cookie_t cookie;
> +
> + tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
> + if (!tx) {
> + dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
> + return -EIO;
> + }
> +
> + cookie = tx->tx_submit(tx);
> + if (dma_submit_error(cookie)) {
> + dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
> + return -EIO;
> + }
> +
> + dma_async_issue_pending(dmm->wa_dma_chan);
> + status = dma_sync_wait(dmm->wa_dma_chan, cookie);
> + if (status != DMA_COMPLETE)
> + dev_err(dmm->dev, "i878 wa DMA copy failure\n");
> +
> + dmaengine_terminate_all(dmm->wa_dma_chan);
> + return 0;
> +}
> +
> +static u32 dmm_read_wa(struct dmm *dmm, u32 reg)
> +{
> + dma_addr_t src, dst;
> + int r;
> +
> + src = dmm->phys_base + reg;
> + dst = dmm->wa_dma_handle;
> +
> + r = dmm_dma_copy(dmm, src, dst);
> + if (r) {
> + dev_err(dmm->dev, "sDMA read transfer timeout\n");
> + return readl(dmm->base + reg);
> + }
> +
> + /*
> +  * As per i878 workaround, the DMA is used to access the DMM registers.
> +  * Make sure that the readl is not moved by the compiler or the CPU
> +  * earlier than the DMA finished writing the value to memory.
> +  */
> + rmb();
> + return readl(dmm->wa_dma_data);
> +}
> +
> +static void dmm_write_wa(struct dmm *dmm, u32 val, u32 reg)
> +{
> + dma_addr_t src, dst;
> + int r;
> +
> + writel(val, dmm->wa_dma_data);
> + /*
> +  * As per i878 workaround, the DMA is used to access the DMM registers.
> +  * Make sure that the writel is not moved by the compiler or the CPU, so
> +  * the data will be in place before we start the DMA to do the actual
> +  * register write.
> +  */
> + wmb();
> +
> + src = dmm->wa_dma_handle;
> + dst = dmm->phys_base + reg;
> +
> +

[PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

From: Tomi Valkeinen 

Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.

This patch changes DMM driver to access DMM registers via sDMA. Instead
of doing a normal readl/writel call to read/write a register, we use
sDMA to copy 4 bytes from/to the DMM registers.

This patch provides only a partial workaround for i878, as not only DMM
register reads/writes are affected, but also accesses to the DMM mapped
buffers (framebuffers, usually).

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   8 ++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 153 ++-
 2 files changed, 159 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h 
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index c2785cc98dc9..9ce9d1d7039a 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -155,10 +155,12 @@ struct refill_engine {
 
 struct dmm_platform_data {
u32 cpu_cache_flags;
+   bool errata_i878_wa;
 };
 
 struct dmm {
struct device *dev;
+   dma_addr_t phys_base;
void __iomem *base;
int irq;
 
@@ -189,6 +191,12 @@ struct dmm {
struct list_head alloc_head;
 
const struct dmm_platform_data *plat_data;
+
+   bool dmm_workaround;
+   spinlock_t wa_lock;
+   u32 *wa_dma_data;
+   dma_addr_t wa_dma_handle;
+   struct dma_chan *wa_dma_chan;
 };
 
 #endif
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index e84871e74615..27c67bc36203 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -79,14 +80,138 @@ static const u32 reg[][4] = {
DMM_PAT_DESCR__2, DMM_PAT_DESCR__3},
 };
 
+static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
+{
+   struct dma_device *dma_dev = dmm->wa_dma_chan->device;
+   struct dma_async_tx_descriptor *tx;
+   enum dma_status status;
+   dma_cookie_t cookie;
+
+   tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
+   if (!tx) {
+   dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
+   return -EIO;
+   }
+
+   cookie = tx->tx_submit(tx);
+   if (dma_submit_error(cookie)) {
+   dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
+   return -EIO;
+   }
+
+   dma_async_issue_pending(dmm->wa_dma_chan);
+   status = dma_sync_wait(dmm->wa_dma_chan, cookie);
+   if (status != DMA_COMPLETE)
+   dev_err(dmm->dev, "i878 wa DMA copy failure\n");
+
+   dmaengine_terminate_all(dmm->wa_dma_chan);
+   return 0;
+}
+
+static u32 dmm_read_wa(struct dmm *dmm, u32 reg)
+{
+   dma_addr_t src, dst;
+   int r;
+
+   src = dmm->phys_base + reg;
+   dst = dmm->wa_dma_handle;
+
+   r = dmm_dma_copy(dmm, src, dst);
+   if (r) {
+   dev_err(dmm->dev, "sDMA read transfer timeout\n");
+   return readl(dmm->base + reg);
+   }
+
+   /*
+* As per i878 workaround, the DMA is used to access the DMM registers.
+* Make sure that the readl is not moved by the compiler or the CPU
+* earlier than the DMA finished writing the value to memory.
+*/
+   rmb();
+   return readl(dmm->wa_dma_data);
+}
+
+static void dmm_write_wa(struct dmm *dmm, u32 val, u32 reg)
+{
+   dma_addr_t src, dst;
+   int r;
+
+   writel(val, dmm->wa_dma_data);
+   /*
+* As per i878 workaround, the DMA is used to access the DMM registers.
+* Make sure that the writel is not moved by the compiler or the CPU, so
+* the data will be in place before we start the DMA to do the actual
+* register write.
+*/
+   wmb();
+
+   src = dmm->wa_dma_handle;
+   dst = dmm->phys_base + reg;
+
+   r = dmm_dma_copy(dmm, src, dst);
+   if (r) {
+   dev_err(dmm->dev, "sDMA write transfer timeout\n");
+   writel(val, dmm->base + reg);
+   }
+}
+
 static u32 dmm_read(struct dmm *dmm, u32 reg)
 {
-   return readl(dmm->base + reg);
+   if (dmm->dmm_workaround) {
+   u32 v;
+   unsigned long flags;
+
+   spin_lock_irqsave(>wa_lock, flags);
+   v = dmm_read_wa(dmm, reg);
+   spin_unlock_irqrestore(>wa_lock, flags);
+
+   return v;
+   } else {
+   return readl(dmm->base + reg);
+   }
 }
 
 static void dmm_write(struct dmm *dmm, u32 val, u32 reg)
 {
-   writel(val, dmm->base + reg);
+   if (dmm->dmm_workaround) {
+   unsigned long flags;
+
+