[PATCH v2 0/4] Fixes for omapdrm on OpenPandora and GTA04

[PATCH v2 0/4] Fixes for omapdrm on OpenPandora and GTA04

[H. Nikolaus Schaller]

V2:
* replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent Pinchart
* keep previous compatibility option in panel driver to handle older device tree binaries

2017-11-08 22:09:36:
This patch set fixes vendor names of the panels
and fixes a problem on omapdrm with enabling
VDD_DSI for OMAP3 which is needed for displaying
the Red and Green channel on OMAP3530 (Pandora).

H. Nikolaus Schaller (3):
  omapdrm: fix compatible string for td028ttec1
  DTS: GTA04: fix panel compatibility string
  DTS: Pandora: fix panel compatibility string

Laurent Pinchart (1):
  drm: omapdrm: Fix DPI on platforms using the DSI VDDS

 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}      | 4 ++--
 arch/arm/boot/dts/omap3-gta04.dtsi                                    | 2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi                           | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c               | 4 ++--
 drivers/gpu/drm/omapdrm/dss/dpi.c                                     | 4 ++--
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c      | 4 +++-
 6 files changed, 11 insertions(+), 9 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} (84%)

-- 
2.12.2

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

The vendor name was "toppoly" but other panels and the vendor list
have defined it as "tpo". So let's fix it in driver and bindings.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}      | 4 ++--
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c               | 4 ++--
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c      | 4 +++-
 3 files changed, 7 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} (84%)

diff --git a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
similarity index 84%
rename from Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
rename to Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
index 7175dc3740ac..ed34253d9fb1 100644
--- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
+++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
@@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
 ========================
 
 Required properties:
-- compatible: "toppoly,td028ttec1"
+- compatible: "tpo,td028ttec1"
 
 Optional properties:
 - label: a symbolic name for the panel
@@ -14,7 +14,7 @@ Example
 -------
 
 lcd-panel: td028ttec1 at 0 {
-	compatible = "toppoly,td028ttec1";
+	compatible = "tpo,td028ttec1";
 	reg = <0>;
 	spi-max-frequency = <100000>;
 	spi-cpol;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index 0a38a0e8c925..2dab491478c2 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -452,7 +452,7 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
-	{ .compatible = "omapdss,toppoly,td028ttec1", },
+	{ .compatible = "omapdss,tpo,td028ttec1", },
 	{},
 };
 
@@ -471,7 +471,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:toppoly,td028ttec1");
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller <hns@goldelico.com>");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index 57e9e146ff74..b67b324e9919 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -455,6 +455,8 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
+	{ .compatible = "omapdss,tpo,td028ttec1", },
+	/* keep to not break older DTB */
 	{ .compatible = "omapdss,toppoly,td028ttec1", },
 	{},
 };
@@ -474,7 +476,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:toppoly,td028ttec1");
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller <hns@goldelico.com>");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
-- 
2.12.2

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[Tomi Valkeinen]

On 16/11/17 10:50, H. Nikolaus Schaller wrote:
> The vendor name was "toppoly" but other panels and the vendor list
> have defined it as "tpo". So let's fix it in driver and bindings.
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---


> -MODULE_ALIAS("spi:toppoly,td028ttec1");
> +MODULE_ALIAS("spi:tpo,td028ttec1");

Doesn't this mean that the module won't load if you have old bindings?
Can't we have two module aliases?

 Tomi

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

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
> 
> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>> The vendor name was "toppoly" but other panels and the vendor list
>> have defined it as "tpo". So let's fix it in driver and bindings.
>> 
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
> 
> 
>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>> +MODULE_ALIAS("spi:tpo,td028ttec1");
> 
> Doesn't this mean that the module won't load if you have old bindings?

Hm.

Well, I think it can load but doesn't automatically from DT strings which might
be unexpected.

> Can't we have two module aliases?

I think we can. Just a random example:
https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754

So we should keep both.

Should I submit a new version?

BR,
Nikolaus

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[Andrew F. Davis]

On 11/16/2017 07:43 AM, H. Nikolaus Schaller wrote:
> 
>> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>
>> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>>> The vendor name was "toppoly" but other panels and the vendor list
>>> have defined it as "tpo". So let's fix it in driver and bindings.
>>>
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> ---
>>
>>
>>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>>
>> Doesn't this mean that the module won't load if you have old bindings?
> 
> Hm.
> 
> Well, I think it can load but doesn't automatically from DT strings which might
> be unexpected.
> 
>> Can't we have two module aliases?
> 
> I think we can. Just a random example:
> https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754
> 
> So we should keep both.

Even better would be to drop both MODULE_ALIAS and let the
MODULE_DEVICE_TABLE macro define them for your from the SPI id table.
Although it doesn't look like this driver has an SPI id table, you
should probably add one, I be interested to see if this module is always
being matched through the "spi" or the "of" alias..

> 
> Should I submit a new version?
> 
> BR,
> Nikolaus
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

Hi Andrew,

> Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <afd@ti.com>:
> 
> On 11/16/2017 07:43 AM, H. Nikolaus Schaller wrote:
>> 
>>> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>> 
>>> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>>>> The vendor name was "toppoly" but other panels and the vendor list
>>>> have defined it as "tpo". So let's fix it in driver and bindings.
>>>> 
>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>> ---
>>> 
>>> 
>>>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>>>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>>> 
>>> Doesn't this mean that the module won't load if you have old bindings?
>> 
>> Hm.
>> 
>> Well, I think it can load but doesn't automatically from DT strings which might
>> be unexpected.
>> 
>>> Can't we have two module aliases?
>> 
>> I think we can. Just a random example:
>> https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754
>> 
>> So we should keep both.
> 
> Even better would be to drop both MODULE_ALIAS and let the
> MODULE_DEVICE_TABLE macro define them for your from the SPI id table.

Why would that be better?

As far as I see it will need more code and changes than adding one line of
MODULE_ALIAS.

> Although it doesn't look like this driver has an SPI id table, you
> should probably add one, I be interested to see if this module is always
> being matched through the "spi" or the "of" alias..

Could you please propose how that code should look like, so that I can test?

BR and thanks,
Nikolaus Schaller

> 
>> 
>> Should I submit a new version?
>> 
>> BR,
>> Nikolaus
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[Andrew F. Davis]

On 11/16/2017 10:10 AM, H. Nikolaus Schaller wrote:
> Hi Andrew,
> 
>> Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <afd@ti.com>:
>>
>> On 11/16/2017 07:43 AM, H. Nikolaus Schaller wrote:
>>>
>>>> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>>>
>>>> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>>>>> The vendor name was "toppoly" but other panels and the vendor list
>>>>> have defined it as "tpo". So let's fix it in driver and bindings.
>>>>>
>>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>> ---
>>>>
>>>>
>>>>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>>>>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>>>>
>>>> Doesn't this mean that the module won't load if you have old bindings?
>>>
>>> Hm.
>>>
>>> Well, I think it can load but doesn't automatically from DT strings which might
>>> be unexpected.
>>>
>>>> Can't we have two module aliases?
>>>
>>> I think we can. Just a random example:
>>> https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754
>>>
>>> So we should keep both.
>>
>> Even better would be to drop both MODULE_ALIAS and let the
>> MODULE_DEVICE_TABLE macro define them for your from the SPI id table.
> 
> Why would that be better?
> 

MODULE_ALIAS is ugly, you already have a table (usually) of device names
that are supported by the driver, the module aliases should be generated
from that table. This also keeps supported device list in one place.

> As far as I see it will need more code and changes than adding one line of
> MODULE_ALIAS.
> 
>> Although it doesn't look like this driver has an SPI id table, you
>> should probably add one, I be interested to see if this module is always
>> being matched through the "spi" or the "of" alias..
> 
> Could you please propose how that code should look like, so that I can test?
> 

Sure,

start with
$ udevadm monitor
and see what string the kernel is looking for when trying to find a
module for this device.

If it is only ever looking for "of:toppoly,td028ttec1", then you can
drop the MODULE_ALIAS and be done as it was never getting used anyway.

What I expect though is "spi:toppoly,td028ttec1", in which case you
should add

static const struct spi_device_id td028ttec1_ids[] = {
	{ "toppoly,td028ttec1", 0 },
	{ "tpo,td028ttec1", 0},
	{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, td028ttec1_ids);

link to it in the td028ttec1_spi_driver struct:
.id_table = td028ttec1_ids,

Then test again to see that the module still loads with the new and old
DT string.

Andrew

> BR and thanks,
> Nikolaus Schaller
> 
>>
>>>
>>> Should I submit a new version?
>>>
>>> BR,
>>> Nikolaus
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

> Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <afd@ti.com>:
> 
> On 11/16/2017 10:10 AM, H. Nikolaus Schaller wrote:
>> Hi Andrew,
>> 
>>> Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <afd@ti.com>:
>>> 
>>> On 11/16/2017 07:43 AM, H. Nikolaus Schaller wrote:
>>>> 
>>>>> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>>>> 
>>>>> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>>>>>> The vendor name was "toppoly" but other panels and the vendor list
>>>>>> have defined it as "tpo". So let's fix it in driver and bindings.
>>>>>> 
>>>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>>> ---
>>>>> 
>>>>> 
>>>>>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>>>>>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>>>>> 
>>>>> Doesn't this mean that the module won't load if you have old bindings?
>>>> 
>>>> Hm.
>>>> 
>>>> Well, I think it can load but doesn't automatically from DT strings which might
>>>> be unexpected.
>>>> 
>>>>> Can't we have two module aliases?
>>>> 
>>>> I think we can. Just a random example:
>>>> https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754
>>>> 
>>>> So we should keep both.
>>> 
>>> Even better would be to drop both MODULE_ALIAS and let the
>>> MODULE_DEVICE_TABLE macro define them for your from the SPI id table.
>> 
>> Why would that be better?
>> 
> 
> MODULE_ALIAS is ugly, you already have a table (usually) of device names
> that are supported by the driver, the module aliases should be generated
> from that table. This also keeps supported device list in one place.
> 
>> As far as I see it will need more code and changes than adding one line of
>> MODULE_ALIAS.
>> 
>>> Although it doesn't look like this driver has an SPI id table, you
>>> should probably add one, I be interested to see if this module is always
>>> being matched through the "spi" or the "of" alias..
>> 
>> Could you please propose how that code should look like, so that I can test?
>> 
> 
> Sure,
> 
> start with
> $ udevadm monitor
> and see what string the kernel is looking for when trying to find a
> module for this device.

Well, the module is loaded automatically from DT at boot time well before
I can start udevadm. So that is the most tricky part to setup the system
to suppress this...

> 
> If it is only ever looking for "of:toppoly,td028ttec1", then you can
> drop the MODULE_ALIAS and be done as it was never getting used anyway.

Since it is an SPI client, I am sure it looks for "spi:something.

> 
> What I expect though is "spi:toppoly,td028ttec1", in which case you
> should add
> 
> static const struct spi_device_id td028ttec1_ids[] = {
> 	{ "toppoly,td028ttec1", 0 },
> 	{ "tpo,td028ttec1", 0},
> 	{ /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(spi, td028ttec1_ids);

We already have a static const struct of_device_id td028ttec1_of_match[]
table with the same information.

So we still have two places to keep in sync.

Or can we remove the td028ttec1_of_match[]? AFAIK not.

> 
> link to it in the td028ttec1_spi_driver struct:
> .id_table = td028ttec1_ids,
> 
> Then test again to see that the module still loads with the new and old
> DT string.

In total I am not really convinced that adding 7 lines of code is better
than one (the "tpo," alias) that is tested and works...

And it looks like a lot of unplanned code testing for me which takes more
than 5 minutes :)

So I'd prefer to leave that exercise of fixing the MODULE_ALIAS/DEVICE_TABLE
to someone else...

BR and thanks,
Nikolaus

> 
> Andrew
> 
>> BR and thanks,
>> Nikolaus Schaller
>> 
>>> 
>>>> 
>>>> Should I submit a new version?
>>>> 
>>>> BR,
>>>> Nikolaus
>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[Andrew F. Davis]

On 11/16/2017 12:18 PM, H. Nikolaus Schaller wrote:
> 
>> Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <afd@ti.com>:
>>
>> On 11/16/2017 10:10 AM, H. Nikolaus Schaller wrote:
>>> Hi Andrew,
>>>
>>>> Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <afd@ti.com>:
>>>>
>>>> On 11/16/2017 07:43 AM, H. Nikolaus Schaller wrote:
>>>>>
>>>>>> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>>>>>
>>>>>> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>>>>>>> The vendor name was "toppoly" but other panels and the vendor list
>>>>>>> have defined it as "tpo". So let's fix it in driver and bindings.
>>>>>>>
>>>>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>>>> ---
>>>>>>
>>>>>>
>>>>>>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>>>>>>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>>>>>>
>>>>>> Doesn't this mean that the module won't load if you have old bindings?
>>>>>
>>>>> Hm.
>>>>>
>>>>> Well, I think it can load but doesn't automatically from DT strings which might
>>>>> be unexpected.
>>>>>
>>>>>> Can't we have two module aliases?
>>>>>
>>>>> I think we can. Just a random example:
>>>>> https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754
>>>>>
>>>>> So we should keep both.
>>>>
>>>> Even better would be to drop both MODULE_ALIAS and let the
>>>> MODULE_DEVICE_TABLE macro define them for your from the SPI id table.
>>>
>>> Why would that be better?
>>>
>>
>> MODULE_ALIAS is ugly, you already have a table (usually) of device names
>> that are supported by the driver, the module aliases should be generated
>> from that table. This also keeps supported device list in one place.
>>
>>> As far as I see it will need more code and changes than adding one line of
>>> MODULE_ALIAS.
>>>
>>>> Although it doesn't look like this driver has an SPI id table, you
>>>> should probably add one, I be interested to see if this module is always
>>>> being matched through the "spi" or the "of" alias..
>>>
>>> Could you please propose how that code should look like, so that I can test?
>>>
>>
>> Sure,
>>
>> start with
>> $ udevadm monitor
>> and see what string the kernel is looking for when trying to find a
>> module for this device.
> 
> Well, the module is loaded automatically from DT at boot time well before
> I can start udevadm. So that is the most tricky part to setup the system
> to suppress this...
> 
>>
>> If it is only ever looking for "of:toppoly,td028ttec1", then you can
>> drop the MODULE_ALIAS and be done as it was never getting used anyway.
> 
> Since it is an SPI client, I am sure it looks for "spi:something.
> 
>>
>> What I expect though is "spi:toppoly,td028ttec1", in which case you
>> should add
>>
>> static const struct spi_device_id td028ttec1_ids[] = {
>> 	{ "toppoly,td028ttec1", 0 },
>> 	{ "tpo,td028ttec1", 0},
>> 	{ /* sentinel */ }
>> };
>> MODULE_DEVICE_TABLE(spi, td028ttec1_ids);
> 
> We already have a static const struct of_device_id td028ttec1_of_match[]
> table with the same information.
> 
> So we still have two places to keep in sync.
> 
> Or can we remove the td028ttec1_of_match[]? AFAIK not.
> 
>>
>> link to it in the td028ttec1_spi_driver struct:
>> .id_table = td028ttec1_ids,
>>
>> Then test again to see that the module still loads with the new and old
>> DT string.
> 
> In total I am not really convinced that adding 7 lines of code is better
> than one (the "tpo," alias) that is tested and works...
> 
> And it looks like a lot of unplanned code testing for me which takes more
> than 5 minutes :)
> 
> So I'd prefer to leave that exercise of fixing the MODULE_ALIAS/DEVICE_TABLE
> to someone else...
> 

That's fine, someday I'll probably get some script to do this for all
the drivers that still have MODULE_ALIAS and an existing table.

> BR and thanks,
> Nikolaus
> 
>>
>> Andrew
>>
>>> BR and thanks,
>>> Nikolaus Schaller
>>>
>>>>
>>>>>
>>>>> Should I submit a new version?
>>>>>
>>>>> BR,
>>>>> Nikolaus
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

Hi Andrew,

> Am 16.11.2017 um 19:32 schrieb Andrew F. Davis <afd@ti.com>:
> 
> On 11/16/2017 12:18 PM, H. Nikolaus Schaller wrote:
>> 
>>> Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <afd@ti.com>:
>>> 
>>> On 11/16/2017 10:10 AM, H. Nikolaus Schaller wrote:
>>>> Hi Andrew,
>>>> 
>>>>> Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <afd@ti.com>:
>>>>> 
>>>>> On 11/16/2017 07:43 AM, H. Nikolaus Schaller wrote:
>>>>>> 
>>>>>>> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>>>>>> 
>>>>>>> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>>>>>>>> The vendor name was "toppoly" but other panels and the vendor list
>>>>>>>> have defined it as "tpo". So let's fix it in driver and bindings.
>>>>>>>> 
>>>>>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>>>>> ---
>>>>>>> 
>>>>>>> 
>>>>>>>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>>>>>>>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>>>>>>> 
>>>>>>> Doesn't this mean that the module won't load if you have old bindings?
>>>>>> 
>>>>>> Hm.
>>>>>> 
>>>>>> Well, I think it can load but doesn't automatically from DT strings which might
>>>>>> be unexpected.
>>>>>> 
>>>>>>> Can't we have two module aliases?
>>>>>> 
>>>>>> I think we can. Just a random example:
>>>>>> https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754
>>>>>> 
>>>>>> So we should keep both.
>>>>> 
>>>>> Even better would be to drop both MODULE_ALIAS and let the
>>>>> MODULE_DEVICE_TABLE macro define them for your from the SPI id table.
>>>> 
>>>> Why would that be better?
>>>> 
>>> 
>>> MODULE_ALIAS is ugly, you already have a table (usually) of device names
>>> that are supported by the driver, the module aliases should be generated
>>> from that table. This also keeps supported device list in one place.
>>> 
>>>> As far as I see it will need more code and changes than adding one line of
>>>> MODULE_ALIAS.
>>>> 
>>>>> Although it doesn't look like this driver has an SPI id table, you
>>>>> should probably add one, I be interested to see if this module is always
>>>>> being matched through the "spi" or the "of" alias..
>>>> 
>>>> Could you please propose how that code should look like, so that I can test?
>>>> 
>>> 
>>> Sure,
>>> 
>>> start with
>>> $ udevadm monitor
>>> and see what string the kernel is looking for when trying to find a
>>> module for this device.
>> 
>> Well, the module is loaded automatically from DT at boot time well before
>> I can start udevadm. So that is the most tricky part to setup the system
>> to suppress this...
>> 
>>> 
>>> If it is only ever looking for "of:toppoly,td028ttec1", then you can
>>> drop the MODULE_ALIAS and be done as it was never getting used anyway.
>> 
>> Since it is an SPI client, I am sure it looks for "spi:something.
>> 
>>> 
>>> What I expect though is "spi:toppoly,td028ttec1", in which case you
>>> should add
>>> 
>>> static const struct spi_device_id td028ttec1_ids[] = {
>>> 	{ "toppoly,td028ttec1", 0 },
>>> 	{ "tpo,td028ttec1", 0},
>>> 	{ /* sentinel */ }
>>> };
>>> MODULE_DEVICE_TABLE(spi, td028ttec1_ids);
>> 
>> We already have a static const struct of_device_id td028ttec1_of_match[]
>> table with the same information.
>> 
>> So we still have two places to keep in sync.
>> 
>> Or can we remove the td028ttec1_of_match[]? AFAIK not.
>> 
>>> 
>>> link to it in the td028ttec1_spi_driver struct:
>>> .id_table = td028ttec1_ids,
>>> 
>>> Then test again to see that the module still loads with the new and old
>>> DT string.
>> 
>> In total I am not really convinced that adding 7 lines of code is better
>> than one (the "tpo," alias) that is tested and works...
>> 
>> And it looks like a lot of unplanned code testing for me which takes more
>> than 5 minutes :)
>> 
>> So I'd prefer to leave that exercise of fixing the MODULE_ALIAS/DEVICE_TABLE
>> to someone else...
>> 
> 
> That's fine, someday I'll probably get some script to do this for all
> the drivers that still have MODULE_ALIAS and an existing table.

That would be cool!

On a second thought, I think there is a quick experiment for this driver
not needing to monitor events.

1st attempt: remove ALIASES => if it still loads it would be fine
2nd attempt: add your id table => if it loads again, it is fine
if not, let's keep ALIASES.

Maybe I can try tomorrow.

BR and thanks,
Nikolaus

> 
>> BR and thanks,
>> Nikolaus
>> 
>>> 
>>> Andrew
>>> 
>>>> BR and thanks,
>>>> Nikolaus Schaller
>>>> 
>>>>> 
>>>>>> 
>>>>>> Should I submit a new version?
>>>>>> 
>>>>>> BR,
>>>>>> Nikolaus
>>>>>> 
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>> 
>>>> 
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

[PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

Hi Andrew,

> Am 16.11.2017 um 19:56 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Andrew,
> 
>> Am 16.11.2017 um 19:32 schrieb Andrew F. Davis <afd@ti.com>:
>> 
>> On 11/16/2017 12:18 PM, H. Nikolaus Schaller wrote:
>>> 
>>>> Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <afd@ti.com>:
>>>> 
>>>> On 11/16/2017 10:10 AM, H. Nikolaus Schaller wrote:
>>>>> Hi Andrew,
>>>>> 
>>>>>> Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <afd@ti.com>:
>>>>>> 
>>>>>> On 11/16/2017 07:43 AM, H. Nikolaus Schaller wrote:
>>>>>>> 
>>>>>>>> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>>>>>>> 
>>>>>>>> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>>>>>>>>> The vendor name was "toppoly" but other panels and the vendor list
>>>>>>>>> have defined it as "tpo". So let's fix it in driver and bindings.
>>>>>>>>> 
>>>>>>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>>>>>>> ---
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>>>>>>>>> +MODULE_ALIAS("spi:tpo,td028ttec1");
>>>>>>>> 
>>>>>>>> Doesn't this mean that the module won't load if you have old bindings?
>>>>>>> 
>>>>>>> Hm.
>>>>>>> 
>>>>>>> Well, I think it can load but doesn't automatically from DT strings which might
>>>>>>> be unexpected.
>>>>>>> 
>>>>>>>> Can't we have two module aliases?
>>>>>>> 
>>>>>>> I think we can. Just a random example:
>>>>>>> https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754
>>>>>>> 
>>>>>>> So we should keep both.
>>>>>> 
>>>>>> Even better would be to drop both MODULE_ALIAS and let the
>>>>>> MODULE_DEVICE_TABLE macro define them for your from the SPI id table.
>>>>> 
>>>>> Why would that be better?
>>>>> 
>>>> 
>>>> MODULE_ALIAS is ugly, you already have a table (usually) of device names
>>>> that are supported by the driver, the module aliases should be generated
>>>> from that table. This also keeps supported device list in one place.
>>>> 
>>>>> As far as I see it will need more code and changes than adding one line of
>>>>> MODULE_ALIAS.
>>>>> 
>>>>>> Although it doesn't look like this driver has an SPI id table, you
>>>>>> should probably add one, I be interested to see if this module is always
>>>>>> being matched through the "spi" or the "of" alias..
>>>>> 
>>>>> Could you please propose how that code should look like, so that I can test?
>>>>> 
>>>> 
>>>> Sure,
>>>> 
>>>> start with
>>>> $ udevadm monitor
>>>> and see what string the kernel is looking for when trying to find a
>>>> module for this device.
>>> 
>>> Well, the module is loaded automatically from DT at boot time well before
>>> I can start udevadm. So that is the most tricky part to setup the system
>>> to suppress this...
>>> 
>>>> 
>>>> If it is only ever looking for "of:toppoly,td028ttec1", then you can
>>>> drop the MODULE_ALIAS and be done as it was never getting used anyway.
>>> 
>>> Since it is an SPI client, I am sure it looks for "spi:something.
>>> 
>>>> 
>>>> What I expect though is "spi:toppoly,td028ttec1", in which case you
>>>> should add
>>>> 
>>>> static const struct spi_device_id td028ttec1_ids[] = {
>>>> 	{ "toppoly,td028ttec1", 0 },
>>>> 	{ "tpo,td028ttec1", 0},
>>>> 	{ /* sentinel */ }
>>>> };
>>>> MODULE_DEVICE_TABLE(spi, td028ttec1_ids);
>>> 
>>> We already have a static const struct of_device_id td028ttec1_of_match[]
>>> table with the same information.
>>> 
>>> So we still have two places to keep in sync.
>>> 
>>> Or can we remove the td028ttec1_of_match[]? AFAIK not.
>>> 
>>>> 
>>>> link to it in the td028ttec1_spi_driver struct:
>>>> .id_table = td028ttec1_ids,
>>>> 
>>>> Then test again to see that the module still loads with the new and old
>>>> DT string.
>>> 
>>> In total I am not really convinced that adding 7 lines of code is better
>>> than one (the "tpo," alias) that is tested and works...
>>> 
>>> And it looks like a lot of unplanned code testing for me which takes more
>>> than 5 minutes :)
>>> 
>>> So I'd prefer to leave that exercise of fixing the MODULE_ALIAS/DEVICE_TABLE
>>> to someone else...
>>> 
>> 
>> That's fine, someday I'll probably get some script to do this for all
>> the drivers that still have MODULE_ALIAS and an existing table.
> 
> That would be cool!
> 
> On a second thought, I think there is a quick experiment for this driver
> not needing to monitor events.
> 
> 1st attempt: remove ALIASES => if it still loads it would be fine
> 2nd attempt: add your id table => if it loads again, it is fine
> if not, let's keep ALIASES.
> 
> Maybe I can try tomorrow.

I found time to give it a try and indeed:

1. with module_aliases

root at letux:~# lsmod | fgrep td028
panel_tpo_td028ttec1    16384  1 
omapdss_base           16384  5 connector_analog_tv,encoder_opa362,panel_tpo_td028ttec1,omapdrm,omapdss
root at letux:~# modprobe -c | fgrep td028
alias of:N*T*Comapdss,toppoly,td028ttec1 panel_tpo_td028ttec1
alias of:N*T*Comapdss,toppoly,td028ttec1C* panel_tpo_td028ttec1
alias of:N*T*Comapdss,tpo,td028ttec1 panel_tpo_td028ttec1
alias of:N*T*Comapdss,tpo,td028ttec1C* panel_tpo_td028ttec1
alias spi:toppoly,td028ttec1 panel_tpo_td028ttec1
alias spi:tpo,td028ttec1 panel_tpo_td028ttec1
root at letux:~# 

=> two MODULE_ALIASEs are possible.

2. without module_aliases

No display and:

root at letux:~# lsmod | fgrep td028
root at letux:~# modprobe -c | fgrep td028
alias of:N*T*Comapdss,toppoly,td028ttec1 panel_tpo_td028ttec1
alias of:N*T*Comapdss,toppoly,td028ttec1C* panel_tpo_td028ttec1
alias of:N*T*Comapdss,tpo,td028ttec1 panel_tpo_td028ttec1
alias of:N*T*Comapdss,tpo,td028ttec1C* panel_tpo_td028ttec1
root at letux:~# 

=> spi: entries are needed.

3. with MODULE_DEVICE_TABLE

Display is back and:

root at letux:~# lsmod | fgrep td028
panel_tpo_td028ttec1    16384  1 
omapdss_base           16384  5 connector_analog_tv,encoder_opa362,panel_tpo_td028ttec1,omapdrm,omapdss
root at letux:~# modprobe -c | fgrep td028
alias of:N*T*Comapdss,toppoly,td028ttec1 panel_tpo_td028ttec1
alias of:N*T*Comapdss,toppoly,td028ttec1C* panel_tpo_td028ttec1
alias of:N*T*Comapdss,tpo,td028ttec1 panel_tpo_td028ttec1
alias of:N*T*Comapdss,tpo,td028ttec1C* panel_tpo_td028ttec1
alias spi:toppoly,td028ttec1 panel_tpo_td028ttec1
alias spi:tpo,td028ttec1 panel_tpo_td028ttec1
root at letux:~#

=> MODULE_DEVICE_TABLE works equally well.

I have prepared a separate patch so that a first one adds
another MODULE_ALIAS and the new one replaces both MODULE_ALIASes
with MODULE_DEVICE_TABLE.

I will submit a [PATCH v3] asap.

BR and thanks,
Nikolaus

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Vendor string is "tpo" and not "toppoly".

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
 
 		/* lcd panel */
 		lcd: td028ttec1 at 0 {
-			compatible = "toppoly,td028ttec1";
+			compatible = "tpo,td028ttec1";
 			reg = <0>;
 			spi-max-frequency = <100000>;
 			spi-cpol;
-- 
2.12.2

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171116 08:53]:
> Vendor string is "tpo" and not "toppoly".
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..ec27ed67a22a 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -86,7 +86,7 @@
>  
>  		/* lcd panel */
>  		lcd: td028ttec1 at 0 {
> -			compatible = "toppoly,td028ttec1";
> +			compatible = "tpo,td028ttec1";
>  			reg = <0>;
>  			spi-max-frequency = <100000>;
>  			spi-cpol;

Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
like it can wait for v4.16 merge window.

Regards,

Tony

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Hi Tony,

> Am 28.11.2017 um 15:57 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171116 08:53]:
>> Vendor string is "tpo" and not "toppoly".
>> 
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
>> index 4504908c23fe..ec27ed67a22a 100644
>> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
>> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
>> @@ -86,7 +86,7 @@
>> 
>> 		/* lcd panel */
>> 		lcd: td028ttec1 at 0 {
>> -			compatible = "toppoly,td028ttec1";
>> +			compatible = "tpo,td028ttec1";
>> 			reg = <0>;
>> 			spi-max-frequency = <100000>;
>> 			spi-cpol;
> 
> Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
> like it can wait for v4.16 merge window.

Hm. Not really. It needs the panel driver to match. So either both or
none should be applied or it will break the panel from working.

I am just 1-2 hours away from submitting a -v3 (rebased and tested
on top of 4.15-rc1).

BR and thanks,
Nikolaus

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171128 15:04]:
> Hi Tony,
> 
> > Am 28.11.2017 um 15:57 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [171116 08:53]:
> >> Vendor string is "tpo" and not "toppoly".
> >> 
> >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> >> ---
> >> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> index 4504908c23fe..ec27ed67a22a 100644
> >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> @@ -86,7 +86,7 @@
> >> 
> >> 		/* lcd panel */
> >> 		lcd: td028ttec1 at 0 {
> >> -			compatible = "toppoly,td028ttec1";
> >> +			compatible = "tpo,td028ttec1";
> >> 			reg = <0>;
> >> 			spi-max-frequency = <100000>;
> >> 			spi-cpol;
> > 
> > Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
> > like it can wait for v4.16 merge window.
> 
> Hm. Not really. It needs the panel driver to match. So either both or
> none should be applied or it will break the panel from working.
> 
> I am just 1-2 hours away from submitting a -v3 (rebased and tested
> on top of 4.15-rc1).

OK fine dropping both. Please update the description in both dts
patches to make it clear they are needed as a fix. Preferrably
with a proper fixes tag.

Having "We can remove the "omapdss," prefix" in the description sure
does not sounds like it's needed as a fix :)

Sounds like maybe these two should be just a single patch for
a proper fix?

Regards,

Tony

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Hi Tony,

> Am 28.11.2017 um 16:10 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171128 15:04]:
>> Hi Tony,
>> 
>>> Am 28.11.2017 um 15:57 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171116 08:53]:
>>>> Vendor string is "tpo" and not "toppoly".
>>>> 
>>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>>> ---
>>>> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>> 
>>>> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
>>>> index 4504908c23fe..ec27ed67a22a 100644
>>>> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
>>>> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
>>>> @@ -86,7 +86,7 @@
>>>> 
>>>> 		/* lcd panel */
>>>> 		lcd: td028ttec1 at 0 {
>>>> -			compatible = "toppoly,td028ttec1";
>>>> +			compatible = "tpo,td028ttec1";
>>>> 			reg = <0>;
>>>> 			spi-max-frequency = <100000>;
>>>> 			spi-cpol;
>>> 
>>> Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
>>> like it can wait for v4.16 merge window.
>> 
>> Hm. Not really. It needs the panel driver to match. So either both or
>> none should be applied or it will break the panel from working.
>> 
>> I am just 1-2 hours away from submitting a -v3 (rebased and tested
>> on top of 4.15-rc1).
> 
> OK fine dropping both. Please update the description in both dts
> patches to make it clear they are needed as a fix. Preferrably
> with a proper fixes tag.

Well, it is not "needed" in a strong sense since current mainline&stable
works. It is more a style and consistency fix to use "tpo," everywhere.

> 
> Having "We can remove the "omapdss," prefix" in the description sure
> does not sounds like it's needed as a fix :)

The description has been improved on -v3.

> 
> Sounds like maybe these two should be just a single patch for
> a proper fix?

Hm. I usually get the feedback to separate DT and driver fixes into
separate commits... Therefore I submit patch sets in the hope they
are not picked apart :)

As promised -v3 is following now.

BR,
Nikolaus

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171128 15:51]:
> > Am 28.11.2017 um 16:10 schrieb Tony Lindgren <tony@atomide.com>:
> > OK fine dropping both. Please update the description in both dts
> > patches to make it clear they are needed as a fix. Preferrably
> > with a proper fixes tag.
> 
> Well, it is not "needed" in a strong sense since current mainline&stable
> works. It is more a style and consistency fix to use "tpo," everywhere.
> 
> > 
> > Having "We can remove the "omapdss," prefix" in the description sure
> > does not sounds like it's needed as a fix :)
> 
> The description has been improved on -v3.

Thanks.

> > Sounds like maybe these two should be just a single patch for
> > a proper fix?
> 
> Hm. I usually get the feedback to separate DT and driver fixes into
> separate commits... Therefore I submit patch sets in the hope they
> are not picked apart :)

See "both dts patches" part above. Yes the dts patches can and should
be sent separately. In almost every case if the dts patches cannot be
applied separately it means your driver changes are breaking things.

Regards,

Tony

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

> Am 28.11.2017 um 17:00 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171128 15:51]:
>>> Am 28.11.2017 um 16:10 schrieb Tony Lindgren <tony@atomide.com>:
>>> OK fine dropping both. Please update the description in both dts
>>> patches to make it clear they are needed as a fix. Preferrably
>>> with a proper fixes tag.
>> 
>> Well, it is not "needed" in a strong sense since current mainline&stable
>> works. It is more a style and consistency fix to use "tpo," everywhere.
>> 
>>> 
>>> Having "We can remove the "omapdss," prefix" in the description sure
>>> does not sounds like it's needed as a fix :)
>> 
>> The description has been improved on -v3.
> 
> Thanks.
> 
>>> Sounds like maybe these two should be just a single patch for
>>> a proper fix?
>> 
>> Hm. I usually get the feedback to separate DT and driver fixes into
>> separate commits... Therefore I submit patch sets in the hope they
>> are not picked apart :)
> 
> See "both dts patches" part above. Yes the dts patches can and should
> be sent separately. In almost every case if the dts patches cannot be
> applied separately it means your driver changes are breaking things.

That is why the v3 driver now accepts both, the old and the new vendor
name. This means applying the driver alone is safe. Applying or not
applying DTS patch afterwards is also safe.

BR,
Nikolaus

[PATCH v2 3/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

We can remove the "omapdss," prefix because the
omapdrm driver takes care of it.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
 
 	lcd: lcd at 1 {
 		reg = <1>;	/* CS1 */
-		compatible =	"omapdss,tpo,td043mtea1";
+		compatible =	"tpo,td043mtea1";
 		spi-max-frequency = <100000>;
 		spi-cpol;
 		spi-cpha;
-- 
2.12.2

[PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS

[H. Nikolaus Schaller]

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
to dpi code") replaced usage of platform data version with SoC matching
to configure DPI VDDS. The SoC match entries were incorrect, they should
have matched on the machine name instead of the SoC family. Fix it.

The result was observed on OpenPandora with OMAP3530 where the panel only
had the Blue channel and Red&Green were missing. It was not observed on
GTA04 with DM3730.

Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
---
 drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 4ed5fde11313..a91e5f1a0490 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll)
 }
 
 static const struct soc_device_attribute dpi_soc_devices[] = {
-	{ .family = "OMAP3[456]*" },
-	{ .family = "[AD]M37*" },
+	{ .machine = "OMAP3[456]*" },
+	{ .machine = "[AD]M37*" },
 	{ /* sentinel */ }
 };
 
-- 
2.12.2

[PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS

[Tomi Valkeinen]

On 16/11/17 10:50, H. Nikolaus Schaller wrote:
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
> to dpi code") replaced usage of platform data version with SoC matching
> to configure DPI VDDS. The SoC match entries were incorrect, they should
> have matched on the machine name instead of the SoC family. Fix it.
> 
> The result was observed on OpenPandora with OMAP3530 where the panel only
> had the Blue channel and Red&Green were missing. It was not observed on
> GTA04 with DM3730.
> 
> Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code")
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c b/drivers/gpu/drm/omapdrm/dss/dpi.c
> index 4ed5fde11313..a91e5f1a0490 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll)
>  }
>  
>  static const struct soc_device_attribute dpi_soc_devices[] = {
> -	{ .family = "OMAP3[456]*" },
> -	{ .family = "[AD]M37*" },
> +	{ .machine = "OMAP3[456]*" },
> +	{ .machine = "[AD]M37*" },
>  	{ /* sentinel */ }
>  };
>  
> 

I have picked this one. I think the rest of the patches are more of a
cleanup, right? And you'll be sending v3 at some point.

 Tomi

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

[PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS

[H. Nikolaus Schaller]

Hi,

> Am 21.11.2017 um 11:25 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
> 
> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> 
>> Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
>> to dpi code") replaced usage of platform data version with SoC matching
>> to configure DPI VDDS. The SoC match entries were incorrect, they should
>> have matched on the machine name instead of the SoC family. Fix it.
>> 
>> The result was observed on OpenPandora with OMAP3530 where the panel only
>> had the Blue channel and Red&Green were missing. It was not observed on
>> GTA04 with DM3730.
>> 
>> Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code")
>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
>> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c b/drivers/gpu/drm/omapdrm/dss/dpi.c
>> index 4ed5fde11313..a91e5f1a0490 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dpi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
>> @@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll)
>> }
>> 
>> static const struct soc_device_attribute dpi_soc_devices[] = {
>> -	{ .family = "OMAP3[456]*" },
>> -	{ .family = "[AD]M37*" },
>> +	{ .machine = "OMAP3[456]*" },
>> +	{ .machine = "[AD]M37*" },
>> 	{ /* sentinel */ }
>> };
>> 
>> 
> 
> I have picked this one.

Fine.

> I think the rest of the patches are more of a
> cleanup, right? And you'll be sending v3 at some point.

Yes. Should we wait for more comments or should I send now?

BR and thanks,
Nikolaus Schaller


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