Fixes for omapdrm on OpenPandora and GTA04
Subsystems (7)
v2 cover Fixes for omapdrm on OpenPandora and GTA04
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%)Signature · 1 line
2.12.2
PATCH v2 1/4 omapdrm: fix compatible string for td028ttec1
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.
---
.../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%)Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt renamed from Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt +2 -2
@@ -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@0 { - compatible = "toppoly,td028ttec1"; + compatible = "tpo,td028ttec1"; reg = <0>; spi-max-frequency = <100000>; spi-cpol;
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c +2 -2
@@ -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 <[email protected]>" );MODULE_DESCRIPTION ("Toppoly TD028TTEC1 panel driver" );MODULE_LICENSE ("GPL" );
drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c +3 -1
@@ -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 <[email protected]>" );MODULE_DESCRIPTION ("Toppoly TD028TTEC1 panel driver" );MODULE_LICENSE ("GPL" );
Signature · 6 lines
2.12.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Review
Quoted 9 lines · 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 <[email protected]>---
(quoted diff) +1
-1-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
Signature · 2 lines
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 1 line
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Quoted 21 lines · H. Nikolaus Schaller
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 6 lines
Quoted 1 line
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#L754So 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..
Quoted 11 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Hi Andrew,
Quoted 26 lines
Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <[email protected]>:
Quoted 23 lines · H. Nikolaus Schaller
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 1 line
Can't we have two module aliases?
Quoted 7 lines
Quoted 4 lines
I think we can. Just a random example:
https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754So we should keep both.
Even better would be to drop both
MODULE_ALIASand let theMODULE_DEVICE_TABLEmacro 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.
Quoted 3 lines
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
Quoted 12 lines
Quoted 12 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Quoted 31 lines · H. Nikolaus Schaller
Hi Andrew,
Quoted 29 lines
Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <[email protected]>:
Quoted 26 lines · H. Nikolaus Schaller
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 1 line
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
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
So we should keep both.
Even better would be to drop both
MODULE_ALIASand let theMODULE_DEVICE_TABLEmacro 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.
Quoted 9 lines
As far as I see it will need more code and changes than adding one line of
MODULE_ALIAS.Quoted 3 lines
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
Quoted 21 lines
BR and thanks,
Nikolaus SchallerQuoted 4 lines
Quoted 4 lines
Should I submit a new version?
Quoted 8 lines
Quoted 8 lines
BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Quoted 57 lines
Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <[email protected]>:
Quoted 31 lines · H. Nikolaus Schaller
Hi Andrew,
Quoted 29 lines
Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <[email protected]>:
Quoted 26 lines · H. Nikolaus Schaller
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 1 line
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#L754Quoted 7 lines
Quoted 4 lines
Quoted 1 line
So we should keep both.
Even better would be to drop both
MODULE_ALIASand let theMODULE_DEVICE_TABLEmacro define them for your from the SPI id table.Why would that be better?
MODULE_ALIASis 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.Quoted 9 lines
As far as I see it will need more code and changes than adding one line of
MODULE_ALIAS.Quoted 3 lines
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?
Quoted 6 lines
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...
Quoted 3 lines
If it is only ever looking for "of:toppoly,td028ttec1", then you can drop the
MODULE_ALIASand be done as it was never getting used anyway.
Since it is an SPI client, I am sure it looks for "spi:something.
Quoted 10 lines
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.
Quoted 6 lines
link to it in the
td028ttec1_spi_driverstruct:
.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
Quoted 24 lines
Andrew
Quoted 21 lines
BR and thanks,
Nikolaus SchallerQuoted 4 lines
Quoted 4 lines
Should I submit a new version?
Quoted 8 lines
Quoted 8 lines
BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Quoted 99 lines · H. Nikolaus Schaller
Quoted 57 lines
Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <[email protected]>:
Quoted 31 lines · H. Nikolaus Schaller
Hi Andrew,
Quoted 29 lines
Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <[email protected]>:
Quoted 26 lines · H. Nikolaus Schaller
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 1 line
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#L754Quoted 7 lines
Quoted 4 lines
Quoted 1 line
So we should keep both.
Even better would be to drop both
MODULE_ALIASand let theMODULE_DEVICE_TABLEmacro define them for your from the SPI id table.Why would that be better?
MODULE_ALIASis 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.Quoted 9 lines
As far as I see it will need more code and changes than adding one line of
MODULE_ALIAS.Quoted 3 lines
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?
Quoted 6 lines
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...
Quoted 3 lines
If it is only ever looking for "of:toppoly,td028ttec1", then you can drop the
MODULE_ALIASand be done as it was never getting used anyway.Since it is an SPI client, I am sure it looks for "spi:something.
Quoted 10 lines
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_idtd028ttec1_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.
Quoted 6 lines
link to it in the
td028ttec1_spi_driverstruct:
.id_table =td028ttec1_ids,Then test again to see that the module still loads with the new and old DT string.
Quoted 9 lines
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.
Quoted 33 lines
BR and thanks,
NikolausQuoted 24 lines
Andrew
Quoted 21 lines
BR and thanks,
Nikolaus SchallerQuoted 4 lines
Quoted 4 lines
Should I submit a new version?
Quoted 8 lines
Quoted 8 lines
BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected]
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Hi Andrew,
Quoted 108 lines
Am 16.11.2017 um 19:32 schrieb Andrew F. Davis <[email protected]>:
Quoted 105 lines · H. Nikolaus Schaller
Quoted 57 lines
Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <[email protected]>:
Quoted 31 lines · H. Nikolaus Schaller
Hi Andrew,
Quoted 29 lines
Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <[email protected]>:
Quoted 26 lines · H. Nikolaus Schaller
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 1 line
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#L754Quoted 7 lines
Quoted 4 lines
Quoted 1 line
So we should keep both.
Even better would be to drop both
MODULE_ALIASand let theMODULE_DEVICE_TABLEmacro define them for your from the SPI id table.Why would that be better?
MODULE_ALIASis 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.Quoted 9 lines
As far as I see it will need more code and changes than adding one line of
MODULE_ALIAS.Quoted 3 lines
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?
Quoted 6 lines
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...
Quoted 3 lines
If it is only ever looking for "of:toppoly,td028ttec1", then you can drop the
MODULE_ALIASand be done as it was never getting used anyway.Since it is an SPI client, I am sure it looks for "spi:something.
Quoted 10 lines
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_idtd028ttec1_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.
Quoted 6 lines
link to it in the
td028ttec1_spi_driverstruct:
.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 :)
Quoted 6 lines
Quoted 3 lines
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_ALIASand 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
Quoted 34 lines
Quoted 34 lines
BR and thanks,
NikolausQuoted 24 lines
Andrew
Quoted 21 lines
BR and thanks,
Nikolaus SchallerQuoted 4 lines
Quoted 4 lines
Should I submit a new version?
Quoted 8 lines
Quoted 8 lines
BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected]
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1
Hi Andrew,
Quoted 121 lines
Am 16.11.2017 um 19:56 schrieb H. Nikolaus Schaller <[email protected]>:
Hi Andrew,
Quoted 108 lines
Am 16.11.2017 um 19:32 schrieb Andrew F. Davis <[email protected]>:
Quoted 105 lines · H. Nikolaus Schaller
Quoted 57 lines
Am 16.11.2017 um 18:08 schrieb Andrew F. Davis <[email protected]>:
Quoted 31 lines · H. Nikolaus Schaller
Hi Andrew,
Quoted 29 lines
Am 16.11.2017 um 16:53 schrieb Andrew F. Davis <[email protected]>:
Quoted 26 lines · H. Nikolaus Schaller
Quoted 7 lines
Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen <[email protected]>:
Quoted 3 lines · 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.
Quoted 8 lines
Review
Quoted 6 lines
Signed-off-by H. Nikolaus Schaller <[email protected]>---
(quoted diff) +1
-1-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.
Quoted 1 line
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#L754Quoted 7 lines
Quoted 4 lines
Quoted 1 line
So we should keep both.
Even better would be to drop both
MODULE_ALIASand let theMODULE_DEVICE_TABLEmacro define them for your from the SPI id table.Why would that be better?
MODULE_ALIASis 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.Quoted 9 lines
As far as I see it will need more code and changes than adding one line of
MODULE_ALIAS.Quoted 3 lines
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?
Quoted 6 lines
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...
Quoted 3 lines
If it is only ever looking for "of:toppoly,td028ttec1", then you can drop the
MODULE_ALIASand be done as it was never getting used anyway.Since it is an SPI client, I am sure it looks for "spi:something.
Quoted 10 lines
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_idtd028ttec1_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.
Quoted 6 lines
link to it in the
td028ttec1_spi_driverstruct:
.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 :)
Quoted 6 lines
Quoted 3 lines
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_ALIASand an existing table.That would be cool!
Quoted 8 lines
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@letux:~# lsmod | fgrep td028 panel_tpo_td028ttec1 16384 1 omapdss_base 16384 5 connector_analog_tv,encoder_opa362,panel_tpo_td028ttec1,omapdrm,omapdss root@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@letux:~#
=> two MODULE_ALIASEs are possible.
2. without module_aliases
No display and:
root@letux:~# lsmod | fgrep td028 root@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@letux:~#
=> spi: entries are needed.
3. with MODULE_DEVICE_TABLE
Display is back and:
root@letux:~# lsmod | fgrep td028 panel_tpo_td028ttec1 16384 1 omapdss_base 16384 5 connector_analog_tv,encoder_opa362,panel_tpo_td028ttec1,omapdrm,omapdss root@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@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
In reply to H. Nikolaus SchallerVendor string is "tpo" and not "toppoly".
--- arch/arm/boot/dts/omap3-gta04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/omap3-gta04.dtsi +1 -1
@@ -86,7 +86,7 @@ /* lcd panel */ lcd: td028ttec1@0 { - compatible = "toppoly,td028ttec1"; + compatible = "tpo,td028ttec1"; reg = <0>; spi-max-frequency = <100000>; spi-cpol;
Signature · 6 lines
2.12.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
Quoted 12 lines · H. Nikolaus Schaller
Vendor string is "tpo" and not "toppoly".
Signed-off-by H. Nikolaus Schaller <[email protected]>--- arch/arm/boot/dts/omap3-gta04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/omap3-gta04.dtsi +0
-0
arch/arm/boot/dts/omap3-gta04.dtsi line 92
Quoted 8 lines
arch/arm/boot/dts/omap3-gta04.dtsi +1
-1@@ -86,7 +86,7 @@ /* lcd panel */ lcd: td028ttec1@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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
Hi Tony,
Quoted 16 lines
Am 28.11.2017 um 15:57 schrieb Tony Lindgren <[email protected]>:
Quoted 13 lines · H. Nikolaus Schaller
Vendor string is "tpo" and not "toppoly".
Signed-off-by H. Nikolaus Schaller <[email protected]>---
arch/arm/boot/dts/omap3-gta04.dtsi| 2 +-1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/omap3-gta04.dtsi +0
-0@@ -86,7 +86,7 @@
Quoted 10 lines
arch/arm/boot/dts/omap3-gta04.dtsi line 92
Quoted 7 lines
arch/arm/boot/dts/omap3-gta04.dtsi +1
-1/* lcd panel */ lcd: td028ttec1@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
Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
Quoted 29 lines · H. Nikolaus Schaller
Hi Tony,
Quoted 16 lines
Am 28.11.2017 um 15:57 schrieb Tony Lindgren <[email protected]>:
Quoted 13 lines · H. Nikolaus Schaller
Vendor string is "tpo" and not "toppoly".
Signed-off-by H. Nikolaus Schaller <[email protected]>---
arch/arm/boot/dts/omap3-gta04.dtsi| 2 +-1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/omap3-gta04.dtsi +0
-0@@ -86,7 +86,7 @@Quoted 10 lines
arch/arm/boot/dts/omap3-gta04.dtsi line 92
Quoted 7 lines
arch/arm/boot/dts/omap3-gta04.dtsi +1
-1/* lcd panel */ lcd: td028ttec1@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.
Quoted 5 lines
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
Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
Hi Tony,
Quoted 35 lines
Am 28.11.2017 um 16:10 schrieb Tony Lindgren <[email protected]>:
Quoted 32 lines · H. Nikolaus Schaller
Hi Tony,
Quoted 16 lines
Am 28.11.2017 um 15:57 schrieb Tony Lindgren <[email protected]>:
Quoted 13 lines · H. Nikolaus Schaller
Vendor string is "tpo" and not "toppoly".
Signed-off-by H. Nikolaus Schaller <[email protected]>---
arch/arm/boot/dts/omap3-gta04.dtsi| 2 +-1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/omap3-gta04.dtsi +0
-0@@ -86,7 +86,7 @@Quoted 10 lines
arch/arm/boot/dts/omap3-gta04.dtsi line 92
Quoted 7 lines
arch/arm/boot/dts/omap3-gta04.dtsi +1
-1/* lcd panel */ lcd: td028ttec1@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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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
Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
Quoted 5 lines · H. Nikolaus Schaller
Quoted 4 lines
Am 28.11.2017 um 16:10 schrieb Tony Lindgren <[email protected]>:
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.
Quoted 8 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 2 lines
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
Quoted 23 lines
Am 28.11.2017 um 17:00 schrieb Tony Lindgren <[email protected]>:
Quoted 5 lines · H. Nikolaus Schaller
Quoted 4 lines
Am 28.11.2017 um 16:10 schrieb Tony Lindgren <[email protected]>:
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.Quoted 8 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
Quoted 2 lines
Sounds like maybe these two should be just a single patch for a proper fix?
Quoted 7 lines
Quoted 3 lines
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
In reply to H. Nikolaus SchallerWe can remove the "omapdss," prefix because the
omapdrm driver takes care of it.
--- arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/omap3-pandora-common.dtsi +1 -1
@@ -626,7 +626,7 @@ lcd: lcd@1 { reg = <1>; /* CS1 */ - compatible = "omapdss,tpo,td043mtea1"; + compatible = "tpo,td043mtea1"; spi-max-frequency = <100000>; spi-cpol; spi-cpha;
Signature · 6 lines
2.12.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v2 4/4 drm: omapdrm: Fix DPI on platforms using the DSI VDDS
In reply to H. Nikolaus SchallerFrom: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/[email protected]>
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.
--- drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/omapdrm/dss/dpi.c +2 -2
@@ -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 */ } };
Signature · 6 lines
2.12.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS
Quoted 25 lines · H. Nikolaus Schaller
From: Laurent Pinchart <[email protected]>
Commit
d178e034d565("drm: omapdrm: MoveFEAT_DPI_USES_VDDS_DSIfeature 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 <[email protected]>Reported-by H. Nikolaus Schaller <[email protected]>Tested-by H. Nikolaus Schaller <[email protected]>--- drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)drivers/gpu/drm/omapdrm/dss/dpi.c +0
-0
drivers/gpu/drm/omapdrm/dss/dpi.c static int dpi_verify_pll(struct dss_pll *pll) · line 573
Quoted 10 lines
drivers/gpu/drm/omapdrm/dss/dpi.c +2
-2@@ -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
Signature · 2 lines
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS
Hi,
Quoted 29 lines
Am 21.11.2017 um 11:25 schrieb Tomi Valkeinen <[email protected]>:
Quoted 26 lines · H. Nikolaus Schaller
From: Laurent Pinchart <[email protected]>
Commit
d178e034d565("drm: omapdrm: MoveFEAT_DPI_USES_VDDS_DSIfeature 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 <[email protected]>Reported-by H. Nikolaus Schaller <[email protected]>Tested-by H. Nikolaus Schaller <[email protected]>---
drivers/gpu/drm/omapdrm/dss/dpi.c| 4 ++--1 file changed, 2 insertions(+), 2 deletions(-)drivers/gpu/drm/omapdrm/dss/dpi.c +0
-0@@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll) }
Quoted 11 lines
drivers/gpu/drm/omapdrm/dss/dpi.c static int dpi_verify_pll(struct dss_pll *pll) · line 573
Quoted 9 lines
drivers/gpu/drm/omapdrm/dss/dpi.c +2
-2static 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.
Quoted 2 lines
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
Quoted 6 lines
Tomi
Signature · 2 lines
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki