[PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tomi Valkeinen]

Hi Tony,

Here's a fix for 3.11 that makes EDID read for DVI work again.

I also included a cleanup patch that removes the non-DT support functions that
are no longer called from anywhere. It's not a fix, but as we're in quite early
rcs, I thought it would be nice to remove the dead code.

Up to you if you want to include that one for 3.11 or not. If not, I'll include
it in a board file series for 3.12 that I'll send soon.

 Tomi

Tomi Valkeinen (2):
  ARM: OMAP: dss-common: fix Panda's DVI DDC channel
  ARM: OMAP2+: Remove legacy DSS initialization for omap4

 arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
 arch/arm/mach-omap2/dss-common.h |  2 --
 2 files changed, 1 insertion(+), 50 deletions(-)

-- 
1.8.1.2

[PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tomi Valkeinen]

Hi Tony,

Here's a fix for 3.11 that makes EDID read for DVI work again.

I also included a cleanup patch that removes the non-DT support functions that
are no longer called from anywhere. It's not a fix, but as we're in quite early
rcs, I thought it would be nice to remove the dead code.

Up to you if you want to include that one for 3.11 or not. If not, I'll include
it in a board file series for 3.12 that I'll send soon.

 Tomi

Tomi Valkeinen (2):
  ARM: OMAP: dss-common: fix Panda's DVI DDC channel
  ARM: OMAP2+: Remove legacy DSS initialization for omap4

 arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
 arch/arm/mach-omap2/dss-common.h |  2 --
 2 files changed, 1 insertion(+), 50 deletions(-)

-- 
1.8.1.2

[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Tomi Valkeinen]

Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
With non-DT, the bus number was 3, and that is what is used in the
dss-common.c which contains the platform data for Panda's DVI.

However, with DT, the bus number is 2. As we now only have DT boot for
Panda, we have to change the bus number to make DVI EDID read
operational.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 393aeef..043e570 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -42,7 +42,7 @@
 
 /* Using generic display panel */
 static struct tfp410_platform_data omap4_dvi_panel = {
-	.i2c_bus_num		= 3,
+	.i2c_bus_num		= 2,
 	.power_down_gpio	= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
 };
 
-- 
1.8.1.2

[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Tomi Valkeinen]

Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
With non-DT, the bus number was 3, and that is what is used in the
dss-common.c which contains the platform data for Panda's DVI.

However, with DT, the bus number is 2. As we now only have DT boot for
Panda, we have to change the bus number to make DVI EDID read
operational.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 393aeef..043e570 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -42,7 +42,7 @@
 
 /* Using generic display panel */
 static struct tfp410_platform_data omap4_dvi_panel = {
-	.i2c_bus_num		= 3,
+	.i2c_bus_num		= 2,
 	.power_down_gpio	= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
 };
 
-- 
1.8.1.2

Re: [PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Nishanth Menon]

On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
> Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
> With non-DT, the bus number was 3, and that is what is used in the
> dss-common.c which contains the platform data for Panda's DVI.
>
> However, with DT, the bus number is 2. As we now only have DT boot for
> Panda, we have to change the bus number to make DVI EDID read
> operational.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/mach-omap2/dss-common.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
> index 393aeef..043e570 100644
> --- a/arch/arm/mach-omap2/dss-common.c
> +++ b/arch/arm/mach-omap2/dss-common.c
> @@ -42,7 +42,7 @@
>
>   /* Using generic display panel */
>   static struct tfp410_platform_data omap4_dvi_panel = {
> -	.i2c_bus_num		= 3,
> +	.i2c_bus_num		= 2,
>   	.power_down_gpio	= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
>   };
>
>
completely dumb question :) :
why cant we have dts support for this instead of having to renumber 
every time?

Example: if -EPROBEDEFER is incurred due to some unexpected dependency, 
we'd have to redo the numbering in the kernel yet again.

-- 
Regards,
Nishanth Menon

[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Nishanth Menon]

On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
> Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
> With non-DT, the bus number was 3, and that is what is used in the
> dss-common.c which contains the platform data for Panda's DVI.
>
> However, with DT, the bus number is 2. As we now only have DT boot for
> Panda, we have to change the bus number to make DVI EDID read
> operational.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/mach-omap2/dss-common.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
> index 393aeef..043e570 100644
> --- a/arch/arm/mach-omap2/dss-common.c
> +++ b/arch/arm/mach-omap2/dss-common.c
> @@ -42,7 +42,7 @@
>
>   /* Using generic display panel */
>   static struct tfp410_platform_data omap4_dvi_panel = {
> -	.i2c_bus_num		= 3,
> +	.i2c_bus_num		= 2,
>   	.power_down_gpio	= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
>   };
>
>
completely dumb question :) :
why cant we have dts support for this instead of having to renumber 
every time?

Example: if -EPROBEDEFER is incurred due to some unexpected dependency, 
we'd have to redo the numbering in the kernel yet again.

-- 
Regards,
Nishanth Menon

Re: [PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

On 02/08/13 15:54, Nishanth Menon wrote:
> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>> Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
>> With non-DT, the bus number was 3, and that is what is used in the
>> dss-common.c which contains the platform data for Panda's DVI.
>>
>> However, with DT, the bus number is 2. As we now only have DT boot for
>> Panda, we have to change the bus number to make DVI EDID read
>> operational.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>>   arch/arm/mach-omap2/dss-common.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/dss-common.c
>> b/arch/arm/mach-omap2/dss-common.c
>> index 393aeef..043e570 100644
>> --- a/arch/arm/mach-omap2/dss-common.c
>> +++ b/arch/arm/mach-omap2/dss-common.c
>> @@ -42,7 +42,7 @@
>>
>>   /* Using generic display panel */
>>   static struct tfp410_platform_data omap4_dvi_panel = {
>> -    .i2c_bus_num        = 3,
>> +    .i2c_bus_num        = 2,
>>       .power_down_gpio    = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
>>   };
>>
>>
> completely dumb question :) :
> why cant we have dts support for this instead of having to renumber
> every time?

What do you mean "every time"?

Feel free to help me develop the DT support for DSS =). When that's
done, we can remove all this code.

> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
> we'd have to redo the numbering in the kernel yet again.

Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?

With board files they were numbered 1, 2, 3, 4, but with DT boot they
seem to be 0, 1, 2, 3. And as we have the current situation where omap4
boots with DT, but DSS does not have DT support, we add the DSS related
devices in a board-file-like-fashion.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Tomi Valkeinen]

On 02/08/13 15:54, Nishanth Menon wrote:
> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>> Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
>> With non-DT, the bus number was 3, and that is what is used in the
>> dss-common.c which contains the platform data for Panda's DVI.
>>
>> However, with DT, the bus number is 2. As we now only have DT boot for
>> Panda, we have to change the bus number to make DVI EDID read
>> operational.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>>   arch/arm/mach-omap2/dss-common.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/dss-common.c
>> b/arch/arm/mach-omap2/dss-common.c
>> index 393aeef..043e570 100644
>> --- a/arch/arm/mach-omap2/dss-common.c
>> +++ b/arch/arm/mach-omap2/dss-common.c
>> @@ -42,7 +42,7 @@
>>
>>   /* Using generic display panel */
>>   static struct tfp410_platform_data omap4_dvi_panel = {
>> -    .i2c_bus_num        = 3,
>> +    .i2c_bus_num        = 2,
>>       .power_down_gpio    = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
>>   };
>>
>>
> completely dumb question :) :
> why cant we have dts support for this instead of having to renumber
> every time?

What do you mean "every time"?

Feel free to help me develop the DT support for DSS =). When that's
done, we can remove all this code.

> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
> we'd have to redo the numbering in the kernel yet again.

Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?

With board files they were numbered 1, 2, 3, 4, but with DT boot they
seem to be 0, 1, 2, 3. And as we have the current situation where omap4
boots with DT, but DSS does not have DT support, we add the DSS related
devices in a board-file-like-fashion.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130802/6f57aa2b/attachment.sig>

Re: [PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Nishanth Menon]

On 08/02/2013 08:00 AM, Tomi Valkeinen wrote:
> On 02/08/13 15:54, Nishanth Menon wrote:
>> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>>> Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
>>> With non-DT, the bus number was 3, and that is what is used in the
>>> dss-common.c which contains the platform data for Panda's DVI.
>>>
>>> However, with DT, the bus number is 2. As we now only have DT boot for
>>> Panda, we have to change the bus number to make DVI EDID read
>>> operational.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>>    arch/arm/mach-omap2/dss-common.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/dss-common.c
>>> b/arch/arm/mach-omap2/dss-common.c
>>> index 393aeef..043e570 100644
>>> --- a/arch/arm/mach-omap2/dss-common.c
>>> +++ b/arch/arm/mach-omap2/dss-common.c
>>> @@ -42,7 +42,7 @@
>>>
>>>    /* Using generic display panel */
>>>    static struct tfp410_platform_data omap4_dvi_panel = {
>>> -    .i2c_bus_num        = 3,
>>> +    .i2c_bus_num        = 2,
>>>        .power_down_gpio    = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
>>>    };
>>>
>>>
>> completely dumb question :) :
>> why cant we have dts support for this instead of having to renumber
>> every time?
>
> What do you mean "every time"?

below

>
> Feel free to help me develop the DT support for DSS =). When that's
> done, we can remove all this code.

suggesting here - but it will be nice we have some steps towards this 
direction - is there anything you'd suggest we do first?

>
>> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
>> we'd have to redo the numbering in the kernel yet again.
>
> Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?
>
> With board files they were numbered 1, 2, 3, 4, but with DT boot they
> seem to be 0, 1, 2, 3. And as we have the current situation where omap4
> boots with DT, but DSS does not have DT support, we add the DSS related
> devices in a board-file-like-fashion.

Aah we are then depending on the following
i2c-omap.c:
  adap->nr = pdev->id;
  r = i2c_add_numbered_adapter(adap);

mach-omapx/i2c.c:
.. i2c_bus_register..
pdev->id = bus_id
platform_device_register(pdev);


I dont seem to see any similar numbering enforced in dtsi - if I reorder 
the i2c entries in SoC dtsi, i'd have an issue as well, no?

probe deferral could create problems as well.. not saying it can change 
random order on a given kernel between boots, but am saying that when 
new changes come in, deferral mechanism ensures proper ordering 
dynamically, which kind of messes up with expected device numbers. I had 
an issue with mmc sometime back where probe deferal on mmc1 made it 
registered as second device as the dependency was not present on the mmc2.

No reason this cannot happen on other busses as well. To solve this on 
i2c dts, the usual convention is as follows (from omap3-beagle):
&i2c1 {
         clock-frequency = <2600000>;

         twl: twl@48 {
                 reg = <0x48>;
                 interrupts = <7>; /* SYS_NIRQ cascaded to intc */
                 interrupt-parent = <&intc>;
         };
};

this ensures that probe success order is made independent of device 
expectation of i2c bus numbering or the order in which it was defined in 
dts.


just my 2 cents to help continued functionality in the world of dts..
-- 
Regards,
Nishanth Menon

[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Nishanth Menon]

On 08/02/2013 08:00 AM, Tomi Valkeinen wrote:
> On 02/08/13 15:54, Nishanth Menon wrote:
>> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>>> Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
>>> With non-DT, the bus number was 3, and that is what is used in the
>>> dss-common.c which contains the platform data for Panda's DVI.
>>>
>>> However, with DT, the bus number is 2. As we now only have DT boot for
>>> Panda, we have to change the bus number to make DVI EDID read
>>> operational.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>>    arch/arm/mach-omap2/dss-common.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/dss-common.c
>>> b/arch/arm/mach-omap2/dss-common.c
>>> index 393aeef..043e570 100644
>>> --- a/arch/arm/mach-omap2/dss-common.c
>>> +++ b/arch/arm/mach-omap2/dss-common.c
>>> @@ -42,7 +42,7 @@
>>>
>>>    /* Using generic display panel */
>>>    static struct tfp410_platform_data omap4_dvi_panel = {
>>> -    .i2c_bus_num        = 3,
>>> +    .i2c_bus_num        = 2,
>>>        .power_down_gpio    = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
>>>    };
>>>
>>>
>> completely dumb question :) :
>> why cant we have dts support for this instead of having to renumber
>> every time?
>
> What do you mean "every time"?

below

>
> Feel free to help me develop the DT support for DSS =). When that's
> done, we can remove all this code.

suggesting here - but it will be nice we have some steps towards this 
direction - is there anything you'd suggest we do first?

>
>> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
>> we'd have to redo the numbering in the kernel yet again.
>
> Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?
>
> With board files they were numbered 1, 2, 3, 4, but with DT boot they
> seem to be 0, 1, 2, 3. And as we have the current situation where omap4
> boots with DT, but DSS does not have DT support, we add the DSS related
> devices in a board-file-like-fashion.

Aah we are then depending on the following
i2c-omap.c:
  adap->nr = pdev->id;
  r = i2c_add_numbered_adapter(adap);

mach-omapx/i2c.c:
.. i2c_bus_register..
pdev->id = bus_id
platform_device_register(pdev);


I dont seem to see any similar numbering enforced in dtsi - if I reorder 
the i2c entries in SoC dtsi, i'd have an issue as well, no?

probe deferral could create problems as well.. not saying it can change 
random order on a given kernel between boots, but am saying that when 
new changes come in, deferral mechanism ensures proper ordering 
dynamically, which kind of messes up with expected device numbers. I had 
an issue with mmc sometime back where probe deferal on mmc1 made it 
registered as second device as the dependency was not present on the mmc2.

No reason this cannot happen on other busses as well. To solve this on 
i2c dts, the usual convention is as follows (from omap3-beagle):
&i2c1 {
         clock-frequency = <2600000>;

         twl: twl at 48 {
                 reg = <0x48>;
                 interrupts = <7>; /* SYS_NIRQ cascaded to intc */
                 interrupt-parent = <&intc>;
         };
};

this ensures that probe success order is made independent of device 
expectation of i2c bus numbering or the order in which it was defined in 
dts.


just my 2 cents to help continued functionality in the world of dts..
-- 
Regards,
Nishanth Menon

Re: [PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

On 02/08/13 16:30, Nishanth Menon wrote:
> On 08/02/2013 08:00 AM, Tomi Valkeinen wrote:

>> Feel free to help me develop the DT support for DSS =). When that's
>> done, we can remove all this code.
> 
> suggesting here - but it will be nice we have some steps towards this
> direction - is there anything you'd suggest we do first?

I do have a DSS-DT branch, which works. I've had such a branch for
almost a year, although I've been refining it all the time. But I'm
still not happy with the DT bindings I have there, and I haven't had any
clear ideas how to solve those issues. And, as the DT bindings are an
external API, I've been very cautious with it.

I'm currently cleaning the branch up, and I hope I can send the series
next week. Hopefully I'll receive some ideas for the problematic parts.
I'll cc you =).

>>> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
>>> we'd have to redo the numbering in the kernel yet again.
>>
>> Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?
>>
>> With board files they were numbered 1, 2, 3, 4, but with DT boot they
>> seem to be 0, 1, 2, 3. And as we have the current situation where omap4
>> boots with DT, but DSS does not have DT support, we add the DSS related
>> devices in a board-file-like-fashion.
> 
> Aah we are then depending on the following
> i2c-omap.c:
>  adap->nr = pdev->id;
>  r = i2c_add_numbered_adapter(adap);
> 
> mach-omapx/i2c.c:
> .. i2c_bus_register..
> pdev->id = bus_id
> platform_device_register(pdev);
> 
> 
> I dont seem to see any similar numbering enforced in dtsi - if I reorder
> the i2c entries in SoC dtsi, i'd have an issue as well, no?

I don't know, but yes, possibly. But you probably won't reorder them, as
they are in the HW I2C ID module order.

> probe deferral could create problems as well.. not saying it can change
> random order on a given kernel between boots, but am saying that when
> new changes come in, deferral mechanism ensures proper ordering
> dynamically, which kind of messes up with expected device numbers. I had
> an issue with mmc sometime back where probe deferal on mmc1 made it
> registered as second device as the dependency was not present on the mmc2.

Yes, interesting point. If I got you right, you're saying that if a
single i2c device gets deferred, but the others not, the ID numbering
could change?

I don't if it's possible to get only single i2c device deferred. Maybe.

Anyway, we need some way to fix this for 3.11. As far as I understand,
it's rather unlikely that the bus number would change, so I think this
fix is the best I can do.

> No reason this cannot happen on other busses as well. To solve this on
> i2c dts, the usual convention is as follows (from omap3-beagle):
> &i2c1 {
>         clock-frequency = <2600000>;
> 
>         twl: twl@48 {
>                 reg = <0x48>;
>                 interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>                 interrupt-parent = <&intc>;
>         };
> };
> 
> this ensures that probe success order is made independent of device
> expectation of i2c bus numbering or the order in which it was defined in
> dts.

With dts, this is not a problem, it's handle with phandles. Although not
as you show above, because we don't really have an i2c device on the board.

The i2c in question goes through the DVI connector to the monitor. So
the monitor is the i2c device. Thus we just get a handle to the i2c bus
going to the monitor, and send messages to it directly, without having a
linux i2c device.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Tomi Valkeinen]

On 02/08/13 16:30, Nishanth Menon wrote:
> On 08/02/2013 08:00 AM, Tomi Valkeinen wrote:

>> Feel free to help me develop the DT support for DSS =). When that's
>> done, we can remove all this code.
> 
> suggesting here - but it will be nice we have some steps towards this
> direction - is there anything you'd suggest we do first?

I do have a DSS-DT branch, which works. I've had such a branch for
almost a year, although I've been refining it all the time. But I'm
still not happy with the DT bindings I have there, and I haven't had any
clear ideas how to solve those issues. And, as the DT bindings are an
external API, I've been very cautious with it.

I'm currently cleaning the branch up, and I hope I can send the series
next week. Hopefully I'll receive some ideas for the problematic parts.
I'll cc you =).

>>> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
>>> we'd have to redo the numbering in the kernel yet again.
>>
>> Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?
>>
>> With board files they were numbered 1, 2, 3, 4, but with DT boot they
>> seem to be 0, 1, 2, 3. And as we have the current situation where omap4
>> boots with DT, but DSS does not have DT support, we add the DSS related
>> devices in a board-file-like-fashion.
> 
> Aah we are then depending on the following
> i2c-omap.c:
>  adap->nr = pdev->id;
>  r = i2c_add_numbered_adapter(adap);
> 
> mach-omapx/i2c.c:
> .. i2c_bus_register..
> pdev->id = bus_id
> platform_device_register(pdev);
> 
> 
> I dont seem to see any similar numbering enforced in dtsi - if I reorder
> the i2c entries in SoC dtsi, i'd have an issue as well, no?

I don't know, but yes, possibly. But you probably won't reorder them, as
they are in the HW I2C ID module order.

> probe deferral could create problems as well.. not saying it can change
> random order on a given kernel between boots, but am saying that when
> new changes come in, deferral mechanism ensures proper ordering
> dynamically, which kind of messes up with expected device numbers. I had
> an issue with mmc sometime back where probe deferal on mmc1 made it
> registered as second device as the dependency was not present on the mmc2.

Yes, interesting point. If I got you right, you're saying that if a
single i2c device gets deferred, but the others not, the ID numbering
could change?

I don't if it's possible to get only single i2c device deferred. Maybe.

Anyway, we need some way to fix this for 3.11. As far as I understand,
it's rather unlikely that the bus number would change, so I think this
fix is the best I can do.

> No reason this cannot happen on other busses as well. To solve this on
> i2c dts, the usual convention is as follows (from omap3-beagle):
> &i2c1 {
>         clock-frequency = <2600000>;
> 
>         twl: twl at 48 {
>                 reg = <0x48>;
>                 interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>                 interrupt-parent = <&intc>;
>         };
> };
> 
> this ensures that probe success order is made independent of device
> expectation of i2c bus numbering or the order in which it was defined in
> dts.

With dts, this is not a problem, it's handle with phandles. Although not
as you show above, because we don't really have an i2c device on the board.

The i2c in question goes through the DVI connector to the monitor. So
the monitor is the i2c device. Thus we just get a handle to the i2c bus
going to the monitor, and send messages to it directly, without having a
linux i2c device.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130802/ed22bd84/attachment.sig>

Re: [PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Nishanth Menon]

On 08/02/2013 09:22 AM, Tomi Valkeinen wrote:
> On 02/08/13 16:30, Nishanth Menon wrote:
>> On 08/02/2013 08:00 AM, Tomi Valkeinen wrote:
>
>>> Feel free to help me develop the DT support for DSS =). When that's
>>> done, we can remove all this code.
>>
>> suggesting here - but it will be nice we have some steps towards this
>> direction - is there anything you'd suggest we do first?
>
> I do have a DSS-DT branch, which works. I've had such a branch for
> almost a year, although I've been refining it all the time. But I'm
> still not happy with the DT bindings I have there, and I haven't had any
> clear ideas how to solve those issues. And, as the DT bindings are an
> external API, I've been very cautious with it.
>
> I'm currently cleaning the branch up, and I hope I can send the series
> next week. Hopefully I'll receive some ideas for the problematic parts.
> I'll cc you =).

Awesome, given that there is work in progress to do this properly and 
the current solution is meant for 3.11 transition, I dont have any 
objections.


>
>>>> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
>>>> we'd have to redo the numbering in the kernel yet again.
>>>
>>> Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?
>>>
>>> With board files they were numbered 1, 2, 3, 4, but with DT boot they
>>> seem to be 0, 1, 2, 3. And as we have the current situation where omap4
>>> boots with DT, but DSS does not have DT support, we add the DSS related
>>> devices in a board-file-like-fashion.
>>
>> Aah we are then depending on the following
>> i2c-omap.c:
>>   adap->nr = pdev->id;
>>   r = i2c_add_numbered_adapter(adap);
>>
>> mach-omapx/i2c.c:
>> .. i2c_bus_register..
>> pdev->id = bus_id
>> platform_device_register(pdev);
>>
>>
>> I dont seem to see any similar numbering enforced in dtsi - if I reorder
>> the i2c entries in SoC dtsi, i'd have an issue as well, no?
>
> I don't know, but yes, possibly. But you probably won't reorder them, as
> they are in the HW I2C ID module order.

we dont want to depend on ordering of anything usually.. anyways, 
besides the point, I guess.

>
>> probe deferral could create problems as well.. not saying it can change
>> random order on a given kernel between boots, but am saying that when
>> new changes come in, deferral mechanism ensures proper ordering
>> dynamically, which kind of messes up with expected device numbers. I had
>> an issue with mmc sometime back where probe deferal on mmc1 made it
>> registered as second device as the dependency was not present on the mmc2.
>
> Yes, interesting point. If I got you right, you're saying that if a
> single i2c device gets deferred, but the others not, the ID numbering
> could change?
>
> I don't if it's possible to get only single i2c device deferred. Maybe.
>
> Anyway, we need some way to fix this for 3.11. As far as I understand,
> it's rather unlikely that the bus number would change, so I think this
> fix is the best I can do.
>
>> No reason this cannot happen on other busses as well. To solve this on
>> i2c dts, the usual convention is as follows (from omap3-beagle):
>> &i2c1 {
>>          clock-frequency = <2600000>;
>>
>>          twl: twl@48 {
>>                  reg = <0x48>;
>>                  interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>>                  interrupt-parent = <&intc>;
>>          };
>> };
>>
>> this ensures that probe success order is made independent of device
>> expectation of i2c bus numbering or the order in which it was defined in
>> dts.
>
> With dts, this is not a problem, it's handle with phandles. Although not
> as you show above, because we don't really have an i2c device on the board.
>
> The i2c in question goes through the DVI connector to the monitor. So
> the monitor is the i2c device. Thus we just get a handle to the i2c bus
> going to the monitor, and send messages to it directly, without having a
> linux i2c device.

I think we should take this as part of your series next week :). I could 
argue that the device on remote display which communicates over DCC is 
an real i2c device and communicates using real i2c protocol? when we 
read it, how the gates to EDID information is opened up is upto the driver.


-- 
Regards,
Nishanth Menon

[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel

[Nishanth Menon]

On 08/02/2013 09:22 AM, Tomi Valkeinen wrote:
> On 02/08/13 16:30, Nishanth Menon wrote:
>> On 08/02/2013 08:00 AM, Tomi Valkeinen wrote:
>
>>> Feel free to help me develop the DT support for DSS =). When that's
>>> done, we can remove all this code.
>>
>> suggesting here - but it will be nice we have some steps towards this
>> direction - is there anything you'd suggest we do first?
>
> I do have a DSS-DT branch, which works. I've had such a branch for
> almost a year, although I've been refining it all the time. But I'm
> still not happy with the DT bindings I have there, and I haven't had any
> clear ideas how to solve those issues. And, as the DT bindings are an
> external API, I've been very cautious with it.
>
> I'm currently cleaning the branch up, and I hope I can send the series
> next week. Hopefully I'll receive some ideas for the problematic parts.
> I'll cc you =).

Awesome, given that there is work in progress to do this properly and 
the current solution is meant for 3.11 transition, I dont have any 
objections.


>
>>>> Example: if -EPROBEDEFER is incurred due to some unexpected dependency,
>>>> we'd have to redo the numbering in the kernel yet again.
>>>
>>> Hmm, sorry? Do you mean that the i2c bus numbers can change "randomly"?
>>>
>>> With board files they were numbered 1, 2, 3, 4, but with DT boot they
>>> seem to be 0, 1, 2, 3. And as we have the current situation where omap4
>>> boots with DT, but DSS does not have DT support, we add the DSS related
>>> devices in a board-file-like-fashion.
>>
>> Aah we are then depending on the following
>> i2c-omap.c:
>>   adap->nr = pdev->id;
>>   r = i2c_add_numbered_adapter(adap);
>>
>> mach-omapx/i2c.c:
>> .. i2c_bus_register..
>> pdev->id = bus_id
>> platform_device_register(pdev);
>>
>>
>> I dont seem to see any similar numbering enforced in dtsi - if I reorder
>> the i2c entries in SoC dtsi, i'd have an issue as well, no?
>
> I don't know, but yes, possibly. But you probably won't reorder them, as
> they are in the HW I2C ID module order.

we dont want to depend on ordering of anything usually.. anyways, 
besides the point, I guess.

>
>> probe deferral could create problems as well.. not saying it can change
>> random order on a given kernel between boots, but am saying that when
>> new changes come in, deferral mechanism ensures proper ordering
>> dynamically, which kind of messes up with expected device numbers. I had
>> an issue with mmc sometime back where probe deferal on mmc1 made it
>> registered as second device as the dependency was not present on the mmc2.
>
> Yes, interesting point. If I got you right, you're saying that if a
> single i2c device gets deferred, but the others not, the ID numbering
> could change?
>
> I don't if it's possible to get only single i2c device deferred. Maybe.
>
> Anyway, we need some way to fix this for 3.11. As far as I understand,
> it's rather unlikely that the bus number would change, so I think this
> fix is the best I can do.
>
>> No reason this cannot happen on other busses as well. To solve this on
>> i2c dts, the usual convention is as follows (from omap3-beagle):
>> &i2c1 {
>>          clock-frequency = <2600000>;
>>
>>          twl: twl at 48 {
>>                  reg = <0x48>;
>>                  interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>>                  interrupt-parent = <&intc>;
>>          };
>> };
>>
>> this ensures that probe success order is made independent of device
>> expectation of i2c bus numbering or the order in which it was defined in
>> dts.
>
> With dts, this is not a problem, it's handle with phandles. Although not
> as you show above, because we don't really have an i2c device on the board.
>
> The i2c in question goes through the DVI connector to the monitor. So
> the monitor is the i2c device. Thus we just get a handle to the i2c bus
> going to the monitor, and send messages to it directly, without having a
> linux i2c device.

I think we should take this as part of your series next week :). I could 
argue that the device on remote display which communicates over DCC is 
an real i2c device and communicates using real i2c protocol? when we 
read it, how the gates to EDID information is opened up is upto the driver.


-- 
Regards,
Nishanth Menon

[PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Tomi Valkeinen]

This is no longer needed as omap4 is now booted using device tree.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 47 ----------------------------------------
 arch/arm/mach-omap2/dss-common.h |  2 --
 2 files changed, 49 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 043e570..00c0492 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
 	.default_device	= &omap4_panda_dvi_device,
 };
 
-void __init omap4_panda_display_init(void)
-{
-	omap_display_init(&omap4_panda_dss_data);
-
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap4_panda_display_init_of(void)
 {
 	omap_display_init(&omap4_panda_dss_data);
@@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
  * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
  * selected by default
  */
-void __init omap_4430sdp_display_init(void)
-{
-	int r;
-
-	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
-			"display_sel");
-	if (r)
-		pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
-	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
-		"DLP POWER ON");
-	if (r)
-		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
-	omap_display_init(&sdp4430_dss_data);
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap_4430sdp_display_init_of(void)
 {
 	int r;
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..c28fe3c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -6,9 +6,7 @@
  * This file will be removed when DSS supports DT.
  */
 
-void __init omap4_panda_display_init(void);
 void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init(void);
 void __init omap_4430sdp_display_init_of(void);
 
 #endif
-- 
1.8.1.2

[PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Tomi Valkeinen]

This is no longer needed as omap4 is now booted using device tree.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/dss-common.c | 47 ----------------------------------------
 arch/arm/mach-omap2/dss-common.h |  2 --
 2 files changed, 49 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 043e570..00c0492 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
 	.default_device	= &omap4_panda_dvi_device,
 };
 
-void __init omap4_panda_display_init(void)
-{
-	omap_display_init(&omap4_panda_dss_data);
-
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap4_panda_display_init_of(void)
 {
 	omap_display_init(&omap4_panda_dss_data);
@@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
  * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
  * selected by default
  */
-void __init omap_4430sdp_display_init(void)
-{
-	int r;
-
-	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
-			"display_sel");
-	if (r)
-		pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
-	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
-		"DLP POWER ON");
-	if (r)
-		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
-	omap_display_init(&sdp4430_dss_data);
-	/*
-	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-	 * later have external pull up on the HDMI I2C lines
-	 */
-	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
-		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
-	else
-		omap_hdmi_init(0);
-
-	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
-	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
 void __init omap_4430sdp_display_init_of(void)
 {
 	int r;
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..c28fe3c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -6,9 +6,7 @@
  * This file will be removed when DSS supports DT.
  */
 
-void __init omap4_panda_display_init(void);
 void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init(void);
 void __init omap_4430sdp_display_init_of(void);
 
 #endif
-- 
1.8.1.2

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Nishanth Menon]

On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
> This is no longer needed as omap4 is now booted using device tree.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/mach-omap2/dss-common.c | 47 ----------------------------------------
>   arch/arm/mach-omap2/dss-common.h |  2 --
>   2 files changed, 49 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
> index 043e570..00c0492 100644
> --- a/arch/arm/mach-omap2/dss-common.c
> +++ b/arch/arm/mach-omap2/dss-common.c
> @@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
>   	.default_device	= &omap4_panda_dvi_device,
>   };
>
> -void __init omap4_panda_display_init(void)
> -{
> -	omap_display_init(&omap4_panda_dss_data);
> -
> -	/*
> -	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
> -	 * later have external pull up on the HDMI I2C lines
> -	 */
> -	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
> -		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
> -	else
> -		omap_hdmi_init(0);
> -
> -	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
> -}
> -
>   void __init omap4_panda_display_init_of(void)
>   {
>   	omap_display_init(&omap4_panda_dss_data);
> @@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
>    * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
>    * selected by default
>    */
> -void __init omap_4430sdp_display_init(void)
> -{
> -	int r;
> -
> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
> -			"display_sel");
> -	if (r)
> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
> -
> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
> -		"DLP POWER ON");
> -	if (r)
> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
> -
> -	omap_display_init(&sdp4430_dss_data);
> -	/*
> -	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
> -	 * later have external pull up on the HDMI I2C lines
> -	 */
> -	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
> -		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
> -	else
> -		omap_hdmi_init(0);
> -
> -	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
> -}
> -
>   void __init omap_4430sdp_display_init_of(void)
>   {
>   	int r;
> diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
> index 915f6ff..c28fe3c 100644
> --- a/arch/arm/mach-omap2/dss-common.h
> +++ b/arch/arm/mach-omap2/dss-common.h
> @@ -6,9 +6,7 @@
>    * This file will be removed when DSS supports DT.
>    */
>
> -void __init omap4_panda_display_init(void);
>   void __init omap4_panda_display_init_of(void);
> -void __init omap_4430sdp_display_init(void);
>   void __init omap_4430sdp_display_init_of(void);
>
>   #endif
>

Am I missing some series which introduces dts entries for the pinctrl 
and gpios for omap4 support?


-- 
Regards,
Nishanth Menon

[PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Nishanth Menon]

On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
> This is no longer needed as omap4 is now booted using device tree.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>   arch/arm/mach-omap2/dss-common.c | 47 ----------------------------------------
>   arch/arm/mach-omap2/dss-common.h |  2 --
>   2 files changed, 49 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
> index 043e570..00c0492 100644
> --- a/arch/arm/mach-omap2/dss-common.c
> +++ b/arch/arm/mach-omap2/dss-common.c
> @@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
>   	.default_device	= &omap4_panda_dvi_device,
>   };
>
> -void __init omap4_panda_display_init(void)
> -{
> -	omap_display_init(&omap4_panda_dss_data);
> -
> -	/*
> -	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
> -	 * later have external pull up on the HDMI I2C lines
> -	 */
> -	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
> -		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
> -	else
> -		omap_hdmi_init(0);
> -
> -	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
> -}
> -
>   void __init omap4_panda_display_init_of(void)
>   {
>   	omap_display_init(&omap4_panda_dss_data);
> @@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
>    * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
>    * selected by default
>    */
> -void __init omap_4430sdp_display_init(void)
> -{
> -	int r;
> -
> -	r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
> -			"display_sel");
> -	if (r)
> -		pr_err("%s: Could not get display_sel GPIO\n", __func__);
> -
> -	r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
> -		"DLP POWER ON");
> -	if (r)
> -		pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
> -
> -	omap_display_init(&sdp4430_dss_data);
> -	/*
> -	 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
> -	 * later have external pull up on the HDMI I2C lines
> -	 */
> -	if (cpu_is_omap446x() || omap_rev() > OMAP4430_REV_ES2_2)
> -		omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
> -	else
> -		omap_hdmi_init(0);
> -
> -	omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
> -	omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
> -}
> -
>   void __init omap_4430sdp_display_init_of(void)
>   {
>   	int r;
> diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
> index 915f6ff..c28fe3c 100644
> --- a/arch/arm/mach-omap2/dss-common.h
> +++ b/arch/arm/mach-omap2/dss-common.h
> @@ -6,9 +6,7 @@
>    * This file will be removed when DSS supports DT.
>    */
>
> -void __init omap4_panda_display_init(void);
>   void __init omap4_panda_display_init_of(void);
> -void __init omap_4430sdp_display_init(void);
>   void __init omap_4430sdp_display_init_of(void);
>
>   #endif
>

Am I missing some series which introduces dts entries for the pinctrl 
and gpios for omap4 support?


-- 
Regards,
Nishanth Menon

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On 02/08/13 15:56, Nishanth Menon wrote:
> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>> This is no longer needed as omap4 is now booted using device tree.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---

<snip>

>> diff --git a/arch/arm/mach-omap2/dss-common.h
>> b/arch/arm/mach-omap2/dss-common.h
>> index 915f6ff..c28fe3c 100644
>> --- a/arch/arm/mach-omap2/dss-common.h
>> +++ b/arch/arm/mach-omap2/dss-common.h
>> @@ -6,9 +6,7 @@
>>    * This file will be removed when DSS supports DT.
>>    */
>>
>> -void __init omap4_panda_display_init(void);
>>   void __init omap4_panda_display_init_of(void);
>> -void __init omap_4430sdp_display_init(void);
>>   void __init omap_4430sdp_display_init_of(void);
>>
>>   #endif
>>
> 
> Am I missing some series which introduces dts entries for the pinctrl
> and gpios for omap4 support?

Umm... What? =).

In this dss-common.c file we have code to add the SDP and Panda DSS
related devices, for both board-file booting and for DT booting. Now the
board-file booting is no longer available, so we can remove the parts
that are purely for board-file booting.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Tomi Valkeinen]

On 02/08/13 15:56, Nishanth Menon wrote:
> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>> This is no longer needed as omap4 is now booted using device tree.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---

<snip>

>> diff --git a/arch/arm/mach-omap2/dss-common.h
>> b/arch/arm/mach-omap2/dss-common.h
>> index 915f6ff..c28fe3c 100644
>> --- a/arch/arm/mach-omap2/dss-common.h
>> +++ b/arch/arm/mach-omap2/dss-common.h
>> @@ -6,9 +6,7 @@
>>    * This file will be removed when DSS supports DT.
>>    */
>>
>> -void __init omap4_panda_display_init(void);
>>   void __init omap4_panda_display_init_of(void);
>> -void __init omap_4430sdp_display_init(void);
>>   void __init omap_4430sdp_display_init_of(void);
>>
>>   #endif
>>
> 
> Am I missing some series which introduces dts entries for the pinctrl
> and gpios for omap4 support?

Umm... What? =).

In this dss-common.c file we have code to add the SDP and Panda DSS
related devices, for both board-file booting and for DT booting. Now the
board-file booting is no longer available, so we can remove the parts
that are purely for board-file booting.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130802/4bdf2627/attachment.sig>

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Nishanth Menon]

On 08/02/2013 08:04 AM, Tomi Valkeinen wrote:
> On 02/08/13 15:56, Nishanth Menon wrote:
>> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>>> This is no longer needed as omap4 is now booted using device tree.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>
> <snip>
>
>>> diff --git a/arch/arm/mach-omap2/dss-common.h
>>> b/arch/arm/mach-omap2/dss-common.h
>>> index 915f6ff..c28fe3c 100644
>>> --- a/arch/arm/mach-omap2/dss-common.h
>>> +++ b/arch/arm/mach-omap2/dss-common.h
>>> @@ -6,9 +6,7 @@
>>>     * This file will be removed when DSS supports DT.
>>>     */
>>>
>>> -void __init omap4_panda_display_init(void);
>>>    void __init omap4_panda_display_init_of(void);
>>> -void __init omap_4430sdp_display_init(void);
>>>    void __init omap_4430sdp_display_init_of(void);
>>>
>>>    #endif
>>>
>>
>> Am I missing some series which introduces dts entries for the pinctrl
>> and gpios for omap4 support?
>
> Umm... What? =).
>
> In this dss-common.c file we have code to add the SDP and Panda DSS
> related devices, for both board-file booting and for DT booting. Now the
> board-file booting is no longer available, so we can remove the parts
> that are purely for board-file booting.

Aaah. sorry about that, i was not completely enlightned about lack of 
dts conversion for DSS into dts.


-- 
Regards,
Nishanth Menon

[PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4

[Nishanth Menon]

On 08/02/2013 08:04 AM, Tomi Valkeinen wrote:
> On 02/08/13 15:56, Nishanth Menon wrote:
>> On 07/23/2013 04:06 AM, Tomi Valkeinen wrote:
>>> This is no longer needed as omap4 is now booted using device tree.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>
> <snip>
>
>>> diff --git a/arch/arm/mach-omap2/dss-common.h
>>> b/arch/arm/mach-omap2/dss-common.h
>>> index 915f6ff..c28fe3c 100644
>>> --- a/arch/arm/mach-omap2/dss-common.h
>>> +++ b/arch/arm/mach-omap2/dss-common.h
>>> @@ -6,9 +6,7 @@
>>>     * This file will be removed when DSS supports DT.
>>>     */
>>>
>>> -void __init omap4_panda_display_init(void);
>>>    void __init omap4_panda_display_init_of(void);
>>> -void __init omap_4430sdp_display_init(void);
>>>    void __init omap_4430sdp_display_init_of(void);
>>>
>>>    #endif
>>>
>>
>> Am I missing some series which introduces dts entries for the pinctrl
>> and gpios for omap4 support?
>
> Umm... What? =).
>
> In this dss-common.c file we have code to add the SDP and Panda DSS
> related devices, for both board-file booting and for DT booting. Now the
> board-file booting is no longer available, so we can remove the parts
> that are purely for board-file booting.

Aaah. sorry about that, i was not completely enlightned about lack of 
dts conversion for DSS into dts.


-- 
Regards,
Nishanth Menon

Re: [PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 867 bytes --]

On 23/07/13 12:06, Tomi Valkeinen wrote:
> Hi Tony,
> 
> Here's a fix for 3.11 that makes EDID read for DVI work again.
> 
> I also included a cleanup patch that removes the non-DT support functions that
> are no longer called from anywhere. It's not a fix, but as we're in quite early
> rcs, I thought it would be nice to remove the dead code.
> 
> Up to you if you want to include that one for 3.11 or not. If not, I'll include
> it in a board file series for 3.12 that I'll send soon.
> 
>  Tomi
> 
> Tomi Valkeinen (2):
>   ARM: OMAP: dss-common: fix Panda's DVI DDC channel
>   ARM: OMAP2+: Remove legacy DSS initialization for omap4
> 
>  arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
>  arch/arm/mach-omap2/dss-common.h |  2 --
>  2 files changed, 1 insertion(+), 50 deletions(-)
> 

Ping.

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tomi Valkeinen]

On 23/07/13 12:06, Tomi Valkeinen wrote:
> Hi Tony,
> 
> Here's a fix for 3.11 that makes EDID read for DVI work again.
> 
> I also included a cleanup patch that removes the non-DT support functions that
> are no longer called from anywhere. It's not a fix, but as we're in quite early
> rcs, I thought it would be nice to remove the dead code.
> 
> Up to you if you want to include that one for 3.11 or not. If not, I'll include
> it in a board file series for 3.12 that I'll send soon.
> 
>  Tomi
> 
> Tomi Valkeinen (2):
>   ARM: OMAP: dss-common: fix Panda's DVI DDC channel
>   ARM: OMAP2+: Remove legacy DSS initialization for omap4
> 
>  arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
>  arch/arm/mach-omap2/dss-common.h |  2 --
>  2 files changed, 1 insertion(+), 50 deletions(-)
> 

Ping.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130802/bb450053/attachment-0001.sig>

Re: [PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130802 05:05]:
> On 23/07/13 12:06, Tomi Valkeinen wrote:
> > Hi Tony,
> > 
> > Here's a fix for 3.11 that makes EDID read for DVI work again.
> > 
> > I also included a cleanup patch that removes the non-DT support functions that
> > are no longer called from anywhere. It's not a fix, but as we're in quite early
> > rcs, I thought it would be nice to remove the dead code.
> > 
> > Up to you if you want to include that one for 3.11 or not. If not, I'll include
> > it in a board file series for 3.12 that I'll send soon.
> > 
> >  Tomi
> > 
> > Tomi Valkeinen (2):
> >   ARM: OMAP: dss-common: fix Panda's DVI DDC channel
> >   ARM: OMAP2+: Remove legacy DSS initialization for omap4
> > 
> >  arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
> >  arch/arm/mach-omap2/dss-common.h |  2 --
> >  2 files changed, 1 insertion(+), 50 deletions(-)
> > 
> 
> Ping.

Oops, sorry I was offline last week and still not caught up on mails..
If you have other DSS fixes I suggest you also send these fixes:

Acked-by: Tony Lindgren <tony@atomide.com>

If not, let me know and I'll queue these.

Regards,

Tony

[PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130802 05:05]:
> On 23/07/13 12:06, Tomi Valkeinen wrote:
> > Hi Tony,
> > 
> > Here's a fix for 3.11 that makes EDID read for DVI work again.
> > 
> > I also included a cleanup patch that removes the non-DT support functions that
> > are no longer called from anywhere. It's not a fix, but as we're in quite early
> > rcs, I thought it would be nice to remove the dead code.
> > 
> > Up to you if you want to include that one for 3.11 or not. If not, I'll include
> > it in a board file series for 3.12 that I'll send soon.
> > 
> >  Tomi
> > 
> > Tomi Valkeinen (2):
> >   ARM: OMAP: dss-common: fix Panda's DVI DDC channel
> >   ARM: OMAP2+: Remove legacy DSS initialization for omap4
> > 
> >  arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
> >  arch/arm/mach-omap2/dss-common.h |  2 --
> >  2 files changed, 1 insertion(+), 50 deletions(-)
> > 
> 
> Ping.

Oops, sorry I was offline last week and still not caught up on mails..
If you have other DSS fixes I suggest you also send these fixes:

Acked-by: Tony Lindgren <tony@atomide.com>

If not, let me know and I'll queue these.

Regards,

Tony

Re: [PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

On 02/08/13 15:46, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130802 05:05]:
>> On 23/07/13 12:06, Tomi Valkeinen wrote:
>>> Hi Tony,
>>>
>>> Here's a fix for 3.11 that makes EDID read for DVI work again.
>>>
>>> I also included a cleanup patch that removes the non-DT support functions that
>>> are no longer called from anywhere. It's not a fix, but as we're in quite early
>>> rcs, I thought it would be nice to remove the dead code.
>>>
>>> Up to you if you want to include that one for 3.11 or not. If not, I'll include
>>> it in a board file series for 3.12 that I'll send soon.
>>>
>>>  Tomi
>>>
>>> Tomi Valkeinen (2):
>>>   ARM: OMAP: dss-common: fix Panda's DVI DDC channel
>>>   ARM: OMAP2+: Remove legacy DSS initialization for omap4
>>>
>>>  arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
>>>  arch/arm/mach-omap2/dss-common.h |  2 --
>>>  2 files changed, 1 insertion(+), 50 deletions(-)
>>>
>>
>> Ping.
> 
> Oops, sorry I was offline last week and still not caught up on mails..

Ok, no prob. There's the "ARM: OMAP2+: use new display drivers" series
also waiting for you, but that's for 3.12 =).

> If you have other DSS fixes I suggest you also send these fixes:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>
> 
> If not, let me know and I'll queue these.

I've got a few fbdev fixes, I can apply the fix to that branch. I'll
leave the second patch for 3.12 as it's really a cleanup (it's actually
also included in the "use new display drivers" series).

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 0/2] OMAP: Panda DVI fix and a cleanup

[Tomi Valkeinen]

On 02/08/13 15:46, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130802 05:05]:
>> On 23/07/13 12:06, Tomi Valkeinen wrote:
>>> Hi Tony,
>>>
>>> Here's a fix for 3.11 that makes EDID read for DVI work again.
>>>
>>> I also included a cleanup patch that removes the non-DT support functions that
>>> are no longer called from anywhere. It's not a fix, but as we're in quite early
>>> rcs, I thought it would be nice to remove the dead code.
>>>
>>> Up to you if you want to include that one for 3.11 or not. If not, I'll include
>>> it in a board file series for 3.12 that I'll send soon.
>>>
>>>  Tomi
>>>
>>> Tomi Valkeinen (2):
>>>   ARM: OMAP: dss-common: fix Panda's DVI DDC channel
>>>   ARM: OMAP2+: Remove legacy DSS initialization for omap4
>>>
>>>  arch/arm/mach-omap2/dss-common.c | 49 +---------------------------------------
>>>  arch/arm/mach-omap2/dss-common.h |  2 --
>>>  2 files changed, 1 insertion(+), 50 deletions(-)
>>>
>>
>> Ping.
> 
> Oops, sorry I was offline last week and still not caught up on mails..

Ok, no prob. There's the "ARM: OMAP2+: use new display drivers" series
also waiting for you, but that's for 3.12 =).

> If you have other DSS fixes I suggest you also send these fixes:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>
> 
> If not, let me know and I'll queue these.

I've got a few fbdev fixes, I can apply the fix to that branch. I'll
leave the second patch for 3.12 as it's really a cleanup (it's actually
also included in the "use new display drivers" series).

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130802/64dc5500/attachment.sig>