[PATCH 3/3] ARM: SAMSUNG: make local s5p-dev-mfc in mach-exynos

2015-07-24 Thread Kukjin Kim 

This patch moves s5p-dev-mfc from plat-samsung into mach-exynos
because it is used for only exynos no other platforms.

Signed-off-by: Kukjin Kim 
Cc: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/Kconfig | 5 +
 arch/arm/mach-exynos/Makefile| 2 ++
 arch/arm/{plat-samsung => mach-exynos}/s5p-dev-mfc.c | 0
 arch/arm/plat-samsung/Kconfig| 5 -
 arch/arm/plat-samsung/Makefile   | 1 -
 5 files changed, 7 insertions(+), 6 deletions(-)
 rename arch/arm/{plat-samsung => mach-exynos}/s5p-dev-mfc.c (100%)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 81064cd..4c4858c 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -30,6 +30,11 @@ menuconfig ARCH_EXYNOS
 
 if ARCH_EXYNOS
 
+config S5P_DEV_MFC
+   bool
+   help
+ Compile in setup memory (init) code for MFC
+
 config ARCH_EXYNOS3
bool "SAMSUNG EXYNOS3"
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index bcefb54..2f30676 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -23,3 +23,5 @@ AFLAGS_sleep.o
:=-Wa,-march=armv7-a$(plus_sec)
 
 obj-$(CONFIG_EXYNOS5420_MCPM)  += mcpm-exynos.o
 CFLAGS_mcpm-exynos.o   += -march=armv7-a
+
+obj-$(CONFIG_S5P_DEV_MFC)  += s5p-dev-mfc.o
diff --git a/arch/arm/plat-samsung/s5p-dev-mfc.c 
b/arch/arm/mach-exynos/s5p-dev-mfc.c
similarity index 100%
rename from arch/arm/plat-samsung/s5p-dev-mfc.c
rename to arch/arm/mach-exynos/s5p-dev-mfc.c
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 0e1874c..57729b9 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -233,11 +233,6 @@ config SAMSUNG_PM_GPIO
  pinctrl-samsung driver.
 endif
 
-config S5P_DEV_MFC
-   bool
-   help
- Compile in setup memory (init) code for MFC
-
 comment "Power management"
 
 config SAMSUNG_PM_DEBUG
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 624f5db..8c91176 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_SAMSUNG_ATAGS)   += platformdata.o
 
 obj-$(CONFIG_SAMSUNG_ATAGS)+= devs.o
 obj-$(CONFIG_SAMSUNG_ATAGS)+= dev-uart.o
-obj-$(CONFIG_S5P_DEV_MFC)  += s5p-dev-mfc.o
 
 # PM support
 
-- 
2.0.0


--
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 2/3] ARM: SAMSUNG: make local dev-backlight in mach-s3c64xx

2015-07-24 Thread Kukjin Kim 

This patch moves dev-backlight from plat-samsung into mach-s3c64xx
because it is used for only s3c64xx no other platforms.

Signed-off-by: Kukjin Kim 
Cc: Krzysztof Kozlowski 
---
 arch/arm/mach-s3c64xx/Kconfig   | 6 ++
 arch/arm/mach-s3c64xx/Makefile  | 2 ++
 arch/arm/{plat-samsung => mach-s3c64xx}/dev-backlight.c | 3 +--
 arch/arm/plat-samsung/Kconfig   | 6 --
 arch/arm/plat-samsung/Makefile  | 2 --
 5 files changed, 9 insertions(+), 10 deletions(-)
 rename arch/arm/{plat-samsung => mach-s3c64xx}/dev-backlight.c (98%)

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index eff95e9..28c7097 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -34,6 +34,12 @@ config S3C64XX_DEV_ONENAND1
help
  Compile in platform device definition for OneNAND1 controller
 
+config SAMSUNG_DEV_BACKLIGHT
+   bool
+   depends on SAMSUNG_DEV_PWM
+   help
+ Compile in platform device definition LCD backlight with PWM Timer
+
 # platform specific device setup
 
 config S3C64XX_SETUP_I2C0
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 17f4b07..bb233f3 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -40,6 +40,8 @@ obj-$(CONFIG_S3C64XX_SETUP_SDHCI_GPIO)+= 
setup-sdhci-gpio.o
 obj-$(CONFIG_S3C64XX_SETUP_SPI)+= setup-spi.o
 obj-$(CONFIG_S3C64XX_SETUP_USB_PHY) += setup-usb-phy.o
 
+obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT)+= dev-backlight.o
+
 # Machine support
 
 obj-$(CONFIG_MACH_ANW6410) += mach-anw6410.o
diff --git a/arch/arm/plat-samsung/dev-backlight.c 
b/arch/arm/mach-s3c64xx/dev-backlight.c
similarity index 98%
rename from arch/arm/plat-samsung/dev-backlight.c
rename to arch/arm/mach-s3c64xx/dev-backlight.c
index 2157c5b..62f4648 100644
--- a/arch/arm/plat-samsung/dev-backlight.c
+++ b/arch/arm/mach-s3c64xx/dev-backlight.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-samsung/dev-backlight.c
- *
+/*
  * Copyright (c) 2011 Samsung Electronics Co., Ltd.
  *  http://www.samsung.com
  *
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index f115c81..0e1874c 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -217,12 +217,6 @@ config SAMSUNG_DEV_PWM
help
  Compile in platform device definition for PWM Timer
 
-config SAMSUNG_DEV_BACKLIGHT
-   bool
-   depends on SAMSUNG_DEV_PWM
-   help
- Compile in platform device definition LCD backlight with PWM Timer
-
 config S3C24XX_PWM
bool "PWM device support"
select PWM
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index c48a2cc..624f5db 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -22,8 +22,6 @@ obj-$(CONFIG_SAMSUNG_ATAGS)   += devs.o
 obj-$(CONFIG_SAMSUNG_ATAGS)+= dev-uart.o
 obj-$(CONFIG_S5P_DEV_MFC)  += s5p-dev-mfc.o
 
-obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT)+= dev-backlight.o
-
 # PM support
 
 obj-$(CONFIG_PM_SLEEP) += pm-common.o
-- 
2.0.0


--
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 1/3] ARM: SAMSUNG: make local setup-camif in mach-s3c24xx

2015-07-24 Thread Kukjin Kim 

This patch moves setup-camif from plat-samsung into mach-s3c24xx
because it can be used only for s3c24xx no other platforms.

Signed-off-by: Kukjin Kim 
Cc: Krzysztof Kozlowski 
---
 arch/arm/mach-s3c24xx/Kconfig | 5 +
 arch/arm/mach-s3c24xx/Makefile| 1 +
 arch/arm/{plat-samsung => mach-s3c24xx}/setup-camif.c | 0
 arch/arm/plat-samsung/Kconfig | 6 --
 arch/arm/plat-samsung/Makefile| 2 --
 5 files changed, 6 insertions(+), 8 deletions(-)
 rename arch/arm/{plat-samsung => mach-s3c24xx}/setup-camif.c (100%)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 23bec3a..ef68ecb 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -124,6 +124,11 @@ config S3C24XX_PLL
  This also means that the PLL tables for the selected CPU(s) will
  be built which may increase the size of the kernel image.
 
+config S3C_SETUP_CAMIF
+   bool
+   help
+ Compile in common setup code for S3C CAMIF devices
+
 # cpu frequency items common between s3c2410 and s3c2440/s3c2442
 
 config S3C2410_IOTIMING
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 05920c8..8ac2f58 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -99,3 +99,4 @@ obj-$(CONFIG_S3C2416_SETUP_SDHCI_GPIO)+= 
setup-sdhci-gpio.o
 obj-$(CONFIG_S3C2443_SETUP_SPI)+= setup-spi.o
 obj-$(CONFIG_ARCH_S3C24XX) += setup-i2c.o
 obj-$(CONFIG_S3C24XX_SETUP_TS) += setup-ts.o
+obj-$(CONFIG_S3C_SETUP_CAMIF)  += setup-camif.o
diff --git a/arch/arm/plat-samsung/setup-camif.c 
b/arch/arm/mach-s3c24xx/setup-camif.c
similarity index 100%
rename from arch/arm/plat-samsung/setup-camif.c
rename to arch/arm/mach-s3c24xx/setup-camif.c
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index cb8e3d6..f115c81 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -231,18 +231,12 @@ config S3C24XX_PWM
  Support for exporting the PWM timer blocks via the pwm device
  system
 
-config S3C_SETUP_CAMIF
-   bool
-   help
- Compile in common setup code for S3C CAMIF devices
-
 config SAMSUNG_PM_GPIO
bool
default y if GPIO_SAMSUNG && PM
help
  Include legacy GPIO power management code for platforms not using
  pinctrl-samsung driver.
-
 endif
 
 config S5P_DEV_MFC
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 1a29ab1..c48a2cc 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -24,8 +24,6 @@ obj-$(CONFIG_S5P_DEV_MFC) += s5p-dev-mfc.o
 
 obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT)+= dev-backlight.o
 
-obj-$(CONFIG_S3C_SETUP_CAMIF)  += setup-camif.o
-
 # PM support
 
 obj-$(CONFIG_PM_SLEEP) += pm-common.o
-- 
2.0.0


--
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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

2015-07-24 Thread Kukjin Kim 
Krzysztof Kozlowski wrote:
> 
> On 24.07.2015 12:40, Kukjin Kim wrote:
> > On 07/24/15 09:30, Michael Turquette wrote:
> >> Quoting Kukjin Kim (2015-07-07 07:43:31)
> >>> Bartlomiej Zolnierkiewicz wrote:
> >
> > [...]
> >
> > Chanwoo Choi (3):
> >   clk: samsung: exynos3250: Add cpu clock configuration data and 
> > instaniate cpu clock
> >   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
> >   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
> >
> >  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
> >  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
> >  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
> >  arch/arm/mach-exynos/exynos.c   |  1 +
> >  drivers/clk/samsung/clk-exynos3250.c| 32 
> > ++--
> >  include/dt-bindings/clock/exynos3250.h  |  1 +
> >  6 files changed, 55 insertions(+), 2 deletions(-)
> 
>  Reviewed-by: Bartlomiej Zolnierkiewicz 
> 
>  Thank you for working on this.
> 
> >>> +1 Thanks.
> >>>
> >>> Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
> >>> Samsung
> >>> tree together. And if you want, I could provide topic branch for clk tree.
> >>
> >> Kukjin,
> >>
> >> A topic branch would be great.
> >>
> > Sure, BTW it means you did 'ack' on this clk change? If not, please let
> > em know ;-) I'll let you know once the topic branch is ready.
> 
> Dear Kukjin,
> 
> Will you handle this patchset and dependants (ARM: dts: Add CPU cooling
> binding for Exynos3250-based Rinato/Monk board) for v4.3?
> 
You mean Chanwoo's patch. Yes, I'll. Thanks for your gentle reminder.

- Kukjin

--
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: [GIT PULL] ARM: defconfig: Improvements for 4.3

2015-07-24 Thread Kukjin Kim 
Krzysztof Kozlowski
> 
> 2015-07-17 15:51 GMT+09:00 Krzysztof Kozlowski :
> > Dear Kukjin,
> >
> > Few defconfig related changes.
> >
> > Description along with a tag.
> > You can find them also on the lists with my reviewed-by.
> >
> > Best regards,
> > Krzysztof
> 
> Any comments on this pull request?
> 
Will pick them up, thanks.

> Best regards,
> Krzysztof
> 
> 
> >
> >
> > The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
> >
> >   Merge tag 'ext4_for_linus_stable' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> (2015-07-05 16:24:54 -0700)

Please don't make a branch based on some random commit, just use 'rc' as a
basis. Note that usually '-rc1' is used if there is no reason to use another
'rc' because of dependency.

- Kukjin

> >
> > are available in the git repository at:
> >
> >
> >   https://github.com/krzk/linux.git tags/samsung-defconfig-4.3
> >
> > for you to fetch changes up to 5efedc7617df7add295702f21f11dd7e7a67b76e:
> >
> >   ARM: multi_v7_defconfig: Enable max77802 regulator (2015-07-16 15:57:31 
> > +0900)
> >
> > 
> > Defconfig changes around Exynos based boards:
> > 1. Enable sound on Odroid XU3 on exynos defconfig.
> > 2. Enable NTC thermistors for Chromebooks on exynos and multi_v7.
> > 3. Enable main PMIC regulator for Chromebooks on multi_v7.
> > 4. Clean up in multi_v7 - remove old (non-existing) configs.
> >
> > 
> > Anand Moon (1):
> >   ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
> >
> > Javier Martinez Canillas (4):
> >   ARM: multi_v7_defconfig: Remove old Samsung USB PHY configs
> >   ARM: multi_v7_defconfig: Enable NTC Thermistors support
> >   ARM: exynos_defconfig: Enable NTC Thermistors support
> >   ARM: multi_v7_defconfig: Enable max77802 regulator
> >
> >  arch/arm/configs/exynos_defconfig   | 3 +++
> >  arch/arm/configs/multi_v7_defconfig | 5 +++--
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> > --

--
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 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

2015-07-24 Thread Kukjin Kim 
Olof Johansson wrote:
> 
> Hi,
> 
Hi,

> On Fri, Jul 17, 2015 at 11:47 AM, Javier Martinez Canillas
>  wrote:
> > Hello Olof,
> >
> > On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson  wrote:
> >> On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
> >>> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
> >>> > Hello,
> >>> >
> >>> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
> >>> >  wrote:
> >>> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
> >>> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
> >>> >> and 2-channel 32kHz clock outputs.
> >>> >>
> >>> >> Enable the kernel config options to have the drivers for these devices
> >>> >> built as a module.
> >>> >>
> >>> >> Signed-off-by: Javier Martinez Canillas 
> >>> >> 
> >>> >> ---
> >>> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
> >>> >>  1 file changed, 3 insertions(+)
> >>> >>
> >>> >> diff --git a/arch/arm/configs/multi_v7_defconfig 
> >>> >> b/arch/arm/configs/multi_v7_defconfig
> >>> >> index 2349584b6e08..080120fe5580 100644
> >>> >> --- a/arch/arm/configs/multi_v7_defconfig
> >>> >> +++ b/arch/arm/configs/multi_v7_defconfig
> >>> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
> >>> >>  CONFIG_REGULATOR_MAX8907=y
> >>> >>  CONFIG_REGULATOR_MAX8973=y
> >>> >>  CONFIG_REGULATOR_MAX77686=y
> >>> >> +CONFIG_REGULATOR_MAX77802=m
> >>> >
> >>> > I noticed that the version that landed in 4.2-rc1 as commit
> >>> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
> >>> > and clock drivers") doesn't include this symbol. I guess it was caused
> >>> > by a wrong resolved conflict? I'll post a patch to enable the
> >>> > regulator again.
> >>>
> >>> As you can see in mentioned mainline commit Kukjin removed it manually:
> >>> [kg...@kernel.org: removing useless REGULATOR_MAX77802 config]
> >>>
> >>> I wonder why?
> >>
> >> Seems odd. exynos_defconfig still enables it.
> >>
It has been removed when I did 'make savedefconfig' at that time maybe because
of dependency with other configs...

> > Yeah since it is needed for at least the Exynos5420 Peach Pit and
> > Exynos5800 Peach Pi Chromebooks that use this PMIC.
> >
> >> Javier or Krzysztof, please send an incremental fix to enable and I'll pick
> >> it up as a fix.
> >>
> >
> > I already posted an incremental patch [0] and Krzysztof is pushing it
> > through Kukjin for 4.3 [1].
> >
Yes. I'll send it out to arm-soc in this weekend.

> > I guess that's OK and there is no need to add it as a fix for the 4.2
> > -rc cycle since this is not really a regression. I mean, the max77802
> > regulator driver was never enabled for multi_v7_defconfig before.
> 
> Yeah, I came across those emails a little further down. :-) It's all
> good, we'll see it come in later.
> 
Thanks,
Kukjin

--
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: [GIT PULL] Non-critical fixes for v4.3

2015-07-24 Thread Kukjin Kim 
Krzysztof Kozlowski wrote:
> 
> 2015-07-24 20:04 GMT+09:00 Bartlomiej Zolnierkiewicz 
> :
> >
> > Hi,
> >
> > On Friday, July 24, 2015 03:34:55 PM Krzysztof Kozlowski wrote:
> >> Dear Kukjin,
> >>
> >> Previously you did not picked up the fix for cpufreq memory leak.
> >> I am sending it again with respective acks from LKML. Also another
> >> minor improvement in the set.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>
> >> The following changes since commit 
> >> 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
> >>
> >>   Merge tag 'ext4_for_linus_stable' of 
> >> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> (2015-07-05 16:24:54 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2
> >>
> >> for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:
> >>
> >>   video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 
> >> +0900)
> >>
> >> 
> >> Improvements for Exynos boards:
> >> 1. Fix memory leak in cpufreq error path.
> >> 2. Constify platform_device_id in video/fbdev/s3c-fb.
> >>
> >> 
> >> Krzysztof Kozlowski (1):
> >>   video: fbdev: s3c-fb: Constify platform_device_id
> >>
> >> Shailendra Verma (1):
> >>   cpufreq: exynos: Fix for memory leak in case SOC name does not match
> >
> > I would suggest merging this fix in v4.2 not v4.3:
> >
> > - it is obvious and touches only error paths
> 
> Indeed, good point, thanks for pointing this. Although these are not
> regressions for issues introduced in current release but they are are
> non-intrusive.
> 
> Kukjin, do you agree? Can you pull them for second round of v4.2 fixes (not 
> 4.3)
> 
Agreed. OK.

> > - (hopefully) in v4.3 the exynos-cpufreq driver will be completely
> >   replaced by using cpufreq-dt for Exynos platforms (thus there will be
> >   no benefits of having this fix in v4.3 but there will be potential
> >   risk of merge conflicts due to exynos-cpufreq driver removal)
> >
> 
> We'll see... The Exynos 4x12 requires OPP patches. Are these ready for 4.3?
> 
I think, if any conflicts based on fixes during -rc, can be handled by
maintainer.

Thanks,
Kukjin

--
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] thermal: consistently use int for temperatures

2015-07-24 Thread Guenter Roeck 

On 07/24/2015 03:11 PM, Pavel Machek wrote:

On Fri 2015-07-24 06:59:26, Guenter Roeck wrote:

On 07/23/2015 11:29 PM, Sascha Hauer wrote:

On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:

On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:

The thermal code uses int, long and unsigned long for temperatures
in different places.

Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.

'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.


Can we do something like

typedef millicelsius_t int;

...to document the units?


I am not very fond of typedefs and I am not sure this adds any value. I
could change it when more people ask for it, but I just sent the new
version without this.



I thought we are supposed to not introduce new typedefs anyway.


You are not supposed to typedef struct, but typedef for millicelsius_t
would be ok. And it is your only chance if you want people to pay
attention. If you make it int, someone will pass it to long or
something else..


Seems to me that would be just lazyness. The same person might use 'long'
even if millicelsius_t is defined. A typedef doesn't preclude people
from ignoring it.

Guenter

--
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] thermal: consistently use int for temperatures

2015-07-24 Thread Pavel Machek 
On Fri 2015-07-24 06:59:26, Guenter Roeck wrote:
> On 07/23/2015 11:29 PM, Sascha Hauer wrote:
> >On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:
> >>On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:
> >>>The thermal code uses int, long and unsigned long for temperatures
> >>>in different places.
> >>>
> >>>Using an unsigned type limits the thermal framework to positive
> >>>temperatures without need. Also several drivers currently will report
> >>>temperatures near UINT_MAX for temperatures below 0°C. This will probably
> >>>immediately shut the machine down due to overtemperature if started below
> >>>0°C.
> >>>
> >>>'long' is 64bit on several architectures. This is not needed since INT_MAX 
> >>>°mC
> >>>is above the melting point of all known materials.
> >>
> >>Can we do something like
> >>
> >>typedef millicelsius_t int;
> >>
> >>...to document the units?
> >
> >I am not very fond of typedefs and I am not sure this adds any value. I
> >could change it when more people ask for it, but I just sent the new
> >version without this.
> >
> 
> I thought we are supposed to not introduce new typedefs anyway.

You are not supposed to typedef struct, but typedef for millicelsius_t
would be ok. And it is your only chance if you want people to pay
attention. If you make it int, someone will pass it to long or
something else..
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] clk: s2mps11: Use kcalloc instead of kzalloc for array allocation

2015-07-24 Thread Stephen Boyd 
On 07/22, Vaibhav Hiremath wrote:
> This patch cleans up the driver for,
> 
>   - Use devm_kcalloc varient instead of devm_kzalloc for array
> allocation.
>   - clk_prepare/unprepare, remove "ret" variable as it is not required
>   - use __exit for cleanup function
> 
> As I am referring this driver as a reference for my 88pm800 clk driver,
> applying same changes here as well.
> 
> Signed-off-by: Vaibhav Hiremath 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

2015-07-24 Thread Michael Turquette 
Quoting Kukjin Kim (2015-07-23 21:08:27)
> On 07/24/15 12:40, Kukjin Kim wrote:
> > On 07/24/15 09:30, Michael Turquette wrote:
> >> Quoting Kukjin Kim (2015-07-07 07:43:31)
> >>> Bartlomiej Zolnierkiewicz wrote:
> > 
> > [...]
> > 
> > Chanwoo Choi (3):
> >   clk: samsung: exynos3250: Add cpu clock configuration data and 
> > instaniate cpu clock
> >   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
> >   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
> >
> >  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
> >  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
> >  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
> >  arch/arm/mach-exynos/exynos.c   |  1 +
> >  drivers/clk/samsung/clk-exynos3250.c| 32 
> > ++--
> >  include/dt-bindings/clock/exynos3250.h  |  1 +
> >  6 files changed, 55 insertions(+), 2 deletions(-)
> 
>  Reviewed-by: Bartlomiej Zolnierkiewicz 
> 
>  Thank you for working on this.
> 
> >>> +1 Thanks.
> >>>
> >>> Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
> >>> Samsung
> >>> tree together. And if you want, I could provide topic branch for clk tree.
> >>
> >> Kukjin,
> >>
> >> A topic branch would be great.
> >>
> > Sure, BTW it means you did 'ack' on this clk change? If not, please let
> > em know ;-) I'll let you know once the topic branch is ready.
> > 
> Mike,
> 
> Done, the topic branch 'v4.3-topic/clk-samsung' in samsung tree is for
> your clk tree.

Thanks!

Mike

> 
> Thanks,
> Kukjin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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] thermal: consistently use int for temperatures

2015-07-24 Thread Guenter Roeck 

On 07/23/2015 11:29 PM, Sascha Hauer wrote:

On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:

On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:

The thermal code uses int, long and unsigned long for temperatures
in different places.

Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.

'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.


Can we do something like

typedef millicelsius_t int;

...to document the units?


I am not very fond of typedefs and I am not sure this adds any value. I
could change it when more people ask for it, but I just sent the new
version without this.



I thought we are supposed to not introduce new typedefs anyway.

Guenter


--
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: [GIT PULL] Non-critical fixes for v4.3

2015-07-24 Thread Krzysztof Kozlowski 
2015-07-24 20:04 GMT+09:00 Bartlomiej Zolnierkiewicz :
>
> Hi,
>
> On Friday, July 24, 2015 03:34:55 PM Krzysztof Kozlowski wrote:
>> Dear Kukjin,
>>
>> Previously you did not picked up the fix for cpufreq memory leak.
>> I am sending it again with respective acks from LKML. Also another
>> minor improvement in the set.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
>>
>>   Merge tag 'ext4_for_linus_stable' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 
>> 16:24:54 -0700)
>>
>> are available in the git repository at:
>>
>>
>>   https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2
>>
>> for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:
>>
>>   video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 
>> +0900)
>>
>> 
>> Improvements for Exynos boards:
>> 1. Fix memory leak in cpufreq error path.
>> 2. Constify platform_device_id in video/fbdev/s3c-fb.
>>
>> 
>> Krzysztof Kozlowski (1):
>>   video: fbdev: s3c-fb: Constify platform_device_id
>>
>> Shailendra Verma (1):
>>   cpufreq: exynos: Fix for memory leak in case SOC name does not match
>
> I would suggest merging this fix in v4.2 not v4.3:
>
> - it is obvious and touches only error paths

Indeed, good point, thanks for pointing this. Although these are not
regressions for issues introduced in current release but they are are
non-intrusive.

Kukjin, do you agree? Can you pull them for second round of v4.2 fixes (not 4.3)

>
> - (hopefully) in v4.3 the exynos-cpufreq driver will be completely
>   replaced by using cpufreq-dt for Exynos platforms (thus there will be
>   no benefits of having this fix in v4.3 but there will be potential
>   risk of merge conflicts due to exynos-cpufreq driver removal)
>

We'll see... The Exynos 4x12 requires OPP patches. Are these ready for 4.3?

Best regards,
Krzysztof
--
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 08/11] MTD: m25p80: Add option to limit SPI transfer size.

2015-07-24 Thread Michal Suchanek 
On 24 July 2015 at 10:34, Marek Vasut  wrote:
> On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wrote:
>
> Hi!
>
> [...]
>
>> >>> It's probably slower to set up DMA for 2-byte commands but it might
>> >>> work nonetheless.
>> >>
>> >> It is, the overhead will be considerable. It might help the stability
>> >> though. I'm really looking forward to the results!
>> >
>> > Hello,
>> >
>> > this does not quite work.
>> >
>> > My test with spidev:
>> >
>> > # ./spinor /dev/spidev1.0
>> > Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
>> > Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8
>> > Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
>> >
>> > I receive correct ID but spi-nor complains it does not know ID 00 c8 60.
>> > IIRC garbage should be sent only at the time command is transferred so
>> > only one byte of garbage should be received. Also the garbage tends to
>> > be the last state of the data output - all 0 or all 1.
>> > So it seems using DMA for all transfers including 1-byte commands
>> > results in (some?) received data getting an extra 00 prefix.
>> >
>> >
>> > I also managed to lock up the controller completely since there is
>> > some error passing the SPI speed somewhere :(
>> >
>> > [ 1352.977530] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -->
>> > 0 [ 1352.977540] spidev spi1.0: spi mode 0
>> > [ 1352.977576] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -->
>> > 0 [ 1352.977582] spidev spi1.0: msb first
>> > [ 1352.977614] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -->
>> > 0 [ 1352.977620] spidev spi1.0: 0 bits per word
>> > [ 1352.977652] spidev spi1.0: setup mode 0, 8 bits/w, 2690588672 Hz max
>> > --> 0 [ 1352.977726] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
>> > src_clk sclk_spi1 mode bpw 8
>> > [ 1352.977753] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: xfer
>> > bpw 8 speed -1604378624
>> > [ 1352.977760] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
>> > src_clk sclk_spi1 mode bpw 8
>> > [ 1352.977781] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: using
>> > dma [ 1352.977797] dma-pl330 121b.pdma: setting up request on thread
>> > 1
>>
>> Hmm, on a second thought it probably works as expected more or less.
>>
>> The nonsensical value was passed from application and there is no
>> guard against that.
>>
>> Since I don't do PIO the controller remains locked up indefinitely.
>
> I have to admit, I don't quite understand the above. I also don't quite know
> what your spidev test does.

It does a full duplex transfer sending what is printed and printing
what is received.

> Can you possibly just bind a regular SPI NOR driver
> and run mtdtests to see if it is stable ?

I can if I use PIO for short transfers. Using DMA for all transfers
results in the received data prefixed with 00 so the NOR flash
identification fails. Admittedly I have no idea what the flash memory
actually contains so if all DMA reads were always prefixed with 00 I
could not tell. I vaguely recall reading the whole content and parsing
the

I can probably make the minimum length for DMA configurable so I can
fall back to PIO when the controler locks up. It seems setting up a
PIO transfer makes it work again.

Thanks

Michal
--
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: [GIT PULL] Non-critical fixes for v4.3

2015-07-24 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Friday, July 24, 2015 03:34:55 PM Krzysztof Kozlowski wrote:
> Dear Kukjin,
> 
> Previously you did not picked up the fix for cpufreq memory leak.
> I am sending it again with respective acks from LKML. Also another
> minor improvement in the set.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
> 
>   Merge tag 'ext4_for_linus_stable' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 16:24:54 
> -0700)
> 
> are available in the git repository at:
> 
> 
>   https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2
> 
> for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:
> 
>   video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 
> +0900)
> 
> 
> Improvements for Exynos boards:
> 1. Fix memory leak in cpufreq error path.
> 2. Constify platform_device_id in video/fbdev/s3c-fb.
> 
> 
> Krzysztof Kozlowski (1):
>   video: fbdev: s3c-fb: Constify platform_device_id
> 
> Shailendra Verma (1):
>   cpufreq: exynos: Fix for memory leak in case SOC name does not match

I would suggest merging this fix in v4.2 not v4.3:

- it is obvious and touches only error paths

- (hopefully) in v4.3 the exynos-cpufreq driver will be completely
  replaced by using cpufreq-dt for Exynos platforms (thus there will be
  no benefits of having this fix in v4.3 but there will be potential
  risk of merge conflicts due to exynos-cpufreq driver removal)

>  drivers/cpufreq/exynos-cpufreq.c | 6 --
>  drivers/video/fbdev/s3c-fb.c | 2 +-
>  2 files changed, 5 insertions(+), 3 deletions(-)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

--
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 08/11] MTD: m25p80: Add option to limit SPI transfer size.

2015-07-24 Thread Marek Vasut 
On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wrote:

Hi!

[...]

> >>> It's probably slower to set up DMA for 2-byte commands but it might
> >>> work nonetheless.
> >> 
> >> It is, the overhead will be considerable. It might help the stability
> >> though. I'm really looking forward to the results!
> > 
> > Hello,
> > 
> > this does not quite work.
> > 
> > My test with spidev:
> > 
> > # ./spinor /dev/spidev1.0
> > Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
> > Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8
> > Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
> > 
> > I receive correct ID but spi-nor complains it does not know ID 00 c8 60.
> > IIRC garbage should be sent only at the time command is transferred so
> > only one byte of garbage should be received. Also the garbage tends to
> > be the last state of the data output - all 0 or all 1.
> > So it seems using DMA for all transfers including 1-byte commands
> > results in (some?) received data getting an extra 00 prefix.
> > 
> > 
> > I also managed to lock up the controller completely since there is
> > some error passing the SPI speed somewhere :(
> > 
> > [ 1352.977530] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -->
> > 0 [ 1352.977540] spidev spi1.0: spi mode 0
> > [ 1352.977576] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -->
> > 0 [ 1352.977582] spidev spi1.0: msb first
> > [ 1352.977614] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -->
> > 0 [ 1352.977620] spidev spi1.0: 0 bits per word
> > [ 1352.977652] spidev spi1.0: setup mode 0, 8 bits/w, 2690588672 Hz max
> > --> 0 [ 1352.977726] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
> > src_clk sclk_spi1 mode bpw 8
> > [ 1352.977753] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: xfer
> > bpw 8 speed -1604378624
> > [ 1352.977760] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
> > src_clk sclk_spi1 mode bpw 8
> > [ 1352.977781] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: using
> > dma [ 1352.977797] dma-pl330 121b.pdma: setting up request on thread
> > 1
> 
> Hmm, on a second thought it probably works as expected more or less.
> 
> The nonsensical value was passed from application and there is no
> guard against that.
> 
> Since I don't do PIO the controller remains locked up indefinitely.

I have to admit, I don't quite understand the above. I also don't quite know
what your spidev test does. Can you possibly just bind a regular SPI NOR driver 
and run mtdtests to see if it is stable ?
--
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: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

2015-07-24 Thread Inki Dae 
On 2015년 07월 22일 19:08, Inki Dae wrote:
> On 2015년 07월 22일 17:42, Joonyoung Shim wrote:
>> On 07/22/2015 05:22 PM, Inki Dae wrote:
>>> On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
 On 07/22/2015 01:55 PM, Inki Dae wrote:
> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>
>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>> commit d80167b85024982c5f18d0481a5c248100360118
>>> Author: Joonyoung Shim 
>>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>>
>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>
>>> Already drm_iommu_attach_device checks whether support iommu 
>>> internally.
>>> It should clear channels always regardless iommu support. We didn't 
>>> know
>>> because we can detect the problem when iommu is enabled, so we don't
>>> have to use drm_iommu_attach_device_if_possible and then we can 
>>> remove
>>> drm_iommu_attach_device_if_possible and clear_channels function 
>>> pointer.
>>>
>>> Signed-off-by: Joonyoung Shim 
>>> Tested-by: Marek Szyprowski 
>>> Signed-off-by: Inki Dae 
>>>
>>> :04 04 83379efbf4960f58d680371628ec04387935bd53
>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>
>>>
>>> Config: exynos
>>> Boot log from Odroid XU3-Lite attached.
>>>
>>> Any hints or ideas?
>>
>> The point that hangs is when accesses fimd register in
>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>
>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>> clock.
>>
>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>> support. Any ideas?
>
> I think bootloader should have enabled ACLK_200_DISP1 clock and also
> device driver should enable all relevant clocks before the device
> accesses its own registers.
>
> Best way would be that the clock is enabled by common clock framework
> but it seems there is no anything that the clock framework can do it. So
> I think what we have to do is to add the clock support to device tree.

 It's not easy problem to me. Should we add which clock? I think we
 cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
 hierarchy, right? Then we should control gate clocks, but we have not
 controlled any gate clocks using BTS_ prefix.

 The clock hierarchy from Exynos5422 user manual,
 ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
HDMI PHY
MIC1
DSIM1
DPTX LINK
MDNIE1
SYSMMU_MIXER
SYSMMU_FIMD1_M0
SYSMMU_FIMD1_M1
BTS_TVM0
BTS_TVM1
BTS_FIMD1_M0
BTS_FIMD1_M1

 Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
 just it should be controlled by connector drivers, e.g. dsi, dp because
 fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
 about this, just i thought that Exynos5 SoCs don't have any gpios for
 dpi, so they cannot use dpi, right?).

 It needs to probe connector driver like dsi or dp earlier than fimd and
 fimd_bind function should return error if connector driver like dsi or
 dp was not probed. This is also not easy to me.
>>>
>>> In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
>>> should be enabled. So I guess the problem would be due to below line of
>>> clk-exynos5420.c,
>>>
>>> GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0),
>>>
>>> Can you check it again after modifying it like below?,
>>> GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0),
>>
>> No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
> 
> Yes, I checked just it through exynos5420 and exynos5422 document. I
> just guessed. So do you mean that aclk200_disp1 affects FIMD controller
> even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very
> strange.

Root problem was because it had tried to access FIMD registers before
crtc and connector driver binding is completed.

ACLK200_DISP1 will be enabled by connector driver - MIPI-DSI - of FIMD
like above clock hierarchy commented by Joonyoung.

So all we have to do would be,
1. to