IK 3.3 - HDMI Doesn't work

This is a problem around dsihs2 enable clock failure, remark: I use a PRCMU v3.4.3.
If I apply the workaround patch (see attachment) and return to the old mcde clock management, that works.
Next step, try with a more recent PRCMU firmware.

Philippe: Please contact Sunil to get a recent release of the PRCMU

Thomas informed us that a new PRCMU is now available for him to test and validate.

Vincent and I try to use this nes startup files on emmc with Android ICS
images and
we got this error during boot:

Xloader version: u5500-android-4.0_v3.4
Built: Wed Mar 07 06:58:54 AM 2012
Configured for: 8500 B0
Running on chip ID: 8500B2
SECURITY_Init
Boot scenario: NORMAL
USB - Enabled: 0x00000001 Enum done: 0x00000000
Last reset reason: POWER_ON_RESET
XP70_DATA_MBFFC: 0xFF000001
PWR_MNGT_STARTED 1
About to load MEMINIT
After MEMINIT loaded
verify_signedheader

verify_signedheader
done
verify_payload hdr size: 0x000000D0 payload
0x40025C10
About to exec MEMINIT
function

SoC settings: INFO: @(#)SOC-SETTINGS v4.0.1-(B)-uc db8500 v2 1000Mhz Jan 10
2012
 15:48:15

SoC settings: INFO: AVS Enable, FVR21 value = : 0x87181360, FVR22 value = :
0x00
13ef03

SoC settings: INFO: Memory size=0x40000000 (1024
MB)
SoC settings: INFO: DDR Test Ended
successfully.
SoC settings: INFO: Requesting 1GHz from
PRCMU
SoC settings: INFO: Set 1GHz
OK
SoC settings: INFO: vmin = 1.3125V, vbbp = +300mV, vbbn =
+300mV
SoC settings: INFO: Very Slow Parts [>>>>...](Very Slow for N Transistor,
Very S
low for P
transistor)
MEMINIT passed
OK
About to load
NORMAL
After NORMAL
loaded
verify_signedheader

TEEC_InvokeCommand TEEC_SUCCESS != result
(0xFFFF000F)
verify_signedheader
failed
Ret_Sts when loading NORMAL
app
xloader
returned!
Wait forever...

How the security team has tested their delivery on Snowball?
On my side, I'm not a specialist and I followed this procedure:
http://www.igloocommunity.org/support/Android_Getting_started_with_ICS#Boot_ICS_from_emmc
and substitute with provided startup files.

On 7 March 2012 14:24, Anmar Oueja <email address hidden> wrote:

> Thomas informed us that a new PRCMU is now available for him to test and
> validate.
>
> --
> You received this bug notification because you are a member of
> IglooCommunity Maintainers, which is subscribed to IglooCommunity.
> https://bugs.launchpad.net/bugs/942814
>
> Title:
> IK 3.3 - HDMI Doesn't work
>
> Status in IglooCommunity Launchpad Project:
> Confirmed
>
> Bug description:
> This is a regression from previous kernel version.
>
> fbdemo error: "mcde mcde: chnl error=00020000"
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/igloocommunity/+bug/942814/+subscriptions
>

I can confirm this problem. The xloader seems buggy.

With latest startup files (PRCMU v3.4.17), the dsihs2 clock enable problem is not fixed.
I don't have any clue.
A STE graphic expert has to debug this problem on Snowball.
Before, he has to revert my workaround "mcde: hdmi: Workaround to don't use the clock framework for MCDE on Snowball" presents on IK integration branches to see the problem.

Analysis by Jayarami:
DSI Clock values are not set correctly in PRCMU registers by clock framework when DSI clock framework is enabled. I had checked the source/patches in IK3.3 from display side related to the DSI clock framework and seems Ok. Need to be checked with PRCMU.

Analysis from Jayarami:--
Below are the PRCMU registers values for DSI clock settings when clock framework is enabled and disabled. DSI Clock values are not set correctly in PRCMU registers by clock framework when DSI clock framework is enabled. I had checked the source/patches in IK3.3 from display side related to the DSI clock framework and seems Ok. Need to be checked with PRCMU experts

PRCMU register Values for DSI clock setting
=================================

HDMI Working scenario (When DSI clock framework is disabled):
=================================================
root@android:/data/tools # chmod 777 devmem2
root@android:/data/tools # ./devmem2 0x80157058
/dev/mem opened.
Memory mapped at address 0xb6ff1000.
Value at address 0x80157058 (0xb6ff1058): 0x18C

root@android:/data/tools # ./devmem2 0x8015707c
/dev/mem opened.
Memory mapped at address 0xb6f14000.
Value at address 0x8015707C (0xb6f1407c): 0xF00

root@android:/data/tools # ./devmem2 0x80157500
/dev/mem opened.
Memory mapped at address 0xb6f32000.
Value at address 0x80157500 (0xb6f32500): 0x40165

root@android:/data/tools # ./devmem2 0x80157530
/dev/mem opened.
Memory mapped at address 0xb6f25000.
Value at address 0x80157530 (0xb6f25530): 0x202

root@android:/data/tools # ./devmem2 0x8015752C
/dev/mem opened.
Memory mapped at address 0xb6f60000.
Value at address 0x8015752C (0xb6f6052c): 0x7030101
root@android:/data/tools #

HDMI NOT Working scenario (When DSI clock framework is enabled):
=================================================

root@android:/data/tools # ./devmem2 0x80157058
/dev/mem opened.
Memory mapped at address 0xb6f6f000.
Value at address 0x80157058 (0xb6f6f058): 0x6

root@android:/data/tools # ./devmem2 0x8015707c
/dev/mem opened.
Memory mapped at address 0xb6fb0000.
Value at address 0x8015707 (0xb6fb007c): 0x700

root@android:/data/tools # ./devmem2 0x80157500
/dev/mem opened.
Memory mapped at address 0xb6fa0000.
Value at address 0x8015750 (0xb6fa0500): 0x40169

root@android:/data/tools # ./devmem2 0x80157530
/dev/mem opened.
Memory mapped at address 0xb6f19000.
Value at address 0x80157530 (0xb6f19530): 0x202

root@android:/data/tools # ./devmem2 0x8015752C
/dev/mem opened.
Memory mapped at address 0xb6ffe000.
Value at address 0x8015752 (0xb6ffe52c): 0x7020101

This must be solved for 12.03, if not possible to fix this the proper way, we will need some kind of workaround to get HDMI working, if so please open another bug to track the proper solution.

The workaround (0001-mcde-hdmi-Workaround-to-don-t-use-the-clock-framewor.patch) has been applied to the stable branches:
stable-linux-ux500-3.3
stable-ubuntu-ux500-3.3
stable-android-ux500-3.3

Keeping this bug open to track the real solution, but moving it to 12.04 since the workaround is OK for 12.03 release.

ETA next week 16

issue is with the PRCM_HDMICLK_MGT register not being to set to required value "8c" by clock framework.
Work around is : in driver/mdf/db8500_prmcu.c , In function set_clock_rate , writel(val, clk_mgt[clock].reg);
manually set val = 8c ie if (clock==PRCMU_HDMICLK) val=0x8c ; writel(val, clk_mgt[clock].reg);

Workaround patch is attached. But we prefer not to push it for now.

because this might get fixed with latest prcmu.
Need to be tested with "stable-android-ux500-3.3-1" after enabling clk framework.
stable-android-ux500-3.3-1 is one of the release candidate.

We suggest to reduce priority of this issue to medium.

Sunil, when will there be a new PRCMU that could be validated?

Its prcmu driver. Should test with latest forward ported kernel. (this already contains prcmu changes). But need to enable clk frameowork for test.

Currently this new kernel is under internal test.

When we switch to stable-android-ux500-3.3-1 branch (should be done by tomorrow), we can re-test and see if this issue is still happening.

We should be able to test it tomorrow.

Lowering priority as there is some work around