exynos4412: powerdomain issues with HDMI PHY and VP

exynos4412: powerdomain issues with HDMI PHY and VP

[Tobias Jakobi]

Hello,

I'm still working on getting HDMI output on my ODROID-X2 board (based on
Exynos4412 Prime) working. My tree is a 3.15-rc6 with some patches on
top to get it boot on the board.

You can find the tree here:
https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.15.y

Here is the DTS:
https://github.com/tobiasjakobi/linux-odroid/blob/odroid-3.15.y/arch/arm/boot/dts/exynos4412-odroidx2.dts

I encountered two issues with powerdomains. On related to HDMI PHY and
the other one related to the VP (video processor).

The pd the mixer is in, is currently set to pd_tv. I can't seem to
specify multiple powerdomains for one device. However the PHY seems to
need both TV and LCD0 pd to function properly.

If TV is on, but LCD0 is not, then all that is shown on the display are
vertical colored lines. I have applied a hack that forces LCD0 on all
the time. This way I get correct output on the display connected via HDMI.

I use the simple modetest test from the libdrm repository
(http://cgit.freedesktop.org/mesa/drm/tree/tests/modetest):
modetest -M exynos -v -s 15@6:640x480
(this issues a continuous vblank test)

So, this is the first issue. The second one, related to the VP, popped
up when I tried to issue modetest more than once. I've included the
kernel warning output in the commit
(https://github.com/tobiasjakobi/linux-odroid/commit/cba8b0fd687e0e60107cf19fc5305e71e524e969).

For some reason disabling the TV pd times out, which in turn then lets
the reset of the VP fail. After that happens, the modetest test becomes
non-functional. If have to reboot the system to get it into useable
state again.

Applying the same hack for the TV pd fixes this issue. The VP reset
works again. That is the second issue.

With best wishes,
Tobias

P.S.:

CCing Inki Dae (since this involves exynos-mixer)
CCing Tomasz Figa (I can see that there were plans to move to more
general pd DT bindings, which may help here)
CCing Arun Kumar K (recent work on pd code that is related to powering
on/off -- might be related to this issue)

Re: exynos4412: powerdomain issues with HDMI PHY and VP

[Tomasz Figa]

Hi Tobias,

First of all, big thanks for investigating this issue. Hopefully we can
have it fixed in upstream soon.

I've added Tomasz Stanislawski to CC list, as he's been doing some work
to enable HDMI support on Exynos4 using Exynos DRM.

On 24.05.2014 22:45, Tobias Jakobi wrote:
> Hello,
> 
> I'm still working on getting HDMI output on my ODROID-X2 board (based on
> Exynos4412 Prime) working. My tree is a 3.15-rc6 with some patches on
> top to get it boot on the board.
> 
> You can find the tree here:
> https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.15.y
> 
> Here is the DTS:
> https://github.com/tobiasjakobi/linux-odroid/blob/odroid-3.15.y/arch/arm/boot/dts/exynos4412-odroidx2.dts
> 
> I encountered two issues with powerdomains. On related to HDMI PHY and
> the other one related to the VP (video processor).
> 
> The pd the mixer is in, is currently set to pd_tv. I can't seem to
> specify multiple powerdomains for one device. However the PHY seems to
> need both TV and LCD0 pd to function properly.

We've discovered this issue too. Unfortunately the Linux implementation
of generic power domain core (genpd) doesn't support multiple power
domains per device, so we ended up with a hack in our internal tree.

Generic power domain bindings aren't going to help too much, because
even though they account for this, the implementation will use only the
first domain.

I have CC'ed Rafael, Kevin and Ulf, as they might have some ideas how to
solve this.

> 
> If TV is on, but LCD0 is not, then all that is shown on the display are
> vertical colored lines. I have applied a hack that forces LCD0 on all
> the time. This way I get correct output on the display connected via HDMI.
> 
> I use the simple modetest test from the libdrm repository
> (http://cgit.freedesktop.org/mesa/drm/tree/tests/modetest):
> modetest -M exynos -v -s 15@6:640x480
> (this issues a continuous vblank test)
> 
> So, this is the first issue. The second one, related to the VP, popped
> up when I tried to issue modetest more than once. I've included the
> kernel warning output in the commit
> (https://github.com/tobiasjakobi/linux-odroid/commit/cba8b0fd687e0e60107cf19fc5305e71e524e969).
> 
> For some reason disabling the TV pd times out, which in turn then lets
> the reset of the VP fail. After that happens, the modetest test becomes
> non-functional. If have to reboot the system to get it into useable
> state again.
> 
> Applying the same hack for the TV pd fixes this issue. The VP reset
> works again. That is the second issue.

Seems like incorrect power down sequence in VP driver. The power domain
won't shut down if certain conditions are not met. I remember Marek
(also on Cc) and Tomasz S. having some issues similar to this with the
old V4L2 driver for VP.

Best regards,
Tomasz

Re: exynos4412: powerdomain issues with HDMI PHY and VP

[Kevin Hilman]

Tomasz Figa <tomasz.figa@gmail.com> writes:

> Hi Tobias,
>
> First of all, big thanks for investigating this issue. Hopefully we can
> have it fixed in upstream soon.
>
> I've added Tomasz Stanislawski to CC list, as he's been doing some work
> to enable HDMI support on Exynos4 using Exynos DRM.
>
> On 24.05.2014 22:45, Tobias Jakobi wrote:
>> Hello,
>> 
>> I'm still working on getting HDMI output on my ODROID-X2 board (based on
>> Exynos4412 Prime) working. My tree is a 3.15-rc6 with some patches on
>> top to get it boot on the board.
>> 
>> You can find the tree here:
>> https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.15.y
>> 
>> Here is the DTS:
>> https://github.com/tobiasjakobi/linux-odroid/blob/odroid-3.15.y/arch/arm/boot/dts/exynos4412-odroidx2.dts
>> 
>> I encountered two issues with powerdomains. On related to HDMI PHY and
>> the other one related to the VP (video processor).
>> 
>> The pd the mixer is in, is currently set to pd_tv. I can't seem to
>> specify multiple powerdomains for one device. However the PHY seems to
>> need both TV and LCD0 pd to function properly.
>
> We've discovered this issue too. Unfortunately the Linux implementation
> of generic power domain core (genpd) doesn't support multiple power
> domains per device, so we ended up with a hack in our internal tree.
>
> Generic power domain bindings aren't going to help too much, because
> even though they account for this, the implementation will use only the
> first domain.
>
> I have CC'ed Rafael, Kevin and Ulf, as they might have some ideas how to
> solve this.

Hmm, this seems a bit strange.  How is this implemented in hardware?  It
seems rather unlikely that the same IP block is getting power from two
different power rails.  So I don't think what you really want is to have
the device modeled in 2 power domains.

Rather, I suspect there's some functional dependency going on that's not
directly a function of the power domain itself.  Taking a wild shot in
the dark, it wouldn't be too surprising if the IP block in question
depends on a clock coming from a device in another power domain?  Since
this sounds display related, is the pixel clock required coming from an
IP block in the other power domain?

If it's something like a clock dependency, then that needs to be modeled
so what when the clock is enabled, the power domain containg the device
providing that clock cannot be shut down.

Kevin

Re: exynos4412: powerdomain issues with HDMI PHY and VP

[Tomasz Figa]

On 27.05.2014 18:49, Kevin Hilman wrote:
> Tomasz Figa <tomasz.figa@gmail.com> writes:
> 
>> Hi Tobias,
>>
>> First of all, big thanks for investigating this issue. Hopefully we can
>> have it fixed in upstream soon.
>>
>> I've added Tomasz Stanislawski to CC list, as he's been doing some work
>> to enable HDMI support on Exynos4 using Exynos DRM.
>>
>> On 24.05.2014 22:45, Tobias Jakobi wrote:
>>> Hello,
>>>
>>> I'm still working on getting HDMI output on my ODROID-X2 board (based on
>>> Exynos4412 Prime) working. My tree is a 3.15-rc6 with some patches on
>>> top to get it boot on the board.
>>>
>>> You can find the tree here:
>>> https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.15.y
>>>
>>> Here is the DTS:
>>> https://github.com/tobiasjakobi/linux-odroid/blob/odroid-3.15.y/arch/arm/boot/dts/exynos4412-odroidx2.dts
>>>
>>> I encountered two issues with powerdomains. On related to HDMI PHY and
>>> the other one related to the VP (video processor).
>>>
>>> The pd the mixer is in, is currently set to pd_tv. I can't seem to
>>> specify multiple powerdomains for one device. However the PHY seems to
>>> need both TV and LCD0 pd to function properly.
>>
>> We've discovered this issue too. Unfortunately the Linux implementation
>> of generic power domain core (genpd) doesn't support multiple power
>> domains per device, so we ended up with a hack in our internal tree.
>>
>> Generic power domain bindings aren't going to help too much, because
>> even though they account for this, the implementation will use only the
>> first domain.
>>
>> I have CC'ed Rafael, Kevin and Ulf, as they might have some ideas how to
>> solve this.
> 
> Hmm, this seems a bit strange.  How is this implemented in hardware?  It
> seems rather unlikely that the same IP block is getting power from two
> different power rails.  So I don't think what you really want is to have
> the device modeled in 2 power domains.
> 
> Rather, I suspect there's some functional dependency going on that's not
> directly a function of the power domain itself.  Taking a wild shot in
> the dark, it wouldn't be too surprising if the IP block in question
> depends on a clock coming from a device in another power domain?  Since
> this sounds display related, is the pixel clock required coming from an
> IP block in the other power domain?
> 
> If it's something like a clock dependency, then that needs to be modeled
> so what when the clock is enabled, the power domain containg the device
> providing that clock cannot be shut down.

Unfortunately we don't have any more detailed information about this
right now. This dependency is not described in documentation and was
discovered experimentally.

Right now I'm on holidays, so I won't be able to get any details about
this, but Marek and Tomasz S. might be able to come up with something.

Best regards,
Tomasz