Re: [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi, On 01/14/2015 09:24 AM, Javier Martinez Canillas wrote: On 01/14/2015 01:19 AM, Javier Martinez Canillas wrote: I dug further on this issue and found that the cause is that the exynos_mixer driver needs some clocks (CLK_HDMI and CLK_SCLK_HDMI) grabbed by exynos_hdmi to be kept enabled after hdmi_poweroff (drivers/gpu/drm/exynos/exynos_hdmi.c). Otherwise, any access to mixer device registers leads to an imprecise external abort error. The following change [0] to the Exynos DRM HDMI driver makes the issue to not happen and I can successfully execute: # echo 1 /sys/devices/platform/exynos-drm/graphics/fb0/blank # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank Did you execute this operation repeatedly? Still i get error when i execute this more than twice with your change [0]. Thanks. Only not disabling the hdmi clock [1]: is enough but doing so makes sometimes the DISP1 power domain disabling fails. It doesn't seem to have side effect though since I also see the signal in the HDMI display to go standby and then on again. # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank # echo 1 /sys/devices/platform/exynos-drm/graphics/fb0/blank [ 63.089080] Power domain disp1-power-domain disable failed # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank # That error message when both clocks are not disabled on hdmi_poweroff() though. This should be: That error message is not shown when both clocks are disabled. Best regards, Javier -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Joonyoung, On 01/20/2015 12:12 PM, Joonyoung Shim wrote: I dug further on this issue and found that the cause is that the exynos_mixer driver needs some clocks (CLK_HDMI and CLK_SCLK_HDMI) grabbed by exynos_hdmi to be kept enabled after hdmi_poweroff (drivers/gpu/drm/exynos/exynos_hdmi.c). Otherwise, any access to mixer device registers leads to an imprecise external abort error. The following change [0] to the Exynos DRM HDMI driver makes the issue to not happen and I can successfully execute: # echo 1 /sys/devices/platform/exynos-drm/graphics/fb0/blank # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank Did you execute this operation repeatedly? Still i get error when i execute this more than twice with your change [0]. You mean that you are seeing the Power domain power-domain disable failed message but the system is not crashing or that you are still having the system crash? I've seen the former when running multiple times but I have not seen the crash when the hdmi clock is not disabled on hdmi_poweroff(). Thanks. Best regards, Javier -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
On 01/14/2015 01:19 AM, Javier Martinez Canillas wrote: I dug further on this issue and found that the cause is that the exynos_mixer driver needs some clocks (CLK_HDMI and CLK_SCLK_HDMI) grabbed by exynos_hdmi to be kept enabled after hdmi_poweroff (drivers/gpu/drm/exynos/exynos_hdmi.c). Otherwise, any access to mixer device registers leads to an imprecise external abort error. The following change [0] to the Exynos DRM HDMI driver makes the issue to not happen and I can successfully execute: # echo 1 /sys/devices/platform/exynos-drm/graphics/fb0/blank # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank Only not disabling the hdmi clock [1]: is enough but doing so makes sometimes the DISP1 power domain disabling fails. It doesn't seem to have side effect though since I also see the signal in the HDMI display to go standby and then on again. # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank # echo 1 /sys/devices/platform/exynos-drm/graphics/fb0/blank [ 63.089080] Power domain disp1-power-domain disable failed # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank # That error message when both clocks are not disabled on hdmi_poweroff() though. This should be: That error message is not shown when both clocks are disabled. Best regards, Javier -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
On 01/13/2015 02:24 PM, Joonyoung Shim wrote: Hi, On 01/13/2015 01:09 AM, Javier Martinez Canillas wrote: Hello Joonyoung, On 01/12/2015 07:40 AM, Joonyoung Shim wrote: And also making changes to the clocks in the clk-exynos5420 driver. Can you please explain the rationale for those changes? I'm asking because without your clock changes (only adding the DISP1 pd and making the devices as consumers), I've HDMI output too but video is even worse. This [0] is the minimal change I have on top of 3.19-rc3 to have some output. I just refer below patches, http://comments.gmane.org/gmane.linux.kernel.samsung-soc/34576 But i'm not sure whether DISP1 power domain is same case with MFC power domain. Thanks a lot for sharing those patches, now your changes are much more clear to me. So there seems to be two issues here, one is the mixer and hdmi modules not being attached to the DISP1 power domain and another one is the clocks setup not being correct to have proper HDMI video output. Hmm, i can see normal hdmi output still from latest upstream kernel(3.19-rc4) with my kernel changes and u-boot changes(DISP1 power domain disable) of prior mail on odroid xu3 board. I thought you said on another email that after commit 2ed127697eb1 which landed on 3.19-rc1 you had bad HDMI output? In your changes, it was missing the SW_ACLK_400_DISP1 and USER_ACLK_400_DISP1 clock mux outputs that goes to internal buses in the DISP1. Adding IDs for these in the exynos5420 clock driver and to the parent and input clock paris list in the DISP1 power domain gives me a good HDMI output on 3.19-rc2. Also, the SW_ACLK_300_DISP1 and USER_ACLK_300_DISP1 are needed for the FIMD parent and input clock respectively. Adding those to the clocks list of the DISP1 power domain gives me working display + HDMI on my Exynos5800 Peach Pi. These are the changes I have now [0]. Please let me know what you think. Good, it's working with your patch without u-boot changes and reverting of commit 2ed127697eb. But i also get stripe hdmi output if hdmi/mixer drivers aren't defered probed, because DISP1 power domain isn't disabled on booting by defered probe so is always on. 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Joonyoung, On 01/13/2015 09:40 AM, Joonyoung Shim wrote: These are the changes I have now [0]. Please let me know what you think. Good, it's working with your patch without u-boot changes and reverting of commit 2ed127697eb. But i also get stripe hdmi output if hdmi/mixer drivers aren't defered probed, because DISP1 power domain isn't disabled on booting by defered probe so is always on. Could you please elaborate on this? I'm not sure I undestood what you meant so it would be great if you can give me the steps to reproduce your issue. Best regards, Javier -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Joonyoung, On 01/13/2015 06:24 AM, Joonyoung Shim wrote: Also, the SW_ACLK_300_DISP1 and USER_ACLK_300_DISP1 are needed for the FIMD parent and input clock respectively. Adding those to the clocks list of the DISP1 power domain gives me working display + HDMI on my Exynos5800 Peach Pi. These are the changes I have now [0]. Please let me know what you think. Good, it's working with your patch without u-boot changes and reverting of commit 2ed127697eb. Perfect, I'll split the the clk and DTS changes in different patches and post the series once we figure out the power-domain disable failed issue. Yes, I was not able to trigger that by running modetest but by turning off my HDMI monitor and then turning it on again. When the monitor is turned on then I see a Power domain power-domain disable failed and the imprecise external abort error. I had to disable CONFIG_DRM_EXYNOS_DP in order to trigger though and that is why I was not able to reproduce it before. I think though that this is a separate issue of the HDMI not working since power domains should be able to have many consumers devices and I see that other power domains are used that way. OK, we need more investigation. Agreed, since even though I think this is a separate issue, I'll prefer to not add a known bug as a side effect of having a working HDMI. Best regard, Javier -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Joonyoung, On 01/13/2015 06:24 AM, Joonyoung Shim wrote: Yes, I was not able to trigger that by running modetest but by turning off my HDMI monitor and then turning it on again. When the monitor is turned on then I see a Power domain power-domain disable failed and the imprecise external abort error. I had to disable CONFIG_DRM_EXYNOS_DP in order to trigger though and that is why I was not able to reproduce it before. I think though that this is a separate issue of the HDMI not working since power domains should be able to have many consumers devices and I see that other power domains are used that way. OK, we need more investigation. I dug further on this issue and found that the cause is that the exynos_mixer driver needs some clocks (CLK_HDMI and CLK_SCLK_HDMI) grabbed by exynos_hdmi to be kept enabled after hdmi_poweroff (drivers/gpu/drm/exynos/exynos_hdmi.c). Otherwise, any access to mixer device registers leads to an imprecise external abort error. The following change [0] to the Exynos DRM HDMI driver makes the issue to not happen and I can successfully execute: # echo 1 /sys/devices/platform/exynos-drm/graphics/fb0/blank # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank Only not disabling the hdmi clock [1]: is enough but doing so makes sometimes the DISP1 power domain disabling fails. It doesn't seem to have side effect though since I also see the signal in the HDMI display to go standby and then on again. # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank # echo 1 /sys/devices/platform/exynos-drm/graphics/fb0/blank [ 63.089080] Power domain disp1-power-domain disable failed # echo 0 /sys/devices/platform/exynos-drm/graphics/fb0/blank # That error message when both clocks are not disabled on hdmi_poweroff() though. I tried different things like set parent of mixer clock to hdmi clock instead of aclk200_disp1 or make the Exynos DRM mixer driver to grab the hdmi clock from DT and prepare_enable from mixer_poweron() but in all cases the same imprecise external abort error was triggered by mixer_poweron() trying to access the mixer registers. Any ideas? Thanks a lot and best regards, Javier [0]: diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 5765a161abdd..0887911cfdd5 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2084,8 +2084,8 @@ static void hdmi_poweroff(struct exynos_drm_display *display) cancel_delayed_work(hdata-hotplug_work); - clk_disable_unprepare(res-sclk_hdmi); - clk_disable_unprepare(res-hdmi); /* reset pmu hdmiphy control bit to disable hdmiphy */ regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL, [1]: diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 5765a161abdd..628bff96d543 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2085,7 +2085,7 @@ static void hdmi_poweroff(struct exynos_drm_display *display) cancel_delayed_work(hdata-hotplug_work); clk_disable_unprepare(res-sclk_hdmi); - clk_disable_unprepare(res-hdmi); /* reset pmu hdmiphy control bit to disable hdmiphy */ regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL, -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi, On 01/12/2015 03:40 PM, Joonyoung Shim wrote: Hi, On 01/09/2015 01:42 AM, Javier Martinez Canillas wrote: Hello Joonyoung, On 01/07/2015 10:55 AM, Joonyoung Shim wrote: I don't think iommu support and power domain issue are related. I also get displaying stripes via hdmi but it is just power domain issue regardless iommu support. I observed 8th bit from 0x1445000C register of mixer is set to 1 with displaying stripes. It means The graphic layer0 line buffer underflow. There was same underflow issue on Exynos4 based boards. As Marek said, because LCD0 power domain was turned off. Interesting, thanks a lot for sharing this information. I just tried to turn off DISP1 power domain at u-boot and DISP1 power domain is turned on from kernel hdmi and mixer driver on odroid xu3 board. As the result, i can see displaying penguin logo from hdmi. Can you share the patches you are using to turn on the DISP1 power domain since AFAIU the kernel does not know about the DISP1 power domain after commit d51cad7df871 (ARM: dts: remove display power domain for exynos5420). I tried reverting that commit before so the kernel knows about the DISP1 power domain and booting with pd_ignore_unused but still had the stripes. I add DISP1 power domain on dts and please refer below patch[0] with some modification on hdmi phy(Actually, i think this is not related). You also should disable DISP1 power domain from bootloader. Thanks a lot for the patch. With your changes I have some HDMI output on my Peach Pi. But the HDMI output is broken since the resolution is very low and the video as a lot of visual artifacts. In your change you are also adding clock phandles for the pd oscillator clock and the CLK_MOUT_SW_ACLK200, CLK_MOUT_USER_ACLK200_DISP1 pairs for the parent input and input clocks of the devices attached to the pd. And also making changes to the clocks in the clk-exynos5420 driver. Can you please explain the rationale for those changes? I'm asking because without your clock changes (only adding the DISP1 pd and making the devices as consumers), I've HDMI output too but video is even worse. This [0] is the minimal change I have on top of 3.19-rc3 to have some output. I just refer below patches, http://comments.gmane.org/gmane.linux.kernel.samsung-soc/34576 But i'm not sure whether DISP1 power domain is same case with MFC power domain. The docs I've access to, don't have information about the clock hierarchy. So each time there is a clock issue, I've a hard time to figure out what's happening. So there seems to be two issues here, one is the mixer and hdmi modules not being attached to the DISP1 power domain and another one is the clocks setup not being correct to have proper HDMI video output. Hmm, i can see normal hdmi output still from latest upstream kernel(3.19-rc4) with my kernel changes and u-boot changes(DISP1 power domain disable) of prior mail on odroid xu3 board. But the problem exists still because it is failed to control on/off of DISP1 power domain more than twice from kernel hdmi and mixer driver.[0] I didn't have this issue when testing your patch against 3.19-rc2. From your log I see that you are testing on a 3.18.1. So maybe makes sense to test with the latest kernel version since this HDMI issue qualifies as an 3.19-rc fix? Since commit 2ed127697eb1 (PM / Domains: Power on the PM domain right after attach completes) that landed in 3.19-rc1, I see that the power domain is powered on when a device is attached. So maybe that is what makes a difference here? I also get ashake hdmi output since commit 2ed127697eb1, it causes on and off of DISP1 power domain when hdmi/mixer driver probe is defered because regulator driver is not probed yet. I'm not sure why it causes abnormal hdmi operation. Thanks. I'm not sure, but i get same error results from 3.19-rc4. Did you test using exynos drm driver? I used modetest of libdrm -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Joonyoung,
On 01/12/2015 07:40 AM, Joonyoung Shim wrote:
And also making changes to the clocks in the clk-exynos5420 driver. Can
you please explain the rationale for those changes? I'm asking because
without your clock changes (only adding the DISP1 pd and making the
devices as consumers), I've HDMI output too but video is even worse. This
[0] is the minimal change I have on top of 3.19-rc3 to have some output.
I just refer below patches,
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/34576
But i'm not sure whether DISP1 power domain is same case with MFC power
domain.
Thanks a lot for sharing those patches, now your changes are much more
clear to me.
So there seems to be two issues here, one is the mixer and hdmi modules not
being attached to the DISP1 power domain and another one is the clocks setup
not being correct to have proper HDMI video output.
Hmm, i can see normal hdmi output still from latest upstream
kernel(3.19-rc4) with my kernel changes and u-boot changes(DISP1 power
domain disable) of prior mail on odroid xu3 board.
I thought you said on another email that after commit 2ed127697eb1 which
landed on 3.19-rc1 you had bad HDMI output?
In your changes, it was missing the SW_ACLK_400_DISP1 and USER_ACLK_400_DISP1
clock mux outputs that goes to internal buses in the DISP1. Adding IDs for
these in the exynos5420 clock driver and to the parent and input clock paris
list in the DISP1 power domain gives me a good HDMI output on 3.19-rc2.
Also, the SW_ACLK_300_DISP1 and USER_ACLK_300_DISP1 are needed for the FIMD
parent and input clock respectively. Adding those to the clocks list of the
DISP1 power domain gives me working display + HDMI on my Exynos5800 Peach Pi.
These are the changes I have now [0]. Please let me know what you think.
I didn't have this issue when testing your patch against 3.19-rc2. From your
log I see that you are testing on a 3.18.1. So maybe makes sense to test with
the latest kernel version since this HDMI issue qualifies as an 3.19-rc fix?
Since commit 2ed127697eb1 (PM / Domains: Power on the PM domain right after
attach completes)
that landed in 3.19-rc1, I see that the power domain is powered on when a
device is attached. So maybe that is what makes a difference here?
I'm not sure, but i get same error results from 3.19-rc4. Did you test
using exynos drm driver? I used modetest of libdrm
Yes, I was not able to trigger that by running modetest but by turning off
my HDMI monitor and then turning it on again. When the monitor is turned
on then I see a Power domain power-domain disable failed and the imprecise
external abort error.
I had to disable CONFIG_DRM_EXYNOS_DP in order to trigger though and that
is why I was not able to reproduce it before.
I think though that this is a separate issue of the HDMI not working since
power domains should be able to have many consumers devices and I see that
other power domains are used that way.
Best regards,
Javier
[0]:
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 0ac5e0810e97..53b0a03843f2 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -270,6 +270,19 @@
reg = 0x10044120 0x20;
};
+ disp1_pd: power-domain@100440C0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440C0 0x20;
+ clocks = clock CLK_FIN_PLL, clock CLK_MOUT_SW_ACLK200,
+ clock CLK_MOUT_USER_ACLK200_DISP1,
+ clock CLK_MOUT_SW_ACLK300,
+ clock CLK_MOUT_USER_ACLK300_DISP1,
+ clock CLK_MOUT_SW_ACLK400,
+ clock CLK_MOUT_USER_ACLK400_DISP1;
+ clock-names = oscclk, pclk0, clk0,
+ pclk1, clk1, pclk2, clk2;
+ };
+
pinctrl_0: pinctrl@1340 {
compatible = samsung,exynos5420-pinctrl;
reg = 0x1340 0x1000;
@@ -537,6 +550,7 @@
fimd: fimd@1440 {
clocks = clock CLK_SCLK_FIMD1, clock CLK_FIMD1;
clock-names = sclk_fimd, fimd;
+ samsung,power-domain = disp1_pd;
};
adc: adc@12D1 {
@@ -710,6 +724,7 @@
phy = hdmiphy;
samsung,syscon-phandle = pmu_system_controller;
status = disabled;
+ samsung,power-domain = disp1_pd;
};
hdmiphy: hdmiphy@145D {
@@ -722,6 +737,7 @@
interrupts = 0 94 0;
clocks = clock CLK_MIXER, clock CLK_SCLK_HDMI;
clock-names = mixer, sclk_hdmi;
+ samsung,power-domain = disp1_pd;
};
gsc_0: video-scaler@13e0 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 848d602efc06..07d666cc6a29 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++
Re: [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi, On 01/13/2015 01:09 AM, Javier Martinez Canillas wrote: Hello Joonyoung, On 01/12/2015 07:40 AM, Joonyoung Shim wrote: And also making changes to the clocks in the clk-exynos5420 driver. Can you please explain the rationale for those changes? I'm asking because without your clock changes (only adding the DISP1 pd and making the devices as consumers), I've HDMI output too but video is even worse. This [0] is the minimal change I have on top of 3.19-rc3 to have some output. I just refer below patches, http://comments.gmane.org/gmane.linux.kernel.samsung-soc/34576 But i'm not sure whether DISP1 power domain is same case with MFC power domain. Thanks a lot for sharing those patches, now your changes are much more clear to me. So there seems to be two issues here, one is the mixer and hdmi modules not being attached to the DISP1 power domain and another one is the clocks setup not being correct to have proper HDMI video output. Hmm, i can see normal hdmi output still from latest upstream kernel(3.19-rc4) with my kernel changes and u-boot changes(DISP1 power domain disable) of prior mail on odroid xu3 board. I thought you said on another email that after commit 2ed127697eb1 which landed on 3.19-rc1 you had bad HDMI output? In your changes, it was missing the SW_ACLK_400_DISP1 and USER_ACLK_400_DISP1 clock mux outputs that goes to internal buses in the DISP1. Adding IDs for these in the exynos5420 clock driver and to the parent and input clock paris list in the DISP1 power domain gives me a good HDMI output on 3.19-rc2. Also, the SW_ACLK_300_DISP1 and USER_ACLK_300_DISP1 are needed for the FIMD parent and input clock respectively. Adding those to the clocks list of the DISP1 power domain gives me working display + HDMI on my Exynos5800 Peach Pi. These are the changes I have now [0]. Please let me know what you think. Good, it's working with your patch without u-boot changes and reverting of commit 2ed127697eb. I didn't have this issue when testing your patch against 3.19-rc2. From your log I see that you are testing on a 3.18.1. So maybe makes sense to test with the latest kernel version since this HDMI issue qualifies as an 3.19-rc fix? Since commit 2ed127697eb1 (PM / Domains: Power on the PM domain right after attach completes) that landed in 3.19-rc1, I see that the power domain is powered on when a device is attached. So maybe that is what makes a difference here? I'm not sure, but i get same error results from 3.19-rc4. Did you test using exynos drm driver? I used modetest of libdrm Yes, I was not able to trigger that by running modetest but by turning off my HDMI monitor and then turning it on again. When the monitor is turned on then I see a Power domain power-domain disable failed and the imprecise external abort error. I had to disable CONFIG_DRM_EXYNOS_DP in order to trigger though and that is why I was not able to reproduce it before. I think though that this is a separate issue of the HDMI not working since power domains should be able to have many consumers devices and I see that other power domains are used that way. OK, we need more investigation. 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi, On 01/09/2015 01:42 AM, Javier Martinez Canillas wrote: Hello Joonyoung, On 01/07/2015 10:55 AM, Joonyoung Shim wrote: I don't think iommu support and power domain issue are related. I also get displaying stripes via hdmi but it is just power domain issue regardless iommu support. I observed 8th bit from 0x1445000C register of mixer is set to 1 with displaying stripes. It means The graphic layer0 line buffer underflow. There was same underflow issue on Exynos4 based boards. As Marek said, because LCD0 power domain was turned off. Interesting, thanks a lot for sharing this information. I just tried to turn off DISP1 power domain at u-boot and DISP1 power domain is turned on from kernel hdmi and mixer driver on odroid xu3 board. As the result, i can see displaying penguin logo from hdmi. Can you share the patches you are using to turn on the DISP1 power domain since AFAIU the kernel does not know about the DISP1 power domain after commit d51cad7df871 (ARM: dts: remove display power domain for exynos5420). I tried reverting that commit before so the kernel knows about the DISP1 power domain and booting with pd_ignore_unused but still had the stripes. I add DISP1 power domain on dts and please refer below patch[0] with some modification on hdmi phy(Actually, i think this is not related). You also should disable DISP1 power domain from bootloader. Thanks a lot for the patch. With your changes I have some HDMI output on my Peach Pi. But the HDMI output is broken since the resolution is very low and the video as a lot of visual artifacts. In your change you are also adding clock phandles for the pd oscillator clock and the CLK_MOUT_SW_ACLK200, CLK_MOUT_USER_ACLK200_DISP1 pairs for the parent input and input clocks of the devices attached to the pd. And also making changes to the clocks in the clk-exynos5420 driver. Can you please explain the rationale for those changes? I'm asking because without your clock changes (only adding the DISP1 pd and making the devices as consumers), I've HDMI output too but video is even worse. This [0] is the minimal change I have on top of 3.19-rc3 to have some output. I just refer below patches, http://comments.gmane.org/gmane.linux.kernel.samsung-soc/34576 But i'm not sure whether DISP1 power domain is same case with MFC power domain. The docs I've access to, don't have information about the clock hierarchy. So each time there is a clock issue, I've a hard time to figure out what's happening. So there seems to be two issues here, one is the mixer and hdmi modules not being attached to the DISP1 power domain and another one is the clocks setup not being correct to have proper HDMI video output. Hmm, i can see normal hdmi output still from latest upstream kernel(3.19-rc4) with my kernel changes and u-boot changes(DISP1 power domain disable) of prior mail on odroid xu3 board. But the problem exists still because it is failed to control on/off of DISP1 power domain more than twice from kernel hdmi and mixer driver.[0] I didn't have this issue when testing your patch against 3.19-rc2. From your log I see that you are testing on a 3.18.1. So maybe makes sense to test with the latest kernel version since this HDMI issue qualifies as an 3.19-rc fix? Since commit 2ed127697eb1 (PM / Domains: Power on the PM domain right after attach completes) that landed in 3.19-rc1, I see that the power domain is powered on when a device is attached. So maybe that is what makes a difference here? I'm not sure, but i get same error results from 3.19-rc4. Did you test using exynos drm driver? I used modetest of libdrm Something that is not clear to me is how display panel is working on the Peach boards if this is a power domain issue since according to the manual both the modules used for display (LCD controller and DP) and the modules used for HDMI (MIXER and HDMI) belong to the same power domain (DISP1). I don't know about that because i just tested on odroid xu3 board without display panel. Hmm, It can be any conditions to success on/off power domain e.g. power state of clocks and of on/off order display devices. My guess is that this is again clock related. Since if I add the DISP1 pd to the DTS and make the fimd node as a consumer of the pd, the display panel works correctly (same than current mainline that doesn't have the node). But, if I also make the mixer and hdmi nodes as consumer of the DISP1, then the exynos dp driver's probe function fails as shown in [1]. In this case, the HDMI output works and I see that the DISP1 power domain is not powered off so the only thing I can think is that is a clocks issue. DP also is related with DISP1 power domain, so it think DP driver should consider DISP1 power domain. Is DISP1 power domain disabled on Peach boards to save power, not always on? No AFAICT, currently as I mentioned before the DISP1 power domain was removed from
Re: [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi Javier,
On 01/07/2015 06:33 PM, Javier Martinez Canillas wrote:
Hello Joonyoung,
On 01/07/2015 03:03 AM, Joonyoung Shim wrote:
On 01/06/2015 06:49 PM, Javier Martinez Canillas wrote:
Also I tried forcing the kernel to not disable unused power domains by
passing the pd_ignore_unused parameter to the kernel command line. I
see on the kernel log a genpd: Not disabling unused power domains
message but HDMI output still has the stripes that Sjoerd mentioned.
Do you know if Exynos DRM HDMI in mainline is supposed to work without
SysMMU / IOMMU support?
I don't think iommu support and power domain issue are related. I also
get displaying stripes via hdmi but it is just power domain issue
regardless iommu support.
I observed 8th bit from 0x1445000C register of mixer is set to 1 with
displaying stripes. It means The graphic layer0 line buffer underflow.
There was same underflow issue on Exynos4 based boards. As Marek said,
because LCD0 power domain was turned off.
Interesting, thanks a lot for sharing this information.
I just tried to turn off DISP1 power domain at u-boot and DISP1 power
domain is turned on from kernel hdmi and mixer driver on odroid xu3
board. As the result, i can see displaying penguin logo from hdmi.
Can you share the patches you are using to turn on the DISP1 power domain
since AFAIU the kernel does not know about the DISP1 power domain after
commit d51cad7df871 (ARM: dts: remove display power domain for exynos5420).
I tried reverting that commit before so the kernel knows about the DISP1
power domain and booting with pd_ignore_unused but still had the stripes.
I add DISP1 power domain on dts and please refer below patch[0] with
some modification on hdmi phy(Actually, i think this is not related).
You also should disable DISP1 power domain from bootloader.
But the problem exists still because it is failed to control on/off of
DISP1 power domain more than twice from kernel hdmi and mixer driver.[0]
Something that is not clear to me is how display panel is working on the
Peach boards if this is a power domain issue since according to the manual
both the modules used for display (LCD controller and DP) and the modules
used for HDMI (MIXER and HDMI) belong to the same power domain (DISP1).
I don't know about that because i just tested on odroid xu3 board
without display panel. Hmm, It can be any conditions to success on/off
power domain e.g. power state of clocks and of on/off order display
devices.
Is DISP1 power domain disabled on Peach boards to save power, not always
on?
Or am I misunderstanding something?
Thanks a lot for your help and best regards,
Javier
Thanks.
[0]:
---
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
drivers/clk/samsung/clk-exynos5420.c | 4 ++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++--
include/dt-bindings/clock/exynos5420.h | 2 ++
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..ff9ad4a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -270,6 +270,14 @@
reg = 0x10044120 0x20;
};
+ disp1_pd: power-domain@100440C0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440C0 0x20;
+ clocks = clock CLK_FIN_PLL, clock CLK_MOUT_SW_ACLK200,
+ clock CLK_MOUT_USER_ACLK200_DISP1;
+ clock-names = oscclk, pclk0, clk0;
+ };
+
pinctrl_0: pinctrl@1340 {
compatible = samsung,exynos5420-pinctrl;
reg = 0x1340 0x1000;
@@ -704,6 +712,7 @@
sclk_hdmiphy, mout_hdmi;
phy = hdmiphy;
samsung,syscon-phandle = pmu_system_controller;
+ samsung,power-domain = disp1_pd;
status = disabled;
};
@@ -717,6 +726,7 @@
interrupts = 0 94 0;
clocks = clock CLK_MIXER, clock CLK_SCLK_HDMI;
clock-names = mixer, sclk_hdmi;
+ samsung,power-domain = disp1_pd;
};
gsc_0: video-scaler@13e0 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 848d602..52ba0e6 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -635,7 +635,7 @@ static struct samsung_mux_clock exynos5x_mux_clks[]
__initdata = {
SRC_TOP3, 0, 1),
MUX(0, mout_user_aclk400_mscl, mout_user_aclk400_mscl_p,
SRC_TOP3, 4, 1),
- MUX(0, mout_user_aclk200_disp1, mout_user_aclk200_disp1_p,
+ MUX(CLK_MOUT_USER_ACLK200_DISP1, mout_user_aclk200_disp1,
mout_user_aclk200_disp1_p,
SRC_TOP3, 8, 1),
MUX(0, mout_user_aclk200_fsys2, mout_user_aclk200_fsys2_p,
SRC_TOP3, 12, 1),
@@ -693,7 +693,7
Re: [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Joonyoung, On 01/07/2015 03:03 AM, Joonyoung Shim wrote: On 01/06/2015 06:49 PM, Javier Martinez Canillas wrote: Also I tried forcing the kernel to not disable unused power domains by passing the pd_ignore_unused parameter to the kernel command line. I see on the kernel log a genpd: Not disabling unused power domains message but HDMI output still has the stripes that Sjoerd mentioned. Do you know if Exynos DRM HDMI in mainline is supposed to work without SysMMU / IOMMU support? I don't think iommu support and power domain issue are related. I also get displaying stripes via hdmi but it is just power domain issue regardless iommu support. I observed 8th bit from 0x1445000C register of mixer is set to 1 with displaying stripes. It means The graphic layer0 line buffer underflow. There was same underflow issue on Exynos4 based boards. As Marek said, because LCD0 power domain was turned off. Interesting, thanks a lot for sharing this information. I just tried to turn off DISP1 power domain at u-boot and DISP1 power domain is turned on from kernel hdmi and mixer driver on odroid xu3 board. As the result, i can see displaying penguin logo from hdmi. Can you share the patches you are using to turn on the DISP1 power domain since AFAIU the kernel does not know about the DISP1 power domain after commit d51cad7df871 (ARM: dts: remove display power domain for exynos5420). I tried reverting that commit before so the kernel knows about the DISP1 power domain and booting with pd_ignore_unused but still had the stripes. But the problem exists still because it is failed to control on/off of DISP1 power domain more than twice from kernel hdmi and mixer driver.[0] Something that is not clear to me is how display panel is working on the Peach boards if this is a power domain issue since according to the manual both the modules used for display (LCD controller and DP) and the modules used for HDMI (MIXER and HDMI) belong to the same power domain (DISP1). Or am I misunderstanding something? Thanks a lot for your help and best regards, Javier -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Marek, On Fri, Dec 5, 2014 at 11:22 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: On 2014-12-02 10:59, Sjoerd Simons wrote: This is another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. The main change from previous version is a rebase onto latest automatic DMA configuration for IOMMU masters patches from Will Deacon. Do you happen to know if anyone is working on iommu/dma-mapping patches for Exynos 5 based on this patchset? I hope to add Exynos5 SYSMMU patches to the next iteration of my patchset, but I doubt it will get into v3.19-rc1. For some background to that question, We (re-)discovered yesterday that the out-of-tree exynos-reference kernel iommu patches are required to get HDMI out working on exynos 5 boards. The current situation in mainline is rather broken, HDMI output without CONFIG_DRM_EXYNOS_IOMMU results in just displaying stripes[0]. While turning on CONFIG_DRM_EXYNOS_IOMMU causes a kernel oops at boot We have observed similar issues with Exynos4 based boards, when LCD0 power domain was turned off and only TV power domain has been powered on. Please check the power domain configuration. Maybe in case of Exynos5 the same So IIUC what you are saying is that enabling the Exynos DRM IOMMU support has the side effect of turning on all the power domains needed by HDMI? I've compared the power domains configuration in mainline with the downstream exynos-reference [0] tree and I didn't find any differences. issue is caused by the interaction between DISP1 and GSCL domains. I was also not able to find a dependency betwen GSCL and DISP1 power domains in the Exynos 5420 manual. But If that's the case then your patch to add support for sub-power domains on Exynos [1] will also be needed, right? AFAICT from the manual, all the used modules in the case of HDMI + Display (LCD, DP, HDMI and MIXER) needs only the DISP1 power domain to be enabled which BTW was removed for Exynos5420 on commit d51cad7 (ARM: dts: remove display power domain for exynos5420). It seems to work just because the power domain is turned on by the bootloader. Also I tried forcing the kernel to not disable unused power domains by passing the pd_ignore_unused parameter to the kernel command line. I see on the kernel log a genpd: Not disabling unused power domains message but HDMI output still has the stripes that Sjoerd mentioned. Do you know if Exynos DRM HDMI in mainline is supposed to work without SysMMU / IOMMU support? Thanks a lot for your help and suggestions. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland Best regards, Javier [0]: https://github.com/exynos-reference/kernel/commits/exynos5-v3.17-rc1-chrome [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/308335.html -- 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
On 01/06/2015 06:49 PM, Javier Martinez Canillas wrote: Hello Marek, On Fri, Dec 5, 2014 at 11:22 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: On 2014-12-02 10:59, Sjoerd Simons wrote: This is another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. The main change from previous version is a rebase onto latest automatic DMA configuration for IOMMU masters patches from Will Deacon. Do you happen to know if anyone is working on iommu/dma-mapping patches for Exynos 5 based on this patchset? I hope to add Exynos5 SYSMMU patches to the next iteration of my patchset, but I doubt it will get into v3.19-rc1. For some background to that question, We (re-)discovered yesterday that the out-of-tree exynos-reference kernel iommu patches are required to get HDMI out working on exynos 5 boards. The current situation in mainline is rather broken, HDMI output without CONFIG_DRM_EXYNOS_IOMMU results in just displaying stripes[0]. While turning on CONFIG_DRM_EXYNOS_IOMMU causes a kernel oops at boot We have observed similar issues with Exynos4 based boards, when LCD0 power domain was turned off and only TV power domain has been powered on. Please check the power domain configuration. Maybe in case of Exynos5 the same So IIUC what you are saying is that enabling the Exynos DRM IOMMU support has the side effect of turning on all the power domains needed by HDMI? I've compared the power domains configuration in mainline with the downstream exynos-reference [0] tree and I didn't find any differences. issue is caused by the interaction between DISP1 and GSCL domains. I was also not able to find a dependency betwen GSCL and DISP1 power domains in the Exynos 5420 manual. But If that's the case then your patch to add support for sub-power domains on Exynos [1] will also be needed, right? AFAICT from the manual, all the used modules in the case of HDMI + Display (LCD, DP, HDMI and MIXER) needs only the DISP1 power domain to be enabled which BTW was removed for Exynos5420 on commit d51cad7 (ARM: dts: remove display power domain for exynos5420). It seems to work just because the power domain is turned on by the bootloader. Also I tried forcing the kernel to not disable unused power domains by passing the pd_ignore_unused parameter to the kernel command line. I see on the kernel log a genpd: Not disabling unused power domains message but HDMI output still has the stripes that Sjoerd mentioned. Do you know if Exynos DRM HDMI in mainline is supposed to work without SysMMU / IOMMU support? I don't think iommu support and power domain issue are related. I also get displaying stripes via hdmi but it is just power domain issue regardless iommu support. I observed 8th bit from 0x1445000C register of mixer is set to 1 with displaying stripes. It means The graphic layer0 line buffer underflow. There was same underflow issue on Exynos4 based boards. As Marek said, because LCD0 power domain was turned off. I just tried to turn off DISP1 power domain at u-boot and DISP1 power domain is turned on from kernel hdmi and mixer driver on odroid xu3 board. As the result, i can see displaying penguin logo from hdmi. But the problem exists still because it is failed to control on/off of DISP1 power domain more than twice from kernel hdmi and mixer driver.[0] Thanks. [0]: [ 63.477922] Power domain power-domain disable failed [ 63.481416] power-domain: Power-off latency exceeded, new value 10613042 ns [ 63.499805] power-domain: Power-on latency exceeded, new value 886 ns [ 63.506766] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf028 [ 63.514191] Internal error: : 1008 [#1] PREEMPT SMP ARM [ 63.519386] Modules linked in: [ 63.522425] CPU: 0 PID: 1499 Comm: modetest Not tainted 3.18.1-7-g04f5a4b-dirty #13 [ 63.530393] task: eddd3400 ti: edfd task.ti: edfd [ 63.535779] PC is at mixer_dpms+0x1dc/0x704 [ 63.539931] LR is at __mutex_unlock_slowpath+0xa8/0x194 [ 63.545125] pc : [c02c0540]lr : [c04c3eb8]psr: 6013 [ 63.545125] sp : edfd1c98 ip : ee709ef4 fp : ee752aa0 [ 63.556561] r10: c07124b8 r9 : ee752800 r8 : c0712a38 [ 63.561761] r7 : c0712a38 r6 : ee451a80 r5 : ee523a28 r4 : ee523a10 [ 63.568260] r3 : f028 r2 : eddd3400 r1 : 035c035b r0 : ee523a28 [ 63.574760] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 63.581864] Control: 10c5387d Table: 6d81006a DAC: 0015 [ 63.587584] Process modetest (pid: 1499, stack limit = 0xedfd0238) [ 63.593736] Stack: (0xedfd1c98 to 0xedfd2000) [ 63.598070] 1c80: c02c0364 c0766b8c [ 63.606219] 1ca0: edf8d000 c0712a38 ee753c00 ee752800 c07124b8 ee752aa0 c02b5118 [ 63.614365] 1cc0: edf8d900 ee422c08 ee422810 ee753c00 edf8d900 ee752800 ee753c00 c0712a38 [ 63.622510] 1ce0: edf8d000 0001 edf8d900 c02b52c4
Re: [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello, On 2014-12-02 10:59, Sjoerd Simons wrote: Hey Marek, Inki, On Wed, 2014-11-19 at 12:15 +0100, Marek Szyprowski wrote: Hello Everyone, This is another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. The main change from previous version is a rebase onto latest automatic DMA configuration for IOMMU masters patches from Will Deacon. Do you happen to know if anyone is working on iommu/dma-mapping patches for Exynos 5 based on this patchset? I hope to add Exynos5 SYSMMU patches to the next iteration of my patchset, but I doubt it will get into v3.19-rc1. For some background to that question, We (re-)discovered yesterday that the out-of-tree exynos-reference kernel iommu patches are required to get HDMI out working on exynos 5 boards. The current situation in mainline is rather broken, HDMI output without CONFIG_DRM_EXYNOS_IOMMU results in just displaying stripes[0]. While turning on CONFIG_DRM_EXYNOS_IOMMU causes a kernel oops at boot We have observed similar issues with Exynos4 based boards, when LCD0 power domain was turned off and only TV power domain has been powered on. Please check the power domain configuration. Maybe in case of Exynos5 the same issue is caused by the interaction between DISP1 and GSCL domains. 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 v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hey Marek, Inki, On Wed, 2014-11-19 at 12:15 +0100, Marek Szyprowski wrote: Hello Everyone, This is another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. The main change from previous version is a rebase onto latest automatic DMA configuration for IOMMU masters patches from Will Deacon. Do you happen to know if anyone is working on iommu/dma-mapping patches for Exynos 5 based on this patchset? For some background to that question, We (re-)discovered yesterday that the out-of-tree exynos-reference kernel iommu patches are required to get HDMI out working on exynos 5 boards. The current situation in mainline is rather broken, HDMI output without CONFIG_DRM_EXYNOS_IOMMU results in just displaying stripes[0]. While turning on CONFIG_DRM_EXYNOS_IOMMU causes a kernel oops at boot 0: http://people.collabora.com/~sjoerd/14120001.jpg -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Everyone, This is another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. The main change from previous version is a rebase onto latest automatic DMA configuration for IOMMU masters patches from Will Deacon. This patchset demonstrates that Will's proposal works fine and significantly simplifies the driver code. Best regards Marek Szyprowski Samsung RD Institute Poland Changelog: v3: - rebased onto [RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters - added some minor fixes for iommu and dma-mapping frameworks v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/ - rebased onto [RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters patches: http://www.spinics.net/lists/arm-kernel/msg362076.html - changed initialization from bus notifiers to DT related callbacks - removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged - removed support for power domain notifier-based runtime power management - this also will be discussed separately later v1: https://lkml.org/lkml/2014/8/5/183 - initial version, feature complete, completely rewrote integration approach Patch summary: Marek Szyprowski (19): iommu: fix const qualifier in of_iommu_set_ops iommu: fix initialization without 'add_device' callback arm: dma-mapping: add missing check for iommu drm: exynos: detach from default dma-mapping domain on init arm: exynos: pm_domains: add support for devices registered before arch_initcall ARM: dts: exynos4: add sysmmu nodes iommu: exynos: don't read version register on every tlb operation iommu: exynos: remove unused functions iommu: exynos: remove useless spinlock iommu: exynos: refactor function parameters to simplify code iommu: exynos: remove unused functions, part 2 iommu: exynos: remove useless device_add/remove callbacks iommu: exynos: add support for binding more than one sysmmu to master device iommu: exynos: add support for runtime_pm iommu: exynos: rename variables to reflect their purpose iommu: exynos: document internal structures iommu: exynos: remove excessive includes and sort others alphabetically iommu: exynos: init from dt-specific callback instead of initcall iommu: exynos: add callback for initializing devices from device tree arch/arm/boot/dts/exynos4.dtsi| 117 +++ arch/arm/boot/dts/exynos4210.dtsi | 23 ++ arch/arm/boot/dts/exynos4x12.dtsi | 82 + arch/arm/mach-exynos/pm_domains.c | 9 +- arch/arm/mm/dma-mapping.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 490 ++ drivers/iommu/iommu.c | 2 +- include/linux/of_iommu.h | 4 +- 9 files changed, 459 insertions(+), 273 deletions(-) -- 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
