Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-20 Thread Javier Martinez Canillas
[Adding Inki and Joonyoung to cc list]

Hello Marek,

On Mon, Jan 19, 2015 at 5:30 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:

 The board instantly died then. No kernel log output from the serial
 console, the heartbeat just stops and the board is dead. Need to
 power-cycle to get it running again.

 I'm unsure how to triage this at all.


 Thanks for you tests and pointing this issue. I turned out that the initial
 fix proposed
 by Andrzej Hajda
 (http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
 fine, while the final version merged to clock fixes ('clk: samsung: exynos4:
 set parent
 of sclk_hdmiphy to hdmi' - commit df019a5c0f7083001cb694f44821ca506425bda2)
 doesn't work
 properly.


I was working on adding HDMI support for Exynos5420/5422/5800 and I
also found that the hdmi clock being gated by the exynos_hdmi driver
on hdmi_poweroff(), was causing a system hang when the exynos_mixer
driver tried to access the mixer module registers.

My first approach was to do the same than Andrzej's patch, that is set
the parent of mixer gate clock to hdmi so when the exynos_mixer driver
enables its mixer clock, the hdmi clock would be enabled too.
Unfortunately that didn't work (more on that below)

 Please check the following kernel tree - instead of hacking around hdmi
 clock I've added
 handling of it directly to drm mixer driver:
 https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
 I hope that this will finally solve all mixer initialization related issues

My second approach was indeed the same that you are doing, to add a
phandle to the hdmi clock directly in the exynos_mixer driver to avoid
having to set the parent of the mixer clock on each exynos clock
driver.

When dumping the value of the CLK_GATE_IP_DISP1 register I see that
both CLK_HDMI and CLK_MIXER are set with both approaches but the
system still crashes. So enabling the hdmi clock seems to be enough to
make the mixer happy on Exynos4 but unfortunately is not enough on
Exynos5420.

 (also for
 Odroid XU3, discussed recently in the other thread). If it works fine, I
 will resend
 exynos4 hdmi patches to include this change.



I compared the clock hierarchy when the system is able to turn on and
off the fb blank and when it crash and I notice this difference:

Working:

 sclk_pwi 002400
   0 0
 sclk_hdmiphy 112400
   0 0
mout_hdmi 112400
   0 0
   sclk_hdmi  112400
   0 0
...
mout_pixel002400
   0 0
   dout_hdmi_pixel002400
   0 0
  sclk_pixel  002400
   0 0


Not working:

 sclk_pwi 002400
   0 0
 sclk_hdmiphy 002400
   0 0
...
mout_pixel002400
   0 0
   dout_hdmi_pixel002400
   0 0
  mout_hdmi   002400
   0 0
 sclk_hdmi002400
   0 0
  sclk_pixel  002400
   0 0

The difference is because the source clock of the hdmi clock is
generated by the output of a mux clock (mout_hdmi) that select either
dout_hdmi_pixel or sclk_hdmiphy as input parent. The exynos5420 clk
driver defines as:

PNAME(mout_hdmi_p) = {dout_hdmi_pixel, sclk_hdmiphy};
...
MUX(CLK_MOUT_HDMI, mout_hdmi, mout_hdmi_p, SRC_DISP10, 28, 1),

And the exynos_hdmi driver does:

clk_disable_unprepare(hdata-res.sclk_hdmi);
clk_set_parent(hdata-res.mout_hdmi, hdata-res.sclk_hdmiphy);
clk_prepare_enable(hdata-res.sclk_hdmi);

So is not only that the hdmi clock has to be enabled but also the
clock hierarchy matters. I don't even know if the hdmi clock is needed
or is that enabling this clock has the side effect of enabling another
clock in the hierarchy that is the one that is needed. It would be
good if someone can compare the clock hierarchy on an Exynos4.

So I would like to understand what is really the root cause here
instead of trying to only solve the symptoms for each platform.

I have also noticed this patch from Inki - commit 245f98f269714
(drm/exynos: hdmi: fix power order issue) that forces the
exynos_mixer to be disabled before exynos_hdmi to prevent a system
crash but only for DRM_MODE_DPMS_OFF. So I wonder if the same should
be true for DRM_MODE_DPMS_ON and the exynos_hdmi should be enabled
before exynos_hdmi.

IOW, I would like to know what is the dependency between the mixer and
hdmi modules at the module level first and then once that is clear we
can dig deeper on what 

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-19 Thread Tobias Jakobi
Marek Szyprowski wrote:
 Please check the following kernel tree - instead of hacking around hdmi
 clock I've added
 handling of it directly to drm mixer driver:
 https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
 
 I hope that this will finally solve all mixer initialization related
 issues (also for
 Odroid XU3, discussed recently in the other thread). If it works fine, I
 will resend
 exynos4 hdmi patches to include this change.
OK, I can verify that with the additional patches the lockup issues no
longer occur.

When doing the vsync tests though there are still the drm_vblank_put
warnings. I have yet to check if patch by Joonyoung (thanks Joonyoung
for the hint!) fixes these warnings.

With best wishes,
Tobias

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-19 Thread Tobias Jakobi
Hello!

Marek Szyprowski wrote:
 Thanks for you tests and pointing this issue. I turned out that the
 initial fix proposed
 by Andrzej Hajda
 (http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
 fine, while the final version merged to clock fixes ('clk: samsung:
 exynos4: set parent
 of sclk_hdmiphy to hdmi' - commit
 df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
 properly.
I should thank you for pushing all this code to mainline. It's really
nice to see how all the pieces now come together.


 Please check the following kernel tree - instead of hacking around hdmi
 clock I've added
 handling of it directly to drm mixer driver:
 https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
 
 I hope that this will finally solve all mixer initialization related
 issues (also for
 Odroid XU3, discussed recently in the other thread). If it works fine, I
 will resend
 exynos4 hdmi patches to include this change.
I have picked the additional patches to my tree, which currently has a
bunch of other stuff in it, in particular v4 of the IOMMU series.

Anyway, now the 'modetest' application immediately crashes the system,
but I get a least something on the serial console:
http://www.math.uni-bielefeld.de/~tjakobi/archive/odroid_modetest_crash_sysmmu.txt

So this is probably due to the IOMMU. Please note that DRM IOMMU support
(CONFIG_DRM_EXYNOS_IOMMU) was disabled (!) in my config.
CONFIG_EXYNOS_IOMMU however was on.

I'm going to retest with the IOMMU series removed and
CONFIG_EXYNOS_IOMMU disabled as well.

Just posting this already since you're probably interested in these
'side-issues' as well.


With best wishes,
Tobias

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-19 Thread Marek Szyprowski

Hello,

On 2015-01-20 00:03, Tobias Jakobi wrote:

Hello!

Marek Szyprowski wrote:

Thanks for you tests and pointing this issue. I turned out that the
initial fix proposed
by Andrzej Hajda
(http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
fine, while the final version merged to clock fixes ('clk: samsung:
exynos4: set parent
of sclk_hdmiphy to hdmi' - commit
df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
properly.

I should thank you for pushing all this code to mainline. It's really
nice to see how all the pieces now come together.



Please check the following kernel tree - instead of hacking around hdmi
clock I've added
handling of it directly to drm mixer driver:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi

I hope that this will finally solve all mixer initialization related
issues (also for
Odroid XU3, discussed recently in the other thread). If it works fine, I
will resend
exynos4 hdmi patches to include this change.

I have picked the additional patches to my tree, which currently has a
bunch of other stuff in it, in particular v4 of the IOMMU series.


This is a known issue. When Exynos IOMMU DRM driver is enabled, you need 
also

to enabled CONFIG_DRM_EXYNOS_IOMMU, otherwise the driver will crash on init.
This also need to be fixed, but for the time being I focused on other 
issues...



Anyway, now the 'modetest' application immediately crashes the system,
but I get a least something on the serial console:
http://www.math.uni-bielefeld.de/~tjakobi/archive/odroid_modetest_crash_sysmmu.txt

So this is probably due to the IOMMU. Please note that DRM IOMMU support
(CONFIG_DRM_EXYNOS_IOMMU) was disabled (!) in my config.
CONFIG_EXYNOS_IOMMU however was on.

I'm going to retest with the IOMMU series removed and
CONFIG_EXYNOS_IOMMU disabled as well.

Just posting this already since you're probably interested in these
'side-issues' as well.


Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-19 Thread Marek Szyprowski

Hello,

On 2015-01-16 23:32, Tobias Jakobi wrote:

Hello,

so OK, this doesn't look too good.

Tobias Jakobi wrote:

I checked with my panel just now and played around a bit with the DRM
(opening, vsync, etc.). However on deinitialization the entire system
locked up. I currently haven't hooked the board up to the serial
console, otherwise I would've tried to extract some more meaningful
information.

Going to check again more thoroughly on the weekend what exactly
triggers the lockup.

So, first of all I did my initial test with the exynos video backend of
RetroArch. But it turns out that there's no fancy application needed. I
now tested this with the 'modetest' application from libdrm, and did this:

./modetest -M exynos -s 16@13:1920x1080
setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480

The board instantly died then. No kernel log output from the serial
console, the heartbeat just stops and the board is dead. Need to
power-cycle to get it running again.

I'm unsure how to triage this at all.


Thanks for you tests and pointing this issue. I turned out that the 
initial fix proposed
by Andrzej Hajda 
(http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
fine, while the final version merged to clock fixes ('clk: samsung: 
exynos4: set parent
of sclk_hdmiphy to hdmi' - commit 
df019a5c0f7083001cb694f44821ca506425bda2) doesn't work

properly.

Please check the following kernel tree - instead of hacking around hdmi 
clock I've added

handling of it directly to drm mixer driver:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
I hope that this will finally solve all mixer initialization related 
issues (also for
Odroid XU3, discussed recently in the other thread). If it works fine, I 
will resend

exynos4 hdmi patches to include this change.


Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-16 Thread Tobias Jakobi
Hello,

so OK, this doesn't look too good.

Tobias Jakobi wrote:
 I checked with my panel just now and played around a bit with the DRM
 (opening, vsync, etc.). However on deinitialization the entire system
 locked up. I currently haven't hooked the board up to the serial
 console, otherwise I would've tried to extract some more meaningful
 information.
 
 Going to check again more thoroughly on the weekend what exactly
 triggers the lockup.

So, first of all I did my initial test with the exynos video backend of
RetroArch. But it turns out that there's no fancy application needed. I
now tested this with the 'modetest' application from libdrm, and did this:

./modetest -M exynos -s 16@13:1920x1080
setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480

The board instantly died then. No kernel log output from the serial
console, the heartbeat just stops and the board is dead. Need to
power-cycle to get it running again.

I'm unsure how to triage this at all.

@Marek: Could you check if this also happens for you?

With best wishes,
Tobias

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-16 Thread Tobias Jakobi
Tobias Jakobi wrote:
 Hello,
 
 so OK, this doesn't look too good.
 
 Tobias Jakobi wrote:
 I checked with my panel just now and played around a bit with the DRM
 (opening, vsync, etc.). However on deinitialization the entire system
 locked up. I currently haven't hooked the board up to the serial
 console, otherwise I would've tried to extract some more meaningful
 information.

 Going to check again more thoroughly on the weekend what exactly
 triggers the lockup.
 
 So, first of all I did my initial test with the exynos video backend of
 RetroArch. But it turns out that there's no fancy application needed. I
 now tested this with the 'modetest' application from libdrm, and did this:
 
 ./modetest -M exynos -s 16@13:1920x1080
 setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
 ^C
 ./modetest -M exynos -s 16@13:640x480
 setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
 ^C
 ./modetest -M exynos -s 16@13:640x480
 setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
 ^C
 ./modetest -M exynos -s 16@13:640x480
 
 The board instantly died then. No kernel log output from the serial
 console, the heartbeat just stops and the board is dead. Need to
 power-cycle to get it running again.
 
 I'm unsure how to triage this at all.
 
 @Marek: Could you check if this also happens for you?

In addition to the simple 'set mode' test, I also tried the 'vsync page
flip' one:

./modetest -M exynos -v -s 16@13:1280x720

While I haven't managed to lock up the system that way (I didn't try to
repeatedly kill and start this test), I managed to produce kernel
warnings that way.

Relevant parts here:
[  108.173644] lcd0-power-domain: Power-on latency exceeded, new value
364958 ns
[  108.174010] tv-power-domain: Power-on latency exceeded, new value
350083 ns
[  192.632246] lcd0-power-domain: Power-on latency exceeded, new value
419499 ns
[  192.632695] tv-power-domain: Power-on latency exceeded, new value
408167 ns
[  195.257343] [ cut here ]
[  195.257379] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1072
drm_vblank_put+0xd8/0xf0()
[  195.257385] Modules linked in: bridge stp llc bnep btrfs xor xor_neon
zlib_inflate zlib_deflate raid6_pq ecb btusb bluetooth usb_storage
[  195.257429] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc4+ #3
[  195.257435] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[  195.257440] Backtrace:
[  195.257462] [c001212c] (dump_backtrace) from [c0012344]
(show_stack+0x18/0x1c)
[  195.257468]  r6:c0595c30 r5: r4:c063ba90 r3:
[  195.257494] [c001232c] (show_stack) from [c048f8f8]
(dump_stack+0x98/0xd8)
[  195.257507] [c048f860] (dump_stack) from [c0028f9c]
(warn_slowpath_common+0x88/0xb8)
[  195.257512]  r5:0430 r4:
[  195.257525] [c0028f14] (warn_slowpath_common) from [c0029070]
(warn_slowpath_null+0x24/0x2c)
[  195.257530]  r8:00200200 r7:ee3a9c00 r6: r5:ed89e380 r4:ed89e380
[  195.257552] [c002904c] (warn_slowpath_null) from [c0268fac]
(drm_vblank_put+0xd8/0xf0)
[  195.257570] [c0268ed4] (drm_vblank_put) from [c028156c]
(exynos_drm_crtc_finish_pageflip+0xc0/0xf0)
[  195.257586] [c02814ac] (exynos_drm_crtc_finish_pageflip) from
[c0290358] (mixer_irq_handler+0xdc/0x104)
[  195.257591]  r10:c06527ee r9:ee1e26c0 r8:0041 r7:0801
r6:ed804e68 r5:0801
[  195.257607]  r4:ed804e10
[  195.257622] [c029027c] (mixer_irq_handler) from [c00610b0]
(handle_irq_event_percpu+0x3c/0x138)
[  195.257627]  r7: r6: r5:ee1e2720 r4:ed89e9c0
[  195.257644] [c0061074] (handle_irq_event_percpu) from [c00611f0]
(handle_irq_event+0x44/0x64)
[  195.257649]  r10: r9:f002 r8:ee008000 r7:0001
r6:ed89e9c0 r5:ee1e2720
[  195.257664]  r4:ee1e26c0
[  195.257677] [c00611ac] (handle_irq_event) from [c0063d84]
(handle_fasteoi_irq+0xb8/0x188)
[  195.257683]  r6:c063be14 r5:ee1e2720 r4:ee1e26c0 r3:
[  195.257701] [c0063ccc] (handle_fasteoi_irq) from [c0060748]
(generic_handle_irq+0x34/0x44)
[  195.257706]  r6: r5: r4:0041 r3:c0063ccc
[  195.257723] [c0060714] (generic_handle_irq) from [c0060a28]
(__handle_domain_irq+0x64/0xb8)
[  195.257728]  r4:c0620a38 r3:0062
[  195.257741] [c00609c4] (__handle_domain_irq) from [c0008604]
(gic_handle_irq+0x38/0x70)
[  195.257746]  r8:c0625f08 r7:c062c944 r6:006b r5:007b
r4:f002000c r3:c0625f08
[  195.257769] [c00085cc] (gic_handle_irq) from [c0012ec0]
(__irq_svc+0x40/0x74)
[  195.257775] Exception stack(0xc0625f08 to 0xc0625f50)
[  195.257785] 5f00:   ffed  
c001fa80 c062c510 c062c4c4
[  195.257794] 5f20:   c0625f60 c0624000 
c0625f5c c0625f60 c0625f50
[  195.257801] 5f40: c000f780 c000f784 600f0053 
[  195.257806]  r9:c0624000 r8:c0625f60 r7:c0625f3c r6:
r5:600f0053 r4:c000f784
[  195.257832] [c000f744] (arch_cpu_idle) from [c0057ccc]
(cpu_startup_entry+0x19c/0x264)
[  195.257845] [c0057b30] (cpu_startup_entry) from [c048bba8]
(rest_init+0x8c/0x90)
[  

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-15 Thread Tobias Jakobi
Hello!

Marek Szyprowski wrote:
 I hope that HDMI display works fine for you.
I checked with my panel just now and played around a bit with the DRM
(opening, vsync, etc.). However on deinitialization the entire system
locked up. I currently haven't hooked the board up to the serial
console, otherwise I would've tried to extract some more meaningful
information.

Going to check again more thoroughly on the weekend what exactly
triggers the lockup.

With best wishes,
Tobias

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-15 Thread Marek Szyprowski

Hello,

On 2015-01-15 11:10, Tobias Jakobi wrote:

Marek Szyprowski wrote: This is on a ODROID-X2.

The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
be handled separately. For the time being simply please disable Exynos IPP
(or Exynos DRM FIMC) feature in your kernel configuration.

I hope that HDMI display works fine for you.

OK, I'll check without FIMC again later this day, but what about the
warning (?) from the mixer:
exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable!

Should this go away as well, when I disable the FIMC?


Well, I also got this warning. It looks that pm_runtime in Exynos DRM 
got changed

recently and the bug is somewhere there. We will also check this issue.

Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-15 Thread Joonyoung Shim
+Cc Inki Dae.

Hi,

On 01/15/2015 07:26 PM, Marek Szyprowski wrote:
 Hello,
 
 On 2015-01-15 11:10, Tobias Jakobi wrote:
 Marek Szyprowski wrote: This is on a ODROID-X2.
 The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
 be handled separately. For the time being simply please disable Exynos IPP
 (or Exynos DRM FIMC) feature in your kernel configuration.

 I hope that HDMI display works fine for you.
 OK, I'll check without FIMC again later this day, but what about the
 warning (?) from the mixer:
 exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable!

 Should this go away as well, when I disable the FIMC?
 
 Well, I also got this warning. It looks that pm_runtime in Exynos DRM got 
 changed
 recently and the bug is somewhere there. We will also check this issue.
 

I posted a patch to fix it already.

http://www.spinics.net/lists/dri-devel/msg75039.html

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-15 Thread Tobias Jakobi
Marek Szyprowski wrote: This is on a ODROID-X2.
 
 The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
 be handled separately. For the time being simply please disable Exynos IPP
 (or Exynos DRM FIMC) feature in your kernel configuration.
 
 I hope that HDMI display works fine for you.
 
 Best regards

OK, I'll check without FIMC again later this day, but what about the
warning (?) from the mixer:
exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable!

Should this go away as well, when I disable the FIMC?

With best wishes,
Tobias

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-15 Thread Marek Szyprowski

Hello,

On 2015-01-14 16:25, Tobias Jakobi wrote:

Hello,

I've applied v6 of the HDMI patchset (together with the patches the set
depends on) onto torvalds/master, but I'm seeing a lot of warnings
(coming from __clk_{unprepare,disable}) that seem to originate from the
fimc subsystem.

Since the patchset also changes PM domain handling (which shows up in
the log as well), I was wondering if this is related?

Full boot log here:
http://www.math.uni-bielefeld.de/~tjakobi/archive/clk_warnings.txt

That's the tree I'm currently using:
https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.19.y
(maybe I'm missing something here?)


With best wishes,
Tobias

PS: This is on a ODROID-X2.


The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
be handled separately. For the time being simply please disable Exynos IPP
(or Exynos DRM FIMC) feature in your kernel configuration.

I hope that HDMI display works fine for you.

Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/6] Enable HDMI support on Exynos platforms

2015-01-13 Thread Marek Szyprowski
Hi all,

This is yet another approach to submit patches, which enables HDMI
support for two Exynos based platforms: UniversalC210 and Odroid X2/U3.

Beside DTS changes, this patchset adds parent domain support for Exynos
PM domains. This was the most controversial patch in the previous
attempts, but I hope I fixes all reported issues and made it really
generic. For more details see individual patches.

The patchset is based on my previous patch:
'ARM: DTS: Exynos: convert to generic power domain bindings'
(http://www.spinics.net/lists/linux-samsung-soc/msg40584.html)
and requires 2 patches that have been merged to v3.19-rc4:
'clk: samsung: exynos4: set parent of sclk_hdmiphy to hdmi'
(commit df019a5c0f7083001cb694f44821ca506425bda2) and
'PM / Domains: Export of_genpd_get_from_provider function'
(commit 7496fcbe8a643097efc061160e1c3b65ee2fa350).

Regards
Marek Szyprowski

Change log:

v2:
- rewrote subdomains patch according to suggestions from Geert
  Uytterhoeven and Amit Daniel Kachhap.

v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html)
- added handling of generic 'power-domains' binding in subdomains

v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html)
- resolved power domain on/off issue with 'clk: samsung: exynos4: set
  parent of mixer gate clock to hdmi' patch

v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html)
- first attempt, used 'always on' power domains hack


Andrzej Hajda (1):
  ARM: dts: exynos5250: add display power domain

Marek Szyprowski (4):
  ARM: Exynos: add support for sub-power domains
  ARM: dts: exynos4: add hdmi related nodes
  ARM: dts: exynos4: add dependency between TV and LCD0 power domains
  ARM: dts: exynos4412-odroid: enable hdmi support

Tomasz Stanislawski (1):
  ARM: dts: exynos4210-universal_c210: enable hdmi support

 .../bindings/arm/exynos/power_domain.txt   |  2 +
 arch/arm/boot/dts/exynos4.dtsi | 41 
 arch/arm/boot/dts/exynos4210-universal_c210.dts| 57 ++
 arch/arm/boot/dts/exynos4210.dtsi  |  8 +++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 44 +
 arch/arm/boot/dts/exynos4x12.dtsi  | 11 +
 arch/arm/boot/dts/exynos5250.dtsi  | 10 
 arch/arm/mach-exynos/pm_domains.c  | 28 +++
 8 files changed, 201 insertions(+)

-- 
1.9.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html