ARM: shmobile: defconfig: enable HDMI output for RCar

Commit Message

Wolfram Sang Oct. 10, 2015, 7:14 p.m. UTC

From: Wolfram Sang <[e-mail]>

Actviate HDMI output of the RCar DU (and LVDS while we are here).
Enable the HDMI encoder chip found on Lager/Koelsch boards.

Signed-off-by: Wolfram Sang <[e-mail]>
---

This is the final bit needed to get HDMI output with an shmobile_defconfig
built kernel. The other bits were renesas-devel-20151008-v4.3-rc4 plus some I2C
patches, which are already in my for-next or soon in my for-current branches.
The complete branch can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/rcar-hdmi-output

Tested with a Lager board and using both I2C/IIC. Based on my testings in
Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch.
Laurent may prove me wrong ;)

 arch/arm/configs/shmobile_defconfig | 3 +++
 1 file changed, 3 insertions(+)

Comments

Simon Horman Oct. 12, 2015, 12:19 a.m. UTC | #1

On Sat, Oct 10, 2015 at 08:14:45PM +0100, Wolfram Sang wrote:
> From: Wolfram Sang <[e-mail]>
> 
> Actviate HDMI output of the RCar DU (and LVDS while we are here).
> Enable the HDMI encoder chip found on Lager/Koelsch boards.
> 
> Signed-off-by: Wolfram Sang <[e-mail]>

Thanks, I have queued this up for v4.4.

Is a similar change appropriate for multi_v7_defconfig?
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wolfram Sang Oct. 12, 2015, 6:38 a.m. UTC | #2

> Is a similar change appropriate for multi_v7_defconfig?

As modules, I'd assume. I'll cook something.

Thanks, Simon.

Simon Horman Oct. 13, 2015, 1:03 a.m. UTC | #3

On Mon, Oct 12, 2015 at 07:38:06AM +0100, Wolfram Sang wrote:
> > Is a similar change appropriate for multi_v7_defconfig?
> 
> As modules, I'd assume. I'll cook something.

Yes, I think that would be best; thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Laurent Pinchart Oct. 14, 2015, 1:09 a.m. UTC | #4

Hi Wolfram,

Thank you for the patch.

On Saturday 10 October 2015 20:14:45 Wolfram Sang wrote:
> From: Wolfram Sang <[e-mail]>
> 
> Actviate HDMI output of the RCar DU (and LVDS while we are here).
> Enable the HDMI encoder chip found on Lager/Koelsch boards.
> 
> Signed-off-by: Wolfram Sang <[e-mail]>
> ---
> 
> This is the final bit needed to get HDMI output with an shmobile_defconfig
> built kernel. The other bits were renesas-devel-20151008-v4.3-rc4 plus some
> I2C patches, which are already in my for-next or soon in my for-current
> branches. The complete branch can be found here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> renesas/rcar-hdmi-output
> 
> Tested with a Lager board and using both I2C/IIC. Based on my testings in
> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch.
> Laurent may prove me wrong ;)

I've tried to reproduce the problem tonight and couldn't, even without your 
recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that 
configuration and make sure to report any issue I can find.

>  arch/arm/configs/shmobile_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/configs/shmobile_defconfig
> b/arch/arm/configs/shmobile_defconfig index 0bdeb4925be477..3aef019c0de789
> 100644
> --- a/arch/arm/configs/shmobile_defconfig
> +++ b/arch/arm/configs/shmobile_defconfig
> @@ -140,7 +140,10 @@ CONFIG_VIDEO_RENESAS_VSP1=y
>  CONFIG_VIDEO_ADV7180=y
>  CONFIG_VIDEO_ML86V7667=y
>  CONFIG_DRM=y
> +CONFIG_DRM_I2C_ADV7511=y
>  CONFIG_DRM_RCAR_DU=y
> +CONFIG_DRM_RCAR_HDMI=y
> +CONFIG_DRM_RCAR_LVDS=y
>  CONFIG_FB_SH_MOBILE_LCDC=y
>  CONFIG_FB_SH_MOBILE_MERAM=y
>  # CONFIG_LCD_CLASS_DEVICE is not set

Wolfram Sang Oct. 14, 2015, 5:52 a.m. UTC | #5

> > Tested with a Lager board and using both I2C/IIC. Based on my testings in
> > Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch.
> > Laurent may prove me wrong ;)
> 
> I've tried to reproduce the problem tonight and couldn't, even without your 
> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that 
> configuration and make sure to report any issue I can find.

Thanks for testing!

The good news of your message is that HDMI works on Koelsch, too :)

Geert Uytterhoeven Oct. 14, 2015, 7:07 a.m. UTC | #6

Hi Laurent,

On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart
<[e-mail]> wrote:
>> Tested with a Lager board and using both I2C/IIC. Based on my testings in
>> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch.
>> Laurent may prove me wrong ;)
>
> I've tried to reproduce the problem tonight and couldn't, even without your
> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that
> configuration and make sure to report any issue I can find.

The Koelsch that failed has a much newer U-Boot (b653737dfca2), which
only enables the MSTP clocks that are really needed, while you and I have
much older versions (I have b6af5fcc8dfc).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Magnus Damm Oct. 14, 2015, 7:44 a.m. UTC | #7

Hi Geert,

On Wed, Oct 14, 2015 at 4:07 PM, Geert Uytterhoeven
<[e-mail]> wrote:
> Hi Laurent,
>
> On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart
> <[e-mail]> wrote:
>>> Tested with a Lager board and using both I2C/IIC. Based on my testings in
>>> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch.
>>> Laurent may prove me wrong ;)
>>
>> I've tried to reproduce the problem tonight and couldn't, even without your
>> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that
>> configuration and make sure to report any issue I can find.
>
> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which
> only enables the MSTP clocks that are really needed, while you and I have
> much older versions (I have b6af5fcc8dfc).

With the new CPG-MSSR driver it should be possible to disable unused
MSTP clocks in the kernel during boot without too much trouble, right?
Of course it is not something that is needed right away, but DT
architecture wise it seems possible to squeeze that in without having
to update the DT binding.

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Geert Uytterhoeven Oct. 14, 2015, 7:54 a.m. UTC | #8

Hi Magnus,

On Wed, Oct 14, 2015 at 9:44 AM, Magnus Damm <[e-mail]> wrote:
> On Wed, Oct 14, 2015 at 4:07 PM, Geert Uytterhoeven
> <[e-mail]> wrote:
>> On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart
>> <[e-mail]> wrote:
>>>> Tested with a Lager board and using both I2C/IIC. Based on my testings in
>>>> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch.
>>>> Laurent may prove me wrong ;)
>>>
>>> I've tried to reproduce the problem tonight and couldn't, even without your
>>> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that
>>> configuration and make sure to report any issue I can find.
>>
>> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which
>> only enables the MSTP clocks that are really needed, while you and I have
>> much older versions (I have b6af5fcc8dfc).
>
> With the new CPG-MSSR driver it should be possible to disable unused
> MSTP clocks in the kernel during boot without too much trouble, right?
> Of course it is not something that is needed right away, but DT
> architecture wise it seems possible to squeeze that in without having
> to update the DT binding.

Unused clocks are already disabled by the clock framework, but that
happens at late_initcall() time, i.e. after i2c probing.

Or do you mean disabling them upfront?
There are some clocks that must not be disabled. Some of them are not
documented.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Magnus Damm Oct. 14, 2015, 8:09 a.m. UTC | #9

Hi Geert,

On Wed, Oct 14, 2015 at 4:54 PM, Geert Uytterhoeven
<[e-mail]> wrote:
> Hi Magnus,
>
> On Wed, Oct 14, 2015 at 9:44 AM, Magnus Damm <[e-mail]> wrote:
>> On Wed, Oct 14, 2015 at 4:07 PM, Geert Uytterhoeven
>> <[e-mail]> wrote:
>>> On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart
>>> <[e-mail]> wrote:
>>>>> Tested with a Lager board and using both I2C/IIC. Based on my testings in
>>>>> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch.
>>>>> Laurent may prove me wrong ;)
>>>>
>>>> I've tried to reproduce the problem tonight and couldn't, even without your
>>>> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that
>>>> configuration and make sure to report any issue I can find.
>>>
>>> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which
>>> only enables the MSTP clocks that are really needed, while you and I have
>>> much older versions (I have b6af5fcc8dfc).
>>
>> With the new CPG-MSSR driver it should be possible to disable unused
>> MSTP clocks in the kernel during boot without too much trouble, right?
>> Of course it is not something that is needed right away, but DT
>> architecture wise it seems possible to squeeze that in without having
>> to update the DT binding.
>
> Unused clocks are already disabled by the clock framework, but that
> happens at late_initcall() time, i.e. after i2c probing.

Oh, right..

> Or do you mean disabling them upfront?
> There are some clocks that must not be disabled. Some of them are not
> documented.

Disabling them upfront with sparse documentation seems fun, but also a
bit like asking for trouble. =)

So disabling clocks upfront may be a troublesome but good way to
trigger incorrect dependencies, and unless I'm mistaken it should give
the same behaviour as the updated u-boot version, right?

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Geert Uytterhoeven Oct. 14, 2015, 8:22 a.m. UTC | #10

Hi Magnus,

On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm <[e-mail]> wrote:
>> Or do you mean disabling them upfront?
>> There are some clocks that must not be disabled. Some of them are not
>> documented.
>
> Disabling them upfront with sparse documentation seems fun, but also a
> bit like asking for trouble. =)

I have hackish code that does it for all boards I have, and use it actively.

> So disabling clocks upfront may be a troublesome but good way to
> trigger incorrect dependencies, and unless I'm mistaken it should give
> the same behaviour as the updated u-boot version, right?

More or less (U-Boot still keeps a few enabled for its own use, e.g. Ethernet).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Wolfram Sang Oct. 14, 2015, 8:25 a.m. UTC | #11

> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which
> only enables the MSTP clocks that are really needed, while you and I have
> much older versions (I have b6af5fcc8dfc).

What Laurent saw was a 1 byte shift in the transferreed EDID data. So,
most likely not a MSTP clock related problem ;)

Magnus Damm Oct. 14, 2015, 8:36 a.m. UTC | #12

Hi Geert,

On Wed, Oct 14, 2015 at 5:22 PM, Geert Uytterhoeven
<[e-mail]> wrote:
> Hi Magnus,
>
> On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm <[e-mail]> wrote:
>>> Or do you mean disabling them upfront?
>>> There are some clocks that must not be disabled. Some of them are not
>>> documented.
>>
>> Disabling them upfront with sparse documentation seems fun, but also a
>> bit like asking for trouble. =)
>
> I have hackish code that does it for all boards I have, and use it actively.

Seems like a good feature to me!

>> So disabling clocks upfront may be a troublesome but good way to
>> trigger incorrect dependencies, and unless I'm mistaken it should give
>> the same behaviour as the updated u-boot version, right?
>
> More or less (U-Boot still keeps a few enabled for its own use, e.g. Ethernet).

So it fails to cleanup after itself then... But by disabling clocks
upfront I guess you can be even more aggressive.

Anyway, it would be nice to see that feature upstream at some point.
Let me know if there is anything I can do to help!!

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Laurent Pinchart Oct. 14, 2015, 11:41 a.m. UTC | #13

Hi Geert,

On Wednesday 14 October 2015 09:07:41 Geert Uytterhoeven wrote:
> On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart wrote:
> >> Tested with a Lager board and using both I2C/IIC. Based on my testings in
> >> Dublin with a Koelsch board, I'd be very surprised if it fails with
> >> Koelsch. Laurent may prove me wrong ;)
> > 
> > I've tried to reproduce the problem tonight and couldn't, even without
> > your recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with
> > that configuration and make sure to report any issue I can find.
> 
> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which
> only enables the MSTP clocks that are really needed, while you and I have
> much older versions (I have b6af5fcc8dfc).

It failed on my Koelsch before, and I have never updated U-Boot on it.

khiemnguyen Oct. 14, 2015, 12:11 p.m. UTC | #14

On 10/14/2015 3:22 PM, Geert Uytterhoeven wrote:
> Hi Magnus,
>
> On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm <[e-mail]> wrote:
>>> Or do you mean disabling them upfront?
>>> There are some clocks that must not be disabled. Some of them are not
>>> documented.
>>
>> Disabling them upfront with sparse documentation seems fun, but also a
>> bit like asking for trouble. =)
>
> I have hackish code that does it for all boards I have, and use it actively.
>
>> So disabling clocks upfront may be a troublesome but good way to
>> trigger incorrect dependencies, and unless I'm mistaken it should give
>> the same behaviour as the updated u-boot version, right?
>
> More or less (U-Boot still keeps a few enabled for its own use, e.g. Ethernet).

AFAIK, in some recent versions of Gen2 BSP, all the devices (including 
all devices enabled by u-boot for its processing, like Ethernet, TMU, 
serial) will be turned off right before jumping to kernel start address.

> Gr{oetje,eeting}s,
>
>                          Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Laurent Pinchart Oct. 14, 2015, 12:55 p.m. UTC | #15

On Wednesday 14 October 2015 19:11:12 Khiem Nguyen wrote:
> On 10/14/2015 3:22 PM, Geert Uytterhoeven wrote:
> > On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm wrote:
> >>> Or do you mean disabling them upfront?
> >>> There are some clocks that must not be disabled. Some of them are not
> >>> documented.
> >> 
> >> Disabling them upfront with sparse documentation seems fun, but also a
> >> bit like asking for trouble. =)
> > 
> > I have hackish code that does it for all boards I have, and use it
> > actively.
> >
> >> So disabling clocks upfront may be a troublesome but good way to
> >> trigger incorrect dependencies, and unless I'm mistaken it should give
> >> the same behaviour as the updated u-boot version, right?
> > 
> > More or less (U-Boot still keeps a few enabled for its own use, e.g.
> > Ethernet).
>
> AFAIK, in some recent versions of Gen2 BSP, all the devices (including
> all devices enabled by u-boot for its processing, like Ethernet, TMU,
> serial) will be turned off right before jumping to kernel start address.

Would it make sense to keep the serial port enabled in order to support early 
printk ?

khiemnguyen Oct. 14, 2015, 1:18 p.m. UTC | #16

On 10/14/2015 7:55 PM, Laurent Pinchart wrote:
> On Wednesday 14 October 2015 19:11:12 Khiem Nguyen wrote:
>> On 10/14/2015 3:22 PM, Geert Uytterhoeven wrote:
>>> On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm wrote:
>>>>> Or do you mean disabling them upfront?
>>>>> There are some clocks that must not be disabled. Some of them are not
>>>>> documented.
>>>>
>>>> Disabling them upfront with sparse documentation seems fun, but also a
>>>> bit like asking for trouble. =)
>>>
>>> I have hackish code that does it for all boards I have, and use it
>>> actively.
>>>
>>>> So disabling clocks upfront may be a troublesome but good way to
>>>> trigger incorrect dependencies, and unless I'm mistaken it should give
>>>> the same behaviour as the updated u-boot version, right?
>>>
>>> More or less (U-Boot still keeps a few enabled for its own use, e.g.
>>> Ethernet).
>>
>> AFAIK, in some recent versions of Gen2 BSP, all the devices (including
>> all devices enabled by u-boot for its processing, like Ethernet, TMU,
>> serial) will be turned off right before jumping to kernel start address.
>
> Would it make sense to keep the serial port enabled in order to support early
> printk ?
>

I don't think early printk is supported in Gen2 BSP, which is base on 
LTSI 3.10.
Geert has introduced early printk support for Gen2 in Nov 2014.

Maybe, we need to consider this point for Gen3.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Geert Uytterhoeven Oct. 14, 2015, 1:32 p.m. UTC | #17

On Wed, Oct 14, 2015 at 3:18 PM, Khiem Nguyen
<[e-mail]> wrote:
>>> AFAIK, in some recent versions of Gen2 BSP, all the devices (including
>>> all devices enabled by u-boot for its processing, like Ethernet, TMU,
>>> serial) will be turned off right before jumping to kernel start address.
>>
>> Would it make sense to keep the serial port enabled in order to support
>> early
>> printk ?
>>
>
> I don't think early printk is supported in Gen2 BSP, which is base on LTSI
> 3.10.
> Geert has introduced early printk support for Gen2 in Nov 2014.
>
> Maybe, we need to consider this point for Gen3.

INTC-RT, MFIS, INTC-SYS, IRQC, and SCIF0 are left enabled, according
to the U-Boot sources.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

khiemnguyen Oct. 14, 2015, 2:11 p.m. UTC | #18

On 10/14/2015 8:32 PM, Geert Uytterhoeven wrote:
> On Wed, Oct 14, 2015 at 3:18 PM, Khiem Nguyen
> <[e-mail]> wrote:
>>>> AFAIK, in some recent versions of Gen2 BSP, all the devices (including
>>>> all devices enabled by u-boot for its processing, like Ethernet, TMU,
>>>> serial) will be turned off right before jumping to kernel start address.
>>>
>>> Would it make sense to keep the serial port enabled in order to support
>>> early
>>> printk ?
>>>
>>
>> I don't think early printk is supported in Gen2 BSP, which is base on LTSI
>> 3.10.
>> Geert has introduced early printk support for Gen2 in Nov 2014.
>>
>> Maybe, we need to consider this point for Gen3.
>
> INTC-RT, MFIS, INTC-SYS, IRQC, and SCIF0 are left enabled, according
> to the U-Boot sources.

Yes, you are right. Above devices were left enabled.
Especially, some interrupt controller devices need to keep ON to ensure 
system operation
while transferring to kernel boot.


> Gr{oetje,eeting}s,
>
>                          Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
>



--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 0bdeb4925be477..3aef019c0de789 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -140,7 +140,10 @@  CONFIG_VIDEO_RENESAS_VSP1=y
 CONFIG_VIDEO_ADV7180=y
 CONFIG_VIDEO_ML86V7667=y
 CONFIG_DRM=y
+CONFIG_DRM_I2C_ADV7511=y
 CONFIG_DRM_RCAR_DU=y
+CONFIG_DRM_RCAR_HDMI=y
+CONFIG_DRM_RCAR_LVDS=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SH_MOBILE_MERAM=y
 # CONFIG_LCD_CLASS_DEVICE is not set